Re: [Python-Dev] Python sprint mechanics
Raymond Hettinger wrote: > Part of the mechanics also involves getting the users set-up on their > own machines. For me, it was a complete PITA because of the > Tortoise/Putty/Pageant/SSH2 dance and then trying to get Python to > compile with the only compiler I had (MSVC++6). The advantage of a > separate sprint repository is that we can essentially leave it unsecured > and make it easy for everyone to freely checkin / checkout and experiment. > For the Iceland sprint and bug days, we need a procedure that is > minimizes the time lost for getting everyone set. For bug days, it is > especially critical because a half-day lost may eat-up most of the time > available for contributing. For the Iceland sprint, it is important > because this is just one of many set-up tasks (others include > downloading and compiling psyco, pypy, etc). If manual merging-back of patches is acceptable, sprinters (and bug-day people) could just operate on the 2.5a2 source release, or (if they manage to master Subversion) on a anonymous subversion checkout. Of course, putting either the trunk or the 2.5aX sources into another repository might also work - except that anybody doing the merge-back would have to come up with sensible commit messages, and (ideally) sensible attributions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: > [Martin v. Löwis] >> I completely agree. Just make sure you master the mechanics of adding >> committers. > > So there's a practical problem: is that procedure documented > somewhere? I once posted the procedure to all current pydotorg project admins. I hesitate to post the precise instructions to a public mailing list (security by obscurity - but you hackers should all know there is real security in place also). > And who is _able_ to do this? For example, taking the > "you" literally, I doubt I have access to the machine(s) on which it > would need to be done. Actually, you (tim.peters) have the necessary permissions. > I'd be happy to learn how to do it, and to > document the procedure (if it's not already documented -- I couldn't > find it), if someone can teach me the ropes. Sure will do (in private mail). Maybe I'm just paranoid - if you think the procedure should be published, I wouldn't object. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
[Raymond Hettinger] > Part of the mechanics also involves getting the users set-up on their > own machines. Yes. > For me, it was a complete PITA because of the > Tortoise/Putty/Pageant/SSH2 dance and then trying to get Python to > compile with the only compiler I had (MSVC++6). The advantage of a > separate sprint repository is that we can essentially leave it unsecured > and make it easy for everyone to freely checkin / checkout and experiment. This seems to be mixing up unrelated problems. For example, the repository in use has nothing to do with that Python became hard to compile under MSVC 6, right? For a new library module, sure, any repository will do for development (& if it contains new C code, then compiler setup is required regardless of repository). If, OTOH, someone is looking to tweak existing code in the Python core, then svn.python.org is "the obvious" place to work from. You may (unsure) have been a unique case wrt Tortoise/Putty/Pageant/SSH2: I expect most open-source programmers working on Windows already have those installed (e.g., I did, and long before Python required them). Tortoise isn't necessary, but the PuTTY tools are. I expect (but don't know) that learning how to use SVN (or SVK) correctly would be a bigger setup cost for those who haven't already used them. Signing a PSF contrib form and getting an SSH2 key installed for svn.python.org are definitely hassles. OTOH, new code can't ever get into Python without signing that form, and collecting forms at a sprint is a lot easier for most people than hassling with snail mail or faxing. So I'd like to collect forms at the sprint regardless of which repository is in use. > For the Iceland sprint and bug days, we need a procedure that is > minimizes the time lost for getting everyone set. For bug days, it is > especially critical because a half-day lost may eat-up most of the time > available for contributing. For the Iceland sprint, it is important > because this is just one of many set-up tasks (others include > downloading and compiling psyco, pypy, etc). I'm far less hopeful about easing the pain for bug days -- that's overwhelmingly a repeated "one person generates a small patch, then bugs someone else to review and commit" dance. Sprints are more about people actively collaborating, and across days. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: >[Tim Peters, on giving commit privs to a sprinter after > extracting a signed PSF contributor form] > > >>>The more realistically ;-) I try to picture the suggested >>>alternatives, the more sensible this one sounds. ... >>> >>> > >[Martin v. Löwis] > > >>I completely agree. Just make sure you master the mechanics of adding >>committers. >> >> Part of the mechanics also involves getting the users set-up on their own machines. For me, it was a complete PITA because of the Tortoise/Putty/Pageant/SSH2 dance and then trying to get Python to compile with the only compiler I had (MSVC++6). The advantage of a separate sprint repository is that we can essentially leave it unsecured and make it easy for everyone to freely checkin / checkout and experiment. For the Iceland sprint and bug days, we need a procedure that is minimizes the time lost for getting everyone set. For bug days, it is especially critical because a half-day lost may eat-up most of the time available for contributing. For the Iceland sprint, it is important because this is just one of many set-up tasks (others include downloading and compiling psyco, pypy, etc). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
[Tim Peters, on giving commit privs to a sprinter after extracting a signed PSF contributor form] >> The more realistically ;-) I try to picture the suggested >> alternatives, the more sensible this one sounds. ... [Martin v. Löwis] > I completely agree. Just make sure you master the mechanics of adding > committers. So there's a practical problem: is that procedure documented somewhere? And who is _able_ to do this? For example, taking the "you" literally, I doubt I have access to the machine(s) on which it would need to be done. I'd be happy to learn how to do it, and to document the procedure (if it's not already documented -- I couldn't find it), if someone can teach me the ropes. >> However ... speaking as a PSF Director, I wouldn't be comfortable with >> this unless sprinters signed a PSF contribution form beforehand. Else >> we get code in the PSF repository with clear-as-mud copyright and >> licensing issues. Having contribution forms in place would also ease >> fears that sprint output might be "subverted" to non-open status. > That would be desirable, indeed. It shouldn't be too difficult to > collect the forms "on site". More like herding cows than herding cats ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: > The more realistically ;-) I try to picture the suggested > alternatives, the more sensible this one sounds. Some people at the > sprint (like me, wrt the Iceland sprint) could volunteer to be > responsible for checking checkins for appropriateness, and in any case > everyone subscribed to python-checkins would see what's going on. That's > a major goodness all by itself, for "more eyeballs" reasons. It should > be possible to quickly stop anyone abusing the privilege. I completely agree. Just make sure you master the mechanics of adding committers. > However ... speaking as a PSF Director, I wouldn't be comfortable with > this unless sprinters signed a PSF contribution form beforehand. Else > we get code in the PSF repository with clear-as-mud copyright and > licensing issues. Having contribution forms in place would also ease > fears that sprint output might be "subverted" to non-open status. That would be desirable, indeed. It shouldn't be too difficult to collect the forms "on site". Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
[Martin v. Löwis] > ... > Or, to put it yet in a different way: whether or not commit privileges > are restricted, you need to add the sprinters to the committers list > first, unless you want to allow anonymous commits to these branches. > > Just to not be mistaken: it is technically fairly easy to add somebody > to the committers list. So technical, there is no problem to add all > sprinters. The more realistically ;-) I try to picture the suggested alternatives, the more sensible this one sounds. Some people at the sprint (like me, wrt the Iceland sprint) could volunteer to be responsible for checking checkins for appropriateness, and in any case everyone subscribed to python-checkins would see what's going on. That's a major goodness all by itself, for "more eyeballs" reasons. It should be possible to quickly stop anyone abusing the privilege. However ... speaking as a PSF Director, I wouldn't be comfortable with this unless sprinters signed a PSF contribution form beforehand. Else we get code in the PSF repository with clear-as-mud copyright and licensing issues. Having contribution forms in place would also ease fears that sprint output might be "subverted" to non-open status. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Greg Ewing wrote: > Tim Peters wrote: >> 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. > > There's no way of restricting commit privileges to > a particular branch? In the current setup, not easily. However, sprinters would certainly restrain themselves to the branches they are told to use. IOW, technical mechanisms for fine-tuned write access are often besides the point: you first need to give these people any kind of write access at all, and then you find that further restricting that can readily be done without any technical enforcement. Or, to put it yet in a different way: whether or not commit privileges are restricted, you need to add the sprinters to the committers list first, unless you want to allow anonymous commits to these branches. Just to not be mistaken: it is technically fairly easy to add somebody to the committers list. So technical, there is no problem to add all sprinters. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: > Benji York wrote: >>Subversion 1.3 added a path-based authorization feature to svnserve. > > That's what I mean by "does not work fine": I would need to update > to subversion 1.3. I noted that in my original message. I thought you meant that it wasn't possible at all with svnserve. A simple misunderstanding. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
"Martin v. Löwis" wrote: > 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. Allow me to make a suggestion. A few months ago, Robert Kern (scipy dev) taught me a very neat trick for this kind of problem; we were going to hack on ipython together and wanted a quick way to share code without touching the main SVN repo (though both of us have commit rights). His solution was very simple, involving just twisted and bazaar-ng (Robert had some bad experiences with SVK, though I suppose you could use that as well). I later had the occasion to test it on a multi-day sprint with other developers, and was extremely happy with the results. For that sprint, I documented the process here: http://projects.scipy.org/neuroimaging/ni/wiki/SprintCodeSharing You might find this useful. In combination with IP aliasing over a local subnet to create stable IPs, and a few named aliases in a little hosts file, a group of people can find each other's data in an extremely efficient way over a several days, sync back and forth as needed, etc. At the end of the sprint, the 'real' committers can evaluate how much of what got done they want to push to the upstream SVN servers. I hope this helps, feel free to ask for further details. Cheers, f ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: > 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. There's no way of restricting commit privileges to a particular branch? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Benji York wrote: >>> I'm not familiar with the mechanics, recent versions of Subversion >>> allow per-directory security. >> >> It works fine for http(s), but not for svn+ssh. > > Versions prior to 1.3 could use Apache's authorization system. How would that work? Apache is not involved at all. > Subversion 1.3 added a path-based authorization feature to svnserve. That's what I mean by "does not work fine": I would need to update to subversion 1.3. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: > Benji York wrote: > >>I'm not familiar with the mechanics, recent versions of Subversion allow >>per-directory security. > > It works fine for http(s), but not for svn+ssh. Versions prior to 1.3 could use Apache's authorization system. Subversion 1.3 added a path-based authorization feature to svnserve. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Benji York wrote: > I'm not familiar with the mechanics, recent versions of Subversion allow > per-directory security. We do this to give some customers read access > to parts of the repo, and read-write to others. It shouldn't be > difficult (given a recent enough Subversion) to set up a sprint area in > the repo. It works fine for http(s), but not for svn+ssh. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Paul Moore wrote: > Is it possible to create a branch in the main Python svn, and grant > commit privs to that branch only, for sprint participants? I seem to > recall something like mod_authzsvn being involved, but I don't know > much more... We couldn't technically enforce it - but I'm sure sprint participants would restrict checkins to a branch if they were told to. However, I don't see how that would help. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Paul Moore wrote: > Is it possible to create a branch in the main Python svn, and grant > commit privs to that branch only, for sprint participants? I'm not familiar with the mechanics, recent versions of Subversion allow per-directory security. We do this to give some customers read access to parts of the repo, and read-write to others. It shouldn't be difficult (given a recent enough Subversion) to set up a sprint area in the repo. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
On 5/5/06, Tim Peters <[EMAIL PROTECTED]> 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. There: I think that's enough to prove I don't have a clue > :-) Is it possible to create a branch in the main Python svn, and grant commit privs to that branch only, for sprint participants? I seem to recall something like mod_authzsvn being involved, but I don't know much more... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: > I think Fredrik Lundh points to svk at such occasions. SVK makes it trivial to mirror a remote SVN repository, and make zillions of local light-weight branches against that repository (e.g.one branch per bug you're working on); see e.g. http://gcc.gnu.org/wiki/SvkHelp for a brief tutorial. I think you can set things up so others can work against your local repository, but I haven't done that myself. anyone here knows more about this ? (if that turns out to be hard, it's trivial to work with patch sets under SVK). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
On Friday 05 May 2006 15:16, Tim Peters wrote: > 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. Given where we are in the 2.5 release cycle, I'd _hope_ that only safe changes are considered for landing on the trunk. Massive refactorings really don't fill me with happy thoughts. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
On 5/4/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > Since I hope we see a lot more of these problems in the future, what Me too. > 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 I guess that means it's my turn to let my ignorance shine yet again. :-) Could we take a snapshot of the SVN repo, hosted on python.org, open it up for public commit during the period? That seems easy to setup. The difficulty would come in when we need to merge back to the real SVN. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
