On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote: > On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote: > > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > Why don't the maintainers know which tree to put them in when they are > > > submitted? As an example, if I get a patch that needs to go to Linus, I > > > put it in my usb-linus branch, and when it hits a -rc release, I then > > > merge that -rc back into my usb-next branch. So I end up with about 2-3 > > > merges to -rc every release, which isn't bad and doesn't cause any > > > duplication issues. > > > > > > Seems that most other subsystems also do this as well. > > > > We do know (mostly) where a patch should go to, and we do push a > > backmerge every 1-2 weeks or so, too. > > > > The reason why we've started to require that every bugfix for drm/i915 > > land in -next first is fairly similar to why you insist every bugfix > > must be in Linus' tree: Without that patches get lost. Well, they > > don't get lost intentionally (they're all still in the git log for us > > due to backmerges), but we did lose some in the horrible resulting > > conflicts. Insisting that we have them in our -next branch means the > > backmerges can be resolved with git merge -x ours. > > > > And in the end this is how it's done byalmost everyone: You push to > > master and cherry-pick over to stable/release branches. Most projects > > don't apply bugfixes to the stable branch and then backmerge to their > > master branch, because it would result in pure chaos. You don't do > > that either for stable kernel. It's just that for most subsystems the > > resulting conflict gallore of using backmerges is fairly manageable > > (it's getting into the no-fun territory with drm core too, but still > > ok), whereas drm/i915 is just too much, moving too fast, to make that > > a working model. > > Ok, I agree that your code is moving too fast for the "normal" stable > model here. I just tried to apply a potential 17 patches and only 8 > applied. That's not a good percentage. Ok, the last remaining ones (all 6) in my queue, did apply cleanly, so your percentage went up a bit more, but it's still the worst of any part of the kernel and I don't think this is working as-is. greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
