Dennis Kubes wrote:
So I have been talking with some of the other committers and I wanted to
layout a suggestion for standardizing some of the nutch committer
workflow processes in the hope of speeding up nutch development.
The first one I was hoping to tackle is time to commit. At least for me
it has been hard to know when to commit something, especially when it
was trivial or no one commented on the issue. Here is what is being
proposed:
Trivial changes = immediate, this at the discretion of the committers
Minor changes = 24 hours from latest patch or 1 or more +1 from committers
Major and blocker changes = 4 days from latest patch or 2 or more +1
from committers
This way if an issue has been active for some time but no one has taken
a look at it, and it has passed all unit tests, then we can go ahead and
commit it. Also this should allow more of the smaller changes to be
handled faster.
So these of course are just some suggestions would love to hear from
others in the community. What I think would be best is to come to a
consensus on this and then have a wiki page describing this and other
processes for committers.
I agree with the overall plan - we need to speed up the process and
release the committers from worrying too much whether a patch is "ripe"
enough to commit it.
Though I think that in case of minor changes, the 24 hours period is too
short. By definition, since they are not trivial then it means they
could use a peer review. Sometimes it's difficult to get a patch
reviewed within 24 hours, and in the coding enthusiasm it's easy to be
too quick ... I'd say 48 hours if no review, or less if the patch is
reviewed and gets +1.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
