Re: Stable list vs versioning

[Greg KH <gregkh@linuxfoundation.org>]

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