fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

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

lore.kernel.org/all/ZxZ8MStt4e

"'[…] Linus Torvalds expressed concerns about the quality of testing that code receives before he pulls it. The subsequent discussion side-tracked to the testability of linux-next, but we didn't directly address Linus's original concern about pre-pull testing quality.

In an attempt to address the concerns, we're trying out a new "linus-next"
tree […]"

lore.kernel.orglinus-next: improving functional testing for to-be-merged pull requests - Sasha Levin

2/ @kees replied to the "linus-next" proposal from Sasha and raised a few points I fully agree with, as that proposal felt a bit off for me.

lore.kernel.org/all/792F4759-E

"'Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

[…]

Why not just use linux-next? […]

[…] have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good. […]"

lore.kernel.orgRe: linus-next: improving functional testing for to-be-merged pull requests - Kees Cook

@vbabka and @ljs, that "Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem." from @kees reminded me of a question you might be able to help out with:

From a quick look it seems to me that the "mm-unstable" branch is in -next (via "mm-everything"). Does that contain stuff for the next merge window only, or more experimental stuff as well? It looks like the latter to me.

@kernellogger @vbabka @kees what does 'experimental' mean?

mm-unstable is everything that _appears_ to be going to Linus because nobody objected to it yet but some stuff might not end up going because it's got issues.

I'm not sure how you're supposed to differentiate between stuff that's eventually going to get reviewed to the point of not being submitted vs. stuff that'll go?

I think this is a bad take to be honest.

Next _should_ contain stuff we _expect_ will go to Linus, which _is_ all of that.

The issue is that people aren't bloody testing next!

@ljs @kees @vbabka

Well, good points, but fwiw, afaiui only patches that *were* reviewed by one of the official maintainers are supposed to be included in -next. To quote Stephen from lore.kernel.org/linux-next/202

"'You will need to ensure that the patches/commits in your tree/series have
been:
[…]
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window."'

lore.kernel.orgRe: update omap branches for linux-next - Stephen Rothwell
@kernellogger @kees @vbabka they are ostensibly reviewed by Andrew.

I mean thanks for trying to make stuff get _less_ tested before rc though...
Thorsten Leemhuis (acct. 1/4)

@ljs @kees @vbabka

But andrew replaces whole patch series with newer ones over time, or am I wrong there?

That's something other subsystems normally don't do.

So from the outside mm looks a bit odd and scary, sorry.

@kernellogger @kees @vbabka I don't even know what you mean by that...

Patch series go through review + different versions that's how kernel development works?

@ljs @kees @vbabka sure that's how it works, but most other subsystems *afaics* only add them to their trees included in -next once they are considered ready; all problems that surface later must then be fixed by patches submitted on-top of the subsystem tree, not by sending yet another newer version of the series.

@kernellogger @kees @vbabka so other subsystems go through multiple versions of a series, and then do a bunch of 'fix' patches on top for some reason? That's not really sane?

I doubt very much that's the case, if it is that's silly, git has rebase you know.

@ljs @kees @kernellogger @vbabka Sane or not, it is pretty much how some subsystems do it. The trees are rolled and re-rolled before submitting to go into `-next`. Though I think fs rebases and rejiggers their trees every time things need to be fixed up instead, similar to mm.

@kernellogger @ljs @kees he normally applies per-patch fixups from a new version, and squashes them before moving from mm-unstable to mm-stable branch at which point (around rc5?) the rebasing should stop. If rewrite of series is too drastic, it's replaced.

@vbabka @kees @ljs

ahh, many thx, now I better understand how he does this.