Re: libc tarballs

[Roland McGrath <roland at redhat dot com>]

For the existing releases missing tarballs (only 2.8 and 2.9), you don't
touch anything.  You just make the tarballs from the existing cvs tags.
In a build dir:

	make dist dist-version=2.8
	make dist dist-version=2.9

This uses cvs export, so it is slow/network-bound.  I usually did it on
sourceware itself, where it is quick.  There you can use space in:
	/sourceware/projects/glibc-home/tmp
Feel free to fiddle everything I have there.  It is just scratch I've
used for making dists and so forth.

Then I sign them (gpg -b, actually done elsewhere with file shuffling since
my keys are not local), publish them on sourceware ftp by copying into:
	/sourceware/ftp/anonftp/pub/glibc/releases/
Then do the GNU upload procedure.

I did all this for 2.8 and 2.9 just now, since it was the easiest way to
verify the correctness of what I'm telling you.  Obviously these steps are
simple.  The real work that we need volunteers to do is to define and
formalize the whole of what happens after the release tag is made (which is
the end of Ulrich's involvement), for the future releases: the whole of
releasing and later maintenance of the release branch, etc. (and then have
active volunteers who follow through on those procedures for each release
branch).

I don't expect we will have changed anything or gelled any new procedures
in the 2.10 cycle.  Thereafter I think we will change how this stuff is
done.  That's to be worked on here and can't happen without fresh devoted
efforts from volunteers, but I don't expect that to get rolling today.

Given the procedure as it is, the steps above are what would be done for
2.10 too when that tag is made.  The other step is to talk on libc-ports
(and not on this list) to coordinate ports tarballs and tags.  You can do
that right now for 2.[89].


Thanks,
Roland