Your Thoughts Wanted — OpenSSL Source Code Reformat

1. Initial Reaction
It's a definitely positive change. Current formatting tooling is not maintainable.
2. There is no direct impact on my workflow but I would be glad to maintain the automation for new foramtting
3. Style format absolutely doesn't matter. The most important it will be consistent.
4. openssl repository has configuration for pre-commit framework. It will check formatting in the CI and you can run it locally to reformat your changes according to the OpenSSL style.

1. I support it, it would save me plenty of PR preparation iterations

2. I do (though not like an individual), I currently have ~60 patches and I would strongly appreciate the procedure to automate the reformatting of the patches.

3. yes if we stop making reformatting once a several years :)

4. Script that would allow me to reformat patches
   

What is this? A mature project or group of beginners? Looks like second.

Did you know how will look git history?

Yet another reformat in 5 years?

I mostly agree with this. It is not a good look and will screw up history. I also don't think that this is the first mass reformat in the project's history.

Nonetheless there are lots of poorly formatted legacy files in the tree and cleaning them up would be beneficial.

To my mind, the webkit format is sufficiently different from the current style guide that it causes too much needless reformatting. If we could tweak the webkit format so it's more like what we currently use, the changes would be better controlled. clang-format is extremely flexible and can be made a lot closer to our current formatting style than webkit is.

1. Initial Reaction

• ClangFormat is undoubtedly good. Not only does it end style change PR comments, but it also supports certain readability improvements that are hard for humans to manipulate.

• I successfully moved a few projects in my organization, and I have experience to share.

• Clang-format is not 100% stable after configuration. Over time, the default format can slightly change (sometimes due to bug fixes). We should try our best to lock it down.

2. Impact on Your Workflow

• It seamlessly integrates with VS Code.

3. Formatting & Accessibility

• We should keep the existing OpenSSL style as much as necessary by replicating the style in ClangFormat. I'm not saying "as much as possible," because some styles:

  • May not be very readable; created merely to simplify editing. Some existing styles in ClangFormat are close in spirit but look better.

  • May not be available in ClangFormat. In that case, we should consider contributing it to ClangFormat if that provides high value. If not, give it up.

4. Tooling & Transition Help

• Don't be afraid of implementing new styles in ClangFormat. It's really easy, often a few lines of code plus tests. I did that for my organization, and there are other people in my organization who did that, too. Our organization is not an LLVM vendor by any means.

IMO there are good reasons to do it. So do it with least pain to everyone: Support instructions (incl. timeline) and software should be available for everyone impacted (both local for pre-commit validation, as well as in CI): authors of existing PRs/patches as well as future contributors and reviewers. Consider making available a guaranteed-in-line-with-CI cross-platform (eg docker based) local format checker tool to avoid "surprises in CI" as also I have made the experience that @Zhihao Yuan shared: "Clang-format is not 100% stable after configuration". Ideally this works both for automated running via pre-commit hooks as per @Dmitry Misharov suggestion as well as fully stand-alone for folks accustomed to running `util/check-format.pl` (maybe hide all logic behind that script, so nobody notices there's been a reformat to begin with :).

A related thought: When the roll-over occurred, make an (automated/scripted) comment to all open PRs, informing authors of the need to update the PR (with a link to instructions how to do it). Use this as an opportunity to weed out actually inactive PRs (e.g., script-close them if no re-format occurred after 2 months) which helps everyone (tagging @Matt Caswell particularly) bring down the PR backlog without any additional work.

That said, nothing in this is specific to this community and the discussion should be a general one happening between everyone impacted in any community to avoid others wasting time writing down things already discussed in another community silo.

1. I support a consistent coding style and also tool-based formatting. But switching the coding style a do a project-wide re-formatting will have dramatic impact to the code history in Git.

2. As a contributor, I will be affected in upcoming PRs. Tooling support for checking changes upfront would be great, as it reduces the effort for my work (and the reviewer's efforts).

3. An automated code formatting would help a lot, for contributing and for increased readability of the code.
   But I would prefer to keep the current coding style and enforce formatting in a first step only to new code or changes. This could help to reduce the impact on the code history.

4. I would like to have tooling support for formatting complete files as well as format-checkers for patches. The latter should also be triggered in the PR workflow.

The coding style of OpenSSL is different to most of the other open-source projects, I'm contributing. As much as I would welcome having a consistent coding style across all my open-source projects, I would prefer to maintain the existing coding style in OpenSSL. The impact on code history in Git is too serious.

I also support this, as it would improve the code readability for me. However, this may lead to git history pollution, which can make it difficult to follow up on. I tried to look up how other projects address this issue and found that `.git-blame-ignore-revs` is a potential solution for a big project like openssl - chromium, which encountered a similar problem. I would suggest everyone to have a look at their discussion as well, as it raises similar concerns like ours - https://groups.google.com/a/chromium.org/g/cxx/c/HT9ZRFgZ1ME?pli=1 and suggests some alternate ideas like -

• reformat only the lines you touch in a change list, so in this way, new code is always properly formatted, but old code stays untouched until it’s modified or

• when comparing versions (old vs new), run clang-format on both sides before diffing

this also mentions a specific example of a "constructor initializer list" in their codebase, where clang-format conflicts with the developers' preferred style, and suggests that it is not completely ready, which again, can be modified as per our requirements, as suggested by Zhihao.

Looking at all of this it doesn't seem there exists a strong consensus to do this reformatting. Are there discussions in the other silos/communities? The "small business" one is a bit "curt"... What does anyone else say (most notably committers)?

And: Is there a point in re-hashing this decision at all, i.e., are we only talking about how to mitigate the negative side effects (my assumption so far) or are the Boards of Directors willing to reconsider the decision to re-format (assuming such decision exists)?

Or in other words, could you please re-state your original formulation more clearly @Aditya Koranga :

Is it "The OpenSSL team plans to reformat the entire codebase using clang-format, following the WebKit coding style and seeks your input on whether and how to do it." or is it "The OpenSSL Boards of Directors have decided to reformat the entire codebase using clang-format, following the WebKit coding style and welcomes your input on highlighting potential negative consequences on your work and suggesting mitigations to those." ?

@Michael Baentsch Hi,

I don't see a related thread in committers group or other. @Dmitry Belyavsky did you get chance to discuss this with committers group or do you think to do this in future?

My intention for creating this thread was to get the feedback from individual community (now feedback can be both positive and negative), as I believe if there are any major changes in the openssl library then it is a good idea to discuss about it with the community members such as Individuals(which i represent) - to know what are their thoughts about that, do they support it or not, if such major changes happens in future then what effect that will have on the individuals( again can be both positive & negative) and do they have any better or creative idea that they can suggest, and what type of transition support they will need or can suggest and more.

When i say 'OpenSSL team' then I am not only talking about Board of directors. It covers more- The OpenSSL Corporation engineers, C-TAC, C-BAC, and similarly OpenSSL Foundation, F-TAC and F-BAC and boards of directors, etc.. In the last Foundation TAC meetings we were discussing about this point also and we wanted to know what community groups think about this and part of which I started these threads to get the feedbacks from the respective groups.