Stable Release Process
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 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:
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?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 9 lines · 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.
Quoted 5 lines
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.
Quoted 12 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>
Quoted 5 lines
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...?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 20 lines · Paul Eggleton
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 9 lines · 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.
Quoted 5 lines
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]?
Quoted 8 lines
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"),
This is a very valid concern. The Linux Kernel stable tree maintainer sends out email to the author of all patches he has queued for a stable update before they hit the tree. This provides a reliable mechanism for authors to provide feedback.
Quoted 17 lines
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.Quoted 12 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>
Quoted 8 lines
Quoted 5 lines
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
I understand we are not the Linux kernel community and we need to take our own priorities and needs into account when definining our process. However, just for reference (learn from history or be doomed to repeat it and all that), here are the Linux kernel stable rules:
Personally, I believe it to be a fairly sound process.
Quoted 6 lines
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...?
Agreed.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
Quoted 50 lines · Paul Eggleton
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 9 lines · 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.
Quoted 5 lines
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.
Quoted 12 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>Quoted 5 lines
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.
Quoted 8 lines
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).
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 68 lines · Martin Jansa
Quoted 58 lines · Paul Eggleton
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 11 lines · 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.
Quoted 6 lines
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.
Quoted 13 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>Quoted 7 lines
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.
Quoted 8 lines
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...?
Quoted 8 lines
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?
Thanks,
- --
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRqOGFAAoJEKbMaAwKp364WjEH/2ppNgSD1sM2uqLAIkLRM842 K+zJKOOrkm2+UI9VUp9NM5mJi5Egm9cfpBymeQS8wetvQEhSCY6epw1/55epzKY/ nG9JOGFpJu4Lnujqun3vAUw0cctfw7re+osGYZ2Dx6icig+6umNOSbeS6vrOT/hp 9bsN8bMBwOUx24iHEU+rQ30KTniGL3jsqCYXHHVO5+hP1TZ50cie5w2rYQ0VHHYf doncbiR+lFa8X8GkgnsfsDy/qn3DePfgD9NSoSJsKYe0ZExHY53csWi6xUgMF+J6 LjVIfs+eMbOD3ZLTkHPDbDe/M9xirem/7lxudfwqFEPOpiRGmGm4fdp+ycjqS0c= =H+iu
-----END PGP SIGNATURE-----
Op 31 mei 2013, om 19:44 heeft Darren Hart <[email protected]> het volgende geschreven:
Quoted 83 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 68 lines · Martin Jansa
Quoted 58 lines · Paul Eggleton
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 11 lines · 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.
Quoted 6 lines
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.
Quoted 13 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>Quoted 7 lines
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.
Quoted 8 lines
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...?
Quoted 8 lines
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).
Quoted 4 lines
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.
regards,
Koen
Quoted 86 lines · Koen Kooi
Op 31 mei 2013, om 19:44 heeft Darren Hart <[email protected]> het volgende geschreven:
Quoted 83 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 76 lines · Martin Jansa
Quoted 58 lines · Paul Eggleton
Hi Darren,
Sorry it's taken me so long to reply to this.
Quoted 11 lines · 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.
Quoted 6 lines
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.
Quoted 13 lines
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]> # denzilCc <[email protected]> # dannySigned-off-by Darren Hart <[email protected]>Quoted 7 lines
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.
Quoted 8 lines
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).
Quoted 6 lines
Quoted 4 lines
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
Quoted 23 lines · Philip Balister
Quoted 17 lines · Koen Kooi
Op 31 mei 2013, om 19:44 heeft Darren Hart <[email protected]> het volgende geschreven:
Quoted 9 lines
Quoted 8 lines
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).
Quoted 4 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
I find the sample git send-email line in the README to be a huge help for me.
Philip
In my experience with this project and our maintainers, they are exceptionally good-natured and eager to help compared to some other projects. There would definitely be a painful period as they tried to resist reminding people and just pulling the patch in anyway. I think it could work, but we would have to be firm about it and document it well. Some kind of a stable-release.txt README is definitely in order.
I went to check oe-core for some kind of existing documentation on policies and came up empty. Perhaps just documenting this pseudo-existing policy in a place where developers are likely to find it and can be easily referred to would be a good first step.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel