Binutils release 2.28 - soon

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Binutils release 2.28 - soon

Tristan Gingold-2
Hello,

if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).

However, commit activity is still high and I'd prefer not to cut arbitrary.
It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

Tristan.

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Jiong Wang-4

Tristan Gingold writes:

> Hello,
>
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
>
> Tristan.

Ping the following three patches:

https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)

They are improvements to GAS and LD testsuite for ILP32 on AArch64.  I
hope they can be included into 2.28

Thanks.


--
Regards,
Jiong
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Alan Modra-3
In reply to this post by Tristan Gingold-2
On Mon, Dec 12, 2016 at 10:49:19AM +0100, Tristan Gingold wrote:
> However, commit activity is still high and I'd prefer not to cut arbitrary.

I suggest that we cut the branch when you have a release candidate.

We don't have anything written about stages of development like the
gcc project, but I think your email should be seen as notice that we
are now in bug fixing mode.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Andrew Pinski-3
In reply to this post by Tristan Gingold-2
On Mon, Dec 12, 2016 at 1:49 AM, Tristan Gingold <[hidden email]> wrote:
> Hello,
>
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

I think it would be good if we get the fixes for AARCH64 ILP32
reviewed and in for 2.28.  I don't know how many are pending right now
though.

Thanks,
Andrew

>
> Tristan.
>
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Yury Norov
On Mon, Dec 12, 2016 at 04:08:46PM -0800, Andrew Pinski wrote:

> On Mon, Dec 12, 2016 at 1:49 AM, Tristan Gingold <[hidden email]> wrote:
> > Hello,
> >
> > if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
> >
> > However, commit activity is still high and I'd prefer not to cut arbitrary.
> > It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
>
> I think it would be good if we get the fixes for AARCH64 ILP32
> reviewed and in for 2.28.  I don't know how many are pending right now
> though.

This is my patches I'd like to see in 2.28:
https://sourceware.org/ml/binutils/2016-12/msg00039.html
https://sourceware.org/ml/binutils/2016-12/msg00167.html

Yury
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Maciej W. Rozycki-3
In reply to this post by Tristan Gingold-2
Hi Tristan,

> if we still follow the new plan, the next release should be made early
> 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut
> arbitrary. It would be nice if the branch could be created this week or
> the next week; if this doesn't work for you, please answer to this mail
> and share your plans!

 I still have a major MIPS feature to commit (which the recent commits are
a preparation to) and don't expect to have it there but by the end of next
week.  I thought you'd be creating the branch after the New Year only --
which I think would be reasonable due to the festive season and people
being busy with other activities.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Nick Clifton
In reply to this post by Jiong Wang-4
Hi Jiong,

> Ping the following three patches:
>
> https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
> https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
> https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
> Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)

All of these patches have been approved by me and are waiting for you to check them in.
If you do not have write access there is bound to be somebody else at ARM who can check
them in for you *cough*Richard Earnshaw*cough*.  But if they are busy then please ping
me and I will take care of it.

Cheers
  Nick

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Jiong Wang-4

Nick Clifton writes:

> Hi Jiong,
>
>> Ping the following three patches:
>>
>> https://sourceware.org/ml/binutils/2016-12/msg00059.html ([AArch64][1/4] Make GAS testcases support ILP32 mode)
>> https://sourceware.org/ml/binutils/2016-12/msg00061.html ([AArch64][2/4] Make LD testcases support ILP32 mode)
>> https://sourceware.org/ml/binutils/2016-12/msg00060.html ([AArch64][3/4]
>> Recognize R_AARCH64_P32_ABS32 as 32-bit relocation in readelf)
>
> All of these patches have been approved by me and are waiting for you to check them in.
> If you do not have write access there is bound to be somebody else at ARM who can check
> them in for you *cough*Richard Earnshaw*cough*.  But if they are busy then please ping
> me and I will take care of it.

Aha, sorry, I am travelling and was relying on terminal mail client,
somehow missed the approve.

All pushed after a quick aarch64-linux build and test OK.

--
Regards,
Jiong
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Palmer Dabbelt
In reply to this post by Tristan Gingold-2
On Mon, 12 Dec 2016 01:49:19 PST (-0800), [hidden email] wrote:
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week;
> if this doesn't work for you, please answer to this mail and share your
> plans!

Thanks for the heads up.  We actually wanted to get a few things upstream
before a release, as our port got merged while still being a bit of a work in
progress.  We've submitted a patch set

  https://sourceware.org/ml/binutils/2016-12/msg00260.html

that we think is sufficient to do a proper release with (ie, maintaining ABI
compatibility forever).  I don't want to cause too much trouble (and I
definitely don't want to hold up a release), but I really don't want to support
a bad set of ABI flags or relocations -- that would be a mess.  Sorry if this
causes trouble!  We'd really just like to get a sane port before anything gets
released.

I'd also like to thank both Kito and Kuan-Lin, as without their help we would
never have been able to get things in as good of a shape as they currently are.
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Cary Coutant-3
In reply to this post by Tristan Gingold-2
> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>
> However, commit activity is still high and I'd prefer not to cut arbitrary.
> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!

Sorry, I meant to respond last week...

I've just checked in -z bndplt support in gold, which is what I really
wanted to get done for 2.28, so I'm OK with whenever you want to
branch.

I still have a bit of a backlog of gold patches to review, but nothing
worth holding up the release.

I'd like to bump the gold version number just before you make the
branch, so if you could give me a heads up, I'd appreciate it.

-cary
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Tristan Gingold-2

