 Hi guys So talk about what I've been up to lately as you probably noticed there are there are get trees now in kernel.org I like to talk about what I'm doing about that and what I plan to do in the future I'd subdivide my tree into three major categories That's hot fixes that stuff's going to go into Linus in this RC window Memory management, which is going to go in the next merge window and then non-MM Which is another? Concept which will go also in the next merge window and that includes a OCFS 2 and I a 64 which I am the maintainer and Proc FS and you name it everything else hundreds and hundreds and hundreds of subsystems Which I have taken patches in the past will take patches in the future most of them empty at any point in time and Of course, I'll mainly be concentrating on the larger part, which is the MM part All three of these things hot fixes MM and non-MM. I divide into two bits one is the stable bit, which is a non-rebasing get branch based on MM's master branch, which I'll cut around that RC 2 RC 3 With a plan to leave it there until the next RC 2 or RC 3 so it goes back and edges are naughty on top of the Stable material, which is a non-basing tree for Linus in the next merge window I'll have the unstable tree, which will be sorry. It's a quilt queue and That will be rebuilt on demand As I do releases All of this material MM hot fixes unstable MM unstable non-MM stable unstable all rolled into a master branch called MM dash everything and that goes off to Stephen Frank inclusion in Linux next and I'll probably recut all these branches two three times a week to keep everything nice and updated in Linux next I Like to keep things that in a quilt tree because it is so flexible Well, things are churning and being stabilized and getting ready to go into the The under the into the stable branch I Can and will if prevailed upon do so do direct get pulls From your branches, but I don't think it works. I don't think I've ever seen a substantial patch set which got through unscathed a Couple of years ago 15 20% of the mm patches I had for dash fixes. They're real functional code changes and Then they're all the changes to the changelogs, which turned at a tremendous rate So my preferred approach is to stabilize stabilize stabilize we decide okay This patch set is now ready to go into stable MM dash stable and I'll talk a bit more in a few minutes about What I'd like to do around that process Once we decide it goes into stable I want to take the quilt patches a crunch mill together fold in the fixes to a final pass across the changelogs Then merge them into a branch under mm stable and that's hopefully where things sit Now of course shit happens. I might eventually have to take a branch out and put it back and unstable or throw it away all together We can do that Alternatively if the originator of the patches with the author really really wants me to Pull their get tree well, I can I'm going to have to handle myself across to them Make sure it comes back to me as identical to what I already have and I will check that That's the easy part, but I'm also going to one check all the changelogs are what I had as well I carry far less dash fixed patches patches than I used to Mainly because I've got lazy if you send me if I'm on v4 and you send me v5 I used to go through it and go all the little v5 fixes so we could see what you changed Now that I just check out v4 silently and re-merge v5 so I've less dash fixed patches, but the code is still churning and Don't know it doesn't matter if you I've seen it if you're a version 11 You're a version 16. You've done absolutely everything you possibly can As soon as it hits the tree the shit hits the fan. I Mean poor old gear how many times we've broken the m68k we always break m68k Yes, I would prefer to keep things in called tree if prevailed upon to do so Yeah, I can send it back to you and you send it back to me But it's latency in its work and things can get lost And incidentally when I do drop your v4 series and merge your v5 series I'll stick kill keep on my little dash fixed patches patches against v4 Just to check whether you incorporated everything and sometimes. Oh, it still applies The submitter missed it missed out on some fixes, which I had so I can double check that branching structure What I have a present for this cycle is really lame The nm unstable print is just a guilt acquit a quill queue every patches Parenthood office predecessor I'll say sorry to Linus and try and get it and merge the whole lot of one hit But then for the next merger window. I want I want to do is go for a very flat structure What? Everything every patch series ideally is based off master and they all get merged and here patch series could be a single patch I'm I think I'm looking at having a separate branch for every single individual patch because if the scripting is right That should be cheap implications of being Probably best if you were to target the mm master branch Which would be cut off RC2 or RC3 because we're gonna remain there But really I don't care because I'm gonna quantify things, you know You can work on last Linus main release. You can work off RC2 Like a nest mainline you can work a flindex next. I'll figure it out based on anything you like really whatever's most convenient But don't base it on Windows NT. That would be a problem Branch naming so I expect after the next merge window have many many many branches these branches will have long names If a patch series is in the unstable queue it'll be mm dash unstable dash And the rest will come from your zero of n email. So you get to choose the name of the branch I'm wanting to ask as I move on to the idea of topic branches is that within the subject of your patch set Which may be a single patch? Please identify what subs what topic you believe it belongs to You know if I've patches that I'm trying one one hell what topic is this it could be a memcg patch Which changes three lines of mem control that see in 30 lines of VM scan dot see so by line count It's a VM scan patch, but in fact functionally it's a memcg patch So please I'm gonna ask the originator to decide what topic you think this is and that will be reflected in the file No in the name of the branch and The reason I want to do that is we can look at the branch name and directly relate that back to the subject of the Email on the manual list. We can go both directions, which I think it's pretty neat if we get the naming right I'll do a large and boring Document and once this is all settled. I'll get that in the documentation directory Which say if people do it wrong I can politely point them at this this section 45 a please This is the process. Please do that I Hate changing the subject on your emails because then that we no longer Can relate what I've got to what's on the manual list. They can't relate that to name of the patch So I think getting the subject right and appropriate is gonna help ease the process along So I'm okay. You can choose whatever branch you you is best suits your needs. I'm gonna attempt to base Your patch queue on on the master branch Sometimes I may have to branch it off one of my existing branches That's okay. I'll make sure my tooling handles that and The branch structure of these many branches will all be captured in my good old series file So my cook you was also in colonel at all in a separate get tree. There'll be a stable link to the series file Which will describe the branch structure in some manner which I will describe and That that'll be a stable URL and I update that several times a day when I'm working I think the only if I've got a particular branch sitting in the AM stable queue Let's say it does something to VM scan My preference would be not to base your work on that but base your work on RC three unless you are really explicitly logically working on somebody else's code which is in this Kernel cycle and that's very rare It's very rare for somebody to work on somebody else's patch set that hasn't gone into a linus yet on The occasions where it does happen. It's the same person, you know, they don't want to patch series and another patch series Which which bases off that? So it's fairly rare so a flat tree structure should work unless the amount of conflicts becomes totally unreasonable Topic branches, you know, other subsystems use topic branches They don't make a lot of sense to me if I've got the patch against VM scan that does one thing or another patch against VM Scan that does another thing that unrelated each is its own topic The only relation between is they happen to hit on the same file and maybe textual conflicts So I will have topic branches But I think really the only reason to have one is so I can reasonably chunk stuff up to send into linus rather than just Enormous, please pull the whole world Now that's bad in a way because for Linus pulls of VM scan Topic and then doesn't pull MCG for another couple of days then we're sitting there in an untested state He's got code which we've never run before not on Linux next to run anywhere before But this has been happening forever. I don't send the entire quilt queue to Linus and one here I'll send them a hundred then another hundred and then seven and then we're done There is a risk that will introduce a bug in one patch and then accidentally fix it another one I think it's only ever happened once so there's a risk and I'll dialogue it with him I think the risk is pretty low So yeah, I ask you people to choose the name of the patches and to allocate the subsystem it goes to That's all patch wrangling shit. There's some people shit on top of this It's all very nice to have a stable non rebasing good tree against which to do ongoing development But that's only useful if we've got something in it Last weekend we're at RC for and I went through all my various patch passing. Okay. What can I move in the stable branch? Series after series after series was not ready a little little cross marks You know, I'm waiting for the reviewer to come back. I'm waiting for the submitter to respond to review I'm waiting this test results to come in. I'm waiting for this person I think should review it to show some sign is actually read it. We got bugs everything RC for halfway through the RC cycle was not yet ready to go into the stable tree So if we want this process to work, I mean, I think we should be more Expeditious about getting these patch sets nailed down. Just don't let things dangle on weeks after week after week and So I will become more active about this and I will help I'll send little emails and they're almost always gonna be private emails I don't want to put people on the spot and embarrass them. I'm just gonna ask you Can you please respond to this one? I want you to understand where I'm coming from and just trying to hurry things along Yes, maybe Just just a question. So one of the things that you Have been doing is to merge changes to your tree as soon as possible and One thing that I and that might be really great in many cases But one deficiency that I have found in that process is that this leads to a lot of fix fix fix fixes and also a unclear situation for the submitter because Whenever you see your patch being merged into your tree You are almost half done So attention to that work decreases considerably right and that's probably the reason why you have those Waiting for somebody. So my question is Would that be a process regression if patches get really merged After they they are not having any Comments like I'm waiting for somebody or something to happen I reread the email you sent me a couple years ago on this topic and yeah, it sounded that's what you said sound awfully familiar I do actually skip version one a lot more than I used to I Don't do it visibly. I'll send a little note person say thanks I think I'll skip version one or I'll let this person look at it or The trees full right now. I just Keep the originator particularly if it's a new person. Just let them know where we're at what my thinking is Please resend it. I'm gonna wait for viewers to provide input So I don't always aggressive leap on version one and sorry to a large extent. It depends who it comes from So if a person thinks that my merge means okay my work here is done that was an inexperienced person I Do like provide guidance to those people to help them understand where things are coming from So that sort of happens under the hood I Always welcome people assembly private email, you know, just send me an email saying I don't think you should merge this yet Or I want to look at it or I don't trust this. Just let me know what you're thinking. I'll take that on board Is that cover? So in general, I mean, I like your style of doing things that that appeals to me and it's been working out great for me Sometimes I feel like we should push more for review before pulling a series into Next for example because like lately we've seen lately. We've been seeing quite a lot of Breakages in next and the patches the question were not reviewed yet So I was wondering what we can do about that because obviously like lately There are a lot of code changes and we have like limited review capacity For example, I try to review a lot, but like the last couple of months. I was busy working on other topics that Took longer than expected. So like I'm wondering if if that should be something to focus on that Like we only pulling pulling something after People looked over it and agreed that it's like in a decent shape or if you really want to go ahead And let's say you say skip version number one I was wondering if that is like a good condition to put something in or really wait for until like Let's call the sub maintainer although that doesn't really exist like says or yeah Like we can give this a shot. This might be worthwhile to expose to next or something like that Yeah, I I don't think I want for get formal review to Be gating on merging it in next time. I'll do my best to look at it I particularly see who it comes from I bought it myself. I think this has got a good chance of going in So I like to pipeline these things To attempt to accelerate the process get them under runtime testing in next while these things are happening But have some in the notes to myself, you know, it's not going to proceed further until I think the appropriate people have looked at it and as long as submitter understands that and Again, if you do want to review this patch set me don't have time Send me a little note. No, I'm a little like mark on it and I can help with that But I think sort of overlapping the runtime testing PR bot tracker fuzz testing along side the review Let's just get these sort of review level things and the runtime things happening concurrently So and you said you kind of didn't want to call people out on hey, I'm waiting for you on this But do you think there's room for more transparency? Like I think there's just the time that in terms of like saying Showing the state of the queue and saying this patch is Especially waiting on more review like can people perceive that in your patch file or that private information for you They certainly can okay if they they know to look and they know how I work But this is why I'm becoming I want to become more activist about this You said present the decision to move a patch set from unstable to stable It's something I do very late in the place basically doing the merge window and I do under my own cognizance I want to fix both those things. I don't want to do it late anymore. I want to move it up You're RC4 RC5. Let's get it go this while I'll be poking people. Can we please get this wrapped up? Now the thing I haven't touched on yet is I don't want to make this decision on my own People are fallible not just me and I could miss an email. I could miss interpreted email, but also you people could fail By failing to make it clear to me that you still have issues so I could think everybody's cool So what I'm going to do now. I'm not just going to take a patch set and move it into the stable branch. I Want to run it by everybody else first But I'm not going to say is everybody okay if I merge it in the stable. I Don't want to do that because I'm not I'm sitting there waiting for this person to say yes this person say yes this but and say hell Yeah, and also, I don't want to do that publicly because it'll put people in the spot They're going oh shit people are waiting on me and they're going to go and nobody's certain you're never certain How can you possibly be certain? So what I'm going to do is I'm going to say I am going to measure this two or three days from now Nobody says anything. I'm going to put it in Okay, and you can send me a private email I feel like if you're really stressed out about this and I will figure it out, but no I want to solve these two issues of getting the end of the stable treat very late and Having to do it all by myself And I'll do that with irritating little emails Understand where I'm coming from Now I think this moving of a patch set or a patch from Unstable to stable is a big deal and so we need to concentrate around that a little bit Now When do we decide to move a patch set from unstable into stable end of the non-rebase and get tree which is often It doesn't have to be perfect When we merge it when I put it in stable tree like says at RC 5 we got many more weeks RC we've got the next merge window week all the next RC. That's three four months We've got to get it up to production quality and to be realistic We've got it probably another couple of entire kernel cycles before anybody uses this code in anger So we have many many many months to sort out the last little 1% We'll have a lot of pipe lining going on in our kernel processes Let's use that. I mean let's not throw any old shit in all this is tree Obviously, we need to be diligent and do our best Let and we're not going to know what's wrong with it and do more and more people roll it out and test it on more and more machines But no, I think the criteria for moving something in this table is Does Linux want this and is it good enough? It doesn't it's gonna be is it perfect? It's good enough Now we can always fix the little shit later. Thank you for CC stable. That's wonderful So when I asked, you know, I'm moving this I plan to move this into stable in a few days time Please ask yourself do I really think Linux wants this feature and do I think it will be production quality? Is this documented anywhere two three months from now? Because actually I was asked I went around before coming here I went to everyone in my department saying what would you like me to bring and one of the topics came out I think it was exactly what you just said could we document the criteria of getting stuff into mm? That was actually almost verbatim what was asked to like you know have something that we could say this is what we You know if we look at this and we could say hey we pass this it would likely Move forward or whatnot or maybe we could fix it or whatnot Maybe there are some things that shouldn't be written down But that would have probably solved a lot of issues over probably wait and save wasted time and such to know like you know Having an idea of like should we go with this features or something we could pull it? How do we go about getting it in getting accepted having something documented or something where we could you know? So people don't waste their time doing a lot of work and then finding out no no one wants this or no, you know go away Well, I do still will be the case right? It still will be the case people doing a lot of work and then finding out nobody wants it. Yeah Yeah, but having some idea about like you know documented Criteria that says you know at least there's a 90% chance or 80% chance that you might actually get it I don't know well I will move all this stuff in a documentation file put in the documentation directory, but the words around that thing I just said will be guided You know we really shouldn't be putting stuff in the tree until it's perfect. Well, sorry This is the real world. How many express that and formal document and don't know I Have a more general question now once we have the MM tree Do we want to create sub-bierarchy likes the networking guys do or drivers guys do or we continue to have separate reset for my Mem block for wheelies a page cache and so on Okay, so do we want to merge everything in the end into the MAM tree or we continue to keep separate tree for separate MM Subsystems well mem block is sort of its own little world world. I've never ever had a conflict with your mem block tree I don't have many patches, right? So I get a nasty email from I mean if you want to Get me to pull on the mem block tree I can do so or you can just send it the linus independently as Flush to me it does with slap. I'll continue to send to Linus independent. Whatever works, but largely question like Probably will create more conflict or will be a base for for different work on top of it So does it make sense to merge really stream to a mem tree? Which tree will is tree? I wish we lived stop writing patches Okay, I found the on switch I Also wish I would stop writing patches So, you know, obviously folios have been hugely disruptive from all points of view I think it's gone quite well considering It could have gone so much worse. I've been really pleasantly surprised with how Few bugs there have been I was expecting this to be far harder than it has been But I think I I think I'm almost done with the hugely conflicting changes between MM and FS and this and that and the other I think things are going to Settle down at least for a little bit I think a large part of the problem we've been having is that you weren't using a git tree before now and I so the the future MM patches that I have indeed the MM patches I have for this cycle I'm sending to you. I'm not planning on having On on doing a git pull to Linus for MM folio patches Now for file system folio patches, I am going to be doing a git pull for Linus Most of the people in this room will not have seen those patches because you're not subscribed to the next FS Debell And that's fine. You don't need to be that's, you know, you're not process and developers and There are going to be and there are some some conflicts and I've marked them as such and Stephen Bothwell has run into them and he's followed the instructions in the patches that says just drop this patch because there's a Conflicting change over in Andrew's tree. It's the swap B page stuff that was Definitely needed and I'm so happy has gone in I wish had gone in you know years ago, but Time So yeah, I think I think That I will continue to run a git tree But it won't contain very many patches which conflict with memory management because I'm going to be funneling most my memory management changes through Andrew through through what you The final bullet point right for myself is okay, we have this nice non rebasing MM stable tree What uses it We don't really want people to base work off it. I prefer the base of master so everything's flat and I could merge it and thank God for git re re re So I don't really Anticipate that many people will do they work off it if you're someone like Willie He's got some super patch that bashes up bashes that the bashes on everything Then he'd rather he'd be better off looking for conflicts with the MM unstable tree Which is everything which plans to go on the verge window But It's there. We'll figure it out as we go along Yeah, Mel go ahead I Very strongly suggest against Defining criteria for why a patch that could be merged because once any criteria is actually specified. It's something I'm a gamer fight Yeah, okay It's Once you lay down guys is these are the rules people try game fight was roots and it's something that Shows up to some extent Well too much less recents in schedule or land in CPU schedule land where people try and like gamify what the criteria are and get like Slap down repeatedly over and over again and I don't think that is is Really something that you should do but in terms of the the rebasing versus non-rebasing thing and when things are considered stable or not stable Let us this criteria for Allowing Tree or a get pulled to be pulled in is based on has this thing been tested or not So if there is an RC to a Stable tree and then there are stuff that needs to be ripped out and it needs to be Redone against a later RC then so be it at least in in mm in memory management It's relatively rare for patches to conflict with each other directly in schedule or land There can be subtle interdependencies between different series that go in so the tend to layer stuff on top of each other Are these say it should be done against at the latest sketch tip that should be done at any given time But that that problem rarely happens at least in my experience in mm most of The series are actually independent of each other and if it comes to the case that We need to rip out something in RC 4 and RC 5 and the baseline moves That's fine as long as there isn't a rebase and RC 8 or an RC 9 Where the accepted patches get reassembled so like stuff coming in and out is It's just not that severe of a problem if it needs to be pulled out and we need to and the mm stable It gets rebased at RC 4 or RC 5. I don't think that should be considered a major problem Just sort of do that. I'm not as new to basis Exactly and like it would be kind of like a flag day Then it says, okay, the base is somebody was working off mm stable and there's a major disruption in RC 4 well then too bad The figures will have to be whatever figures that you use to justify that your series go in or just have to be redone And we would hope to be relatively rare But at least my primary working workflow right now is that I do everything against RC 1 And I do piles of individual series some of them are mm based some of them are scheduler based as according as each one Individually passes testing. I assembled them to make sure that they all work in combination Which is particularly important to schedule or less important than mm But like if something needs to get thrown out it gets thrown out So just make sure that they end result is still okay, and that's fine up until you're at least at RC 5 once our RC 5 I Find there's pretty much no point trying to send a new series at all. I might so just wait through the next merge window well Well, it depends how big a change it is from one to the next but I Think for an individual developer If you want to do runtime testing RC 2 could be a bit flaky I think the best approach there would be for you to just locally merge up with Linux's latest RC 6 and do your testing Right, you do your runtime testing on the result of that merge Even though your patch that remains based on RC 2 and of course Steven is going to do that as well He's going to integrate I change it with the latest reading edge linus kernel and we'll get the runtime testing results back from that One final note our little head. I always had there. There is one little tree which Is special I will be maintaining often I get these patches which are kernel-wide, you know somebody renames everything or does some stupid shit or or it take it a It explicitly works on patches which are pending in Linux next or something So I will have a little cue which will probably always be a guilt get a quilt queue of Kernel-wide patches and then I'll sort of independently feed that through the back door to Steven for inclusion in Linux next and Send it to Linus probably as a quilt patch bomb very late in the merger window But I would be very reluctant to significant mm material in that series Basically mm stuff should be based on RC 2 not Linux next But that include Like file system interactions like or you're talking about like things that are actually kernel-wide like What what trips what trips it into that? workflow is when Because the only damn thing I can get the patch to apply to a make any sense is Linux next I was essentially I wish the point one nothing's working. Yes, so I'm going to move the patch to behind Linux makes some magic It applies. That's the main criteria. So as long as it functionally makes sense and Syntactically applies. Yeah, I'm going to cure it up behind Linux next It's very much a moving target and I wait things to stabilize at the end of merge window before presenting it to Linus That's what I got Yeah, so I would like to get back to the I think that Mike has brought up and That's about sub-maintainers because we currently have few areas that are handled by a git tree and For some reason I I still cannot cope really well with with people bypassing you and sending pull requests to Linus directly because to me it seems like a Potential problem long-term what by completely balkanizing the whole mm and not having a coherent picture of of the area and Do you think that it would make sense to Have growing number of sub-maintainers so that you do not have to care yourself about those areas and Made essentially pulling from them as they ask you so you get those nice Let's say pull requests with the description descriptions of what the changes are so that you can when you are sending your pull requests, you do not have to care about those high-level descriptions and If you are okay with that what would be the Where that work would be Gathered like it would be the stable branch where you essentially when you are getting a pull request from a sub-maintainer You just merged that into this stable branch and then once you are done with the current let's say Merge blend and you send a pull request from that branch or how do you envision that thing? Yeah, that would work I wouldn't want to put in stable branch until it is stable until you know We agree that this is hopefully unchanging from now until that until the merge window So it initially put it in the unstable branch because it's unstable And then as that we see the appropriate manner of view come in Then at some point in time will agree to move it into into the non rebasing stable trick Okay That sounds like a great improvement to me I'm speaking for myself, but I Guess that this would make the process much more transparent also for others and That would be cool. Yeah, I still want to see that said the appropriate manner of view from the appropriate people have enough runtime in the next max and And I'd still like to say, you know, I Think it's time to move Michelle's branch from unstable Distable I'm going to do that three days from now If I don't see any objections. I'm doing it. I still go through the same process. Yeah. Yeah, sure I mean that there will be likely a lot of things to be sent through patches not through the gateway, but we seem to have some areas that are maintaining their sub little thing and Yeah, that was my primary concern that Just to grow that sense of Sub-maintainers that might even encourage more people to be actively maintaining their areas Because you would be pulling from them like as we see in other Other areas. Yeah, I'd still like them to follow the same Diligence, you know all those little reviewed buys of those little act buyers Adam make sure all the appropriate people CC that the change like additions come in that Every little fix is rolled in and doesn't get dropped on the floor somehow Even if you're not delegating the actual Code movement like what it makes sense to declare Somewhere like the review team because I know when I I know when I added a new memory zone Dave Hansen got a got a ping from Andrew saying Dan or a few people like you're kind of in your in the MM inner circle like got notified like hey, is this okay? Should we back this out? Are people aware that they're maybe maybe they already know that they're kind of in that reviewer team but it kind of works from the Like how the x86 mm side works with anything there. We there's like Andy Peter Dave We they you talk you talk to them before it goes to the tip tree So they're not actually they're not actually sending code to tip, but they're they're the gate can not my gatekeepers But they're like the review team that kind of a well the maintainers fire can capture that Accurately enough. I don't think there is any sort of formal Siloization there. I don't think it's appropriate because so many people to say busy and doing stuff And so it basically I end up making judgment call and where things would be adequately reviewed It might be by a regular person or a part-timer But I don't think having hard and fast Go no go team would be workable And to some extent, you know people may end up reviewing it post facto and we've still got those months to fix it up And also backtracking in a long way I'll talk about the readiness of a tree to become stable When you we need to agree that it's But it's a desirable feature for Linux and that it's it's ready enough Cleanups cleanups are wonderful. We will have cleanups, but cleanups can be deferred indefinitely I don't think cleaning up the code Should be a gating issue if you think move this function here rename this to that and that sort of thing Yeah, fine. It's desirable, but we can do that them next RC As long as the codes got at runtime, you know cleanups can be deferred So I don't think that should block inclusion migration of a patch set into the stable branch I Just had a question. I thought I before today I thought I had a rough understanding of where to base my patch sets, you know At any given time, you know right now, maybe you say okay today RC one is out So I know I should base my patch set on RC one or or but now I've lost that confidence and as I wondering if maybe you could just kind of run down and say, okay You know, here's the situation where you would base it on RC one Here's the situation where you'd base it on Linux next. Here's one where you'd go for MM stable Well, my preference would be of Of MM gets master branch. I mean I could draw a line in the sign Sam and say I'll cut RC to So that RC to will be my target from merging these things but you can work against linus is most recent at least probably and Things will be fine. So to large extent. It's whatever is most convenient for you What makes most sense for you Probably not Linux next that's that's a stretch Yeah, so we have lost him along the chat and he he's saying that I think for pool from a sub maintainers The reviews would be already gathered by them and the pool would go directly to stable at that point of time or at least that that's his understanding so So yeah treating it as any other patches patch set or any other patches Wouldn't really save much work for you That's fair enough as long as that I'd like to see that patch set and we're talking about the slab series here Has already been in Linux next for a long time. So I assume that's being independently included by Steven So even before he's got all the reviews coming and hopefully if this stuff is already been rounding in Linux next for a week or two So yeah Yeah, the slot trees also continuously being exposed to Linux next the question would be if if to also do this Exposure through your tree or independently or and only the The end result would be Going through the mm stable tree, I guess we can Look at how other Trees with sub maintainers do that Could but main slabs pretty damn standalone. I think what we've been doing for the past few months has worked. Okay I've never observed any conflict between my get a nasty email from Steven So I think just keep doing what we're doing and just treat it as an independent branch. I Just send it directly to Steven to Linus. I don't think I would add any value Okay, it works for me, but The question was if there was more Sub maintainer sub trees like for example, mcg or whether that should Really break the mm3 To pieces that would be independent or or whether we should strive to unify them in the end I've gone quite no There are a lot of peripheral stuff in mm. I mean memory hot plug slab Z three-fold zs Muller go that stuff, which is pretty standalone But the core material mcg vm scan page a lot and map huge tlb It's just all Everything's smeared together. I think decoupling those amongst maintainers amongst trees will be It'll be a nightmare Few years back when I was trying to mimic your free with with get free I essentially was doing that by topic branches and then merge things together And I was quite surprised that Conflicts about those different areas for example my mcg or hot plug were really been minimal So do you think it would make sense to at least try that approach or? Maybe I'd like to try this approach for a few months and see how it goes, but I Mean if it makes sense if it'll give us something better than what we have yeah, why not? Okay, because I believe that we can sit with with Roman and Neoness and create a mcg part for that that would be probably one of those larger source of patches in your tree and Yeah for memory hot plug I believe that David and Oscar are doing quite a lot of work right there. So maybe they can't come up with something and Yeah, if you're willing to try that approach then yeah But worse can happen then we just throw everything away and and just apply those patches, but you know Well, let's let me get this get this stabilized and go through a couple of cycles with it and then start looking at moving that stuff in Mcg does have a sticky little pause a lot of places that my worries me a bit So what what I wanted to bring up in a context was something that was raised upstream that Especially people that are new to the kernel or to mm. They sometimes don't have a clue who to cc And I mean if you do get maintainers on a specific file, you're mostly out of luck I mean get you and then like 200 people that committed court sometime Yeah, so the question was then whether we actually want to define for example in maintainers some MM subsystems and not necessarily at maintainer attacks, but for example review attacks and I was actually proposing to do that soon for example for memory hot plug Like just the most important files that I care about and then I might just get like see see it more often So to say I was wondering if that should be then something we should discuss in general I mean, I'll propose a patch to do that, but maybe it makes sense for other subsystems as well Yeah, fine. I think get I think get maintainer and the maintainers tree handles up pretty well the files You're interested in you put your name in there and you'll get even more email Yeah Yeah, but then I don't have to dig through Linux amendment like find out that there is something interesting after three weeks when catching up Part of part of my life is making sure the right people were CC Just a small note like I think adding Documentation files and test files into maintainers file actually raises awareness of just like people don't know that they exist And like adding it makes it more obvious I don't think I follow that sorry I'm saying that like just listing Test tests like which exists like self for example memc group castle tests or like as a any any sort of testing and Also, like any sort of documentation in the maintainers file It's a good thing just to kind of raise an awareness that they exist Right. Yeah. Yeah. Yeah for see groups. I added like Castle of test like recently and I think we should do this more often Okay Mill talk to us Gonna be heard you can you hear me? Fright, sir. Oh Okay I'll take that would be me classic I exist in the maintainer file With an R entry under scheduler and it's far like just one specific config parameter for anything schedule or releases where if something is coming in that's Is affecting that config that I meant to review is it's not some possible to have the same for Breeding management. Now, we don't have the same granularity Are the same breakdown both we can document in the maintainers file that someone is not necessarily a sub maintainer But if you are touching a particular part of the memory management that you Should at least get an act from this person are some acknowledgments that they've at least seen it So different a part of my role to make sure the right people have looked at it and rubbed in their nose So you all have a lot of maple tree reviewing to Can't argue with the logic We don't know I get to sit down yet. Oh good No, okay, so When when when you send maybe a larger patch set sometimes you have to set certain things up before you actually get to the meat of what you're doing and I'm just wondering how the message in That beautiful pretty cover letter Will get merged in in the new plan How's it handled in the Upstreaming Well, you know, I tend to put it inside the first patch and I think I will continue to do that Okay It means it means that like the maple tree for instance. I'm setting up Test framework at first so that you're gonna have like all this information about how the maple tree is gonna be you know making sliced bread For the first time versus and and and it's gonna be in the patch that says like add print error to The radix tree Test infrastructure, so it's just wondering if that could be handled in a different way. Yeah, I mean that that's Yeah, it's a bit silly to do that, but you can just have the one-liner seat patch five the details Okay well that had to link back to the morning list but Mm-hmm You'll have the info in Well in this in my patch one I have a link to the zero of N as well as the link to this particular patch I always do that so go to link to the head of series as well So yeah, people will figure it out but to your But then should your first patch be a documentation patch back to the mic request and Because a lot of times there's like really good details in the change log like why is it's not in documentation? It's like a good narrative well, well I usually the I Put that with the whole the the data structure, right? So the code goes in and the documentation and then the next patch was a huge test patch So I mean I guess I could put The big patch first and then the setup for the test that comes next Or It's just kind of it's just kind of Other other places in the kernel they have this the merge right and then that goes in The get pull or whatever, right? So you have the the one that actually has no code, but it's just like a huge Documentation on what what's going on in the next 50 patch 70 maybe who knows I Guess I've seen when you've pulled in the change log You'd like Andrew tends to pull it into the passion makes the most sense and like oh, I'm glad you save my save my cover letter because I Would have forgot what this does. Yeah Yeah Okay, I think leaving the merge request kind of leaves it stranded Yeah, I might get lost in history. That's true, right? Unless you dig through the get log for specific information, but usually most of it Hopefully is in in the code slash documentation, right? I mean apparently I'm the only one who does that but but other people are going to start today, right?