[Freeciv-Dev] CVS management [was [Patch] Add BOOL_VAL around ANDs]

[Daniel Sjölie <deepone@xxxxxxxxxx>]

On 2002-02-13 11:35:41, Petr Baudis wrote:
> 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 ;-)

Perhaps if you don't read every mail you don't read mails with subjects
about adding bool stuff...

I certainly stand by what I've said before and I do like it better
now... If something is commited to CVS that shouldn't have been it will
be noticed and it will be discussed and dealt with if necessary... I
don't think that's an argument against a "more chaotic" development but
_for_ it... So just go ahead and commit when you feel it's ready - I
trust the maintainers to take the beating and fix it if something
breaks... :)

> > 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.

But not for design changes?

> > 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 ;).

Amen, brother! ;)

> > 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 :).

I think it's always true... The mess can be cleaned up even if the
changes are conceptual and if you make the change you can be sure to
either get objections and have to fix it or get no objections and then
all is well... If you don't notice a change it doesn't hurt you... If
you find it hurts you later you can always make a patch to change it
back if you get support...

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)