Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
	"Garman, Scott A" <scott.a.garman@intel.com>
Subject: Stable Release Process
Date: Wed, 24 Apr 2013 10:32:54 -0700	[thread overview]
Message-ID: <51781746.2000509@linux.intel.com> (raw)

As the stable releases become first class citizens, we should probably
look at streamlining the process of getting patches to them.

The maintainer for the stable release currently changes by release,
which undoubtedly creates some confusion of where to send patches and
who to CC. These maintainers currently attempt to track these
patches via email filters searching for release branch names and such,
which is proving tedious and prone to missing patches.

Other projects have seen good results using a stable list for this
purpose. This would both make it obvious when a patch is intended for a
stable release as well as remove any confusion about who to Cc as it
would be the same list for all releases. Perhaps something like
openembedded-core-stable@lists.openembedded.org?

In addition to the list, some policy would need to be documented on how
to use the list. For example, it should always be Cc'd, and never
emailed with patches directly that don't go first to the master branch.
Backports being the exception. A policy could also be put in place to
aid in automatic processing, such as that employed by the Linux kernel
stable project. The following would request that the patch be applied to
the denzil and danny stable releases:

Cc: <openembedded-core-stable@lists.openembedded.org> # denzil
Cc: <openembedded-core-stable@lists.openembedded.org> # danny
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

The advantage here over something like a subject tag, "[danny]" is that
it scales a bit better to sending a patch for multiple releases.

There are certainly other approaches, I mention this one as it has a
proven track record and I don't have a reason to deviate from it.

Thoughts?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel



             reply	other threads:[~2013-04-24 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24 17:32 Darren Hart [this message]
2013-05-31 16:34 ` Stable Release Process Paul Eggleton
2013-05-31 17:27   ` Darren Hart
2013-05-31 17:34   ` Martin Jansa
2013-05-31 17:44     ` Darren Hart
2013-06-03  6:00       ` Koen Kooi
2013-06-03 11:18         ` Philip Balister
2013-06-03 16:22           ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51781746.2000509@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=scott.a.garman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox