RE: [External] Difficulties with kernel package contributions
Thanks Ben
> -----Original Message-----
> From: Ben Hutchings <ben@decadent.org.uk>
> Sent: Sunday, May 17, 2020 11:50 AM
> To: Mark Pearson <mpearson@lenovo.com>
> Cc: Pete Batard <pete@akeo.ie>; Debian kernel maintainers <debian-
> kernel@lists.debian.org>
> Subject: [External] Difficulties with kernel package contributions
>
> I'm not cc'ing the BTS on this as this discussion is no longer specific
> to one bug report.
>
> On Sun, 10 May 2020 16:46:47 +0000 Mark Pearson
> <mpearson@lenovo.com> wrote:
> [...]
> > 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
>
> Yes, there's definitely room for improvement in the documentation.
>
> We also have documentation spread across debian/README.source, kernel-
> handbook, the docs directory of kernel-team.git, and some wiki pages.
> We (the kernel team) should clarify who they're for and what
> information belongs where; and probably we should add more cross-
> references.
>
> Oh, and I gave this talk:
>
> https://peertube.debian.social/videos/watch/3b1818f2-e44c-4cbd-b9a0-
> c9465c53667a
> https://www.decadent.org.uk/ben/talks/mdch2018-help-the-kernel-team.pdf
>
These are good - thank you.
> and I'm not sure all of the information there is written down elsewhere...
>
> > 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.
>
> I got the impression that you're not hugely familiar with git, so
> having to deal with git and quilt at the same time is bound to be
> difficult.
>
That's fair. I have used git but there has definitely been some learning of
functionality (rebase) that I'd not come across before.
Quilt is new to me but I'm getting more used to it
> > 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.
>
> A fair amount of that is needed for Debian packages in general, so I
> don't think we should be writing our own documentation about it but we
> should refer to existing documentation.
>
Makes sense - I need to make more effort to go through those. I've tended to
be kernel focused as it's the area where I'm more aware of patches upstream
that impact our platforms that are (I hope) good to get into Debian sooner.
> > 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).
>
> I'm going to assume that you're talking specifically about backporting
> features from upstream (either mainline or a maintainer tree). If the
> target Debian branch is not far behind, that I would usually:
>
> 1. Export the upstream commits with git-format-patch-for-debian. This is a
> wrapper for "git format-patch" that adds the extra patch headers, and it's
> in the kernel-team.git repository.
> 2. Depending on the number of patches, either:
> - Import them individually, with something like:
> quilt import -P features/all/foo.patch ~/linux/0001-foo.patch
> - Move them into a subdirectory of debian/patches, e.g.:
> cd debian/patches
> mkdir features/all/foo
> mv ~/linux/0*.patch features/all/foo/
> ls features/all/foo/*.patch >> series
> 3. Apply each patch (quilt push) and fix up any conflicts.
> 4. Build and test (to the extent possible).
>
> If the target Debian branch is further behind (e.g. 4.19 as Pete is
> dealing with) then I would more likely:
>
> 1. Start a git branch from the upstream stable branch.
> 2. For each upstream commit:
> 1. Cherry-pick it with "git cherry-pick -x" it. Fix up any
> conflicts and note the change in the commit message.
> 2. Build the kernel, or at least the affected subsystem or driver.
> Fix any failure, possibly by picking additional commits it
> depends on. Note any changes in the commit message.
> 3. Export the backported commits and import into the Debian package as
> in the previous list. (This requires fixing up the Origin headers,
> and I don't currently have an easy way to do that.)
>
Really appreciate these steps - it's very helpful.
I know I still have MR 240 out there but I'll follow these more carefully for the
next one.
> > 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.
>
> Speaking just for myself, I don't have a queue of work. I look at bug
> reports as they come in, and triage them (adjust severity, reassign,
> close if invalid). I also make a note of those that appear to be
> immediately actionable (request applying a patch from upstream, or
> request a config change), and I deal with those in batches.
>
> I will take longer to answer bug reports that look like they require
> more time to investigate or review. And unfortunately, with the
> current size and availability of the team, there are just too many bugs
> to answer all of them.
>
> > 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.
>
> It's also a bit disappointing for me, as someone who's used Debian on a
> succession of Thinkpads for 13 years.
From your view what is the recommended approach for a upstream patch that
fixes functionality - to best get it out to Debian users.
As an example: Right now I've got the MR 240 with OLED brightness control fix that
I've been working on (with enough mistakes in my first attempt I ended up binning
it).
Assuming I manage to get this done with no more mistakes on my side and it makes
it into master what are your recommendations for backports?
I'm assuming it's a bit case-by-case depending on how complex the patch is but
I've not really gotten to the case of initial success yet to know what sensibly comes
next and is best for users. Are there any default preferences or expectations?
>
> > 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
>
> I agree.
>
> > 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)
>
> No need to be embarrassed. If my answers above don't help, let me know
> what specifically what information you're missing.
>
> Ben.
>
> --
> Ben Hutchings
> Logic doesn't apply to the real world. - Marvin Minsky
>
Reply to: