[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How does team maintenace of python module works?

On 16 February 2013 21:35, Robert Collins <robertc@robertcollins.net> wrote:
> 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

Corrected url s/bazaar/bzr/ and disabled vote to make the graph lighter.


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



Reply to: