-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/11/10 08:18, Georg Brandl wrote:

Am 16.11.2010 19:38, schrieb Jesus Cea:

...

Is there any updated mercurial schedule?.

Any impact related with the new 3.2 schedule (three weeks offset)?

I've been trying to contact Dirkjan and ask; generally, I don't see much connection to the 3.2 schedule (with the exception that the final migration day should not be a release day.)

I can't find the mail now, but I remember that months ago the Mercurial migration schedule was mid-december. I wonder if there is any update. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTOPP5Zlgi5GaxT1NAQLpSgP/e31LxthlSKgrVYbVhmHKfpdRvQKS2KGb kd0wpIYHhYs/TF0Jwm+Z1r4ylNTaOq0bSL8mJAFqZDnf2IA/jSn9Db/JUk338z7B FIcP0jYLSG0wS+pITRL+f6ifCK5s9SgdbSlPVTdyA6R5G9BDw0T72ZI4WDbnbTEy zqPfvWULiqY= =kPIk -----END PGP SIGNATURE-----

Am 17.11.2010 08:18, schrieb Georg Brandl:

Am 16.11.2010 19:38, schrieb Jesus Cea:

...

Is there any updated mercurial schedule?.

Any impact related with the new 3.2 schedule (three weeks offset)?

I've been trying to contact Dirkjan and ask; generally, I don't see much connection to the 3.2 schedule (with the exception that the final migration day should not be a release day.)

Please reconsider. When Python migrates to Mercurial, new features will be added to Python, most notably a new way of identifying versions, perhaps new variables in the sys module. So far, the policy has been that no new features can be added after beta 1. So consequentially, migrating 3.2 to Mercurial would violate that policy if done after b1. Consequentially, we would need to release 3.2 from Subversion, which in turn means that the Mercurial migration should be delayed until after 3.2 is released. Alternatively, b1 should be postponed until after the Mercurial migration is done. Regards, Martin

...

Alternatively, b1 should be postponed until after the Mercurial migration is done.

I think this "new feature" is not so shocking that it can be used as an argument to hold up the migration. If you have another reason to stop the migration please say so; personally I can't wait for it to happen.

I can't point out any other specific concern, just a general feeling that *when* the migration happens, it will be rushed, and we will have to deal for a long time with the aftermath. For example, I expect that it will take me several days until I get the Windows build process to work correctly, and, if the migration gets as rushed as it appears to, that the migration will happen without everything being worked out beforehand. Therefore, I'm concerned that I will have to work out all the details on my own, just so that I can produce the b2 binaries (says); this is not something I look forward to. I'm not asking that the migration be stopped - I'm asking that it be accelerated, so that there is plenty of time to identify all the problems. But I'm also not willing to put time into it. Failing the acceleration, I ask that appropriate consequences for the 3.2 release are drawn: either it is postponed, or done using Subversion until the final release (I think something can be worked out then to get the 3.2.1 release from Mercurial - with only slight incompatibilities). In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems. Regards, Martin

...

Therefore, I'm concerned that I will have to work out all the details on my own, just so that I can produce the b2 binaries (says); this is not something I look forward to.

How much does the binary build process really depend on version control? I.e., what would be stopping you from making a binary from an archive made with e.g. "svn export"? (I'm really asking because I don't know.)

The build process currently compiles a program (make_buildinfo), which in turn finds the subversion installation, and runs subwcrev if found. If no .svn folder is found, it falls back to the version information in the export. I would have to try out what exactly will happen when I try to build the current hg conversion result on Windows, but chances are that the resulting interpreter will crash because the string manipulation fails to find the right substrings.

Well, put some butter to the fish: how many volunteers would you deem sufficient, and which specific tasks are uncared for in the infrastructure? I can only speak for myself, but I am prepared to put in my time.

As a starting point, I'd like to see a complete, current conversion result, using as many repositories as planned, and including as many branches into each repository as planned (rather than the giant cpython repository which we have now - unless the plan now is that there will be a single giant repository). Then the existing patches to the build identification should be applied, and the repositories should be opened for (test) commits. Then people could start identifying problems. As a parallel activity, I'd also ask that the PEP is finished, or atleast put into a form where the authors consider it complete (again so that people could start identifying issues, and determine where the PEP differs from reality - currently most obviously in the branching approach). Regards, Martin

2010/11/18 Jesus Cea <jcea@jcea.es>:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 18/11/10 18:32, "Martin v. Löwis" wrote:

...

In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems.

Do we have a exhaustive list of mercurial "to do" things?.

http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt -- Regards, Benjamin

