Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves <nsteeves@gmail.com>]

On 4 July 2016 at 09:12, Cyril Brulebois <kibi@debian.org> wrote:
> Hi,
>
> Steve McIntyre <steve@einval.com> (2016-07-04):
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days. That's *basically* just
>> like a normal jessie release, but with a few key updates:
>>
>>  * backports kernel
>
> That's a given.

I still wonder if a fork of the last linux:src=4.4, updated to bring
it to linux-4.4.14 would be a lower support burden?  I'm still finding
that there are a fair number of issues reported with 4.5.x and 4.6.x
on various mailing lists.  Does anyone know how Skylake support is
like for the 4.4.x branch?  What is arm64 support like?  I've
corresponded with Ben Hutchings, and he tells me an LTS kernel effort
is ok to do, but unofficial.  Personally, I believe following bpo
kernel is a bit of a rodeo in comparison to what one expects from
Debian Stable, which is why I'm looking into this project.  I would
very much prefer to do it as a team, because I do not believe that I
am qualified to maintain kernel packages.

Philipp, what do you think?

>>  * rebuilt d-i to match that kernel
>
> You know there are patches around for that.
>
>>  * X drivers
>
> I don't see backports for them.

libdrm2: 2.4.68-1~bpo8+1
libgl1-mesa-.*: 11.1.3-1~bpo8+1
xserver-xorg-video-intel:2:2.99.917+git20160522-1~bpo8+1

I backported the libva stuff and required dependencies yesterday.
Some time ago, there was also a user who requested a
xserver-xorg-video-savage bpo on IRC.  I made a quick one, sent him
the link, but he never filed a bug report and I forgot to officially
upload it.

In private email correspondence with Andreas Boll, with respect to
backported X drivers and mesa, it came to light that

On 21 March 2016 at 14:49, Andreas Boll <andreas.boll.dev@gmail.com> wrote:
>
> Actually radeonsi requires LLVM >= 3.6 but since we currently use Mesa
> with LLVM 3.7 in unstable and testing it would make sense to backport
> LLVM 3.7.

So for radeon hardware enablement, there is 1) the proprietary driver
2) a need to backport llvm.

>>  * ... (other things that might be needed for consistency)

Maybe pinning a list of drivers that a user would expect would come
from backports instead of main?  eg: presumably a user would expect
that this Jessie+hardware enablement bpos would choose the latest
broadcom-sta-dkms in backports.  I could be wrong here, and I
recognise that backports are officially opt-in only, but if we're
already opting the user into a bpo X-stack, wouldn't he/she also
assume that installing some-non-free-dkms-driver will also pull in the
bpo version?  Also, I imagine this might one day be necessary,
particularly if tracking backported linux-src due to ABI changes
between kernels, eg: if the out-of-tree drivers in testing begin to
require >> linux-src=3.16.0 ABI.

Ben, could you please lend your insight into this point?

>> all rolled up with a small installer image build (netinst, maybe
>> DVD#1).
>
> That'd probably make it easy to decide how to resolve open questions
> with my "d-i vs. backported kernel" patches.
>
>> A lot of arm64 machine users would benefit from this, and maybe owners
>> of very recent amd64 machines too, with better support for things on
>> the Skylake platform. Those are the only two architectures I'm
>> thinking of supporting at this point.
>>
>> Is anybody else interested in helping? Thoughts/comments?

Yes, it's a project I'm already working on ;-)  Is this project a
candidate for a new Debian Team?

> Questions:
>  1. Is it going to pick pieces from backports only? (See X question
>     above.)

Please see Philipp and my concern wrt rolling kernel updates.

>  2. Does it have to be called "jessie and a half"? (How much is the
>     concept understood across users? Wouldn't it be a better idea to
>     squeeze the "backports" concept into the name somehow?)

Maybe something like jessie-fresh-unofficial?

>  3. What about security support once the system is installed? (Which
>     can be answered along with 1., I suppose.)

Given the current status of backports, security support would be
"Unfortunately not" ( https://backports.debian.org/FAQ/ ).  This is
one point in support of a team that would monitor a subset/list of
supported/shipped/blessed backports for security issues.

Sorry this is so long, I'm excited to see that there are other people
interested in this project!

On 4 July 2016 at 13:13, Hideki Yamane <henrich@debian.or.jp> wrote:
>
>  Just a comment. I don't have any objection for this proposal.
>
>  However, not only half but also updates with some point is better
>  to deliver value for users, I hope it'll be in Stretch cycle.
>
>  Recently I've read "lean software development" and it's quite
>  impressive for me. "deliver value to users" is one of the most
>  important thing in Debian (it means "do continuous improvement
>  for stable"), IMO.

Agreed!  Also, OpenSUSE has been doing this with their post-42.x
release model.  Mind you, to the best of my knowledge Debian has
always cherry picked fixes and essential hardware enablement fixes for
the stable packages (eg: intel-microcode).  This newly proposed Debian
project seems to be a more aggressive approach...but does it also have
a client machine focus to the exclusion of servers, or should it serve
both?

Cheers,
Nicholas