Bug#950578: [External] Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
> From: Ben Hutchings <benh@debian.org>
> Sent: Saturday, May 9, 2020 5:20 PM
>
> On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote:
> [...]
<snip>
>
> > If Debian 11 was planning to continue to use a 4.x kernel, I could see
> > some point in splitting the patch and ensuring, so that it *might* be
> > easier to maintain for many years to come. But, from what I gather,
> > Debian 11 will bump kernel major, so any work being done making the 4.x
> > backport (which is not that complex, sorry, especially as I made sure to
> > already group the code changes in a manner that makes it easier to
> > handle) easier to maintain in the long run seems like a waste of time,
> > even if 10.x may see long time support for a few more years...
> [...]
>
> Debian 10 will be supported for 4 more years, in fact. During that
> time this driver may well see other changes backported through the
> stable process. Based on past experience, I think it will be easier to
> resolve any conflicts if our patches make smaller changes.
>
> So please don't assume what's "easier to handle" for us.
>
> Ben.
>
I'm hesitant to post to this thread as I don't agree with all of Pete's points,
but this thread somewhat resonated, especially this last comment.
As someone who is still learning and finding their way through the process
myself - finding the preferred way of doing things and all the little details
is hard - or at least that's my experience. The kernel handbook is OK, but
it doesn't cover this detail in my opinion
It would be really nice to have an idiots/beginners guide to what the best way
is to make the maintainers life easy - I have been stumbling my way through,
making plenty of mistakes and I'm sure I generate more headaches then I mean
to.
Having a guide explaining how to backport a patch cleanly from kernel.org
would be a really nice thing to have - down to best working practices with
salsa, all the bits of info that have to be added to the patch(es), using dch,
how to deal with patches that don't merge cleanly, git best practices etc. I'm
sure as a kernel maintainer you see the same mistake again and again and it
must be infuriating. Recommended workflows would be amazing - I'm still not
sure what the *best* way to work on the Debian kernel is (I have steps I use
but I had to figure them out myself and I suspect they could be better).
It would also be really nice to have a way to reasonably escalate things (with
a reason for the escalation) without pissing off people who are too busy to be
swamped with nag-emails (I've been told those are a huge no-no with the
kernel Debian community). I'd be OK with a "this is not a priority I will look at it
in N weeks" but having no insight into where you are in the queue or if you
have been missed is hard.
From my point of view I regularly get asked "when will X be available in Debian"
and I can never give an estimate. I cannot recommend to even expert Lenovo
customers to use Debian on our platforms - and that is frustrating because it is
a great distro.
Please note - I do not mean to sound like I am complaining. I believe part of
being in the community is to do things the way the community wants. I just
think the path for newcomers to contribute and make Debian better is not
an easy one and wanted to offer insight as to why. If you can point me at
what I'm missing that would be awesome (and slightly embarrassing as I've
looked for it at length)
Mark
Reply to: