Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA29737; Wed, 20 Dec 95 03:24:50 EST
Received: from pain.lcs.mit.edu by MIT.EDU with SMTP
	id AA26364; Wed, 20 Dec 95 03:24:50 EST
Received: (from daemon@localhost) by pain.lcs.mit.edu (8.6.12/8.6.9) id CAA19520; Wed, 20 Dec 1995 02:32:08 -0500
Received: from lestat.nas.nasa.gov by pain.lcs.mit.edu (8.6.12/8.6.9) with ESMTP id CAA17666; Wed, 20 Dec 1995 02:19:09 -0500
Received: from localhost (thorpej@localhost)
	by lestat.nas.nasa.gov (8.6.12/NAS.6.1) with SMTP id XAA04452; Tue, 19 Dec 1995 23:19:01 -0800
Message-Id: <199512200719.XAA04452@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost didn't use HELO protocol
To: core@NetBSD.ORG
Subject: PR repsonsibility structure
Cc: netbsd-developers@NetBSD.ORG
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Dec 1995 23:19:00 -0800
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class
X-Loop: netbsd-developers@NetBSD.ORG

With the recent concern re. old PRs and "who can check in what", it seems 
that folks aren't aware of whatever policy might be in place for dealing 
with such issues.  I.e. there were several differing impressions, ranging 
from "clear it with core" to "check it in if it's not going to break 
anything".

I don't really think either extreme is really the best approach (extremes 
rarely are).  On the one side, you have a bottleneck.  We all know how 
busy we are.  On the otherside, things which work but aren't necessarily 
the best in terms of overall architecture might slip in.

Also, having given it some more thought, I agree with Perry that 
sometimes a jog of memory is required to get PRs closed.  I've seen 
many-a-time where a bug was fixed but it's PR not closed out.  On the 
other hand, I'm with Ted: I don't need anymore machine-generated e-mail.  
Well, at least no more than is absolutely necessary.

I think we've all noticed the "kern-bug-people" and "bin-bug-people" (or 
whatever they are :-) on the "Responsible" line in PRs.  It seems to me 
that these should be pointing at real mailing lists (unless they do 
already?).  Port-specific PRs should point at a port specific person or 
group of people, perhaps the port's mailing list.

Once a week, the "who" listed on the "responsible" line should be 
reminded of outstanding PRs (which have reached a certain 
age) corresponding to them.  This seems like a fair compromise between 
Perry's and Ted's position ... if you're not on that list, you don't 
have to hear about it.

This, of course, means that we're going to need people to "sign up" to 
take "official" responsibility for certain areas.  JT, Christos, and 
whomever might sign up to be "lib-bug-people".  Others can sign up for 
"bin-bug-people".  That group has responsibility for that bug, but others 
are not excluded for fixing it if they know the solution, or can get to 
it more promptly (and solve it correctly), or whatever.

Now, if someone in a group says "I'll fix that bug.", then the 
"responsible" field should be updated by that person to reflect that 
fact.  Then, they alone will get notification of that PRs outstanding 
status.  It's also easy to look and see who's working on a particular 
problem.  This has many "team effort" as well as "public image" benefits.

When "sweeping" changes are to be made (of if a fix isn't completely 
clear-cut), getting an "OK" is probably appropriate.  However, an 
outright blessing is overdoing it.  An "if I don't hear any real 
objections in 3 business days, I'm going to commit the following..." 
message is probably appropriate, unless you're Really Not Sure.  That's a 
judement call, but one all of you are trusted to make.  (Keeping in touch 
with the trust model is important ... if you weren't trusted, you 
wouldn't have source access; if you have source access, you can be 
trusted.  A break of that trust model by anyone is a step in the wrong 
direction.)

Anyhow, I've tried to think of a middle ground that everyone can be happy 
with (re. PR notification, check-in privs, etc.), and made a stab at 
coming up with some sort of "official" model that we can document (for 
the benefit of new developers as they arrive.  I apologize for the poor 
layout of this post, but today has been _really_ hectic, and I promised 
something tonight, and I just got rid of a raging headache.

If anyone has any suggestions or comments, have at it.  However, if there 
are no real objections in the mean time, I'd like to get this implemented 
reasonably soon after Jan 1 :-)

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939
