[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xen Coding style

On 08.05.20 16:23, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 8:18 AM Jürgen Groß <jgross@xxxxxxxx> wrote:

On 08.05.20 14:55, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 6:21 AM Julien Grall <julien@xxxxxxx> wrote:

Hi Jan,

On 08/05/2020 12:20, Jan Beulich wrote:
On 08.05.2020 12:00, Julien Grall wrote:
You seem to be the maintainer with the most unwritten rules. Would
you mind to have a try at writing a coding style based on it?

On the basis that even small, single aspect patches to CODING_STYLE
have been ignored [1],

Your thread is one of the example why I started this thread. Agreeing on
specific rule doesn't work because it either result to bikesheding or
there is not enough interest to review rule by rule.

I don't think this would be a good use of my

I would have assumed that the current situation (i.e
nitpicking/bikeshedding on the ML) is not a good use of your time :).

I would be happy to put some effort to help getting the coding style
right, however I believe focusing on an overall coding style would value
everyone's time better than a rule by rule discussion.

If I was promised (reasonable) feedback, I could take what I
have and try to add at least a few more things based on what I find
myself commenting on more frequently. But really I'd prefer it to
be done the other way around - for people to look at the patches
already sent, and for me to only subsequently send more. After all,
if already those adjustments are controversial, I don't think we
could settle on others.
While I understand this requires another investment from your part, I am
afraid it is going to be painful for someone else to go through all the
existing coding style bikeshedding and infer your unwritten rules.

It might be more beneficial for that person to pursue the work done by
Tamas and Viktor in the past (see my previous e-mail). This may mean to
adopt an existing coding style (BSD) and then tweak it.

Thanks Julien for restarting this discussion. IMHO agreeing on a set
of style rules ahead and then applying universally all at once is not
going to be productive since we are so all over the place. Instead, I
would recommend we start piece-by-piece. We introduce a baseline style
checker, then maintainers can decide when and if they want to move
their code-base to be under the automated style checker. That way we
have a baseline and each maintainer can decide on their own term when
they want to have their files be also style checked and in what form.
The upside of this route I think is pretty clear: we can have at least
partial automation even while we figure out what to do with some of
the more problematic files and quirks that are in our code-base. I
would highly prefer this route since I would immediately bring all
files I maintain over to the automated checker just so I never ever
have to deal with this again manually. What style is in use to me
really doesn't matter, BSD was very close with some minor tweaks, or
even what we use to check the style just as long as we have

Wouldn't it make more sense to have a patch checker instead and accept
only patches which change code according to the style guide? This
wouldn't require to change complete files at a time.

In theory, yes. But in practice this would require that we can agree
on a style that applies to all patches that touch any file within Xen.
We can't seem to do that because there are too many exceptions and
corner-cases and personal-preferences of maintainers that apply only
to a subset of the codebase. So AFAICT what you propose doesn't seem
to be a viable way to start.

I think long ago we already agreed to have a control file which tells a
style checker which style to apply (if any). As a start we could have a
patch checker checking only the commit message (has it a Signed-off-by:
etc.). The next step would be to add the control file, and the framework
to split the patch into the changed file hunks and passing each hunk to
the correct checking script (might be doing nothing in the beginning).
And then we could add some logic to the single checkers.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.