On 06/02/17 12:19, Илья Шипицин wrote: > > it is the same as previous version of this patch, which I sent before > your guidelines, and you did not complain earlier. > it is not clear, how 167 chars long might be bad or good. for me it is > just 167 chars.
You do understand and realize you just prove my earlier points and make
them really obvious? ... you seem not to read and learn ... from the
same URL [1] already provided several times now:
The seven rules of a great Git commit message
---------------------------------------------
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
[1] <http://chris.beams.io/posts/git-commit/#seven-rules>
As a clever person once said: "I can only provide the information, I
cannot make you understand it".
> it is not trivial to be sure that it will fit your expectation.
> as an example, there are automatic tests. and you are ok with that.
First ... *read* URL[1], *read* the 7 guidelines above.
Code itself can be automated tested. But the syntax of the code needs
to be correct to be possible to test it. From my point of view, making
an analogy: You break the syntax. It doesn't compile. Which means the
result isn't testable.
> we should not assign machine job to a man, just involve some
> automation which will tell "your commit message is too long" without
> involving your time.
Those seven rules are not that far away from the coding style guidelines
we all are being picked at from time to time (*including* myself).
It is first and foremost the submitters responsibility to ensure that
everything is in order before doing the submission. And we have both
on-list, off-list and IRC requests from time to time, where people ask
what kind of guidelines we use, where to find them and so on. This is a
pretty common behaviour by most community contributors, not even
remotely unique to OpenVPN. What you want is a way to not take proper
ownership of your contribution, moving the responsibility out of your area.
Sorry, this is not going to happen.
And I don't think I will even have much to say for the future in this
regards.
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
