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. > > If you have distro issues, go complain to them, nothing this list can do > about that, sorry. > >> 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. > I find it hard to believe you don't have access to them already. But > again, if not, there's nothing we can do here, right? Yes, that's right. Item b) would be a local thing. > > thanks, > > greg k-h Thanks for your input Greg! 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