This is the mail archive of the
mailing list for the binutils project.
Re: 2.22.1 Possible -> Yes!
- From: Fred Cooke <fred dot cooke at gmail dot com>
- To: binutils <binutils at sourceware dot org>
- Date: Wed, 24 Oct 2012 11:51:03 +0200
- Subject: Re: 2.22.1 Possible -> Yes!
- References: <4F97F997.email@example.com> <CAMe9rOoR_7AZnf0_AgcVkX=7Fh30-zd3KSTiNQCOoF2=u9w85Q@mail.gmail.com> <CAMe9rOpX4a3gwuXZHc3fZTKMZ5C=xCXoDgVyxzGmr7tRaS9mmg@mail.gmail.com> <firstname.lastname@example.org>
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
This. Is. Worth. It.
On Fri, Apr 27, 2012 at 7:23 PM, Mike Frysinger <email@example.com> 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.