Re: 2.22.1 Possible -> Yes!

[Fred Cooke <fred dot cooke at gmail dot com>]

Bump for full migration to Git before a future 2.24.0 release. (and
after a subset of 2.23.X releases)

The current release has gone a bit wrong, and because I can't
comprehend how that was possible, it must be some of the *magic* from
the system that Linus described as "worse than emailing patches
around".

This. Is. Worth. It.

Fred.

On Fri, Apr 27, 2012 at 7:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
> On Friday 27 April 2012 10:33:23 H.J. Lu wrote:
> > On Fri, Apr 27, 2012 at 7:28 AM, H.J. Lu wrote:
> > > On Fri, Apr 27, 2012 at 7:26 AM, Mike Frysinger wrote:
> > >> On Friday 27 April 2012 09:27:48 H.J. Lu wrote:
> > >>> On Fri, Apr 27, 2012 at 3:37 AM, Alan Modra wrote:
> > >>> > On Fri, Apr 27, 2012 at 12:07:15AM -0400, Mike Frysinger wrote:
> > >>> >> Gentoo used to but found them too unstable.  so once the GNU
> > >>> >> releases started picking up, we stopped relying on his snapshots.
> > >>> >
> > >>> > HJ's snapshots are binutils trunk + some HJ patches.  One person
> > >>> > decides when to release, and works on stabilising that release.  The
> > >>> > entire binutils team ought to do better, don't you think?  Well, at
> > >>> > least there's some chance we will!
> > >>>
> > >>> If a binutuls can build kernel, gcc, glibc and binutils on x86, it is
> > >>> good enough for me.  Any binutils release has bugs (some may be
> > >>> critical), which may not be known if it isn't released.   I will make
> > >>> sure that all bugs are fixed as soon as possible.  I don't see why it
> > >>> should take a month to make a release.  A week should be plenty.  You
> > >>> just deal with bugs.
> > >>
> > >> yes, and the way you effectively deal with them is by branching and
> > >> doing point releases.  constant releases from trunk won't help as there
> > >> is always development going on there.
> > >
> > > Just freeze trunk for a week to make a release and move on after
> > > that.
> >
> > We don't have to make each release from trunk as a major release.
> > Trunk can be
> >
> > 2.23
> > 2.23.1
> > 2.23.2.
> > ..
> >
> > At any time, we can call trunk 2.24.
>
> yeah, i don't think that works.  it implies stability of patch choices which
> is not the case at all and goes against the versioning expectations of just
> about every other major project out there.
> -mike