On Fri, Oct 7, 2016 at 11:26 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Oct 07, 2016 at 08:05:59AM -0700, Thomas Hellstrom wrote: >> On 10/07/2016 07:18 AM, Greg KH wrote: >> > On Fri, Oct 07, 2016 at 06:47:47AM -0700, Thomas Hellstrom wrote: >> >> 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. >> > Then go complain to the distros! And even then, all of them keep their >> > kernels in pretty well-known, and documented, locations. If not, go bug >> > them, there is nothing we can do about it. >> > >> > Also, shouldn't your QA scripts just suck in the correct distro >> > kernel/tree automatically? No QA person should have to ever hunt for a >> > kernel tree, that means you have not automated it, which seems very >> > wrong to me. >> > >> >>>> 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. >> > But the stable mantainers DO all do that already today! That info is >> > all there, and has been there, for over a decade! Just look at every >> > commit in the stable kernel branches, it has that information for you, >> > in a semi-easy format to parse. >> >> Indeed they do, but the idea here was to have that information >> extractable from a binary, but that would have required cooperation both >> from the stable maintainers and the distro maintainers (who typically >> are on this list). That's why I posted. > > You can't extract each individual patch information from a binary, how > would you encode 10k patches in every release? > > Oh wait, look, we already do that with the git commit id as part of the > version number, you always know exactly what is contained in that binary > based on that. > > So again, the community has already done this for you, I don't know why > you are ignoring it :( > > And again, if you have problems with distro source trees, go complain to > them. Yes, there are some distro developers on this list, but it's not > a distro-specific place to complain to them about things, you know > better than that... I am curious which distros they're having trouble finding the kernel tree for though. josh -- 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