Date: Thu, 28 Apr 2011 00:18:13 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: John Marino <freebsdml@marino.st> Cc: freebsd-ports@freebsd.org Subject: Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO? Message-ID: <20110427221813.GB32138@owl.midgard.homeip.net> In-Reply-To: <4DB8664D.70001@marino.st> References: <4DB7B237.7000603@marino.st> <BANLkTinoGufNYZmkFgQmwGR4RjBXWXcDTA@mail.gmail.com> <20110427075436.70ae18ac@seibercom.net> <19896.4396.161941.282904@jerusalem.litteratus.org> <20110427093258.3966cfd2@seibercom.net> <20110427134836.GA30085@owl.midgard.homeip.net> <20110427101257.414aaf8b@seibercom.net> <4DB8664D.70001@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 27, 2011 at 08:54:05PM +0200, John Marino wrote: > On 4/27/2011 4:12 PM, Jerry wrote: > > On Wed, 27 Apr 2011 15:48:36 +0200 > > Erik Trulsson<ertr1013@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. And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. > > Unfortunately, a FIFO setup requires that all the requests go through a > single entity who then assigns them. And who is going to do all that extra work? You volunteering? > 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. Details indeed, and the devil is in the details as the saying goes. First of all there is no entity that knows about the timeline, availability, etc. of the various committers. The only way to get that information would be if committers were to report it at regular intervals which they don't have any reason to do. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. > > 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. Worth it for who? Hardly to the guy who is going to do the extra work. As for "fair" you haven't convinced me why it should be a requirement. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110427221813.GB32138>