[Top][All Lists]

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

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

From: Bob Friesenhahn
Subject: Re: Integration of git-based release workflow into "make dist"
Date: Sat, 15 Aug 2009 10:51:15 -0500 (CDT)

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

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


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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]