On Tue, Mar 7, 2017 at 10:56 AM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Mon, Mar 6, 2017 at 7:11 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> 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). > > I've always tried to have all major new features sent to Dave by rc5, > so no problems with the timelines. Dave and Linus have generally been > ok with new asic support at strange times assuming it has minimal > impact on existing support. Our code release dates rarely line up > well with kernel cycles, but we can manage. > > >> >> 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. > > It sucks, but I guess my skin has hardened over the years. We've had > a fair share of heated arguments even on dri-devel. I discussed this a bit with Daniel on IRC and I realized I may not have made myself clear. My main point was that I think it's important not to shield our developers too much. They need to have some knowledge or linux-kernel and other subsystems just to get a taste of different development styles or things that might not have occurred to them so seeing feedback from outside developers is important. I'm not condoning threats or insults. Alex > >> >> 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? > > I agree. I don't see the need to split up the pulls. I think we do > pretty well overall. > > Alex > > >> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
