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