Issues for general cleanup?
boaks opened this issue · comments
As mentioned in add ccm - comment on too many whitespace change the current code seems the have a mixed up format.
Therefore I would like to collect some input for a general cleanup.
From my side:
- whitespace format
- license update to EPL v2.0
- logging:
- check messages (e.g. calls
dtls_debug_dumpalready with a ":" at the end of the name), - remove eols ("\n") from the messages and add that to the print functions in
dtls_debug.
- check messages (e.g. calls
Such general cleanups usually "locks the code for some time", so maybe it's also worth to get some feedback, what should be done before (e.g. merging selected open PRs).
One task would be to adjust existing code to follow the basic coding style outlined in CONTRIBUTING and enforce contributions to follow that style. In another project, I am currently testing a clang-format specification that does almost the right thing. (The problem with these tools is that you need to write a lot of annotations where you want to deviate from the strict formatting rules.)
Regarding license update: What would be the reasons for undergoing the enormous pain of changing the license model? I presume you would not do this unless there is something entirely wrong with the existing EPL v1.0/EDL v1.0.
I may be wrong, but I assume, a new release requires a 2.0.
enormous pain
Because the difference in the license?
It mainly enables the user to combine it with code under GPL, if they want/need to do so.
Or because the editing?
Tinydtls is tiny, the editing will be done fast.
For some coorporate user it may be also important to have a "SPDX-License-Identifier: EPL-?.0" in order to apply scanners. That would anyway cause the edit.
I may be wrong, but I assume, a new release requires a 2.0.
Okay, more reading to do for release preparation.
The pain arises from reading legal stuff: All tinydtls users will have to make their lawyers process the new license. It is not the editing that makes license changes difficult but the changed contents of the license. I have not yes compared the two documents or read discussions that may have commented on the changes but then again, this is exactly what I meant with "pain".
Yes, some may require to read it.
But many people and companies are common to EPL 2.0 and therefore I consider, that processing it by lawyers is a rare exception.
EPL 2.0 is not intended to make the use harder, it's intended to make it easier.
In another project, I am currently testing a clang-format specification that does almost the right thing. (The problem with these tools is that you need to write a lot of annotations where you want to deviate from the strict formatting rules.)
As long as the tool is used manually, that should not cause too much trouble. I would propose to go with one commit with the applied format, and one commit (maybe one per file), which need manual corrections of that.
I would propose, to spare out the included third-party stuff as, "aes/rijndael" or "sha2/sha2".
If agreed, we may also update the copyright times for the EPL files.
My first experience with ".clang-format" using VS Code is promising.
It's also possible to apply a change only on a change section.
FMPOV, using it manually and not automated, will make it possible to have a couple of "custom formatted sections" (hopefully not too much) while the main parts will be formatted accordingly.
(When it gets clear, how many section requires a custom format, we may consider again to use the "protection comments".)
Follow the coding conventions, e.g.:
static inline uint8_t
contains_cipher_suite(...args...) {
(The function name starts on its own line, the opening brace is on the same line as the last formal parameter.)
As a comment, 74 of the git tracked files have lines that end in white space. Things code wise need to be stable before this is changed.
It can get a bit annoying, but I just now
$ cp .git/hooks/pre-commit.sample .git/hooks/pre-commit
which will then trap any files I am trying to commit with whitespace errors (have been doing this for some time in libcoap)
In my experience, it easier to do such cleanup on a "code-freeze" period.
Even if I don't know, when we will be ready with the pending PRs :-).