Branching this weekend

Branching this weekend

[Nick Clifton]

Hi Guys,

   Sorry for the short notice - I just wanted to remind everyone
   that I am going to be creating the branch for the 2.43 release
   this weekend.  So if you have any features that you want to see
   in the release, ping me today.

Cheers
   Nick

Re: Branching this weekend

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Nick Clifton <nickc@redhat.com> writes:

> Hi Guys,

Hi Nick,

>
>   Sorry for the short notice - I just wanted to remind everyone
>   that I am going to be creating the branch for the 2.43 release
>   this weekend.  So if you have any features that you want to see
>   in the release, ping me today.

I was hoping to have a change ready for HPPA to default to not requiring
executable stacks by default but I haven't had a chance to discuss it with Helge
and Dave yet. My testing for it has gone well though.

thanks,
sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: Branching this weekend

[Nick Clifton]

Hi Sam,

> I was hoping to have a change ready for HPPA to default to not requiring
> executable stacks by default but I haven't had a chance to discuss it with Helge
> and Dave yet. My testing for it has gone well though.

Do you think that it might be ready next week ?

I can delay branching for a week if it will help...

Cheers
   Nick

Re: Branching this weekend

[Indu Bhagat]

On 7/12/24 12:11 AM, Nick Clifton wrote:
> Hi Guys,
> 
>    Sorry for the short notice - I just wanted to remind everyone
>    that I am going to be creating the branch for the 2.43 release
>    this weekend.  So if you have any features that you want to see
>    in the release, ping me today.
> 
> Cheers
>    Nick
> 

Hi Nick,

I would really like the SCFI experimental support for aarch64 be a part 
of the release.

The V4 version of the series was recently reviewed. I am close to 
posting V5.  Depending on how the reviews for V5 go, we should be in a 
better position to decide whether there is consensus on this.

Thanks

Re: Branching this weekend

[Nick Clifton]

Hi Indu,

>>    Sorry for the short notice - I just wanted to remind everyone
>>    that I am going to be creating the branch for the 2.43 release
>>    this weekend.  So if you have any features that you want to see
>>    in the release, ping me today.

> I would really like the SCFI experimental support for aarch64 be a part of the release.
> 
> The V4 version of the series was recently reviewed. I am close to posting V5.  Depending on how the reviews for V5 go, we should be in a better position to decide whether 
> there is consensus on this.

OK, in which case I will postpone branching for a week.

I would prefer not to delay any longer than that however
so please do let me know if the v5 series will not be
able to make it in.

Cheers
   Nick

Re: Branching this weekend

[Sam James]

Nick Clifton <nickc@redhat.com> writes:

> Hi Sam,

Hi Nick,

>
>> I was hoping to have a change ready for HPPA to default to not requiring
>> executable stacks by default but I haven't had a chance to discuss it with Helge
>> and Dave yet. My testing for it has gone well though.
>
> Do you think that it might be ready next week ?
>
> I can delay branching for a week if it will help...
>

I was hoping the answer would be yes (as I saw your answer to Indu) but
it's been too hot to run the machine to let me finish testing while
keeping me healthy ;)

Don't worry about the change - it can wait for the next release :)

best,
sam

Re: Branching this weekend

[Maciej W. Rozycki]

On Fri, 12 Jul 2024, Nick Clifton wrote:

>   Sorry for the short notice - I just wanted to remind everyone
>   that I am going to be creating the branch for the 2.43 release
>   this weekend.  So if you have any features that you want to see
>   in the release, ping me today.

 I'm blocked on having correct authorship attribution provided for: 
<https://inbox.sourceware.org/binutils/20230616072536.1805704-1-yunqiang.su@cipunited.com/>, 
which I have a fixed version of ready to push, and which I want to see in 
2.43.  I guess this probably is not something that should prevent you from 
branching unless you want to cut the release right away (which I gather is 
not the case) as I can just push it to master and backport instead in the 
stability period.

  Maciej

Re: Branching this weekend

[Nick Clifton]

Hi Maciej,

>   I'm blocked on having correct authorship attribution provided for:
> <https://inbox.sourceware.org/binutils/20230616072536.1805704-1-yunqiang.su@cipunited.com/>,
> which I have a fixed version of ready to push, and which I want to see in
> 2.43.  I guess this probably is not something that should prevent you from
> branching unless you want to cut the release right away (which I gather is
> not the case)

Correct - I will be evaluating the branch for at least 2 weeks.

> as I can just push it to master and backport instead in the
> stability period.

Please do this when you are ready.

Cheers
   Nick

Re: Branching this weekend

[Maciej W. Rozycki]

Hi Nick,

