[Python-Dev] Revised 1.6 jobs list

[Jeremy Hylton]

>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

  GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote:
  >> ...  Sorry for the excuses.  I think better tools would help a
  >> lot, but we'll have to get more people checkin privileges
  >> regardless.

  GS> There are several issues with expanded checkin privs:

  GS> 1) trust: will the person make sure it is Right And Proper to do
  GS> the checkin? (have they reviewed the code? is a a Good Change?
  GS> etc) The counter here is that we don't want people that will
  GS> simply take stuff arriving at patches@ and checking them in.

Many of the people who ultimately have checkin privileges should limit
themselves to their particular domains.  There are a bunch of modules
that are owned by other people, e.g. Eric's netrc module, your new
httplib, MAL for Unicode, etc.

We'll probably develop a second group of developers who have broader
privileges to make changes, but they'll know how they are.

Ultimately, I think I agree with Mark's suggestion that we be a little
more liberal with changes and risk backing out the occasional
changes.  (For some definition of "a little more" :-).

  GS> 2) more people reviewing changes on the -checkins mailing
  GS> list. Assuming that you want more than one pair of eyeballs
  GS> looking at patches/code, that more people with commit privs
  GS> increases the rate of commits, then you need more reviewers to
  GS> keep up (because the reviewers probably are not going to review
  GS> ALL checkins)

You're doing a great job so far.  We'll just have to get you to spend
more time on it <0.8 wink>.

  GS> 3) increasing dependence on -checkins means that patches MUST be
  GS> smaller chunks. they MUST be single-purpose patches. practically
  GS> nobody will review a 200k patch, or patches that fix N different
  GS> things at once. A small, focused patch is easily reviewed.

  GS>    For example: Trent has recently mailed a bunch of patches to
  GS> the patches list. This is Goodness: each one is focused and can
  GS> be individually reviewed. Since they are not a single, giant
  GS> blob, it also keeps them short and reviewable... each can have a
  GS> +1/-1 independent of the others.

I agree in principle, but there are times when it will make more sense
to commit a set of changes as one big patch.  The GC patches are going
to affect a bunch of files, but probably ought to be done as one big
commit. 

Jeremy