Re: nolibc changes since 6.6-rc1 for linux-next

[Willy Tarreau <w@1wt.eu>]

Hi Paul,

On Sun, Oct 08, 2023 at 09:27:43AM -0700, Paul E. McKenney wrote:
(...)
> The other approach involves rebasing the "nolibc/next" stack
> on top of the "nolibc/fixes" stack.

That was my initial expectation as well, it's much easier, preserves
the patches ordering so it guarantees that all fixes are always present
in -next and that there won't be conflicts when they're finally submitted.

> And then I send the fixes portion of the branch to Linus after a few
> days of exposure to -next testing, and the full branch for the upcoming
> merge window.

Indeed, it also allows to test both together and can reduce the cost of
testing (unless we really want to test something specific to the fixes
branch once in a while).

> Test results for nolibc-rebase.2023.10.08a:
> "make run": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> "make run-user": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> 
> This approach has its strenghts and weaknesses.
> 
> 1.	It avoids all the weaknesses called out for merging.
> 
> 2.	It can require more testing when moving yet another commit
> 	down into urgent-fixes portion of the branch.
> 
> 3.	Many people are much less comfortable rebasing and mass
> 	cherry-picking than they are with merging.

I tend to think that anything called "-next" should mostly be expected
to change over time and support rebases. One good reason for this is to
remerge fixes for recently added changes so as not to needlessly leave
bogus commits in the history, since that tends to break bisect.

> While in the area, would the following (absolutely not urgent or even
> particularly important) patch be a good idea?  This gets rid of a line
> of noise from "git status" after running the tests.

Good idea, feel free to propose a patch ;-)

Thanks!
Willy