Re: linus-next: improving functional testing for to-be-merged pull requests

Steven Rostedt
2024-10-23T08:20:08Z

On Tue, 22 Oct 2024 22:47:09 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Tue, Oct 22, 2024 at 04:12:43AM -0400, Steven Rostedt wrote:
> > You mean have everything go into linux-next before going to Linus after -rc1?
> >
> > I'm one that doesn't do this. That's because my code in linux-next
> > after -rc1 is for the next merge window, and the code I send to Linus
> > is only fixes for code I sent before -rc1. I tend to keep an "urgent"
> > and "core" branch. My "core" branch is everything I plan to send in the
> > next merge window and goes into linux-next (via being pulled into my
> > for-next branch). After I send my pull request to Linus, and he pulls
> > it in the merge window, that "core" branch becomes my "urgent" branch.
>
> You can easily have two branches in linux-next. Many trees do that.
> It is also a really nice warning about self-conflicts.

I actually do have several branches in linux-next. But they are all
topic branches. My urgent branches usually mirror them (by naming
convention). My scripts pull my for-next branches together and then I
push them up.

I did push urgent branches to linux-next some time back, but never
found any advantage in doing so, so I stopped doing it. As the code in
my urgent branches are just fixing the stuff already in Linus's tree,
they seldom ever have any effect on other subsystems. My new work does
benefit from being in linux-next. But since I don't find more testing
in linux-next for things that are already in Linus's tree, I still
don't see how its worth the time to put my urgent work there.

To put it this way. The bugs I'm fixing was for code in linux-next
where the bugs were never found. They only appeared when they went into
Linus's tree. So why put the fixes in linux-next, if it didn't catch
the bugs I fixed in the first place?

-- Steve