On Thu, Oct 13, 2011 at 8:02 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
> I like this concept, but I am curious about something.
> Ultimately a committer needs to vet the patch and apply it.
In most of the Hadoop projects, we have a review-then-commit policy.
So, even if you're a committer, another committer needs to vet the
patch and provide a "+1" before the patch author can commit it.
Apparently this is abnormal for the ASF, though - most projects in the
foundation allow committers to commit without review, assuming that
another commit can ask for a revert if there is a big problem.
> projects you have seen use this how does that happen? Does the
> contributor owning the ticket informally work w/ a committer? Does
> this happen organically, or did they setup something more structured?
It's pretty organic. The only structure is that there are some saved
links to the "patch available queue". Once the contributor feels the
patch is ready, they hit "Submit patch", which moves it to the PA
state. Then, hopefully, committers will triage this queue regularly to
review any items with available patches. If the patch looks good, it
gets committed. Otherwise, they will provide review feedback and move
it back to "Open" state.
The above is the theory. In some projects, the PA queue grows very
long. Here's an interesting graph:
> In these projects, is it the contributor's responsibility to ensure
> the tickets assigned to them do not languish because of a lack of
> attention from a committer?
More experienced contributors (eg those who are working on the project
on a regular basis) tend to know who the expert is for each area of
the code, and often do off-list pings to solicit a review. Users who
happen to fix a small bug are often less tenacious - eg they just post
a patch and disappear, hoping it will eventually get reviewed and
committed. Hopefully any patch that a user contributes is a real fix
for a real problem, and worth the time to look over. Sometimes there
are patches uploaded that are just poor quality or really low
priority, and those tend to languish longer than others.
Software Engineer, Cloudera