On 06.12.2023 18:55, Julien Grall wrote: > On 06/12/2023 02:32, George Dunlap wrote: >> On Tue, Dec 5, 2023 at 2:07 PM Jan Beulich <jbeul...@suse.com> wrote: >>> On 05.12.2023 14:46, Luca Fancellu wrote: >>>> In my opinion, I don’t know of any tool that can address all the >>>> flexibility the Xen codestyle allows, yet the use of automatic >>>> checkers would improve the review time, allow more new contributors to >>>> approach the community without being put down by >>>> the amount of code-style comments, >>> >>> Since this argument is being repeated: I find it odd. No-one needs to even >>> fear any amount of style comments if they simply follow the written down >>> policy plus a tiny bit of common sense. According to my observation, (some) >>> newcomers don't even care to look at what is being said about our style. >>> It's not like you and I haven't been through this. When I started working >>> with GNU toolchain, I had to adopt to their style. When I later started to >>> work with Linux, I had to also adopt there. And then for Xen. And all of >>> that already past closed source projects I had been working on before. > > I am not sure I get the point. With this argument, we are not only > putting load on the contributors but also on the reviewers because we > have to check the style manually while reviewing the code. > > Do you really think this is a good use of our time? Personally I don't > think so and definitely there are more unwritten rule than you let > transpire above. > > A good example is the "_" vs "-". If even a maintainer can't guess it, > then how can a contributor know it?
I didn't even hint at anything unwritten, did I? I certainly agree that things would better be written down. >> Most modern languages, including golang (and I think rust) have >> built-in style correctors (`go fmt` is go's official one). If you >> haven't worked with an automatic style checker / fixer, you don't know >> how much time, hassle, and emotional energy you're saving. I don't >> think I know anyone who, after using one, wants to go back to not >> using one any more. >> >> In general, I'm in favor of making changes to our style such that we >> can make clang's style checker official. The only reason I would vote >> against it is if one of the style requirements was really intolerable; >> but I find that pretty unlikely. > > +1 > >> >> And as I've said before, the main reservation I have going forward >> with this discussion is that I can't see clearly what it is that I'm >> agreeing to. > > +1 > > I found the way we dealt with MISRA rules quite helpful. We had a weekly > meeting to discuss some of the rules and then the outcome was posted on > the ML. Maybe we should do the same here? Any other suggestion how to move? I have mixed feelings with meetings like the Misra ones. That's probably unavoidable because of it being a goal to move fast. I'm not sure the same applies here. But first of all - see also what George said - there needs to be a coherent proposal of what aspects of style to change in which way. The more heavy the changes, the harder it may be for long time contributors to adapt; whether that's a worthwhile price to pay is yet to be determined. Jan
