On 16 February 2013 21:35, Robert Collins <robe...@robertcollins.net> wrote: > On 17 February 2013 08:29, Dmitrijs Ledkovs <x...@debian.org> wrote: >> On 16 February 2013 14:27, Jakub Wilk <jw...@debian.org> wrote: >>> * Scott Kitterman <deb...@kitterman.com>, 2013-02-16, 09:10: >>>> >>>> On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote: >>>>> >>>>> The following four positions have all been advocated in this thread: >>>>> >>>>> A - Maintain the status quo, in which DPMT packages may only be >>>>> maintained in SVN. >>>>> B - As A, but encourage the creation of a separate team where Python >>>>> modules can be maintained in git. >>>>> C - Allow DPMT-maintained packages to live in SVN or git, so new packages >>>>> can be committed to git if the packager prefers. Optionally, we could make >>>>> provisions to migrate existing packages. >>>>> D - Migrate all the DPMT-maintained packages to git. >>>>> >>>>> (I suggest we don't consider other VCSs - while we might have our >>>>> favourites, I sampled the list of Debian teams, and found very few using >>>>> anything other than svn or git. So tools & workflows for other VCSs are >>>>> likely to be less well developed.) >>>>> >>>>> So I would vote CDBA, in order of preference. >>>> >>>> >>>> E - Migrated to bzr, but I want someone else to to all the work. >>>> >>>> EA >>> >>> >>> F - Migrate to Mercurial, but I want someone else to do all the work. >>> >> >> A, F.1 - Migrate to Mercurial, if and only if mercurial queues are >> fully functional and are used to maintain the debian/patches >> sub-repository. >> >> realisticly i am opposed to a mix of version control systems. >> >> someone to do the work - means starting a mirror which works in >> read-only / mirror mode only. >> >> When gnome.org was migrating from svn - they had multiple mirrors >> running (bzr, and git, not sure if an hg was there as well) >> >> Regards, >> >> Dmitrijs. > > I will *always* have a soft spot in my heart for bzr, having spent > many years working on it. > But consider: > > http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m&beenhere=1 >
Corrected url s/bazaar/bzr/ and disabled vote to make the graph lighter. http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bzr&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 > If we're changing VCS, there is a vastly higher probability that the > folk whose software we are packaging is in git, and that contributors > we get will be familiar with git, than any other system now. That > doesn't mean git is better or worse, but if we're changing systems > because of preference (rather than fitness-for-purpose), then I think > we'd be crazy to consider any other VCS. > svn is very alive and stable. I have managed in the past to crash or otherwise make bzr/hg/git inconsistent. Some of my bugs got fixed and mostly git is fit for purpose on the stability side of things. I haven't used hg in a while. svn has always been good for me (but i guess i'm a fairly recent developer and haven't seen the pre 1.5 days of svn). we are yet to figure out a packaging workflow that works great, especially w.r.t. patch management. On one hand you want to simply commit and merge, on the other hand you want to ship a patch series for the convenience of dowstream/users, but that means rebasing, and rebasing is pain to track history off, hence end up committing patches but one wants to commit directly LOOPREACHED. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluimts5aijzvzcuye9yajm6rzkbskvsadnjdug9prp0...@mail.gmail.com
