OK, I'll try not to take so long to have a look at it this time.
Thorsten Leemhuis <[email protected]> writes:
> Create two documents explaining various aspects around regression
> handling and tracking; one is aimed at users, the other targets
> developers.
>
> The texts among others describe the first rule of Linux kernel
> development and what it means in practice. They also explain what a
> regression actually is and how to report one properly.
>
> Both texts additionally provide a brief introduction to the bot the
> kernel's regression tracker uses to facilitate the work, but mention the
> use is optional.
>
> To sum things up, provide a few quotes from Linus in the document for
> developers to show how serious he takes regressions.
>
> Signed-off-by: Thorsten Leemhuis <[email protected]>
> ---
> Documentation/admin-guide/index.rst | 1 +
> .../admin-guide/regressions-users.rst | 436 ++++++++++++
> Documentation/process/index.rst | 1 +
> Documentation/process/regressions-devs.rst | 672 ++++++++++++++++++
I'll start with some *serious* bikesheddery...it's best if the names of
the files tell readers what's inside. This isn't something I feel
really strongly about, but we could consider
admin-guide/reporting-regressions.txt (or just regressions.txt)
process/regression-policy.txt
> MAINTAINERS | 2 +
> 5 files changed, 1112 insertions(+)
> create mode 100644 Documentation/admin-guide/regressions-users.rst
> create mode 100644 Documentation/process/regressions-devs.rst
>
[...]
> +Send a mail to the regressions mailing list ([email protected]) while
> +CCing the Linux kernel's regression tracker ([email protected]); if the
> +issue might better be dealt with in private, feel free to omit the list.
Perhaps a separate concern, but might you want to set up an @kernel.org
alias for the regression tracker? Trust me, you're not gonna want to
run it forever, and the ability to quickly redirect the mail may prove
to be a nice thing to have. An email address with your domain sitting
in the docs will circulate for years after it gets changed.
> +
> +Additional details about regressions
> +------------------------------------
> +
> +
> +What is the goal of the "no regressions rule"?
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Users should feel safe when updating kernel versions and not have to worry
> +something might break. This is in the interest of the kernel developers to make
> +updating attractive: they don't want users to stay on stable or longterm Linux
> +series that are either abandoned or more than one and a half years old. That's
> +in everybody's interest, as `those series might have known bugs, security
> +issues, or other problematic aspects already fixed in later versions
> +<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
> +Additionally, the kernel developers want to make it simple and appealing for
> +users to test the latest pre-release or regular release. That's also in
> +everybody's interest, as it's a lot easier to track down and fix problems, if
> +they are reported shortly after being introduced.
> +
> +Is the "no regressions" rule really adhered in practice?
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +It's taken really serious, as can be seen by many mailing list posts from Linux
serious*ly*
Otherwise I can't find a lot to complain about at this point. I'm not
really convinced that we need all those Quotations From Chairman Linus,
but I won't fight about it either :)
In general, though, unless objections show up, I don't see any real
reason to not apply this one.
Thanks,
jon
On 02.02.22 00:13, Jonathan Corbet wrote:
> OK, I'll try not to take so long to have a look at it this time.
>
> Thorsten Leemhuis <[email protected]> writes:
>
>> Create two documents explaining various aspects around regression
>> handling and tracking; one is aimed at users, the other targets
>> developers.
>>
>> The texts among others describe the first rule of Linux kernel
>> development and what it means in practice. They also explain what a
>> regression actually is and how to report one properly.
>>
>> Both texts additionally provide a brief introduction to the bot the
>> kernel's regression tracker uses to facilitate the work, but mention the
>> use is optional.
>>
>> To sum things up, provide a few quotes from Linus in the document for
>> developers to show how serious he takes regressions.
>>
>> Signed-off-by: Thorsten Leemhuis <[email protected]>
>> ---
>> Documentation/admin-guide/index.rst | 1 +
>> .../admin-guide/regressions-users.rst | 436 ++++++++++++
>> Documentation/process/index.rst | 1 +
>> Documentation/process/regressions-devs.rst | 672 ++++++++++++++++++
>
> I'll start with some *serious* bikesheddery...it's best if the names of
> the files tell readers what's inside. This isn't something I feel
> really strongly about, but we could consider
I wasn't totally happy with the file names myself, so it's good that you
bring it up.
> admin-guide/reporting-regressions.txt (or just regressions.txt)
> process/regression-policy.txt
I like "reporting-regressions.txt", but I wonder if using the word
"policy" is a good idea. I tried to avoid it (and similar words, like
guidelines), as they might do more harm then good. So how about:
admin-guide/reporting-regressions.rst
process/regressions.rst
> [...]
>> +Send a mail to the regressions mailing list ([email protected]) while
>> +CCing the Linux kernel's regression tracker ([email protected]); if the
>> +issue might better be dealt with in private, feel free to omit the list.
>
> Perhaps a separate concern, but might you want to set up an @kernel.org
> alias for the regression tracker? Trust me, you're not gonna want to
> run it forever, and the ability to quickly redirect the mail may prove
> to be a nice thing to have. An email address with your domain sitting
> in the docs will circulate for years after it gets changed.
Yeah, it's on my mental to do list for a few weeks already, but never
set down to actually get this rolling. You are right, I'll ask for an alias.
>> +Is the "no regressions" rule really adhered in practice?
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +It's taken really serious, as can be seen by many mailing list posts from Linux
>
> serious*ly*
Fixed.
> Otherwise I can't find a lot to complain about at this point. I'm not
> really convinced that we need all those Quotations From Chairman Linus,
> but I won't fight about it either :)
I'll take a look again and consider kicking a few.
> In general, though, unless objections show up, I don't see any real
> reason to not apply this one.
Great, many thx!
Ciao, Thorsten