[Python-Dev] Python sprint mechanics

Tim Peters tim.peters at gmail.com
Fri May 5 07:16:15 CEST 2006


There's going to be a Python sprint in Iceland later this month, and
it raises some management issues we also see on Bug Days, but more so:
 a relatively large number of people slinging code without commit
privileges, and a relative handful with commit privileges.  The latter
end up spending all their time reviewing and doing commits for the
former.

While that may be unavoidable for Bug Days, a major difference for the
sprint is that little of the code is likely _intended_ to end up on
the trunk at this time.  Instead it would make best sense for each
sprint project to work in its own branch, something SVN makes very
easy, but only for those who _can_ commit.  This year's PyCon core
sprint isn't a good model here, as everyone there did have commit
privs -- and that's unusual.

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.  There:  I think that's enough to prove I don't have a clue
:-)


More information about the Python-Dev mailing list