|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Dave Airlie <airlied-AT-gmail.com> |
|| ||Re: [git pull] drm fixes |
|| ||Mon, 7 Jun 2010 14:03:46 -0700 (PDT)|
|| ||Dave Airlie <airlied-AT-linux.ie>, dri-devel-AT-lists.freedesktop.org, linux-kernel-AT-vger.kernel.org|
|| ||Article, Thread
On Tue, 8 Jun 2010, Dave Airlie wrote:
> Oh the one where I said to the reporter, I've reproduced this, and
> will fix it tomorrow when I have proper time and access to my test
> I didn't think writing a fix in the 5 mins before I left the test
> machine and sending it you was acceptable, again can you maintain some
> semblance of consistency across maintainers/releases?
No, no. I really didn't imply that you should hurry and not be careful. I
was just unhappy about the mixing of non-regression fixes with the
> Like I'm happy if you really enforce this no features idea, I'd be
> really happy if you did it every release since it makes it a lot
> easier to push back to submaintainers if you can point at Linus not
> pulling features from people.
I already had another person state their happiness with me pushing back,
and while I had my reasons for doing it this particular release, I do know
that I've been letting things slide wrt the merge window a bit too much.
So let's see how the 2.6.35 release cycle ends up looking when all is said
and done. If pushing back harder ends up actually making things easier and
the release cycle ends up working better as a result, I'm certainly very
open to just being hardnosed in general.
I suspect it won't even be very painful if people just get used to it. And
if it ends up really helping sub-maintainers ("I can't do that, because
Linus wouldn't pull the result anyway"), then that would be a really good
reason for me to be rather stricter about the rules.
to post comments)