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

[Doug Barton]

On 04/27/2011 15:39, John Marino wrote:
> As you notice, I never said they are limited what they work on.  The
> order of the work is the focus.

John,

You (and others) seem to be very focused on the idea of what's "fair." 
Specifically you seem to believe that FreeBSD committers have a duty to 
handle PRs in a FIFO order, because that is what is "most fair" to the 
PR submitters. Short answer, that view is unrealistic, and will not be 
implemented.

Longer answer. I understand your frustration. Those are not just empty 
words, I may be a committer for FreeBSD but I'm also an "individual 
contributor" for other projects, and I have to sit around and wait until 
someone looks at the bugs and/or patches that I contribute to those 
projects just like people contributing to FreeBSD do. It's really 
annoying to put a lot of work into a submission and then have it wallow 
in the queue. No one is denying that.

However, and I realize that many of you don't like this answer, but it's 
the truth. This *is* a volunteer project. If we tried to "require" 
committers to do what you suggest, we'd lost most of them. Let me give 
you a very real, concrete example.

Recently I picked up a new task, and needed a tool to do that task. We 
had a version of the tool in the ports collection but it was out of 
date. Before embarking on updating it myself, I looked in the PR db, and 
there was exactly what I needed, a patch to update the port to the 
latest version. Now let's assume that we adopted your rule. At that 
point I would have 2 options. Either commit all the patches between it 
and the one I needed, or leave the patch uncommitted. I'm a busy guy, I 
have a lot of demands on my time. (And don't forget, I got here because 
I have an actual project that needs to be finished.) Is it "fair" to me 
to require me to do all of that unrelated work just so I can get this 
one patch into the tree? Is it "fair" to the submitter of the patch that 
I _not_ commit it because I don't have the time to do all that other work?

Let's look at it another way. Let's suppose we implement your idea, but 
in order to make it more practical we implement a companion policy that 
before you can _submit_ a patch you have to go through all the other 
patches in the queue ahead of yours and test them, then submit your 
findings. (We're going to do this because that way when a committer gets 
around to a patch they will have a very good idea of whether it's 
suitable or not.) Is that "fair" to you? How many patches do you think 
we'd get from individual contributors if we required that amount of work 
before you could even submit a patch?


hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/