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

Jerry jerry at
Wed Apr 27 14:13:02 UTC 2011

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:
> > On Wed, 27 Apr 2011 08:50:52 -0400
> > 
> > However, I do find troubling you statement regarding a large update
> > to an older port or even a new port submission for that matter. I
> > see no logical reason for a committer to bypass an item simple
> > based on its size or the amount of work involved in getting it
> > committed. After all, consider that the original submitter invested
> > a large amount of his/her time in that same item.
> 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.

Jerry ✌
jerry+ports at

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

More information about the freebsd-ports mailing list