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
