[OE-core] Stable Release Process

[Martin Jansa]

On Fri, May 31, 2013 at 05:34:51PM +0100, Paul Eggleton wrote:
> Hi Darren,
> 
> Sorry it's taken me so long to reply to this.
> 
> On Wednesday 24 April 2013 10:32:54 Darren Hart wrote:
> > 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 at lists.openembedded.org?
> 
> In the OE-Classic days we used to have an openembedded-stablebranch mailing 
> list for the same purpose. I don't recall anyone complaining about that when 
> we had it, so this sounds like it could help with the aforementioned issues.
> 
> The downside I can see is that it's one more mailing list with the associated 
> problems of not everyone monitoring it ("that patch of mine shouldn't have 
> been backported!" or "you backported one of my patches but missed an 
> associated one"), and new users erroneously emailing it with requests for help 
> that should have gone to the normal mailing list. That could however be 
> outweighed by the advantage of stable branch patches not being drowned out by 
> the rest of the patches as they currently can be.
> 
> > 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 at lists.openembedded.org> # denzil
> > Cc: <openembedded-core-stable at lists.openembedded.org> # danny
> > Signed-off-by: Darren Hart <dvhart at 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.
> 
> I'm not familiar with this, but I've never had any direct contact with the 
> kernel patch submission process so that might explain it. I have to say I'm 
> not unhappy with the existing convention we have of marking it in the title of 
> the email though.
> 
> I'd like to hear more opinions from others, particularly submitters of stable 
> branch patches and other stable branch maintainers who have been doing it 
> longer than I have. Ping...?

I like subject tags, at least because they are nicely shown in patchwork
subject, so I can easily sort incoming patches to right bundles.

And this problem with scaling when sending a patch for multiple
releases we already have when tagging multiple affected layers (which happens
more often for meta-oe layers then multiple releases).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130531/edd846f4/attachment-0002.sig>