[GRASS-dev] [GRASS-SVN] r60713 - in grass/trunk: include lib/gis

[Sören Gebbert]

Hi,
just to add my 2 cent:

2014-06-06 16:35 GMT+02:00 Huidae Cho <grass4u at gmail.com>:
> All,
>
> I can feel strong frictions between Glynn and some of us. I was shocked when
> Glynn simply broke 7.1 on Windows. From my experience, I can see that he is
> more of a purist and doesn't like workarounds and hacks. I totally

IMHO that has nothing to do with purism or with liking or not liking
workarounds and hacks. It is a decision made on common sense to keep
complex code bases maintainable.

> understand his points, but just because there is an issue doesn't make it
> any more acceptable to break other people's solutions that have been proved
> to work for a long time, *without* providing his own better solution. I
> don't mind any existing code being replaced by more correct solutions, but
> simply reverting it and breaking the whole system is not acceptable at all.

Actually, hacks and workarounds shouldn't be committed in the first
place if the problem isn't fully understand.
Usually the workaround/hack will be accepted as a working solution (if
it works for several people) and nobody will try again to implement a
reasonable solution that actually fix the problem. The danger is that
such an approach leads to new errors that are even more difficult to
fix and nobody is aware anymore what the root of the problem was.
So the pragmatic solution is: "Don't allow workarounds/hacks even if
it breaks the software to force developers to implement reasonable
solutions".

> I think that the whole system *should* always be in a working condition no
> matter what "magic" was used in the code. If that magic is hackery, dirty or
> whatever, it has to be *fixed*, not just removed. If he submitted a part of
> his solution in the middle, it's not acceptable again because he should have
> submitted a whole solution to make sure the system is at least not worse
> than before.
> Now, regarding my "exclusive" hack or implementations without any
> discussion, first, I apologize for not discussing this issue before
> submitting my implementations. Putting aside who's right and who's wrong,
> it's very frustrating and demotivating to see hours of effort is gone in
> seconds of typing with no better solutions coming in. As Martin said, I saw
> a lot of core implementations from Glynn without clear discussions and he
> often insists that he's right and he even said that he would revert any
> changes he doesn't like. Looks like, any core changes have to be approved by
> Glynn after serious discussions with him? He may be one of the best
> developers in the team, but does it give him "exclusive" rights to revert or
> break things with no solutions? I don't know.

Why should Glynn provide always a solution when he tries to keep the
GRASS code in libgis and libraster in a maintainable state by
reverting bad solutions? You can see it as a hint to provide a better
solution.
It is sometimes quite undiplomatic to revert changes by simply stating
"this doesn't solve the problem". But the correct approach to apply
changes would be to commit a change request in trac wiki so that the
changes/patches/code can be discussed in the first place. I hope that
all of us will consider this approach. However, since i am the lead
developer of the temporal framework i will not discuss all changes
that i will make in the core of the framework. Simply because i am
(hopefully) aware of what i am doing and i am the conceptual mind
behind it,  feeling fully responsible for it. I will not do this with
any other part of GRASS (except temporal modules and maybe the gpde
and voxel libraries, since i feel responsibility for them as well). I
think the same is true for Glynn and many other developers.

I guess that Martin Landa and Markus Metz will revert any
hack/workaround that i will implement in the vector library without
discussion if they see that my code is a bad solution (at least i hope
they will do it). Well i can say in this case "If you don't agree to
my solution then provide a better one" but here i miss the point that
i actually don't understand what i was doing wrong.

> Maybe, I was just simply wrong because I didn't have any discussion before
> submitting the "exclusive" implementations and don't have rights to complain
> about the revert. Now, I'm not sure what to discuss and what not to. I even
> posted a couple of messages calling for a discussion, but they got no
> attention at all. This kind of experience just demotivates and pushes me
> away from real implementations and keeps me fixing small bugs and typos here
> and there.

I think this is the usual friction in open source software
development. Please don't feel demotivated, working with people
together from different parts of the world with different cultural
backgrounds is always challenging. It is sometimes hard to fully
understand the motivation/opinion of each other.
But it think the GRASS developers are doing very well, i didn't saw
here "real" flame wars that are common in other open source projects
(Linux Kernel ...). Everyone is in my opinion (opinion with strong
German cultural background) really polite and thoughtful. :)

> Last, I have a strong feeling that we really need defined procedures that we
> can follow when making changes to the core and even individual modules.
> Otherwise, this same situation will arise again and again.

I fully agree.
Making change requests including code patches in the trac wiki for
parts of GRASS that are not directly maintained by the requester is
maybe a reasonable approach?

Best regards
Soeren

>
> Best,
> Huidae
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev