Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add 'make format' and remove tabs

[Christian Lindig <christian.lindig@xxxxxxxxxx>]

> On 10 Nov 2022, at 09:25, Henry Wang <Henry.Wang@xxxxxxx> wrote:
> 
> Hi Christian,
> 
>> -----Original Message-----
>> From: Christian Lindig <christian.lindig@xxxxxxxxxx>
>> Subject: Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add
>> 'make format' and remove tabs
>>>> While I understand the goal and support, this seems to be a bit too late
>>>> to do it in Xen 4.17 (we are only a couple of weeks away). At this stage
>>>> of the release we should only do bug fix.
>>>> 
>>>> This is clearly only a comesmetic change and there I would argue this
>>>> should be deferred to 4.18. That said the last call is from the RM.
>>> 
>>> I agree with your point. I think maybe defer the patch to 4.18 is better,
>>> given the deep freeze state we are currently in.
>> 
>> I disagree. This is an automated change that can be verified to not add
>> functional changes. Edvin has demonstrated that wrong indentation has
>> mislead reviewers in the past and caused bugs. Nobody except Edvin has
>> contributed to the affected code in years and thus it is not a burden on the
>> project outside the OCaml part. I suggest to accept this.
> 
> I understand points from you, Edwin and Julien, but I think in the earlier
> discussion in this thread, Julien has provided an argument [1] which I do
> think is a valid reason to defer this patch a little bit.
> 
> But since you are the only maintainer of the Ocaml code, so if you strongly
> insist this patch should be included for the release and there would not be
> any more explicit objections from others in the next couple of days, I think I
> will provide my release-ack for the purpose of respecting opinions from the
> maintainer. Hope this solution should be acceptable to you.

Thanks Henry. I think the argument here is the balance between maintaining a 
policy against late large changes and improving the quality and the reliability 
of future patches by using more automation. I agree that large functional 
changes and any change that can’t be verified should be avoided but I don’t 
think this case is one. However, 
I am fine deferring the patch based on an agreed policy if we can make it a 
priority to get in in soon. For me this is part of improving the OCaml code 
base and project quality by using more automation in formatting and the build 
system that lowers the barrier for contributors such that they don’t have to 
worry about procedural aspects like tabs, spaces, indentation, or build 
systems. 

— C