On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:
> On Fri, Jul 3, 2009 at 20:04, Brett Cannon<br...@python.org> wrote: > > Fine by me as long as people realize that if anything is questionable > then > > the switch will not happen. Getting this right takes precedence over any > > deadline. And obviously we will need to do at least one live conversion > on > > python.org hardware to make sure everything will work smoothly. > > I'm not sure I see the need to do a (live? what does that mean in this > context) on python.org hardware. "Live" as in run through all the steps on python.org hardware w/o hitting any final switch that turns off svn. > Why exactly is that better than me > doing it on one of my boxes, as long as all the necessary tools and an > idea of how to do it are publically available (from the pymigr repo, > for example)? Because there are different OSs, installed software, etc. Basically because you just never know. =) Plus it will make Martin sleep better. > > > > And will make the idea of splitting out the standard library and tests a > > reasonable thing to do. > > In due time, yes. > > > While I really like the idea of using named branches for each release so > > that there is a single py3k branch that contains all relevant history for > > every release, I think we should start simple and go with cloned > branches. > > That way the workflow does not radically shift from what we do now for > svn > > to start. Once the conversion is done and people are comfortable with hg > we > > can then discuss moving towards a named branch approach. > > I don't think the cloned branches is much simpler than the named > branches approach, in several ways. For example, populating the branch > part of a sys.whatever value is significantly harder. Also, if you > follow a useful tagging approach, doing cloned branches means that > release tags aren't available on trunk/main/default. That seems like a > step backwards. > I personally prefer named branches, but that's just me and I am not about to force my preferences on everyone. Guess we just have to see if others have opinions against named branches. > > > Sounds reasonable to me. We can just make a list and send it to > > python-committers to make final decisions of what should stick around. > > This list exists and has been referenced in my email a few times. > Sure, but as inlining the PEP in this email thread has shown, not making people click a link helps. =) Plus a separate email makes it very obvious that people need to check their email instead of making it a bullet point in a much larger email. > > > I don't use tags so I don't really care, but in the name of easy > transition > > I say we don't change the naming scheme (although I have no issue > dropping > > obscure tags). > > The current proposal is to clean up old tags to agree with the current > naming scheme (and dropping obscure and partial tags). > Fine by me. > > > Something else that can go out to python-committers before the switch. > > This should just be done ASAP, it helps with a smooth conversion process. > > > I don't think there is a single project we host -- all two of them -- > that > > have not said they want to convert. So I say convert everything and let's > > turn off the svn server by the end of the year. > > I say we tackle each one as we go. I say doing a good conversion job > is valuable, and we should take as much time as we need (though not > more). You advocate something similar below for the Python conversion. > I am not suggesting we do all conversions on the same day, just that everything should eventually be converted. > > > Can we check these scripts into the repository itself? That way there is > a > > chance of reuse as hg commands, e.g. ``hg pydev-ci`` as a replacement for > > ``make patchcheck``. > > I'm not sure there's an easy way to make them into commands (although > I guess you could make an extension to that effect), but hooks would > be very easy. > OK. I was just hoping we could factor the code in such a way as to share the basic steps the hooks were checking so as to reuse them in a command. > > > How about hg.python.org for the official branches and we keep > > code.python.org for personal branches of the developers like we have > done > > with the bzr experiments? > > I think that's just confusing. Most people seem to like hg.python.org, > and it's obvious that hg goes to hg.p.o. Dividing up the namespace > only makes it harder to find things. > Yeah, I realize I have lost this battle. > > > As I have said, we should change our workflow habits after the switch and > > people are comfortable with hg. > > Well, not everyone agrees, and although I think it doesn't matter much > for the conversion itself, it may affect the branching strategy > discussion. > Sure, to an extent. > > (sys.revision discussion elided because some others have already been > bikeshedding on it.) I think it has been answered; sys.subversion goes away and sys.mercurial or sys.mercurial_revision comes into existence. -Brett
_______________________________________________ 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
