2.22.1 Possible -> Yes!

[Mike Frysinger]

On Thursday 26 April 2012 23:41:01 Alan Modra wrote:
> On Thu, Apr 26, 2012 at 10:07:27PM -0400, Mike Frysinger wrote:
> > a release from trunk means 2.23, not another 2.22.
> 
> What matters the number?

you've missed my point (see below), but specifically speaking, yes, if you 
release from trunk, you should be incrementing the 22.

> >  i also don't think you can
> > say that the trunk is that much better considering it hasn't been
> > released and tested on distros for a variety of targets.
> 
> I do claim that.  I can claim that based on the number of bugs I know
> have been fixed on trunk but not on the branch.  I also know that
> people use trunk binutils in production, and HJ releases binutils
> effectively off trunk all the time, so it's not as if trunk is only
> tested by developers.

yes, and his last release (2.22.52.0.1) had a fairly trivial but critical bug 
-- trying to use the environ with --gc-sections lead to undefined references 
causing all Gentoo builds to segfault.  that's on x86_64.

> Even distros use trunk snapshots as their base
> for binutils, eg. RHEL6.3 is based on binutils-2.20.51.0.2.

Gentoo used to but found them too unstable.  so once the GNU releases started 
picking up, we stopped relying on his snapshots.

i also don't think Redhat is a good example considering they have a full time 
team working on making the releases actually stable, and this:
 58 files changed, 19467 insertions(+), 7295 deletions(-), 67 modifications(!)
granted, some of those are Fedora-specific or in-development patches, but that 
does not install confidence that the vanilla hjlu releases are ready for prime 
time.

> >  if trunk really truly was as well
> > tested & stable as you say, then we wouldn't have releases which were
> > badly broken for some targets.  this isn't anything specific to the 2.22
> > branch point, just a reality of development -- bugs slip through.  every
> > release has its own set of issues.
> 
> Long release cycles tend to break less used targets.  I think my
> suggestion will allow shorter release cycles, simply because the
> release process will not impact developer time so much.

i'm not against shortened releases.  i disagree that point releases are a 
waste of time.  Linux certainly has benefited from them.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20120427/990e58b6/attachment.sig>