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

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

[Dave Airlie]

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.

Dave.

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

[Daniel Vetter]

On Tue, Aug 26, 2014 at 09:13:49AM +1000, Dave Airlie wrote:
> 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?

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?

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.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Dave Airlie]

(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.

Dave.