Re: How does team maintenace of python module works?
On 17 February 2013 08:29, Dmitrijs Ledkovs <xnox@debian.org> wrote:
> On 16 February 2013 14:27, Jakub Wilk <jwilk@debian.org> wrote:
>> * Scott Kitterman <debian@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
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.
-Rob
--
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Cloud Services
Reply to: