Fwd: [attention: drm submaintainers] merge window for features to drm-next

Dave Airlie airlied at gmail.com
Tue Aug 26 14:14:44 PDT 2014

(this time for the list).

>> Okay, I've thought about this a lot lately, and I've been been getting
>> too lax on when I merge stuff to drm-next and I think people are
>> taking advantage of my good nature :-P
>> So we are going to try something new this cycle, I'm going to use -rc5
>> of the current kernel as the cut off for major feature merges to the
>> -next. That means that subsystem maintainers should have their -next
>> trees to me by -rc5, with allowances with advance warnings up to -rc6,
>> i.e. maintainer on holidays etc.
>> I realise this might make 3.18 a rather smaller kernel from a drm
>> perspective but that could be a good thing,
>> So its -rc2 now, you have 3 weeks to merge features and get them to
>> me. If they aren't ready they get to wait for 2-3 months.
> So I usually only send you the actual pull after 1 week to allow QA to run
> all the labour-intensive manual tests. So I'd prefer if the merge cut-off
> is -rc5, but that I can send you the pull request a week later. Since I
> won't rebase anyway you can easily check that I didn't cheat ;-) That ok?

Yeah that is fine.

> If not I'll simply send you less tested stuff - we ofc still do all the
> automated tests in nightly runs.
> Also thus far we've had alloance for early hw enabling for new platforms
> late into the merge window, as long as it doesn't wreak havoc with
> existing code and really just plugs in. Is that still on, or should this
> also be ready with the final stuff around -rc5?

It depends? I suppose I'd have to trust the new hw enabling is better
than what is currently in tree for that hw, and doesn't do anything
sneaky like enabling PSR or rc6!

> Also if you want to close this early I really think drm-next has to open
> right after -rc1 - the pile-up of patches will be fairly huge by then
> given that -rc1 is usually a full month after -rc5.

Well this round drm-next was open straight after -rc1 effectively, it
just happened -rc1 was during KS and made it kinda annoying to push
trees. I've based -next on -rc2, but yes I think keeping a tree open
all the time is required.


More information about the dri-devel mailing list