Hi,
Some weeks (months?) ago we discussed the need for some general
contribution guidelines with mato. That issue has now percolated to the
top in the usual weirdly non-linear pipelined brain process, so here
goes my proposal. The document is mainly meant to point newcomers to
the right place, and also to establish common procedure for us old ...
um ... hackers.
Initial draft follows. Comments on either content or wording/grammar?
nb. it's not intended to be a legal document.
When we have agreed on the guidelines, I'll commit the guidelines to the
rumpkernel.org site and add a link to the "community section" on the wiki.
=== snip ===
The goal of the rump kernel project is to offer free, re-usable,
kernel-quality drivers. Additionally, we offer products built on top of
those drivers, such as the rumprun unikernel.
The emphasis of development is on a well-architected and modular
infrastructure providing the maximal amount of features with the minimal
amount of code. As a rule of thumb, we do not write, port or maintain
code that we can use unmodified and readily tested from other sources.
Contributions
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 covered by a
2-clause BSD license. In exceptional circumstances we will also accept
a BSD-like license, e.g. when a key part of a contribution consists of
code from a third party. Contributions are also to be free of all legal
encumberment such as, but not limited to, software patents. If you are
not the owner of the contribution, e.g. in case working for a company,
you must have appropriate authorization. Copyright remains with the
contributors.
Contributions are divided roughly into two groups: ones needing public
review discussions and ones not needing them. Large, architectural and
controversial changes need public review. Simple and "obviously
correct" changes to not need it. It is not possible to precisely define
the subjective term "obviously", so when in doubt, it is better to err
on the side of too much review. You can find the review process
detailed below in the section "Review process".
When the appropriate review has been undertaken, if you have push access
to the repository you are contributing to, you can push your change.
Otherwise, submit a pull request to the appropriate repository. We do
not require {Approved,Reviewed,etc}-by tags in the commits.
We encourage contributions in the size of minimal self-contained
functional units. For example, if bug fixes are made while working on a
larger feature, it is best to submit the bug fixes 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.
Do not submit changes based on subjective improvements, e.g. "make X
faster" without conducting at least one performance measurement, or
perform churn that "improves" readability. As usual, common sense
prevails here too, e.g. switching from an O(n^2) algorithm to an O(n log
n) may be so "obviously" correct that it does not need benchmarking.
Review process
Review happens by sending a patch to the appropriate mailing list
(currently always [email protected]) with a descriptive
subject. We prefer a single patch and mail for a single contribution
instead of a series of mails and patches (nb. you can still issue the
pull request as a series of commits). Include a few lines of background
information on your contribution so that people not intimately familiar
with the area of your patch can still understand how the patch fits into
the big picture of the rump kernel ecosystem.
Bugs reports
Submit bug reports as issues to the appropriate repositories. If you
have a proposed fix, follow the contribution procedure as described
above. A proposed fix is never required for submitting a bug report.
If you are working on a fix, but it will take some time, submit the bug
report and note that you are working on a fix. We would rather have the
majority of our bugs be known bugs instead of unknown bugs.
=== snip ===
- contribution guidelines (proposal) Antti Kantee
-
