linux-kernel - Re: [PATCH v2 2/3] auxdisplay: Move cfag12864b.h to the subsystem folder

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72mYMztZG5Y5v6m+h2xroDFyyf0Kn7aZ2D7p6p4k_YtTcw@mail.gmail.com>
Date: Wed, 14 Feb 2024 19:48:31 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	linux-kernel@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>
Subject: Re: [PATCH v2 2/3] auxdisplay: Move cfag12864b.h to the subsystem folder

On Wed, Feb 14, 2024 at 6:50 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> It's a standard practice in the Linux kernel development.
> If it's not a so critical issue, why should we rebase?
>
> rebasing will break SHA sums and it's not appreciated especially at the late
> rcX weeks. Linus can even refuse to accept a PR based on this fact.

I am well aware of what rebasing does and the rules for PRs to Linus, thank you.

First of all, you should have not applied the patch this quickly.
Nobody gave a tag for it and you yourself are the author. Even if
someone gave you a tag, 2 days is way too little time for something
like auxdisplay. 2 weeks would be a more reasonable time frame.

The point is: you seem to be rejecting feedback on the basis that you
already applied a patch that you yourself authored 2 days ago. Not
good.

Now, for branches in linux-next, what you should avoid is rebasing
wildly, but you can still do so if needed. If you are uncomfortable
with that, then you should avoid rushing patches to begin with so that
you don't have to do that.

Regarding PRs to Linus, we are still in -rc4. There is plenty of time
to bake things in `linux-next`. Unless you meant to sent this to a -rc
release. But in that case: 1) there is no rush, 2) please see the
first point again.

Cheers,
Miguel