Re: Integration of git-based release workflow into "make dist"

[Roger Leigh]

On Fri, Aug 14, 2009 at 09:46:52AM -0500, Bob Friesenhahn wrote:
> On Fri, 14 Aug 2009, Roger Leigh wrote:
> 
> >ÿÿ distribute generated release tarball
> >
> >However, the "distribute release tarball" step is becoming less and
> >less relevant with the advent of git.
> 
> The "release tarball" step is always needed since software
> development is protected by copyright laws so we need a step which
> is a equivalent to publishing the work.  A release branch or tag in
> a live repository will not be compelling enough in a court of law.
> No judge or jury would understand it or believe it.

While I can't really comment on this, not being a lawyer, it looks
like distribution (publication) to my mind, seeing that it's all
publicly available.

However, you can continue to use the other dist- targets to create
tarballs.  Additionally, you can use "git tar-tree $dist_tag"
to create a tarball /directly/ from git.

The point of this isn't to completely eliminate tarballs.  It's to
provide a more convenient way of getting releases when transferring
them between version control systems.  When we are going git→git,
this makes much more sense than making a tarball and re-importing it;
not only is it more convenient, it's tied into the history of the
whole repo, which a tarball loses.  This allows for easy pushing and
pulling of changesets both upstream and downstream.

Additionally, VCSes don't typically store the results of "make dist",
only the source for that.  Due to changing tool versions over the
years, you can get in a situation where you can no longer rebootstrap
checkouts of old versions.  By storing this in the VCS as well, you
guarantee that you can get a usable tree even if those tools are no
longer available or functional.  Plus, you can also diff the
generated files between releases as an added bonus, which can help
track down build infrastructure issues.

> Creating a git
> repository to contain the release and then bundling up so that it
> can be archived as a new form of "tarball" would be sufficient as
> long as it is clearly an act of publishing the work.

This is essentially what the "3.0 (git)" Debian source format is.

> >I do a lot of Debian packaging work, as well as actual software
> >development for Debian.  All of this work nowadays occurs in git
> >repositories.  For packages of software distributed by third
> 
> Maintenance for other OSs may be in Subversion, Mercurial, CVS,
> Perforce, or one of the many other active version control systems.

Of course.  In case it wasn't clear, I was describing the workflow
for the work *I* do, and the packages I maintain; git is just one of
many VCSes in use for package maintenance.

> >ÿÿ Add a dist-git option and Makefile target.
> > This will cause $distdir to be injected into git, rather than just
> > calling tar as for other git targets.
> 
> It is easy enough for the Automake user to add targets like
> "dist-git" since Automake is extensible.  The main problem you will
> face is how to herd the cats so that they all add a "dist-git"
> option that you want for your particular release system.  This seems
> quite hard to accomplish unless your OS distribution can somehow
> become the clear monopoly player so that the work of others can be
> ignored and rendered pointless.

I think you have misunderstood the intent here.  This adds the ability
for upstream developers, who specifically choose to enable it, the
means of storing their releases under git version control.  There's
no coercion or anything implied.  It's an optional feature people
can choose to use.

It's something I've wanted for my own use as an upstream developer for
some time, but which I felt was generally useful enough that it might
be considered for inclusion in automake itself once tested and proven.

> If this manages to be implemented flexibly and concrete enough to be
> included in stock Automake, then it should be a requirement to
> support the many other version control systems as well.

Why, and where do you draw the line for which systems need supporting?
--there are tens of different systems out there.

I can't commit to doing that myself; I lack the specific knowledge of
those other systems.  Support for other systems can be added as and
when users of those systems provide patches to implement such
functionality.

From a purely technical POV, doing this was *easy* in git, because
we can do it without touching the user's current working tree (we
use an alternative index and work directory).  Doing it in other
systems requires a lot of hairy saving of state, switching branches,
adding and removing files so the tree state reflects the distdir,
committing that and then restoring the tree to the state it was
beforehand (including all dirty files and non-version-controlled
files).  Even then, I doubt you can replicate the merge between
distribution and release branches that git does automatically.  In
short, an order of magnitude more difficult, with potential to
lose or scramble the user's data if you mess up at any point.

In git, we inject a tree object, commit object and do a single
ref update (plus optional tag).  It's quick, clean and **safe**.
The working directory is never touched, so there's no chance for
dataloss.

That's not to say I don't welcome other VCS support where possible,
just that I can't see the point of mandating it as a requirement
for git support.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

signature.asc
Description: Digital signature