Feedback for postponing the 4.17 release to a week later

Feedback for postponing the 4.17 release to a week later

[Henry Wang]

Hi all,

Since there will be a batch of XSAs released on Nov. 1 [1] and the original date for
the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the 4.17
release to a week later (Nov. 11) to give a little bit longer time so that:

- The security team won't do anything in rush.
- We can have more feedback after merging these XSAs.
- Include more release-relevant bugfixes.

May I please have some feedback on this proposal? Thanks very much!

[1] https://xenbits.xen.org/xsa/

Kind regards,
Henry

Re: Feedback for postponing the 4.17 release to a week later

[Christopher Clark]

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

On Thu, Oct 27, 2022 at 9:44 PM Henry Wang <Henry.Wang@arm.com> wrote:

> Hi all,
>
> Since there will be a batch of XSAs released on Nov. 1 [1] and the
> original date for
> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the
> 4.17
> release to a week later (Nov. 11) to give a little bit longer time so that:
>
> - The security team won't do anything in rush.
> - We can have more feedback after merging these XSAs.
> - Include more release-relevant bugfixes.
>
> May I please have some feedback on this proposal? Thanks very much!
>

I think you have presented an appropriate rationale for the date
adjustment, so I am supportive of it.

As for effect on downstreams: I don't think that this change of date will
negatively affect OpenEmbedded and Yocto (+CC Bruce for visibility).

Christopher


>
> [1] https://xenbits.xen.org/xsa/
>
> Kind regards,
> Henry
>
>

[-- Attachment #2: Type: text/html, Size: 1497 bytes --]

Re: Feedback for postponing the 4.17 release to a week later

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 811 bytes --]

On 28.10.22 06:43, Henry Wang wrote:
> Hi all,
> 
> Since there will be a batch of XSAs released on Nov. 1 [1] and the original date for
> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the 4.17
> release to a week later (Nov. 11) to give a little bit longer time so that:
> 
> - The security team won't do anything in rush.
> - We can have more feedback after merging these XSAs.
> - Include more release-relevant bugfixes.
> 
> May I please have some feedback on this proposal? Thanks very much!

The alternatives would be:

- not including the XSAs in 4.17 (IMO a bad idea)
- don't do final tests with the XSAs included (another bad idea)

This is a clear indication for me to delay the release, like we did in
similar cases in the past several times.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Feedback for postponing the 4.17 release to a week later

[Julien Grall]

On 28/10/2022 05:43, Henry Wang wrote:
> Hi all,

Hi Henry and others,

> Since there will be a batch of XSAs released on Nov. 1 [1] and the original date for
> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the 4.17
> release to a week later (Nov. 11) to give a little bit longer time so that:
> 
> - The security team won't do anything in rush.
> - We can have more feedback after merging these XSAs.
> - Include more release-relevant bugfixes.
> 
> May I please have some feedback on this proposal? Thanks very much!

Somewhat related. When should we branch for the release and set 
CONFIG_DEBUG=n?

I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we 
usually do it at a point where the tree is nearly frozen.


AFAICT, there are still a few things in flight (including fix for 
XSA-409). So I am not sure we are in position yet to branch. Any opinions?

Cheers,

-- 
Julien Grall

Re: Feedback for postponing the 4.17 release to a week later

[Jan Beulich]

On 28.10.2022 10:57, Julien Grall wrote:
> On 28/10/2022 05:43, Henry Wang wrote:
>> Since there will be a batch of XSAs released on Nov. 1 [1] and the original date for
>> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the 4.17
>> release to a week later (Nov. 11) to give a little bit longer time so that:
>>
>> - The security team won't do anything in rush.
>> - We can have more feedback after merging these XSAs.
>> - Include more release-relevant bugfixes.
>>
>> May I please have some feedback on this proposal? Thanks very much!
> 
> Somewhat related. When should we branch for the release and set 
> CONFIG_DEBUG=n?
> 
> I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we 
> usually do it at a point where the tree is nearly frozen.
> 
> 
> AFAICT, there are still a few things in flight (including fix for 
> XSA-409). So I am not sure we are in position yet to branch. Any opinions?

