How are [MAINTAINER] patches handled and why aren't PRs FIFO?
dougb at FreeBSD.org
Wed Apr 27 23:10:21 UTC 2011
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.
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
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?
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/
More information about the freebsd-ports