Re: Xen 4.18 release: Reminder about code freeze

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi Stefano,

> On Sep 26, 2023, at 05:05, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Mon, 25 Sep 2023, Henry Wang wrote:
>>> On Sep 25, 2023, at 18:07, George Dunlap <george.dunlap@xxxxxxxxx> wrote:
>>> On Mon, Sep 25, 2023 at 10:35 AM Julien Grall <julien@xxxxxxx> wrote:
>>>> On 25/09/2023 07:40, Henry Wang wrote:
>>>>>> On Sep 25, 2023, at 14:32, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>>> This, for example, would then likely mean
>>>>>> that all Misra work now needs queuing for after the tree re-opens ...
>>>>> 
>>>>> …I also thought about this, to be honest I am tempted to loose the control
>>>>> or at least offer some flexibility on this specific part, as normally 
>>>>> MISRA
>>>>> related changes are harmless and actually harden the code. I am wondering
>>>>> if there are any objections from others…
>>>>> 
>>>>> Committers, would you mind sharing your opinion on this one? Thanks!
>>>> 
>>>> I am split. On one hand, I agree they low risk and would be good to have
>>>> them. But on the other hand, they tend to be invasive and may interfere
>>>> with any bug we need to fix during the hardening period.
>>> 
>>> *Theoretically* MISRA patches should have no behavioral side effects;
>>> but it's quite possible that they will. I'd be in favor of a more
>>> strict view, that they should all go on a separate branch (or simply
>>> be reviewed in-principle and re-submitted after we branch) now that
>>> the feature freeze is done.
>> 
>> Thanks for sharing your opinion. I definitely understand your concern. I 
>> think in
>> Xen Summit we agreed that the release process should not affect the normal
>> code review, so MISRA patches can still be posted to the list and be 
>> reviewed.
>> When the staging reopens, these staged MISRA patches can be committed right
>> away.
>> 
>>> That's my recommendation, but ultimately I'd leave the decision to Henry.
>> 
>> Since this is about MISRA, I would like to wait one more day to see if there 
>> is
>> any input from Stefano, otherwise I think Julien’s suggestion is very good so
>> we can just follow that proposed timeline.
> 
> I am not concerned about MISRA C patches breaking the build because
> Bugseng has been running all their patches through gitlab-ci before
> posting them to xen-devel.
> 
> I agree with Jan that on a case by case basis still allowing some MISRA
> C patches to be committed is okay. I think they should require a
> Release-ack from Henry, so Henry (and the maintainers) can still decide
> which ones are low risk enough to go in, and also limit the amount of
> overall churn. This means that I expect that we are slowing down with
> MISRA C commits.

+1

> 
> I think we should slow down further after RC1 to only few commits and we
> should stop entirely at some point, maybe at RC2. I would suggest after
> RC2 even the least controversial of the MISRA C fixes should not go in,
> unless it is also a bug fix. And even if it is a bug fix, it would be up
> to Henry to decide if it is a bug we want to fix in this release or not.

This is a reasonable plan and I think this is also consistent with the idea
proposed by Julien, so I am ok with it. I would like to suggest that please
CC me in the relevant patches before we branch off 4.18 so that I can respond
in time. Thanks!

Kind regards,
Henry