brett at python
Jul 4, 2009, 12:28 PM
Post #56 of 83
(1249 views)
Permalink
|
|
Re: Mercurial migration: progress report (PEP 385)
[In reply to]
|
|
On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman <dirkjan [at] ochtman> wrote:
> On Fri, Jul 3, 2009 at 20:04, Brett Cannon<brett [at] python> 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
|
