forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Things to enhance as committer
Date Sun, 04 Sep 2005 00:07:24 GMT
Thorsten Scherler wrote:
> It seems we prefer to kill a momentum that arises (and that somebody had
> a hard time to start) by starting a debate on principles. Latest example
> is the lenya forrest integration momentum (which should be the base for
> DOCO). What happend to the "Commit-then-review" method for
> decision-making?

I have a great deal of sympathy with this. I also recognise there should 
be a balance between making major contributions and ensuring those 
contributions are well thought through. This is a difficult thing to 
balance. We do get it wrong sometimes.

My response here is not intended as an argument, but an attempt to add a 
little balance to this particular position, as I said, I have much 
sympathy with Thorstens intentions with this mail and add my support to 
that intention.

> We say one step at a time, which is perfectly alright, but still we need
> to do the first step. If somebody offers to do the first step then try
> to lead his way and not building barriers.

Building barriers is certainly the *wrong* balance.

> It seems we (committers) open issues that could have been fixed at the
> same time as we opening them. Just go ahead and fix it and save the
> resources of the ASF and the project (every issue produces overhead:
> mail, time, ...).

Speaking personally I know I open issues that I see whilst working on 
other parts of code. When I'm working on one job I cannot start fixing 
things that are not directly related to that job. Creating an issue is a 
way of logging the issue so it is not forgotten.

I suspect the same is true for everyone. To fix an issue requires 
testing (see the bug I introduced in views with my *.source.xml patch 
that I did for a specific job but clearly did not test enough).

> Lets please live again our commit-then-review method for
> decision-making.

(now I am speaking personally...)

If I'm not sure of the best way to implement something I will always ask 
questions first. For major changes I will *always* ask questions first, 
I don't like doing something twice and I want to ensure my contributions 
are the right thing to do.

For smaller contributions, yes, I agree, commit-then-review.


View raw message