Re: Proposal: Switch back to savannah using GIT

[David Chisnall]

On 29 May 2015, at 11:41, Riccardo Mottola <address@hidden> wrote:
> 
> Since we have an advanced make system,

Hahahaha!  Oh, sorry, you were serious.

> make dist, if you are on a quickie
> make svn-tag && make svn-dist, if you want to do it nice.

Okay, where does this upload the tarball to?  Or do I now need to add tarball 
hosting to the requirements of a hosting provider as well?

Oh, and this doesn’t actually do what I do (and what is best practice to do) to 
ensure a clean release tarball, which is tar up the result of svn export, to 
ensure that the tarball exactly matches the contents of svn.  Instead, it 
deletes some files, hoping that it gets everything.

If I run [g]make dist in something that is not a pristine checkout, then I get 
an incorrect release tarball.  

> Ah, and when I use cvs....
> make cvs-tag && make cvs-dist, really that different, isn't it?

You’re missing the steps of uploading the tarball to the destination location.  
With GitHub, it is two git commands to go from a working branch to a release 
with public tarballs available.  That just leaves sending the release 
announcement.

> http://wiki.gnustep.org/index.php/Writing_Makefiles
> 
> No need to launch a browser click on some web interface of github.

None with GitHub either:
$ git tag release_foo
$ git push

And now it’s done.  The tarballs are online.  The release is tagged, the 
tarballs are online, with a stable URL, and all I need to do to turn this into 
a FreeBSD package is change the release entry in the port Makefile into 
whatever release_foo was.  

> No need for a "hash", I have a version tag and I'm done.

The hash is only required if I want to create a package from a non-released 
version.  If I want to update a package from a release to an unreleased version 
(for example, if GNUstep used git now, I would make the packages include the 
fix that was found just after the last release by just setting the hash to use 
to the hash of that commit).

It’s my fault for conflating two things here:

1) It is very easy to push out a release from a GitHub repo.

2) It is very easy as a packager *who is not necessarily a committer on that 
project* to create a package from a GitHub repo.

If anything, the second of these is more important.  Here is an example of a 
Makefile for a FreeBSD port of a GNUstep application that is hosted on GitHub:

https://svnweb.freebsd.org/ports/head/devel/cherivis-devel/Makefile?revision=385521&view=markup

If I want tup update this to a newer git revision, I need to modify two lines:

PORTREVISION=   2

Becomes

PORTREVISION=   3

This is internal to the FreeBSD ports system and is used to provide 
monotonicity in versions, even for unreleased code.  The second line is:

GH_TAGNAME=     525aeb4

This becomes the first 7 digits of the hash of the new revision (easy to find 
from either the git logs locally or via the GitHub web interface).  Doing this 
update does not require the upstream (who, in this case, happens to be me, but 
pretend for a moment that it isn’t) to do a release.  It just requires the 
packager to decide that they want to pull in a newer revision.

Note that this Makefile is actually slightly more complex than most because it 
is packaging an unreleased version.  Packaging the released version would not 
require the GH_TAGNAME entry at all, if the PORTVERSION matches the name of the 
release tag.

After making these changes, the rest of the update is more or less automated.  
I presume that it’s similar for other packaging systems.  GitHub goes out of 
its way to make it easy for packagers by generating (stable) tarballs from git 
versions and enough things are hosted on GitHub that it’s been worth providing 
some generic infrastructure to make packaging them easy on the FreeBSD side.

David

-- Sent from my STANTEC-ZEBRA