Documentation/committer-responsibilities.md

   1 Expectations for Developers with Open vSwitch Repo Access
   2 =========================================================
   3
   4 Prerequisites
   5 -------------
   6
   7 Be familiar with [CodingStyle.md](../CodingStyle.md) and
   8 [CONTRIBUTING.md](../CONTRIBUTING.md).
   9
  10 Review
  11 ------
  12
  13 Code (yours or others') must be reviewed publicly (by you or others)
  14 before you push it to the repository. With one exception (see below),
  15 every change needs at least one review.
  16
  17 If one or more people know an area of code particularly well, code
  18 that affects that area should ordinarily get a review from one of
  19 them.
  20
  21 The riskier, more subtle, or more complicated the change, the more
  22 careful the review required. When a change needs careful review, use
  23 good judgment regarding the quality of reviews. If a change adds 1000
  24 lines of new code, and a review posted 5 minutes later says just
  25 "Looks good," then this is probably not a quality review.
  26
  27 (The size of a change is correlated with the amount of care needed in
  28 review, but it is not strictly tied to it. A search and replace
  29 across many files may not need much review, but one-line optimization
  30 changes can have widespread implications.)
  31
  32 Your own small changes to fix a recently broken build ("make") or
  33 tests ("make check"), that you believe to be visible to a large number
  34 of developers, may be checked in without review. If you are not sure,
  35 ask for review. If you do push a build fix without review, send the
  36 patch to ovs-dev afterward as usual, indicating in the email that you
  37 have already pushed it.
  38
  39 Regularly review submitted code in areas where you have expertise.
  40 Consider reviewing other code as well.
  41
  42 Git conventions
  43 ---------------
  44
  45 Do not push merge commits to the Git repository without prior
  46 discussion on ovs-dev.
  47
  48 If you apply a change (yours or another's) then it is your
  49 responsibility to handle any resulting problems, especially broken
  50 builds and other regressions. If it is someone else's change, then
  51 you can ask the original submitter to address it. Regardless, you
  52 need to ensure that the problem is fixed in a timely way. The
  53 definition of "timely" depends on the severity of the problem.
  54
  55 If a bug is present on master and other branches, fix it on master
  56 first, then backport the fix to other branches. Straightforward
  57 backports do not require additional review (beyond that for the fix on
  58 master).
  59
  60 Feature development should be done only on master. Occasionally it
  61 makes sense to add a feature to the most recent release branch, before
  62 the first actual release of that branch. These should be handled in
  63 the same way as bug fixes, that is, first implemented on master and
  64 then backported.
  65
  66 Keep the authorship of a commit clear by maintaining a correct list of
  67 "Signed-off-by:"s. If a confusing situation comes up, as it
  68 occasionally does, bring it up on the mailing list. If you explain
  69 the use of "Signed-off-by:" to a new developer, explain not just how but
  70 why, since the intended meaning of "Signed-off-by:" is more important
  71 than the syntax. As part of your explanation, quote or provide a URL
  72 to the Developer's Certificate of Origin in
  73 [CONTRIBUTING.md](../CONTRIBUTING.md).
  74
  75 Use Reported-by: and Tested-by: tags in commit messages to indicate
  76 the source of a bug report.
  77
  78 Keep the [AUTHORS](../AUTHORS) file up to date.