On 28 August 2012 07:29, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi, > > On Mon, Aug 27 2012, Shawn Guo wrote: >> On 28 August 2012 07:07, Chris Ball <cjb@xxxxxxxxxx> wrote: >>> Thanks, pushed to mmc-next for 3.6. (stable@ shouldn't be CC'd.) >>> >> I categorised it as a fix for a regression. > It means not only for stable but also for -rc series rather than -next. > It is a fix for a regression, but the rules for submitting patches to > stable@ are significantly more strict than "is it a regression?". > From Documentation/stable-kernel-rules.txt: > > == > Rules on what kind of patches are accepted, and which ones are not, into the > "-stable" tree: > > ... > - It or an equivalent fix must already exist in Linus' tree (upstream). > > Procedure for submitting patches to the -stable tree: > > - Send the patch, after verifying that it follows the above rules, to > stable@xxxxxxxxxxxxxxx. You must note the upstream commit ID in the > changelog of your submission, as well as the kernel version you wish > it to be applied to. > == > > It doesn't already exist in mainline -- so it shouldn't have been > e-mailed to stable@ -- and even if it were already in mainline, you > shouldn't e-mail stable@ without including the upstream commit ID > and kernel version to apply it to. (Unless I'm missing something?) > Ok, thanks for pointing it out. But in practice, the process seems not so strict. I have a lot of successful cases with Greg (Cc-ed) by simply Cc-ing stable when submit a fix that should be applied on stable kernel. Doing this strictly means people have to keep tracking if the fix hits mainline and remember to resubmit it to stable afterwards. Should subsystem maintainer or author be that people? It's not easy anyway. Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
