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