[RFC] Upstart patch policy and workflow

James Hunt james.hunt at ubuntu.com
Thu May 26 19:21:27 UTC 2011


Hi All,

Over the coming week or so, I'll be taking over the stewardship of the
Upstream Upstart branch on launchpad.net (lp:upstart).

This will allow us to ensure that copyrights are audited appropriately
are correct credit is given to contributors.

The plan is to consolidate the outstanding Upstart patches and branches
back into a single "master branch" on launchpad.net as there has been
some confusion recently over this.

What this actually means is that lp:upstart will soon be represented by
a new branch which will include all the code Scott and I worked on for
the Ubuntu 11.04 Natty release. When this actually happens, I'll mail
the list with full details (the old branch will of course still be
available ad infinitum).

As a precursor to that, I'd like to propose a lightweight workflow for
contributing and reviewing of patches / branches. Once we agree on a
process, I'll add it to the wiki [1] (which I'm aware does need to be
updated in places).

== Contributing Changes ==

Having followed the instructions here...

  http://upstart.ubuntu.com/wiki/ContributingCode

... Authors should send changes to the upstart-devel at lists.ubuntu.com
mailing list either as:

  - a unified diff ("diff -up")
  - a link to the launchpad.net branch (or merge proposal)

Diffs should be against either the latest official downloadable release,
or ideally against the tip of the lp:upstart branch.

== Review Policy ==

To be followed by members of the upstart-developers group for reviewing
patches/branches, but also applies to any changes they make too.

Apart from the obvious "does this patch make sense", I propose the
process be:

1. Coding Style

   Ensure the patch has a coding style consistent with the existing
   codebase (see file ./HACKING in the source).

2. Documentation

   Ensure the change is documented, both in code comments and correctly
   formattted ChangeLog entry.

3. Bugs

   If the patch fixes any bugs, ensure they are referenced in the
   ChangeLog.

4. Copyright Agreement

   Ensure developer has signed the Contributor Agreement:

     http://www.canonical.com/contributors
     https://launchpad.net/~contributor-agreement-canonical/+members

5. Tests

   If the patch is for a new feature, ensure that suitable comprehensive
   unit tests have been provided.

6. Build

   Ensure the patch applies cleanly and that "make check distclean"
   works as expected.

7. Run

   Ensure that the resulting build runs as expected and that you can
boot a system using the new build.

=== Sign Off ===

If no problems are found, an email acknowledgement on the mailing list
from an upstart-developer will allow us to get the changes merged into
lp:upstart.

Note that this policy applies to all contributors (including members of
upstart-developers).


Does this sound sensible?

Kind regards,

James.

[1] http://upstart.ubuntu.com/wiki/



More information about the upstart-devel mailing list