Hi all, In the 4.11 drm pull request Linus raised a few things that we need to discuss: Late driver/enabling pull requests ---------------------------------- Imo this isn't as one-sided as Linus made it sound, we've had the policy of pulling new drivers and enabling for new hw very late in the merge window forever. And I think there's some good benefits, both for users as for companies trying to do early enabling. It's just that in the past few years it's been mostly arm drivers (where Linus doesn't see the inevitable Kconfig fail) or new code in existing big drivers (where Kconfig fail tends to not happen if you leave backlight code alone ...). Anyway, Linus has been pretty clear here, not really wiggle room left and personally I think this doesn't hurt us that much, it's more on the unfortunate side. I discussed this a bit with Dave on irc, and the proposal would be that every feature patch must be in linux-next by -rc6 and in drm-next by -rc7. This is how drm-intel has run since years, and also what we started doing with drm-misc (except new platform enabling, which I guess now can't happen any more, amdgpu with Vega will probably be hurt first). So works, just means everyone needs to queue stuff early and also have their tree in linux-next (or get into drm-misc if that's too much pain). Linus shitting on dri-devel --------------------------- I'm not happy with that, and asked Linus to at least drop dri-devel when he shits on Dave and maintainers. Dave also brought up the idea of bcc'ing dri-devel, which should prevent shouting from Linus reliably. Note I'm not suggesting we ignore Linus' input, just that we keep the 90% insults that it's wrapped in out of our community as much as we can. Better ideas than bcc would be good. Splitting the drm pull ---------------------- I don't think this would be a good idea at all: - Personally I don't want to send pull requests to Linus. Dave seems ok with taking the heat for us, and I'm very happy he's willing to do that. I'd certainly not do that. - There's the small problem that more trees means we need to spent more time with the burocratics. From my experience with drm-misc and drm-intel alone there's lots of coordination needed, and we resync every 1-3 weeks in drm-next with pull requests to Dave. I don't see anyone volunteering to spend more time on burocratics, there's already enough to do. - We've done some really impressive refactorings in drm the past 1-2 years, very often cleanups that new driver contributors have done. Looking at drm-misc we need to resync about once per month to be able to move forward, since new drivers depend upon new refactorings and new refactorings later then need to have a tree with all the drivers. So really no way to split things up I think without slowing down a lot. And ime if you want to ship upstream as product in the embedded space, we're still not fast enough. For Intel that'd mean we'd have to pull out a lot of our efforts spent in improving the core and helpers, and I think the same holds for a lot of other drivers. Many might even entirely drop upstream because bikeshedding a helper for 3 months first and then the driver for another 3 months for something trivial is silly. So overall I think overall this would hurt way too much, and we don't have the people with free time to implement it anyway. Well, without slowing down and making upstream gfx irrevelant again now that it's finally being taken more serious. I also discussed this with Dave and others on irc a bit, and Dave thinks that there shouldn't be any problem for us if we keept he one single overall subsystem tree. Those 3 items where the ones I noted, anything I missed? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
