NOTICE: Planned style conversion Monday, Jul 17
Hi folks, In a technical meeting many weeks ago we decided to restyle the codebase to Linux kernel style with the intent of easing maintenance burdens, increasing readability and having a common standard across all FRR components. With our pull request backlog presently at a minimum, the plan is to bite the bullet and convert FRR's master branch to Linux kernel style on Monday, July 17. The tooling for this task will be a Python wrapper for the clang-format <https://clang.llvm.org/docs/ClangFormat.html> source code formatter. The script and configuration file for clang-format will be checked in over the coming days prior to conversion. This patch will not be submitted in a pull request. This will be a direct push to master. All stable branches will remain as-is. Code submissions against those branches -- which should by now be limited to bug fixes -- should continue to follow the style guide present in those branches. Going forward we will require all patch submissions against master to conform to Linux kernel style, with some exceptions (DEFUNS primarily) that will be documented prior to conversion and which the Python script knows about. Recommended procedure will be to run the indent script over new code prior to submission. David has offered to write a helper script to ease merges / rebases for currently open pull requests and local branches. Please familiarize yourself with the kernel style guide located here: https://www.kernel.org/doc/html/v4.10/process/coding-style.html It will also be useful to have passing familiarity with clang-format: https://clang.llvm.org/docs/ClangFormat.html https://clang.llvm.org/docs/ClangFormatStyleOptions.html The first page contains instructions on how to integrate it with Vim and Emacs should you wish to do so. The tools are located in the LLVM clang repository, which you can clone by following the instructions here: https://clang.llvm.org/get_started.html Quentin
Quentin Young <qlyoung@cumulusnetworks.com> wrote: > This patch will not be submitted in a pull request. This will be a > direct push to master. All stable branches will remain as-is. Code > submissions against those branches -- which should by now be limited to > bug fixes -- should continue to follow the style guide present in those > branches. I think you should permit backported code, when it is an entire function, to remain in the new style so that it will be easier to verify that the code is the same as in master. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
I'm not sure I understand what the use case is here. At this point patch volume against stable/3.0 and stable/2.0 is low enough that I think this is really an edge case. In any case you can use the -w flag to diff which should get you 90% of the way there. On Fri, Jul 14, 2017 at 7:06 PM, Michael Richardson <mcr@sandelman.ca> wrote:
Quentin Young <qlyoung@cumulusnetworks.com> wrote: > This patch will not be submitted in a pull request. This will be a > direct push to master. All stable branches will remain as-is. Code > submissions against those branches -- which should by now be limited to > bug fixes -- should continue to follow the style guide present in those > branches.
I think you should permit backported code, when it is an entire function, to remain in the new style so that it will be easier to verify that the code is the same as in master.
-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
To move over/adjust any existing branches, please follow the instructions posted at: https://github.com/FRRouting/frr/wiki/Reindenting This should hopefully minimize related annoyance... -David
participants (3)
-
David Lamparter -
Michael Richardson -
Quentin Young