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!
@kernellogger@kees@vbabka I don't necessarily agree with the process in mm as it stands but this is how it works right now, that is a lack of objection and Andrew not finding major flaws = Andrew in effect approves, and unless it's a relative newcomer or otherwise he has reason not to want it, the series will get merged.
So it's representative of what will be in the next merge window (+ hotfixes not yet upstreamed for rc).
I'd like there to be more of a 'needs a tag from at least someone' rule in mm, but can't control that. It adds workload to people who have to act fast to stop stuff getting pulled in.
If we limited it to mm-stable or something then -next would be _miles_ behind what is going into the next merge window, and you'd also _not_ be stabilising as while not enough people test -next NOBODY tests mm-unstable so it'd become a pretty useless tree.
Again, I think the issue is that more people need to test against -next.
@kernellogger@kees@vbabka to be clear I am not a fan of the 'automerge' stuff, but I do think once something has at least sufficient review it should go in to -next, even if it might have unexpected later rounds of review.
Andrew won't take anything that has outstanding review on it btw. It is literally only the stuff that truly looks like it's going in.
But I concede I'd like there to be at least 1 tag and a day or 2 to make sure no obvious other objection before moving to -next.
The basically 'wait until we are really really sure there's nothing more before subjecting to testing' take though, yeah profoundly disagree.
What I've been finding with my series is that it goes to Linus and _suddenly_ you get a bunch of reports and are doing 12 hour days to fix things.
If you want less 'you ate my data!' I'd say test sooner.
Anybody testing -next and expecting serious stability is being silly even if all of your conditions were met, it's very fresh unstabilised code you can't rely on it.
And I literally run an rc as my main system atm btw...
So what you're saying is - during all of those weeks - we must not have build bots on the series, we must not have anything doing even ostensibly small levels of testing, we just wait until rc and ship it as is and that's 'safer' and will make people 'less scared'.
Truly the most stupid of all source control mechanisms and I saw my then boss (this is like 2007 era lol) constantly having to run a repair on its database.
I did say 'do you think that's a good sign?' and he laughed at me as if I was stupid to question it