[OE-core] Stable Release Process

[Philip Balister]

On 06/03/2013 02:00 AM, Koen Kooi wrote:
> 
> Op 31 mei 2013, om 19:44 heeft Darren Hart <dvhart at linux.intel.com> het volgende geschreven:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> On 05/31/2013 10:34 AM, Martin Jansa wrote:
>>> 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).
>>
>> It has been expressed that this has been challenging to enforce
>> (anything that is freeform is). Do you have any suggestions on how we
>> could address that? Documentation? Firm maintainer policy of willfully
>> ignoring non-tagged patches?
> 
> An email saying "wrong tag, please read README and resubmit" followed by willfully ignoring wrong tags has worked quite well in the past. But only if the README clearly states the tags needed and has a sample git-send-email cmdline.

I find the sample git send-email line in the README to be a huge help
for me.

Philip