+1 to it being too early to branch. I would suggest that the XSA batch
should have gone in first and release blockers should have been dealt
with (unless for some it is clear that they're going to be unintrusive),
to limit what needs applying to staging and the new branch.

Jan

RE: Feedback for postponing the 4.17 release to a week later

[Henry Wang]

Hi Julien and Jan,

Thanks for being cautious :)

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Subject: Re: Feedback for postponing the 4.17 release to a week later
> 
> On 28.10.2022 10:57, Julien Grall wrote:
> > On 28/10/2022 05:43, Henry Wang wrote:
> >> Since there will be a batch of XSAs released on Nov. 1 [1] and the original
> date for
> >> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the
> 4.17
> >> release to a week later (Nov. 11) to give a little bit longer time so that:
> >>
> >> - The security team won't do anything in rush.
> >> - We can have more feedback after merging these XSAs.
> >> - Include more release-relevant bugfixes.
> >>
> >> May I please have some feedback on this proposal? Thanks very much!
> >
> > Somewhat related. When should we branch for the release and set
> > CONFIG_DEBUG=n?
> >
> > I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we
> > usually do it at a point where the tree is nearly frozen.
> >
> > AFAICT, there are still a few things in flight (including fix for
> > XSA-409). So I am not sure we are in position yet to branch. Any opinions?
> 
> +1 to it being too early to branch. I would suggest that the XSA batch
> should have gone in first and release blockers should have been dealt
> with (unless for some it is clear that they're going to be unintrusive),
> to limit what needs applying to staging and the new branch.

I agree, therefore I think we can switch to CONFIG_DEBUG=n in the RC
next week after the Nov. 1 XSAs. So we have at least a week after the RC3.

Does this sound ok?

Kind regards,
Henry

> 
> Jan

Re: Feedback for postponing the 4.17 release to a week later

[Bruce Ashfield]

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

On Fri, Oct 28, 2022 at 2:43 AM Christopher Clark <
christopher.w.clark@gmail.com> wrote:

> On Thu, Oct 27, 2022 at 9:44 PM Henry Wang <Henry.Wang@arm.com> wrote:
>
>> Hi all,
>>
>> Since there will be a batch of XSAs released on Nov. 1 [1] and the
>> original date for
>> the 4.17 release was supposed to be Nov. 2, I am thinking to postpone the
>> 4.17
>> release to a week later (Nov. 11) to give a little bit longer time so
>> that:
>>
>> - The security team won't do anything in rush.
>> - We can have more feedback after merging these XSAs.
>> - Include more release-relevant bugfixes.
>>
>> May I please have some feedback on this proposal? Thanks very much!
>>
>
> I think you have presented an appropriate rationale for the date
> adjustment, so I am supportive of it.
>
> As for effect on downstreams: I don't think that this change of date will
> negatively affect OpenEmbedded and Yocto (+CC Bruce for visibility).
>
>
Thanks for the heads up.

We have time in our cycle, so no problems on this end.

Bruce



> Christopher
>
>
>>
>> [1] https://xenbits.xen.org/xsa/
>>
>> Kind regards,
>> Henry
>>
>>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 2829 bytes --]

RE: Feedback for postponing the 4.17 release to a week later

[Henry Wang]

Hi Julien and Jan,

