Re: Improving the handling of PR:s

On Sat, Jan 12, 2008 at 10:27:47AM +0000, Matthew Seaman wrote:
> As I understand it, I think the reason for this difference in performance
> at resolving PRs is because there is a body of ports committers that
> basically expect to spend a lot of time committing other people's work,
> whereas src committers are generally focussed on their own projects and
> tend to commit what they or people closely associated with them have
> developed.

That's partly it.  However:

 - ports are far more "granular" than the base system.  Although the
   occasional commits such as e.g. chasing shared library version bumps
   touch a lot of different areas, in general 80% of the commits are
   limited in scope.

 - because of this granularity, we assign a maintainer to each port.
   (Yes, only 75% of the ports are maintained, but never mind :-) )

 - that allows us to identify, route, and auto-assign ports PRs via
   an add-on script that Edwin wrote.  That sped up the turnaround
   time significantly.

 - probably 80% of the ports PRs are upgrades or things like fixes
   to scripts, options, etc.  The other 20% are more like "doesn't
   work when you do foo" which is probably what 80% of the src PRs are.

 - there's a known regression-test suite (pointyhat) for the "easy"
   cases, and a feedback mechanism to alert people when things break.

Identifying what parts of the base system will be affected by a
particular patch is a little bit more tricky, but should be done.

However, a large number of src PRs are "problem possibly touching
multiple subsystems" or "system does not perform well" or "panic
in unknown circumstances".  In each of these cases, we need to enlist
some people to work with these submitters.   They don't necessarily
need to be senior developers, but the need to be at least fairly
experienced with such tools as kernel dump analysis, our build
system, and so on.

Right now all this gets handled via email, which is not really an
ideal medium for quick feedback.  And, the senior developers who
generally respond to such things generally have enough to do as it
is; there simply aren't enough of them to go around.  Even if they
did, not much development work would get done :-)

In the past we've given 2 different people GNATS-only access as an
experiement, as discussed in one of my other posts in this thread.
I think the experiment has been a success and I'd like to build on that.

mcl