OK, I'll try not to take so long to have a look at it this time.
Thorsten Leemhuis <linux@xxxxxxxxxxxxx> 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 <linux@xxxxxxxxxxxxx>
> ---
> 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 (regressions@xxxxxxxxxxxxxxx) while
> +CCing the Linux kernel's regression tracker (regressions@xxxxxxxxxxxxx); 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
