[Python-Dev] Mercurial migration: progress report (PEP 385)

[Dirkjan Ochtman]

On Fri, Jul 3, 2009 at 20:04, Brett Cannon<brett at 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. 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)?

> 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.

> 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.

> 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).

> 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.

> 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.

> 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.

> 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.

(sys.revision discussion elided because some others have already been
bikeshedding on it.)

Cheers,

Dirkjan