Hi Roger, >> >> 3) The size of the patch after applying clang-format is huge. Really. >> Something >> like 9 MB. Even if everyone agrees that the approach is good and we can >> proceed >> with it, it is highly unlikely anyone will be able to review it. Considering >> that new patches are being added to the upstream during such a review, it may >> also lead to new code style violations or require a new review of that huge >> patch. > > I think this approach is difficult. It would likely introduce a lot > of noise when using `git blame` (I know, it's just one extra jump, > but...), plus would likely break every patch that we currently have > in-flight.
I think we already discussed this in the past and having some churn was accepted, also about breaking existing patches, every change merged has the potential to do that, this one is more likely but it’s the game I guess? > >> 4) Which clang-format version should we set as the one used by Xen, so it is >> easy for everyone to use it on their hosts? >> >> 5) You name it. I think many people in the community can name their points >> for >> and against clang-format. > > What are the parts of our coding style that clang-format cannot > correctly represent? Could you make a list of what would need to > change in Xen coding style for it to match perfectly what clang-format > will check? we already went through that route, there is no checker anywhere that matches the Xen coding style perfectly, so it’s either we change the coding style or we don’t proceed further with any automatic check > > Ideally the first step would be to prepare a patch to adjust the > coding style so it's in line with what clang-format will do. It’s easy to say that, but difficult to implement, if we could accept the clang-format rules it would be easier to adopt the configuration itself as coding style, maybe enhanced with some comments. Cheers, Luca
