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

[Bob Friesenhahn]

On Sat, 15 Aug 2009, Roger Leigh wrote:
> > 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.

I am not a lawyer either.  Generally publications become detached from 
the publisher.  If the git server goes away (as servers often do) then 
the publication goes away as well unless someone happens to have 
pulled from that server before it goes away and is willing to offer it 
to others.  Due to the many issues with dedicated version control 
servers, I can't recommend that anyone solely use this approach to 
make a formal release available.  The result is unlikely to be broadly 
disseminated, burned to DVDs, mirrored, indexed by search engines, or 
be usefully archived at sites like archive.org.

> The point of this isn't to completely eliminate tarballs.  It's to

Good.

> Additionally, VCSes don't typically store the results of "make dist",
> only the source for that.  Due to changing tool versions over the

This is a choice which varies by project.  Some projects (like mine) 
are rash and do commit generated files.

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

If by "upstream developers" you mean people like Debian package 
maintainers, then those maintainers would need to re-autotool the 3rd 
party packages with their own modifications.  There is then risk that 
additional work is required so that the package builds and works 
correctly.

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

This is a reason why autotools has tried to be VCS and packaging-tool 
agnostic.  Whenever particular version control tools or access to a 
particular version server has found its way into autotools project 
makefiles, I have argued to make sure that the standard build targets 
(e.g. 'make dist' or 'make distcheck') do not have such ties.  New 
targets like your 'dist-git' are not standard so they can do whatever 
they want.

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

Git is an amazing tool.

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

Open source software tends to live for a long time.  Some people here 
have been tending to open source projects for over 20 years.  During 
that time, many version control systems have come and gone and 
gained/lost popularity.  Even the Linux kernel has changed source 
control systems several times.  It seems best to keep autotools 
version-control agnostic while enabling application developers and 
package maintainers to add enhancements as needed.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/