How are [MAINTAINER] patches handled and why aren't PRs FIFO?
freebsdml at marino.st
Wed Apr 27 18:53:51 UTC 2011
On 4/27/2011 4:12 PM, Jerry wrote:
> On Wed, 27 Apr 2011 15:48:36 +0200
> Erik Trulsson<ertr1013 at student.uu.se> articulated:
>> On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote:
>> Very simple. A particular committer during one particular period of
>> time maybe only 45 minutes of free time to spend on handling PRs.
>> If the committer estimates that one large submitted PR would take at
>> least two hours to review, test, and commit, while another, smaller,
>> PR would only take 30 minutes to handle.
>> Then the committer in question would have two choices: Don't handle
>> either submission, or handling the smaller submission, while skipping
>> the large one and hoping that some other committer with more free time
>> will pick up that one.
>> I see no reason to prefer the first of these choices.
> If the committer cannot finish the project in their allotted time
> frame they simply stop and pick up from that point in their next
> session. I have literally hundreds of projects that I cannot complete
> in one day; however, I don't simply shrug them off. If I did nothing
> would ever get accomplished, or at best only the easiest assignments.
> One of the basic fallacies in your analysis is that someone else will
> pick up the slack. Unfortunately, our society has become over run by
> those who are always ready to blame others or expect others to do our
> job for us. Quite honestly, I find that pathetic.
I seemed to have kicked off quite a dialog! First of all, I want to
thank Frederic Culot for committing my patch today.
Basically, I'm in complete agreement with Jerry with regards to FIFO.
The proposal was made that given a short amount a time, a committer
should choose the simpler project and bypass the first one simply based
on time/complexity. I couldn't disagree more. As soon as it's possible
to skip valid ports, then that's what is going to happen. If people can
physically cherry-pick, then they'll exercise their ability to do that
and immediately you sink into the current situation.
Unfortunately, a FIFO setup requires that all the requests go through a
single entity who then assigns them. I don't really buy the
joe-the-font-guy with mary-the-network-gal mismatch. Nobody said the
PRs have to be assigned as round-robin. And then that changes the
dynamic since the PR is assigned rather than chosen. This entity can't
just assign a PR without knowing the committer's timeline, availability,
etc, so there are clearly implementation details to work out.
Maybe a compromise would be to keep the current system in place with the
addition of having somebody do these assignments if the new PRs are
unclaimed for more than 3-7 days. Yes, it means a new job for someone,
but if one believes that FIFO is the fair and respectful approach, the
extra effort should be worth it.
More information about the freebsd-ports