On 10/07/2016 05:48 AM, Greg KH wrote: > On Thu, Oct 06, 2016 at 09:51:08PM -0700, Thomas Hellstrom wrote: >> On 10/06/2016 09:22 PM, Greg KH wrote: >>> On Thu, Oct 06, 2016 at 09:19:50PM -0700, Thomas Hellstrom wrote: >>>> Hi! >>>> >>>> On 10/06/2016 08:52 PM, Greg KH wrote: >>>>> On Thu, Oct 06, 2016 at 06:54:43PM -0700, Thomas Hellstrom wrote: >>>>>> Hi, Stable! >>>>>> >>>>>> As you might be aware of, some companies that maintain linux kernel >>>>>> drivers have the habit of assigning each driver change a new version >>>>>> number. >>>>> And, as you have found out, that's a horrible thing to do for Linux and >>>>> doesn't work at all :) >>>>> >>>>> Just because it works for other slower-moving operating systems, I >>>>> wouldn't recommend doing it for Linux. >>>> Yes, I'm fully aware of the difficulties, though I was hoping that I, >>>> with the help some bright ideas from the list could come up with a >>>> clever way to make everybody happy. >>> But who has the problem here really? Not the kernel community or >>> developers, but rather an odd set of unskilled QA people (your word, not >>> mine.) >>> >>> Why can't they get more "skill"? :) >>> >>> thanks, >>> >>> greg k-h >> Well, I would in no way call our QA people unskilled just because they >> in general don't have the skill to know how to locate a particular, >> sometimes well-hidden git repo and find out if a certain bug is fixed or >> not. Not even Einstein knew how to do that ;) > Huh? All of the kernel trees we "release" are in one single repo, and > it is very well known (linked to off of the kernel.org site front page): > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_stable_linux-2Dstable.git&d=CwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=2nFSKLtpsbVgl3FEz2G3Io4y14rAxcjmJACORglPiwI&s=E02w2V0waHQkqaQ4KAcPYM3o2nWfYavhd12uJDJ24dI&e= > > How is that difficult to find? The "vanilla" stable ones are easy. The distro ones may not be, save Ubuntu that sometimes "take over" a stable tree. Typically the kernels we test are a distro-modified version of a stable tree. > >> But I won't try to argue here. I do think, though, that as long as >> people believe the easier solution is to version each change they will >> keep on doing that and unfortunately as a result important patches won't >> get CC'd stable because that would mess up the versioning. >> >> From your answer I take it there is no interest from the stable >> maintainers in helping solving this using some kind of mainline hash >> registering tool. I guess perhaps another option is to locally automate >> stable / distro git tree scanning. > Maybe I really don't understand the "issue" you are trying to address > here, can you try to rephrase it by showing a real example of what you > are trying to solve? > > But again, there's nothing we can do about out-of-tree code, remember, > they know where we are (and I'll take anything!), but we don't know > where they are... > > thanks, > > greg k-h Yes. The problem would be Given a *binary* version of distro kernel X, based on stable kernel Y. What _upstreamed_ bugfix patches has touched our module since the stable branch was created? Let's assume the distro git tree is hard to find. a) Now if stable maintainers and distro kernel maintainers could use a flag "record commit id" to the git am command, the mainline commit id would be added to a binary visible table in the module, problem solved. b) If we assume that the distro git tree is accessible to us, we can solve this locally by building such a table by matching the distro kernel version to a commit in that git tree and then scan the git tree for the known bugfix patches we've sent out. Problem also solved. So the reason for sending out the email was basically to enquire whether there were others facing the same problem and if anybody was interested in a common solution along a). I mean even if we code a) up but nobody wanted to use it because they disliked the whole idea, that wouldn't make much sense. And if nobody else is interested, we'd probably be better off with b) provided we can gain access to the git trees of the important distro kernels. Thanks, Thomas -- 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