How are [MAINTAINER] patches handled and why aren't PRs FIFO?

John Marino freebsdml at
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>  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.

--  John

More information about the freebsd-ports mailing list