Re: [issues] Why eglibc does not provide tarball?

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Sat, 30 May 2009, Brett Neumeier wrote:

> On Sat, May 16, 2009 at 2:10 PM, Joseph S. Myers
> <joseph@xxxxxxxxxxxxxxxx> wrote:
> > There is no such thing as an EGLIBC release; a tarball claiming to be such
> > would be masquerading as something that does not exist.
> 
> That is an interesting statement!
> 
> I had not considered that the Consortium members might not think of
> the branches in the eglibc SVN repository as maintenance branches for
> eglibc releases. They certainly have the superficial appearance of
> being exactly that, since they are named things like "eglibc-2_10".

They might be considered release branches, but ones with no releases, just 
the branches.  There is no preferred point on such a branch other than the 
tip, and the branchpoint is an intermediate branch-setup state to be 
avoided for all purposes and not used for any build wanting a stable ABI.

> > As with the lack of releases, there is no release number scheme for
> > identifying points on branches other than SVN revision numbers; the only
> > meaningful naming system would be to name snapshots [..]
> > after the branch version and the SVN revision number of the
> > most recent revision on the branch at the point the snapshot is created,
> > e.g. 2.10-8454.  (The branchpoints are definitely bad points to use; only
> > tip of a branch might be sensible for creating snapshots.)
> 
> The problem with creating snapshots based on the tip of the branch is
> that the tip keeps changing. That's why I opted to create snapshots at
> the branchpoint, and provide update patches that encapsulate the
> further commits on those branches.

But tarballs at the branchpoint might lead people into temptation to use 
those tarballs, which would be a very bad idea; the branchpoint is an 
intermediate state in setting up the branch, and it's common that the 
vagaries of how FSF GLIBC is developed mean that the EGLIBC branch does 
not reach a stable ABI point, and so a point that people should actually 
be using, until some merges have been done following branching (see how 
Ulrich made ABI changes and moved tags around after the initial 
announcement of 2.10, for example).  The first point on a branch that is 
suitable for use can only be identified by examining subsequent commits 
and messages to the patches list with a good understanding of the ABI 
issues involved; it is something that becomes known in retrospect when 
time for last-minute fixes has elapsed, not something known as soon as 
the branch is set up.

It might be better for FSF GLIBC to have an ABI freeze some time before 
the branchpoint, at which a public call would be posted for people to test 
it on various platforms and compare the ABI with that of previous releases 
(with appropriate scripts provided to facilitate this - to some extent 
they exist, but the baseline data has not been kept up to date for years).  
But this is not what is done at present, which means that branchpoints 
cannot be a good point to use or encourage using.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx