Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Mar 2014 17:30:22 -0500
From:      Mark Linimon <linimon@lonesome.com>
To:        Jim Ohlstein <jim@ohlste.in>
Cc:        Randy Bush <randy@psg.com>, freebsd-stable stable <freebsd-stable@freebsd.org>
Subject:   Re: reason 23 why we've moved to linux
Message-ID:  <20140323223022.GC796@lonesome.com>
In-Reply-To: <532F1C48.7080003@ohlste.in>
References:  <m2iorb1ms8.wl%randy@psg.com> <532EDDD0.80700@ohlste.in> <20140323153843.GA16935@lonesome.com> <532F1C48.7080003@ohlste.in>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 23, 2014 at 01:39:20PM -0400, Jim Ohlstein wrote:
> How many PR's contain "broken" or "broken on 10" or "break" or
> "build" or similar? Another few I'm sure. Updates are important too.

% grep -i break foo | wc -l
      19
% grep -i brok foo | wc -l
      33
% grep -i build foo | wc -l
     227

> I'm not trying to make this more a bitch-fest than it is, but I'll
> point out the obvious that if a third of PR's are from the last
> three months, that means two thirds are older than three months! I
> don't find that to be "quite brisk".

I don't feel we're in a bitch-fest :-)  I'm simply trying to give
my perspective from here in the trenches.  Worse, I guess I didn't
make the point I thought I was trying to make.

The first ports PR from 2014 that's still open is 185378.  The most
recent is 187859.  There's roughly 500 open PRs in between.

Now, not all of 187859-185378-500 = 1981 were ports PRs, but if past
statistics still hold, over half of them were.

So I claim that the *majority* of ports PRs get handled quickly.

There's no arguing that the ones that don't, tend to stick around
for a long time (too long).  This was partly the inspiration for
my writing portsmon in the first place.  Both it and the auto-
assigner have helped IMHO.

> I was separately mentioning the glacial pace at which ports related
> PR's get looked at, taken, and committed.

Again, my guess from the above is that overall it's faster that you
think.  But, more below.

> There is no obvious triage system. It's simply if someone is "interested"
> they take the PR. If no one is interested, it sits.

That's exactly correct.  For better or worse, that's the FreeBSD ports
gestalt.

> In the current system, if there is a maintainer, s/he may not answer
> a PR for months, even if that person is a FreeBSD committer.

And there is a policy for that: if a PR sits for more than 2 weeks,
any committer can take it.  If a maintainer is unresponsive for 3
months, they can be reset.

> Imagine if a hospital emergency department functioned that way.

This is a false analogy: they get paid.  Right now AFAIK no one is
paid to work on FreeBSD ports, other than a handful of people paid
to work on ports that affect their employer.

Back when the ports tree was only a few thousand ports, an all-volunteer
force was adequate.  These days it seems we're under strain.

Right now we're asking a lot from our volunteers: two major architectures
and 3 supported releases (plus -current), not counting the experiment to
create a "stable" ports tree branch.  (This latter IMHO is going to be a
key fix to the long-term problem).  The rewards are mostly the feeling of
"a job well done".

There's no tangible reward for working on PRs in someone's "priority
order".  From my previous experience as bugmeister, I can state that
most people think their own problems _are_ the priority.  In a world
where everything's a priority, nothing is.

We don't have a stick we can beat the committers with if they don't
do things in any particular order.  The most that we can reasonably
do is to reset their maintainership, or reassign their PRs, if they
become inactive.

fwiw, this afternoon I did one of my periodic passes through the ports
PRs looking for things that should be reassigned, and I've forwarded
my results to portmgr@.

Finally, FreeBSD always needs more volunteers to do the hard and often
thankless work of keeping the system going.

This is probably not what you wanted to hear, but in a system without
e.g. paid support contracts, it's merely the facts on the ground.

mcl



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140323223022.GC796>