On 10/05/2017 03:53 PM, Thomas Gleixner wrote: > Jens, > > On Thu, 5 Oct 2017, Jens Axboe wrote: >> On 10/05/2017 01:23 PM, Thomas Gleixner wrote: >>> Come on. You know very well that a prerequisite for global changes which is >>> not yet used in Linus tree can get merged post merge windew in order to >>> avoid massive inter maintainer tree dependencies. We've done that before. >> >> My point is that doing it this late makes things harder than they should >> have been. If this was in for -rc1, it would have made things a lot >> easier. Or even -rc2. I try and wait to fork off the block tree for as >> long as I can, -rc2 is generally where that happens. > > Well, yes. I know it's about habits. There is no real technical reason not > to merge -rc3 or later into your devel/next branch. I actually do that for > various reasons, one being that I prefer to have halfways testable > branches, which is often not the case when they are based of rc1, which is > especially true in this 4.14 cycle. The other is to pick up stuff which > went into Linus tree via a urgent branch or even got applied from mail > directly. Yes, it's not impossible, I just usually prefer not to. For this case, I just setup a for-4.15/timer, that is the current block branch with -rc3 pulled in. I applied the two patches for floppy and amiflop, I'm assuming Kees will respin the writeback/laptop version and I can shove that in there too. >> I'm not judging this based on whether I find it interesting or not, but >> rather if it's something that's generally important to get in. Maybe it >> is, but I don't see any justification for that at all. So just looking >> at the isolated change, it does not strike me as something that's >> important enough to warrant special treatment (and the pain associated >> with that). I don't care about the core change, it's obviously trivial. >> Expecting maintainers to pick up this dependency asap mid cycle is what >> sucks. > > I'm really not getting the 'pain' point. > > 'git merge linus' is not really a pain and it does not break workflows > assumed that you do that on a branch which has immutable state. If you want > to keep your branches open for rebasing due to some wreckage in the middle > of it, that's a different story. I try never to rebase the development branches. It'll happen very rarely, but only for cases where the screwup has been short and I'm assuming/hoping no one pulled it yet. >> Please stop accusing me of being hypocritical. I'm questionning the >> timing of the change, that should be possible without someone resorting >> to ad hominem attacks. > > Well, it seemed hypocritical to me for a hopefully understandable reason. I > didn't want to attack or offend you in any way. > > I just know from repeated experience how painful it is to do full tree > overhauls and sit on large patch queues for a long time. There is some > point where you need to get things going and I really appreciate the work > of people doing that. Refactoring the kernel to get rid of legacy burdens > and in this case to address a popular attack vector is definitely useful > for everybody and should be supported. We tried to make it easy by pushing > this to Linus and I really did not expect that merging Linus -rc3 into a > devel/next branch is a painful work to do. > > As Kees said already, we can set that particular patch aside and push it > along with the rest of ignored ones around 15-rc1 time so we can remove the > old interfaces. Though we hopefully wont end up with a gazillion of ignored > or considered too painful ones. No worries, we'll get over it. The new branch is setup, so as soon as the patches are funneled in, hopefully it can be ignored/forgotten until the merge window opens. -- Jens Axboe
