[Freeciv-Dev] Re: [Patch] Add BOOL_VAL around ANDs

[Petr Baudis <pasky@xxxxxxxxxxx>]

Dear diary, on Wed, Feb 13, 2002 at 05:22:59AM CET, I got a letter,
where Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> told me, that...
> On Tue, 12 Feb 2002, Petr Baudis wrote:
> > It appears to me that the development is getting more chaotic now.. 
> > (compared
> > to situation in November/December) It looks there's not even clear consensus
> > between the maintainers what're the current goals and what should we do now;
> 
> Funny how things change :-) Back then people were saying the maintainers
> were stagnating and that in order to increase output to "save" Freeciv we
> should turn into a Mozilla like anarchy. Now people think its chaotic. How
> much things change in a couple of months ;-)

I said my opinion changed, but I'm still not *so* unhappy with this whole
system but only with certain its symptoms which appeared now.

> > like vasco commiting recently the patches in order to make g++ happy, or 
> > like
> > you saying that cleanups are low-priority and we should focus on finishing
> > features for 1.12.1 now (before about a month) (this apparently changed
> > mysteriously and without any notice i cought; and I believe your previous
> > opinion was much more correct).
> 
> Its only natural. People seldom have the same goals. At most they share a
> common sub-set of goals. As long as these goals don't conflict with each
> other, everything works well.

In fact, yes.

> As of late i've been making debugging, speed improvements and minor
> cleanups. This goes hand in hand with perceived user desires for better
> performance and more stability. The cleanups done recently by the
> maintainers involve no changes in outputed code. So they add (hopefully) no
> new bugs. Raimar's patches in particular have enabled the squashing of some
> insidious bugs in the code.

The cleanups really don't matter for the users, but they matter a lot for the
developers. They are bringing precedents and new rules to coding style of
freeciv, and in fact developers are forced to live with them to the end of
their days. Thus I believe they should be discussed, and IMHO even more that
patches which just adds some features or so; if there are bugs there, you can
always fix them.

> There is still time for one or two major features to be commited before
> release, as long as there remains some time for debugging.

Hmm.. this means that there's already approx date of 1.12.1's release?

> > IMHO we just need to review the patches and have some time for that (like 2
> > days at least - after all, we don't hurry anywhere, do we?).  I had a little
> > different opinion before two months, but now it looks like this doesn't work
> > well; like the patches which got commited too soon after posted for review 
> > or
> > which didn't posted for review at all (like the pointers stuff or all [or
> > almost all] vasco's patches). It seems we have two or three (raimar, vasco 
> > and
> 
> Which pointer stuff? Excuse me for my swiss cheese brain <@:-)

== NULL here, != NULL there :) hopefully reverted later.

> And yes, i agree, i should post stuff to freeciv-dev more. Just don't ask
> me to post 1 line patches :-)

They should be hopefully ok, if obvious bugfixes ;).

> > mike [he is at least interested in my job ;]) active maintainers now, so 
> > what
> > about enforcing the policy that maintainer should never commit own patches? 
> >  I
> > think we are getting into trouble now with this 'cleanups', changing too 
> > much
> > things too fast.
> 
> Well there are commits and commits. Commits which don't change the outputed
> code are no problem. The problem is stuff that changes the inner workings
> of Freeciv. Parts that would break everything if they have a bug.

That doesn't mean they will change the outputed code. Changing of outputed code
is IMHO irrelevant here. I would classify commits to bugfixes, features
additions, and design changes. And I would probably put a lot of ongoing
cleanup stuff into the design changes class.

> I believe useless red tape is a waste of neuron cycles. Having other
> people commit someone else's patches doesn't seem warranted to me at this
> time. The important factors to me are:
> 
> 1) have you read & tested the code with a compile and some run cycles?
> 2) is it a big/messy patch? then post it and await for discussion.
> 3) be commited to what you do. if you introduce something into CVS you are
>    responsible for it. if it still breaks for some reason, either clean it
>    up immediatly before anything else or remove it from CVS.

I agree with those for bugfixes and features.

> I have tried to uphold these principles. When i introduced the impr_gen
> patch which caused memory corruption (my fault not Ben's) i knew it should
> break despite my testing (call it programmer's instinct) and so i commited
> it at a Thursday. Why? Because of the weekend that's why. This way i
> wouldn't disrupt the schedule of the other developers. I fixed the bugs
> in 3 days. Friday, Saturday and Sunday. Do you honestly believe that i
> could have achieved the same results in 3 days using the regular process?
> Of course this shouldn't be done as standard practice, but i think certain
> features warrant this practice.

I even like this pracitce. No reason why not to commit new features
not-completely-debugged, all this people using CVS will catch the bugs for you
soon :) (this doesn't mean NO testing by you at all!). After all, CVS is
supposed to be unstable ;).

> The question is not if you will do mistakes. That always has a chance of
> happening. The question is: will you clean the mess up afterwards?

Yes. If the changes aren't conceptual :).

-- 

                                Petr "Pasky" Baudis

* UN*X programmer && admin         * IPv6 guy (XS26 co-coordinator)
* elinks maintainer                * FreeCiv AI hacker
* IRCnet operator
.
I love deadlines.
I love the whooshing sound they make as they fly by.
-- Douglas Adams.
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/