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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