> On 23 Dec 2016, at 05:25, Cary Coutant <[hidden email]> wrote:
>
>> if we still follow the new plan, the next release should be made early 2017, which means the 2.28 branch should be created soon (TM).
>>
>> However, commit activity is still high and I'd prefer not to cut arbitrary.
>> It would be nice if the branch could be created this week or the next week; if this doesn't work for you, please answer to this mail and share your plans!
>
> Sorry, I meant to respond last week...
>
> I've just checked in -z bndplt support in gold, which is what I really
> wanted to get done for 2.28, so I'm OK with whenever you want to
> branch.
>
> I still have a bit of a backlog of gold patches to review, but nothing
> worth holding up the release.
>
> I'd like to bump the gold version number just before you make the
> branch, so if you could give me a heads up, I'd appreciate it.

I have just made the branch (I will be away next week so I preferred to make it before).
Do not hesitate to bump the gold version on master and on the branch.

Tristan.

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Maciej W. Rozycki-3
On Fri, 23 Dec 2016, Tristan Gingold wrote:

> I have just made the branch (I will be away next week so I preferred
> to make it before). Do not hesitate to bump the gold version on master
> and on the branch.

 FYI, I'll be automatically pushing all changes I've intended to make as
a part of the current MIPS development effort to this branch then, until
a further notice.

 I'll be away from tomorrow until Jan 8th, and I will have further stuff
to push when I am back, as I won't be able to complete the documentation
and test suite updates tonight for the upcoming MIPS feature I intend to
publish.

 Thanks for the extra work you caused me and Merry Christmas anyway.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Alan Modra-3
On Fri, Dec 23, 2016 at 07:08:20PM +0000, Maciej W. Rozycki wrote:
>  Thanks for the extra work you caused me and Merry Christmas anyway.

Heh.  At least it's really easy to backport with git cherry-pick and
git-merge-changelog.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Matthias Klose-6
In reply to this post by Tristan Gingold-2
[CCing Joel]

On 23.12.2016 10:13, Tristan Gingold wrote:
> I have just made the branch (I will be away next week so I preferred to make it before).
> Do not hesitate to bump the gold version on master and on the branch.

As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
Maybe worth documenting for the release process.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Joel Brobecker
> On 23.12.2016 10:13, Tristan Gingold wrote:
> > I have just made the branch (I will be away next week so I preferred
> > to make it before).  Do not hesitate to bump the gold version on
> > master and on the branch.
>
> As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
> Maybe worth documenting for the release process.

Thanks for the heads up. IMO, we should resume the efforts in trying
to get rid of that date (using the git revision when available instead),
so as to avoid those daily checkins. On the branch especially, they
completely drown the real commits, rendering the branch history
very painful to read.

In the meantime, i've updated the branch name for the date bump.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Matthias Klose-6
On 29.12.2016 05:44, Joel Brobecker wrote:

>> On 23.12.2016 10:13, Tristan Gingold wrote:
>>> I have just made the branch (I will be away next week so I preferred
>>> to make it before).  Do not hesitate to bump the gold version on
>>> master and on the branch.
>>
>> As with the 2.27 branch, the date bumps are not enabled on the 2.28 branch.
>> Maybe worth documenting for the release process.
>
> Thanks for the heads up. IMO, we should resume the efforts in trying
> to get rid of that date (using the git revision when available instead),
> so as to avoid those daily checkins. On the branch especially, they
> completely drown the real commits, rendering the branch history
> very painful to read.
>
> In the meantime, i've updated the branch name for the date bump.

thanks!  I still think using the date is more expressive than using a commit ID.
 So what about only bumping the date if the last commit is not a date bump?

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Maciej W. Rozycki
On Thu, 29 Dec 2016, Matthias Klose wrote:

> > Thanks for the heads up. IMO, we should resume the efforts in trying
> > to get rid of that date (using the git revision when available instead),
> > so as to avoid those daily checkins. On the branch especially, they
> > completely drown the real commits, rendering the branch history
> > very painful to read.
> >
> > In the meantime, i've updated the branch name for the date bump.
>
> thanks!  I still think using the date is more expressive than using a commit ID.
>  So what about only bumping the date if the last commit is not a date bump?

 Depending on the history of a particular commit its date may be out of
order, sometimes way out, which may be confusing and having time stamps
might help -- although we still require any accompanying ChangeLog records
to have the actual date of the commit being applied to a particular
branch.

 OTOH extra commits increase the amount of work required for bisection,
and that can be more costly (e.g. requiring a full toolchain bootstrap per
iteration) than the amount of effort required to reach out for any
ChangeLog update included with a given commit.

 FWIW,

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Joel Brobecker
In reply to this post by Matthias Klose-6
> thanks!  I still think using the date is more expressive than using a
>  commit ID.  So what about only bumping the date if the last commit is
>  not a date bump?

In my opinion, git describe is much much more precise than a date.
Eg:

    % git describe
    ref-tag-190-gdda5790

From there, I know that the commit is 190 commits past a tag called
ref-tag.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Matthias Klose-6
On 30.12.2016 06:48, Joel Brobecker wrote:

>> thanks!  I still think using the date is more expressive than using a
>>  commit ID.  So what about only bumping the date if the last commit is
>>  not a date bump?
>
> In my opinion, git describe is much much more precise than a date.
> Eg:
>
>     % git describe
>     ref-tag-190-gdda5790
>
> From there, I know that the commit is 190 commits past a tag called
> ref-tag.

This only seems to work when there is a tag once the release branch is created.

Reply | Threaded
Open this post in threaded view
|

Re: Binutils release 2.28 - soon

Joel Brobecker
> > From there, I know that the commit is 190 commits past a tag called
> > ref-tag.
>
> This only seems to work when there is a tag once the release branch is
> created.

That's very easily resolved by updating our procedures. And even if a
tag isn't created, the command will go look for the first one past the
branch point.

--
Joel
12