On 07/05/15 17:49, Martin Lucina wrote:
Contributions to the rump kernel project are defined as changes
hosted under repo.rumpkernel.org and include, but are not limited
to, documentation and code. All code contributions are to be
I'd re-word this as
Contributions to the rump kernel project are defined as changes submitted
to the repositories hosted under repo.rumpkernel.org and include ...
ok (that's what I thought I'd written anyway. i blame coffee ;)
Also, repo.rumpkernel.org currently redirects to repositories hosted on
Github under the "rumpkernel" organisation. You might want to explicitly
mention that somehow since most people will not "see" a clone of / links to
repo.rumpkernel.org.
I don't know how to succinctly express that in this document without
either adding to confusion or using multiple sentences to explain
something which is not the subject matter all.
I'd expect someone to read the guidelines before their first
contribution, check out what repo.rumpkernel.org is, and the matter
being clear after that.
That said, if you or someone else can suggest text, I'll incorporate it.
Do we want Signed-off-by tags and the associated "Certificate of Origin"?
This is eg. used also by the Xen project:
http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Signing_off_a_patch
Such sign-off *may* make it easier if someone wants to do a legal audit of
the code/licensing.
I personally don't see it worth the fuss, and unless some software
lawyer with enough street cred tells me otherwise, I'm not going to
start seeing otherwise.
What happens e.g. if someone forgets to include a Signed-off from
something that hits master? I worry about establishing rules which are
not enforced.
At any rate, >99% of our code comes from a source without Signed-off.
However, if enough people want to require them, sure.
independently -- trivial bug fixes also do not need review. Also,
if independently useful functionality is developed as part of a
larger change, contributing it individually is encouraged.
... contributing it as individual changes ... ?
ok (except singular, since "functionality" is singular), plus being more
explicit about "it":
"Also, if independently useful functionality is developed as part of a
larger change, contributing that functionality as an individual change
is encouraged."
faster" without conducting at least one performance measurement, or
perform churn that "improves" readability. As usual, common sense
The bit about churn that "improves" readability has a somewhat sarcastic
tone to it... eg. I'd be more than happy if someone went through all of
what is left of the Mini-OS code and reformatted it to match a single style
and tabs/spaces scheme, it's a total mess.
good that you caught the tone ;)
(arguably, documents like contribution guidelines shouldn't have a tone,
but I'll pull the "we're all (semi-)human" card)
You didn't quote the part which said "subjective". While the overall
style is subjective, once a style is defined, code observably either
conforms to that style or it doesn't, no room for debate. (we use the
NetBSD style, which is more or less the same as the Berkeley Kernel
Normal Form, a.k.a. KNF)
As for your case of Mini-OS specifically, I'm undecided whether the code
should be reformatted to conform or not. On one hand it is, like you
note, not very consistent, and while I think we've abandoned the
prospects of a full upstream sync, I don't know if we're still going to
have bidirectional patches with upstream. Usually, if it's undecided
whether something is an improvement, it's best to do nothing. The
previous sentence is also the distillate of the tonal paragraph; that,
and "common sense prevails".
Hmm. Maybe it's better to be shorter. I added "observable improvement"
to the definition of contribution and removed the tonal paragraph.
I put a full version of the current draft at:
http://testing.rumpkernel.org/contrib.txt