> -----Original Message-----
> > > Somewhat related. When should we branch for the release and set
> > > CONFIG_DEBUG=n?
> > >
> > > I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we
> > > usually do it at a point where the tree is nearly frozen.
> > >
> > > AFAICT, there are still a few things in flight (including fix for
> > > XSA-409). So I am not sure we are in position yet to branch. Any opinions?
> >
> > +1 to it being too early to branch. I would suggest that the XSA batch
> > should have gone in first and release blockers should have been dealt
> > with (unless for some it is clear that they're going to be unintrusive),
> > to limit what needs applying to staging and the new branch.
> 
> I agree, therefore I think we can switch to CONFIG_DEBUG=n in the RC
> next week after the Nov. 1 XSAs. So we have at least a week after the RC3.
> 
> Does this sound ok?

Thank you both for the suggestions!

Just in case I forget this...I saw the xenstore XSAs been merged yesterday,
and hence may I please ask for a clarification if you are ok with the above
plan so we can tag RC3 this week later after master branch is synced with
smoke/staging?

Also I think we need to submit a patch to make the default CONFIG_DEBUG
to n in Kconfig? Thanks!

Kind regards,
Henry

Re: Feedback for postponing the 4.17 release to a week later

[Jan Beulich]

On 02.11.2022 04:00, Henry Wang wrote:
> Hi Julien and Jan,
> 
>> -----Original Message-----
>>>> Somewhat related. When should we branch for the release and set
>>>> CONFIG_DEBUG=n?
>>>>
>>>> I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we
>>>> usually do it at a point where the tree is nearly frozen.
>>>>
>>>> AFAICT, there are still a few things in flight (including fix for
>>>> XSA-409). So I am not sure we are in position yet to branch. Any opinions?
>>>
>>> +1 to it being too early to branch. I would suggest that the XSA batch
>>> should have gone in first and release blockers should have been dealt
>>> with (unless for some it is clear that they're going to be unintrusive),
>>> to limit what needs applying to staging and the new branch.
>>
>> I agree, therefore I think we can switch to CONFIG_DEBUG=n in the RC
>> next week after the Nov. 1 XSAs. So we have at least a week after the RC3.
>>
>> Does this sound ok?
> 
> Thank you both for the suggestions!
> 
> Just in case I forget this...I saw the xenstore XSAs been merged yesterday,
> and hence may I please ask for a clarification if you are ok with the above
> plan so we can tag RC3 this week later after master branch is synced with
> smoke/staging?
> 
> Also I think we need to submit a patch to make the default CONFIG_DEBUG
> to n in Kconfig? Thanks!

Iirc what was done in 4.16 was to switch to non-debug immediately after
branching, on the new branch only. That was specifically to keep debug
enabled at all times (and no undue code churn) in staging. Debug
intermediately off was (earlier on) observed to result in huge Coverity
reports, because of the perceived differences in the pre-processed /
produced code.

Jan

Re: Feedback for postponing the 4.17 release to a week later

[Julien Grall]

On 02/11/2022 07:27, Jan Beulich wrote:
> On 02.11.2022 04:00, Henry Wang wrote: >>
>> Also I think we need to submit a patch to make the default CONFIG_DEBUG
>> to n in Kconfig? Thanks!
> 
> Iirc what was done in 4.16 was to switch to non-debug immediately after
> branching, on the new branch only. That was specifically to keep debug
> enabled at all times (and no undue code churn) in staging. Debug
> intermediately off was (earlier on) observed to result in huge Coverity
> reports, because of the perceived differences in the pre-processed /
> produced code.

That's correct. I will send the patch once we agreed when to branch.

@Henry, From the previous discussion, it seems like we still have some 
blocker. Do we have any update on them?

Cheers,

-- 
Julien Grall

RE: Feedback for postponing the 4.17 release to a week later

[Henry Wang]

Hi Julien,

> -----Original Message-----
> Subject: Re: Feedback for postponing the 4.17 release to a week later
> On 02/11/2022 07:27, Jan Beulich wrote:
> > On 02.11.2022 04:00, Henry Wang wrote: >>
> >> Also I think we need to submit a patch to make the default
> CONFIG_DEBUG
> >> to n in Kconfig? Thanks!
> >
> > Iirc what was done in 4.16 was to switch to non-debug immediately after
> > branching, on the new branch only. That was specifically to keep debug
> > enabled at all times (and no undue code churn) in staging. Debug
> > intermediately off was (earlier on) observed to result in huge Coverity
> > reports, because of the perceived differences in the pre-processed /
> > produced code.
> 
> That's correct. I will send the patch once we agreed when to branch.

Thanks.

> 
> @Henry, From the previous discussion, it seems like we still have some
> blocker. Do we have any update on them?

I think current release blocker board [1] is accurate.

For the update, IIUC, the MSR_VIRT_SPEC_CTRL fix-up is almost there, we
have 2 out of 3 patches already be reviewed (I will provide my release ack now).
Only the patch #2 needs some review from x86 maintainers.

For the other tickets, I am not really sure if there is any updates. I will raise
a topic to discuss in the community call.

[1] https://gitlab.com/groups/xen-project/-/boards/4723605?milestone_title=Release%204.17&label_name[]=Priority%3A%3ARELEASE%20BLOCKER

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall