[Python-Dev] Python sprint mechanics

["Martin v. Löwis"]

Tim Peters wrote:
> Since I hope we see a lot more of these problems in the future, what
> can be done to ease the pain?  I don't know enough about SVN admin to
> know what might be realistic.  Adding a pile of  "temporary
> committers" comes to mind, but wouldn't really work since people will
> want to keep working on their branches after the sprint ends.  Purely
> local SVN setups wouldn't work either, since sprint projects will
> generally have more than one worker bee, and they need to share code
> changes.

I think Fredrik Lundh points to svk at such occasions.

People usually get commit privileges when they have demonstrates to
simultaneously meet a number of requirements, such as
- following style guides
- never committing anything without discussion which might cause
  strong opposition
- always committing tests and documentation along with the actual
  code changes
- licensing all of their own changes to the PSF
- ...more things I can't put into words right now.
Of course, many committers miss some of these rules some of
the time, but I hope they all feel guilty when doing so :-)

It might be reasonable to waive the "have demonstrated" part for
some group of people, i.e. give them commit privs after telling
them what the rules are. However, in this case, I'd would really
like to see some "shepherd" who oversees this group of people.
gcc has a "commit-after-approval" privilege; if you have that,
you can only commit after somebody (a "maintainer") has approved
a change. Approvals are 'on file' in a mailing list archive.

I could imagine such a model for sprint participants, if
there would be somebody to volunteer as a shepherd. That person
would have to track the status of the individual projects,
and either revoke commit privs when the project is eventually
completed, or grant the contributors permanent (without-approval)
commit privs if he considers this appropriate.

Regards,
Martin