On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl <g.brandl@gmx.net> wrote:

Am 19.11.2010 03:23, schrieb Benjamin Peterson:

...

2010/11/18 Jesus Cea <jcea@jcea.es>:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 18/11/10 18:32, "Martin v. Löwis" wrote:

...

In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems.

Do we have a exhaustive list of mercurial "to do" things?.

http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt

Uh, that's the list of things to do *at* the migration.  The todo list is

http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt

That kind of link is the sort of thing that should really be in the PEP... (along with the info about where to find the hooks repository, specific URLs for at least 3.x, 3.1 and 2.7, pointers to a draft FAQ to replace the current SVN focused FAQ, etc) Target dates for the following specific activities would also be useful: - date a "final draft" of converted repository will be made available to Martin and Ronald to dry run creation of Windows and Mac OS X installers - date SVN will go read only - date Hg will be available for write access (it should be frozen for a while, to give the folks doing the conversion a chance to make sure buildbot is back up and run, commit emails are working properly, etc) So as long as we acknowledge that any migration problems may mean additional beta releases of 3.2 to iron things out, I don't see a problem with releasing beta 1 as planned to close the door on any *other* new features, and giving the Hg migration a clear run at the source repository before we start working seriously on dealing with bug reports (either existing ones, or those from the first beta). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Am 19.11.2010 15:36, schrieb "Martin v. Löwis":

...

- date Hg will be available for write access (it should be frozen for a while, to give the folks doing the conversion a chance to make sure buildbot is back up and run, commit emails are working properly, etc)

I would target the build slaves to the Mercurial repository already in the testing phase, e.g by creating builders for building from commits to the 3k branch. I hope Buildbot supports multiple change sources now. Likewise, I'd also see commit emails being delivered in the test phase already, and let committers make test commits to trigger this all (and also to get acquainted with the Mercurial tools they are going to use, without fear of breaking something).

I've already let my Mercurial buildbot configuration run for a few checkins while testing it; a separate changesource was not needed. The commit email hook also has been tested extensively by its usage for the distutils2 repo, which are also sent to python-checkins. That said, it will of course be nice to activate both for the test repo as well, once it's available. Georg

On Sat, Nov 20, 2010 at 12:46 AM, Barry Warsaw <barry@python.org> wrote:

On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote:

...

- date SVN will go read only

Please note that svn cannot be made completely read-only.  We've already decided that versions already in maintenance or security-only mode (2.5, 2.6, 2.7, 3.1) will get updates and releases only via svn.  But only the release managers should have write access to the svn repositories.

