On Tue, Jul 08, 2014 at 08:23:26AM +1000, NeilBrown wrote: > On Mon, 07 Jul 2014 13:42:37 -0700 <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > This is a note to let you know that I've just added the patch titled > > > > md: make sure GET_ARRAY_INFO ioctl reports correct "clean" status > > > > to the 3.4-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > The filename of the patch is: > > md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch > > and it can be found in the queue-3.4 subdirectory. > > > > If you, or anyone else, feels it should not be added to the stable tree, > > please let <stable@xxxxxxxxxxxxxxx> know about it. > > I wasn't expecting this patch to enter the stable tree as I didn't > add "cc: stable". > I guess your scripts picked up on the "Fixes:" tag? Yes it did. > Just because a patch "fixes" a bug, that doesn't mean that it meets the > requirements of "-stable". I would really like to be able to record these > connections without them triggering a backport. > Should I use "Fixes-but-not-needed-for-stable"?? > > In this case I don't object to the patch going to -stable as it really is > very very trivial. But the bug itself is trivial and doesn't justify a > -stable update. Ok, I can drop this, I go through all of the "Fixes:" tags that people add, without stable@ markings, and review them to see if they are relevant to apply. Lots of people seem to forget to add stable@, so it has been useful. I'll drop this one, I was just trying to error on the side of "this looks like a valid bugfix and you forgot to add stable@" to the patch. > Can we have one-tag-one-meaning please? Heh, I wish, people seem to do one or the other these days, some do both for odd reasons. I'll continue to sweep the tree for fixes: when I have the time, it is much lower down on my list of patches to review. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html