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

Re: How does team maintenace of python module works?



On Sunday, February 17, 2013 10:35:01 AM Robert Collins 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+baza
> ar&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.

That was roughly my point.  We all have our VCS preferences, but last time we 
went through this topic, none of them other than SVN met all of the 
requirements.  I haven't seen anything in this thread to convince me that's 
changed.

You'd also have to get some consensus around full source or debian directory 
only branches.  I don't think we can split on that either.  Personally, I've 
found nothing but frustration from trying to manage both Debian packaging and 
upstream code in the same repository.  I know other people have different 
views, but that's been my experience.

Scott K


Reply to: