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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/