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 > > [email protected]? > > 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: <[email protected]> # denzil > > Cc: <[email protected]> # danny > > Signed-off-by: Darren Hart <[email protected]> > > > > 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: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