> >   I'm blocked on having correct authorship attribution provided for:
> > <https://inbox.sourceware.org/binutils/20230616072536.1805704-1-yunqiang.su@cipunited.com/>,
> > which I have a fixed version of ready to push, and which I want to see in
> > 2.43.  I guess this probably is not something that should prevent you from
> > branching unless you want to cut the release right away (which I gather is
> > not the case)
> 
> Correct - I will be evaluating the branch for at least 2 weeks.

 Great!

> > as I can just push it to master and backport instead in the
> > stability period.
> 
> Please do this when you are ready.

 My sources have confirmed that the change was not actually developed at 
ImgTec/MIPS so I have committed it now and backported to 2.43 with the 
author set to YunQiang Su and myself as a co-author for the multitude of 
clean-ups made.  Thank you for the pre-approval for 2.43.

 I have a couple of follow-up clean-ups and improvements ready for master, 
but I'll wait with them for the release so as not to make master diverge 
from 2.43 unnecessarily.

  Maciej

Re: Branching this weekend

[Nick Clifton]

Hi Maciej,

>   My sources have confirmed that the change was not actually developed at
> ImgTec/MIPS so I have committed it now and backported to 2.43 with the
> author set to YunQiang Su and myself as a co-author for the multitude of
> clean-ups made.  Thank you for the pre-approval for 2.43.
> 
>   I have a couple of follow-up clean-ups and improvements ready for master,
> but I'll wait with them for the release so as not to make master diverge
> from 2.43 unnecessarily.

Excellent - I am glad that it worked out.

Cheers
   Nick

Re: Branching this weekend

[Nick Alcock]

On 22 Jul 2024, Nick Clifton verbalised:

> Hi Maciej,
>
>>   I'm blocked on having correct authorship attribution provided for:
>> <https://inbox.sourceware.org/binutils/20230616072536.1805704-1-yunqiang.su@cipunited.com/>,
>> which I have a fixed version of ready to push, and which I want to see in
>> 2.43.  I guess this probably is not something that should prevent you from
>> branching unless you want to cut the release right away (which I gather is
>> not the case)
>
> Correct - I will be evaluating the branch for at least 2 weeks.

Presumably there's no objection to bugfixes and reversals of
in-hindsight-ill-advised changes made in trunk between the branch and
release? I have some libctf stuff coming up in the next day or so...

(Mostly bugfixes, but also one addition of a bit of API to make the
recent change to block addition of duplicate enumerators in enums an
opt-in feature instead of always-on, since horrifyingly existing
programs really do rely on this even though C obviously prohibits such
things in C itself. e.g. it turns out pahole can stuff duplicate
enumerators into the BTF it emits, and it turns out to hugely complicate
BTF->CTF converters for libctf to unequivocally ban it.)

-- 
NULL && (void)

Re: Branching this weekend

[Nick Clifton]

Hi Nick,

>> Correct - I will be evaluating the branch for at least 2 weeks.
> 
> Presumably there's no objection to bugfixes and reversals of
> in-hindsight-ill-advised changes made in trunk between the branch and
> release? I have some libctf stuff coming up in the next day or so...

Bug fixes - please go ahead.

API reversals are ... more of a grey area.  If the bit of the API
that you are changing is new - ie not yet in any binutils release -
then changing it is OK.  (As long as you are sure that the change
is correct).  If the part that you want to change is an established
component of the API then I would be against the change.  Last minute
changes often have repercussions that are not apparent at the time
that they are made.  So giving a change time to percolate in the
development sources is usually a good idea.

Cheers
   Nick

Re: Branching this weekend

[Nick Alcock]

On 30 Jul 2024, Nick Clifton outgrape:

> Hi Nick,
>
>>> Correct - I will be evaluating the branch for at least 2 weeks.
>> Presumably there's no objection to bugfixes and reversals of
>> in-hindsight-ill-advised changes made in trunk between the branch and
>> release? I have some libctf stuff coming up in the next day or so...
>
> Bug fixes - please go ahead.
>
> API reversals are ... more of a grey area.  If the bit of the API
> that you are changing is new - ie not yet in any binutils release -
> then changing it is OK.

It is. And the API thing was more of a "this is a new restriction too
far -- lift it by default", so it acts like it used to in earlier
releases.

>                          (As long as you are sure that the change
> is correct).  If the part that you want to change is an established
> component of the API then I would be against the change.

It's a new API function which can be used to set a flag which changes
the ctf_add_enumerator() API so it works differently from how it does in
trunk (but like it did in previous releases, since that change broke
real users).

>                                                           Last minute
> changes often have repercussions that are not apparent at the time
> that they are made.  So giving a change time to percolate in the
> development sources is usually a good idea.

Absolutely! If you'd rather I hold off with the API part of things, I
can do that. (At least one of the bugfixes is... more urgent, since it
can be used to cause writing into freed memory, ugh. That one I'm
backporting all the way to its introduction.)

-- 
NULL && (void)