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... 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