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

[Henry Wang <Henry.Wang@xxxxxxx>]

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
> > 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. 

Thanks for your understanding. I will take a note of this patch and try to ping
committers to commit this patch as soon as the staging tree gets unfrozen
after the release. In this way I think your concerns in...

> 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.

...here would be minimized.

I do understand your points and frustration. Thanks again for your
understanding.

Kind regards,
Henry

> 
> — C