Hosting and Vcs-* fields in packages modified from Debian

[Loïc Minier]

On Wed, Aug 20, 2008, Steve Langasek wrote:
>                                  Ideally if the maintainer is already using
> feature branches in a distributed VCS, Ubuntu could hook into that with its
> own feature branches, and that would entirely satisfy my concerns about
> maintainability of the patches.  But the highest percentage of Vcs-* fields
> in Debian packages still point at subversion, which is not at all useful for
> this purpose.

 Ah it's been a while I'm tempted to ask how other people deal with a
 couple of issues I have on these topics...

 I personally try to use the same type of VCS that upstream is using for
 the packaging bits I maintain [1]: I can merge from upstream and keep a
 common history.
   I wonder about a couple of things:

 a) I don't have access to centralized hosting for e.g. git trees with
    Launchpad's access control / unix permissions; ideally, we would
    have the major services provided by Alioth on Launchpad to share
    with various Ubuntu teams, but since we only have Bzr, it's not easy
    to use other distributed VCSes for Ubuntu branches; it's not always
    possible to import into Bzr, and it adds a conversion step (also it
    makes it harder to pull the other way around)
      So where do you people host your branches?
       * I could push to say people.ubuntu.com/~lool, but then if I were
         to declare this to be the location for the Ubuntu packaging
         bits, I would have to act as a middleman before any update to
         this tree.
       * I could push to Alioth [2], but it's disturbing for many
         reasons:
         - not all Ubuntu people have accounts, and we would miss the
           groups anyway
         - use of Debian resources for Ubuntu; I feel I need permission
           of the packaging project I'm forking from; not really
           possible for packages in Ubuntu alone
         - causes a dependency between Ubuntu data and Debian
           infrastructure: e.g. Alioth is down and you can't commit  :-/
       * I could ship the DVCS files in the source package itself, but
         I understand it's still "future technology"

 b) we seem to lack clear/strict guidelines for dealing with Debian
    versus Ubuntu versus upstream Vcs information; I think we need more
    tools, more policies, and more documentation for this issue:
    - we should clear Vcs-* fields when forking a package for Ubuntu
      which was kept in a Vcs when we don't intend to keep it in a Vcs
      (examples of packages getting this wrong: pbuilder, xorg-server)
      -- or rename them to X(S)-Original-Vcs-* -- or mention the Ubuntu
      Vcs instead
    - we should update tools such as "update-maintainer" to do the right
      thing
    - we could enhance the Vcs-* policies/specs to cover upstream
      information and perhaps improve the "X*-Original*" policies/specs
      to handle multiple levels of forking (package forked from maemo
      into Debian, and then forked from Debian into Ubuntu for instance
      :-)


 So I'd love to read what you people are doing around these issues;
 perhaps I'm too conservative and should make more use of Alioth;
 perhaps we shouldn't tweak Vcs fields manually but use a central
 Launchpad override (the information might be in Launchpad already!) or
 perhaps Launchpad should import the information and help us fork the
 packages?  I'm sure other people have very cool ideas to deal with
 these!


[1] it's a tighter constraint than what you mention, or perhaps it's
    what you meant, not sure
[2] In the past I (as an Alioth project maintainer) personally offered
    to other distros to host their packaging in the same repo (e.g.
    SVN)
-- 
Loïc Minier