This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 2.22.1 Possible -> Yes!


On Thursday 26 April 2012 21:30:56 Alan Modra wrote:
> On Thu, Apr 26, 2012 at 08:58:34PM -0400, Mike Frysinger wrote:
> > On Thursday 26 April 2012 20:39:11 Alan Modra wrote:
> > > On Thu, Apr 26, 2012 at 03:29:22PM +0200, Tristan Gingold wrote:
> > > > Ok, I will make a 2.22.1 release.
> > > 
> > > I don't know why we bother with branches.  We just fool users into
> > > thinking that the branches are live, when really, not much activity
> > > takes place on binutils branches.
> > 
> > bugfixes get applied to the branches ... what more activity should there
> > be ?
> 
> Most bugfixes *don't* get applied to the branch.  Take a look at
> change logs if you disbelieve.

i'm not disagreeing that all bugfixes get applied to the branch.  but some do, 
and we get feedback from people as to the really important ones that bite to 
make sure those do get merged.

> Typically you get a flurry of activity
> during the time from a branch being cut to the release (even that is
> wasted developer time, applying patches to both trunk and branch),
> then very little activity after the release.  That makes the 2.22
> branch on major targets, at this point in time, quite inferior to
> trunk.

a release from trunk means 2.23, not another 2.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.  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.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]