This series bundle a few patches that piled up for
Documentation/admin-guide/reporting-issues.rst. The main changes are these:
* patch 2/5: tones down 'test vanilla mainline' a little and mention that
vendor kernel might be find in some cases if they are close to vanilla. Gets rid
of a "FIXME" box.
* patch 5/5: creates a streamlined process for users wanting to report
regressions within a stable and longterm kernel series. The existing process is
too demanding, complicated and takes too much time for this case. I didn't CC
the stable maintainers here, they need to review the whole document anyway once
the last few details have been sorted out.
Patch 1/5 are just small fixes I wanted to keep separated. Patch 3/4 and 4/5 are
mainly there to make the diff in the last patch of this series easier to read in
the review phase. They can easily be squashed into the patches that follow them.
v3:
* add patch to fix a typo and an existing style-issue that came up during review
that until now handled separately
* add related patch that tones down 'test vanilla mainline' a bit
* add another patch to make the diff easier to read
v2: https://lore.kernel.org/linux-doc/[email protected]/
* initial version, starting straight with v2 to avoid confusion, as one of the
patches was submitted earlier already
Thorsten Leemhuis (5):
docs: reporting-issues.rst: fix small typos and style issues
docs: reporting-issues.rst: tone down 'test vanilla mainline' a little
docs: reporting-issues.rst: reorder some steps
docs: reporting-issues.rst: duplicate sections for reviewing purposes
docs: reporting-issues.rst: improved process esp. for stable
regressions
.../admin-guide/reporting-issues.rst | 832 ++++++++++--------
1 file changed, 471 insertions(+), 361 deletions(-)
base-commit: a8f2a68e42d19e6fc1e0eb6eaef548ef07b19d75
--
2.30.2
Hi Jonathan!
On 19.03.21 20:27, Thorsten Leemhuis wrote:
> This series bundle a few patches that piled up for
> Documentation/admin-guide/reporting-issues.rst. The main changes are these:
Sorry to bring the following up, as I saw you mentioning in another mail
on linux-doc you have a lot on your plate already. I really would prefer
to not add something to it, but something came up.
My vague hope had been to get this patchset merged for 5.13-rc1 and
after its release post the text to Greg, Sasha, ksummit-list and LKML
for a round of really public review. That would make sure at least all
the important maintainers are aware of the text and have a chance to
intervene before it gets fully official. Depending on the outcome I had
hoped to remove the the two last remaining "FIXME" boxes and the "WIP"
box at the top of reporting-issues.rst for 5.14-rc1 and also remove
reporting-bugs.rst.
But a few days ago Konstantin put a visible admonition on the front of
bugzilla.kernel.org that links to the rendered version of
reporting-issues.rst – for context see
https://lore.kernel.org/lkml/CAMwyc-Sqbkg=VxCWcfRazkGG7vkwEQ43m9Dov_Nawia5MN_oUQ@mail.gmail.com/
And then Tytso brought up that it might be a good time to bless the
text: https://lore.kernel.org/lkml/[email protected]/
That's why I'd like to speed things up a little. But for that it would
be good to have something from you: a kind of "I like the direction
where this patch set is heading and I'm optimistic that we get it merged
for 5.13-rc1" message from you. With something like that I could move
ahead as outlined above already. Do you maybe have a minute for that?
Ciao, Thorsten
> * patch 2/5: tones down 'test vanilla mainline' a little and mention that
> vendor kernel might be find in some cases if they are close to vanilla. Gets rid
> of a "FIXME" box.
>
> * patch 5/5: creates a streamlined process for users wanting to report
> regressions within a stable and longterm kernel series. The existing process is
> too demanding, complicated and takes too much time for this case. I didn't CC
> the stable maintainers here, they need to review the whole document anyway once
> the last few details have been sorted out.
>
> Patch 1/5 are just small fixes I wanted to keep separated. Patch 3/4 and 4/5 are
> mainly there to make the diff in the last patch of this series easier to read in
> the review phase. They can easily be squashed into the patches that follow them.
>
> v3:
> * add patch to fix a typo and an existing style-issue that came up during review
> that until now handled separately
> * add related patch that tones down 'test vanilla mainline' a bit
> * add another patch to make the diff easier to read
>
> v2: https://lore.kernel.org/linux-doc/[email protected]/
> * initial version, starting straight with v2 to avoid confusion, as one of the
> patches was submitted earlier already
>
> Thorsten Leemhuis (5):
> docs: reporting-issues.rst: fix small typos and style issues
> docs: reporting-issues.rst: tone down 'test vanilla mainline' a little
> docs: reporting-issues.rst: reorder some steps
> docs: reporting-issues.rst: duplicate sections for reviewing purposes
> docs: reporting-issues.rst: improved process esp. for stable
> regressions
>
> .../admin-guide/reporting-issues.rst | 832 ++++++++++--------
> 1 file changed, 471 insertions(+), 361 deletions(-)
>
>
> base-commit: a8f2a68e42d19e6fc1e0eb6eaef548ef07b19d75
>
Thorsten Leemhuis <[email protected]> writes:
> That's why I'd like to speed things up a little. But for that it would
> be good to have something from you: a kind of "I like the direction
> where this patch set is heading and I'm optimistic that we get it merged
> for 5.13-rc1" message from you. With something like that I could move
> ahead as outlined above already. Do you maybe have a minute for that?
Honestly, I don't see any reason to delay this work any further, so I've
just applied the set.
Sorry for the slowness, it has been a rather harsh week.
Thanks,
jon
On 25.03.21 19:43, Jonathan Corbet wrote:
> Thorsten Leemhuis <[email protected]> writes:
>
>> That's why I'd like to speed things up a little. But for that it would
>> be good to have something from you: a kind of "I like the direction
>> where this patch set is heading and I'm optimistic that we get it merged
>> for 5.13-rc1" message from you. With something like that I could move
>> ahead as outlined above already. Do you maybe have a minute for that?
> Honestly, I don't see any reason to delay this work any further, so I've
> just applied the set.
Ahh, great, many thx.
> Sorry for the slowness,
No worries, it's improvements to a docs text, not a crucial security
issue in core code. :-D
> it has been a rather harsh week.
I hope things will get better soon!
BTW, I wondered it it would make sense to add a entry to the MAINTAINERS
file for the text so I can keep and eye on things and help with fine
tuning. Let me known if you think that idea is overblown, otherwise I'll
likely add one with the patch that I'll send sooner or later to remove
the WIP box near the top.
Ciao (and make sure to take care of yourself!), Thorsten
Thorsten Leemhuis <[email protected]> writes:
> BTW, I wondered it it would make sense to add a entry to the MAINTAINERS
> file for the text so I can keep and eye on things and help with fine
> tuning. Let me known if you think that idea is overblown, otherwise I'll
> likely add one with the patch that I'll send sooner or later to remove
> the WIP box near the top.
A MAINTAINERS entry makes sense for a document like that; I think it's a
fine idea to add yourself.
Thanks,
jon