This is the mail archive of the 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 Apr 27, 2012, at 2:39 AM, 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.

I agree that this is true for the 2.22 branch.  For previous releases, there were hot stuff that were checked in just before the release that needed to be tuned.

That's why I am/was reluctant to make a 2.22.1 minor release while I think that 2.21.1 was required.

>> If anyone has patches to backport, please speak up.
> The 2.22 branch doesn't even build with current gcc.  Lots of set but
> unused variable warnings.  I started fixed them all, and backporting
> powerpc patches, then decided the whole process is just an incredible
> waste of developer time.

I agree.  But we don't need to support gcc 4.7.  Binutils 2.22 was released in late 2011, so we tested only with gcc 4.6
(There is still --disable-werror).
To me this is not a stopper.

>  binutils is a stable project.  We don't have
> people contributing new features that might destabilise everything, at
> least not very often.

I agree.  But there were some precedents such as plugins that weren't perfect.

>  So
> - Announce a release is happening in 1 week.  Hopefully people will

[ 1 week is too short, but that's a detail ].

>  take notice, and test their favourite targets.  During this time, 
>  everyone should take a conservative approach to patches.
> - Tag the trunk and release.
> - If the release is a disaster, repeat.

I think there are a few more constraints:

- we need to loosely synchronize with gcc:  if the next gcc release requires a binutils feature, we should/must make a binutils release before.

- Although most of the actions to make a release are scripted, there are still many manual steps.  Making a release still takes time (2 or 3 days), and I have to fit that in my calendar.  Minor releases are much cheaper.  That's why I'd prefer to avoid the repeat step.

- Not many people test their targets.  I do a 'make check' for many targets built on linux, but that's far from perfect.

Of course, if someone wants to join and create a release team, that would be helpful.

Thank you for your comments,

> This wouldn't preclude cutting a branch from the tag point should we
> find that necessary at some later date.
> -- 
> Alan Modra
> Australia Development Lab, IBM

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