On Thu, May 26, 2016 at 1:42 AM, Michal Kubecek email@example.com wrote:
On Wed, May 25, 2016 at 06:02:20PM -0400, Greg Freemyer wrote:
On Wed, May 25, 2016 at 5:38 AM, Andreas Schwab firstname.lastname@example.org wrote:
Richard Brown email@example.com writes:
For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed.
Or they can use Kernel:stable on top of Leap, which combines the stability with extra hardware support.
Even kernel stable is moving much faster than my proposal.
Is it reasonable to ask for a Kernel:LTS repo to be created?
As I said yesterday in my response to Carlos, it's not a technical problem, the infrastructure exists and virtually anyone can do it. After all, the kernel intended for Evergreen 13.1 lived in my home project for over a year and some people were happily using it from there. And I believe if such kernel branch is well maintained, its OBS project might be even given some nicer name.
So IMHO the real problem of what you are asking is not a repository but someone to prepare the kernel branch and - even more important - maintain it for its whole lifetime. Unless I misunderstood you and you meant to volunteer to do the work, rather than requesting it from poor old Mr. Someone Else.
For the next 6 months, the effort involves a single 5 minute effort to branch the appropriate SLE 12 SP2 or Leap 42.2 Kernel repo to Kernel:LTS
As those kernel repos are maintained, the Kernel:LTS repo would automatically be maintained.
Thus no other work in 2016.
If it existed back in Jan 2016, it could have been populated with 4.4 then and "early" adopters of the Leap 42.2 kernel could have started to test it.
Looks like another mail of mine went unnoticed... What would you get this way would be very different from openSUSE-42.2 kernel we have now. There is a big difference between just basing on an upstream LTS and basing on a maintained SLE kernel. (I'm not looking forward to the discussions about Leap 42.3 kernel where this is likely to become a real dilemma.)
It is precisely the 42.3 kernel that I'm hoping we can start to layout a plan for.
In Q1 2017, the 2017 LTS kernel should be published by kernel.org.
It will soon find its way into Kernel:Stable.
A couple months later 2017 LTS+1 will be published. That too will make its way into Kernel:Stable.
If Kernel:LTS exists, then during the couple months that 2017 LTS is in Kernel:Stable, I'm asking that a SR from Kernel:Stable to Kernel:LTS be made.
All of the above is straight forward and if I had permissions I could easily do it. (And I'm willing to do it if asked, but I think the permissions issue is more work than the occasional SR).
But, as you note the big question then becomes what happens to Kernel:LTS once the 2017 LTS kernel is in it.
- On one hand: the SLE team has already said they are not planning to release a SLE Kernel based on the 2017 LTS kernel so they won't necessarily be maintaining it.
- On the other hand: the method of choosing the Leap 42.1 kernel was to use the most recent LTS kernel. If that is also the decision for Leap 42.3, then the 2017 LTS kernel will be the Leap 42.3 kernel. Therefore Kernel:LTS will by default become the Devel Project for the Leap 42.3 kernel.
Even if the 2017 LTS kernel does not find its way into either SLE or Leap 42.3, I think it is beneficial to the openSUSE community to maintain a Kernel:LTS repo. It just may be that it doesn't get a lot of support except by importing updates from kernel.org.