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
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.
> 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.
> 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.)
> 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.
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part