[Pkg-samba-maint] Early plans for a merged samba3/samba4 package

[Steve Langasek]

On Fri, May 11, 2012 at 12:30:15PM +0200, Christian PERRIER wrote:
> Next action (aha) will be to decide *where* to maintain all this. I'm
> not sure we can continue to survive with subversion but is anyone
> ready to try playing with svn->git?
> (I'd personnally favor git, which I tend to be more comfortable with
> as I have to use it more for other stuf....and also because upstream
> uses git anyway and, yes, I know we did setup a bzr repository..:-))

> Given that our current Subversion is kinda clumsy (/me being the
> culprit for most of the clumsyness, I'm afraid), do you guys thinks it
> is really possible to convert it as it has so many tags and branches
> (and subprojects, some of which being quite dead).

If we're merging samba 3 and 4 into a single source package, I think this is
the time to consider discarding the subversion history and starting from
scratch in a good VCS.  In my experience we almost never have to go back to
the oldest history of the svn repo; so the extra work needed to try to
stitch the (very complex and often broken) subversion history into a new
DVCS repository is IMHO not worthwhile.  It's more important that we get
ourselves into a state where we can merge cleanly with upstream - so
something that can talk to the upstream git repo - and support sensible
branching.

This doesn't itself have to be git of course.  I think there are two
specific advantages to using bzr which I would like to call out.

 - bzr-builddeb is a far superior tool to git-buildpackage and provides a
   sensible framework for everything we need to do - tagging, tarball
   imports with pristine-tar, upstream merges, etc.
 - We could base our packaging on one of the existing bzr branches for the
   Debian packaging.  This would not enable us to retain visibility into
   each and every subversion commit in the history of the package, but it
   *would* give us a rich history at the granularity of package uploads.

In all other respects, I think bzr is approximately on par with git here.
We should certainly be able to merge from the upstream git repository into
the package without problems (especially given that most of the issues have
been worked out via cifs-utils).  The one thing that may be disadvantageous
in bzr is that upstreaming patches via bzr-git is more awkward - there is
support for spitting out git-style patches from bzr, but not with all the
options seen in the native git tools.  But IMHO this is a minor point,
especially if we continue to use 3.0 (quilt) source format.


Now, if we did decide to use one of the existing bzr branches and merge it
with upstream git, we have several options of which branch to base it on.

- The samba4 package has a bzr branch already, at
  <http://bzr.debian.org/pkg-samba/samba4/unstable>, which would give us
  rich recent history for the samba4 source package.  Recent history is more
  likely to be useful than the ancient history.  However, this branch
  doesn't include pristine-tar data for all historical samba4 versions. 
  Maybe we would want to merge those in, to ensure we could work with the
  branch consistently.  It also doesn't currently branch from the upstream
  source, but I think this is fixable.

- There is a samba4 "UDD" branch at lp:debian/samba4 which has been
  autoimported based on all the history of package uploads to Debian.  This
  will contain the pristine-tar data for all historical uploads, but not the
  rich history of individual commits.

- There is also a branch at lp:debian/samba for the samba3 package which we
  could use instead.  I'm not sure this would make sense, but if someone
  feels that it's more important to have the samba3 package history than the
  samba4 package history, this is an option.  (I don't see any reasonable
  solution for retaining both the samba3 and samba4 package history in a
  single repository, using either git or bzr.  One way or another, we're
  going to have to do a big merge of the packaging between the two, and I
  don't think any available tools will give a meaningful representation of
  that merge.

So there are lots of options... we should probably figure out which one we
think best meets our needs going forward.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20120513/46e7e40b/attachment.pgp>