Again, something that should be in PEP 385 (but isn't). It seems that the work *is* going on, and the people actually doing it have a reasonable idea as to what has been decided and where things are going, but those of us "out here" have a fair stake in this as well, and without an up to date PEP 385 there's no one place to go to to see the current state of the migration. That's enough to make folks like me somewhat nervous as to whether or not we're actually going to have a usable source control system come December 12. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Am 19.11.2010 16:00, schrieb Dirkjan Ochtman:

On Fri, Nov 19, 2010 at 15:56, Nick Coghlan <ncoghlan@gmail.com> wrote:

...

That's enough to make folks like me somewhat nervous as to whether or not we're actually going to have a usable source control system come December 12.

Yes, I've been negligent about updating the PEP. I'll try do so next week. Georg, if you have time to update it a bit, that would be great as well.

I'm at it. In fact, I think I will merge both todo.txt and tasks.txt into the PEP. It's not more of a burden to update it there, and it's more visible to the developer community. Georg

Am 19.11.2010 15:46, schrieb Barry Warsaw:

On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote:

...

- date SVN will go read only

Please note that svn cannot be made completely read-only. We've already decided that versions already in maintenance or security-only mode (2.5, 2.6, 2.7, 3.1) will get updates and releases only via svn. But only the release managers should have write access to the svn repositories.

Really? I can understand this for security-only branches (commits there will be rare, and equivalent commits to the Mercurial branches can be made by others than the release managers, in order to keep history consistent). But having the maintenance branches (by then, that will mostly be 2.7 because 3.1 will go to security-only mode soon) in SVN will be a burden for every developer, since they have to backport bugfixes from Hg to SVN... Georg

On Fri, 19 Nov 2010 12:41:58 -0500 Barry Warsaw <barry@python.org> wrote:

...

Really? I can understand this for security-only branches (commits there will be rare, and equivalent commits to the Mercurial branches can be made by others than the release managers, in order to keep history consistent).

But having the maintenance branches (by then, that will mostly be 2.7 because 3.1 will go to security-only mode soon) in SVN will be a burden for every developer, since they have to backport bugfixes from Hg to SVN...

Maybe I misremembered Martin's suggestion, and he was only talking about security releases. I think the key thing is whether you're going to backport the vcs related bits to stable releases.

It would be horribly burdensome to use two different VCSes depending on whether you're working on a bugfix branch or a feature branch.

I plan to only do releases for 2.6 from svn, because it's not worth breaking things like sys.subversion, and as you say the number of commits will be small.

But 2.6 is security-fixes only, right? It would really be annoying if the same rules applied for 2.7 and 3.1. I don't understand all the worry about sys.subversion. It's not like it's useful to anybody else than us, and I think it should have been named sys._subversion instead. There's no point in making API-like promises about which DVCS, bug tracker or documentation toolset we use for our workflow. Regards Antoine.

I don't understand all the worry about sys.subversion.

Really? For a security release, there should be *zero* chance that it breaks existing applications, unless the application relies on the security bug that has been fixed. By "zero chance", I mean absolutely no chance, never. I'm pretty sure that applications *will* break because of the change to sys.subversion, or sys.version. People made bug reports complaining that sys.version has a newline on some systems and not on others.

It's not like it's useful to anybody else than us

I think you underestimate what API people actually use in applications http://tinyurl.com/292vhxx http://tinyurl.com/23ah8ps http://tinyurl.com/27fhyvk http://tinyurl.com/28cuyv9 etc. Regards, Martin

Le vendredi 19 novembre 2010 à 22:35 +0100, "Martin v. Löwis" a écrit :

...

I don't understand all the worry about sys.subversion.

Really? For a security release, there should be *zero* chance that it breaks existing applications,

It should have been clear that my message explicitly excluded security releases. Regards Antoine.

2010/11/19 "Martin v. Löwis" <martin@v.loewis.de>:

...

Maybe I misremembered Martin's suggestion, and he was only talking about security releases.

Technically, I was only talking about 2.5. For each branch, the respective release manager should make a decision. For 2.5 and 2.6, it's been decided; Benjamin has not yet announced plans how 2.7 and 3.1 will be maintained after the switchover.

I propose that they follow the development branches over to hg. Having to backport bug fixes with any frequency from hg to svn would probably be more unpleasant than the current svnmerge situation. -- Regards, Benjamin

On Fri, Nov 19, 2010 at 05:50, Nick Coghlan <ncoghlan@gmail.com> wrote:

On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl <g.brandl@gmx.net> wrote:

...

Am 19.11.2010 03:23, schrieb Benjamin Peterson:

...

2010/11/18 Jesus Cea <jcea@jcea.es>:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 18/11/10 18:32, "Martin v. Löwis" wrote:

...

In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems.

Do we have a exhaustive list of mercurial "to do" things?.

http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt

Uh, that's the list of things to do *at* the migration.  The todo list is

http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt

That kind of link is the sort of thing that should really be in the PEP... (along with the info about where to find the hooks repository, specific URLs for at least 3.x, 3.1 and 2.7, pointers to a draft FAQ to replace the current SVN focused FAQ, etc)

I am spending my PSF grant time in January rewriting python.org/dev practically from scratch. Any needed updates to take Mercurial in account will happen no later than then. -Brett

Target dates for the following specific activities would also be useful: - date a "final draft" of converted repository will be made available to Martin and Ronald to dry run creation of Windows and Mac OS X installers - date SVN will go read only - date Hg will be available for write access (it should be frozen for a while, to give the folks doing the conversion a chance to make sure buildbot is back up and run, commit emails are working properly, etc)

So as long as we acknowledge that any migration problems may mean additional beta releases of 3.2 to iron things out, I don't see a problem with releasing beta 1 as planned to close the door on any *other* new features, and giving the Hg migration a clear run at the source repository before we start working seriously on dealing with bug reports (either existing ones, or those from the first beta).

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia _______________________________________________ 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/brett%40python.org

Am 19.11.2010 08:58, schrieb "Martin v. Löwis":

Am 19.11.2010 03:23, schrieb Benjamin Peterson:

...

2010/11/18 Jesus Cea <jcea@jcea.es>:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 18/11/10 18:32, "Martin v. Löwis" wrote:

...

In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems.

Do we have a exhaustive list of mercurial "to do" things?.

http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt

This doesn't, but IMO should, list

- resolve open issues in PEP - finalize and implement branch structure - set and implement policy for external code bases for Windows builds - set up account management infrastructure, determine account managers

Good points, I've added the missing ones to the todo list. Georg