On Fri, 19 Nov 2010 12:41:58 -0500 Barry Warsaw <ba...@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. _______________________________________________ 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
