On Thu, 8 Nov 2018, Theodore Y. Ts'o wrote: > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote: > > > > I know at least StGit mail does not grok that "#"notation. I've > > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is > > preferred over "# <KVER>" if only because it can be used to track > > fixes to commits that have been backported to stable. Is there any > > reason for "# <KVER>" to continue in a world where we have "Fixes:"? > > The main annoyance I have with Fixes is because it can be a pain to > figure out what the "# <KVER>" would be. Something like: > > % tag --contains DEADBEEF | grep ^v | head > > doesn't work because kernel version numbers don't sort obviously. So > v4.10 comes before v4.3 using a normal sort, and even sort -n doesn't > do the right. > > I suppose it wouldn't be that hard to write a perl/python script that > correctly sorts kernel version numbers, but when the "# <KVER>" is > present, I find it convenient. > > (Also note that even with fast SSD's and/or everything in page cache, > runnning "tag --contains <COMMITID>" will take a good 3-4 seconds, and > if the git packs are not in the page cache, and/or you're unfortunate > enough to have your git trees on an HDD.... it's not pretty.)
Fair enough. But as I said before we please let us have both the fixes tag and a decicated backport-to one and make the latter mandatory. It if's not there and the patch has a 'Cc: stable' tag it's easy enough to reject it. The the submitter or the maintainer who decides that a patch needs to be backported to stable has to wait the 4 seconds and add that information. Thanks, tglx