[lkml]   [2011]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/29] gma500: Ensure the frame buffer has a linear virtual mapping
On Tue, 28 Jun 2011, Alan Cox wrote:

> > Is there drm changes in linux-next for this driver that I don't have?
> >
> > If so, maybe we need to just start sending these patches through that tree?
> Not DRM - looks like more sem-random treewide damage in -next tht has yet
> again not gone via the maintainers of subsystems.
> e44ba033c5654dbfda53461c9b1f7dd9bd1d198f
> 28f65c11f2ffb3957259dece647a24f8ad2e241b
> Can you drop the bits you have merged and I'll send you a new set (which
> will instead break the stuff Jiri has in his tree and he can fix it up)
> Really though this sort of treewide trivial has to stop, its costing tons
> of time and delays in real work. It should all be going via maintainers
> of subsystems but clearly Jiri is letting stuff through that isn't
> trivial but is in fact nuisance.

So, what I am normally doing:

- I usually wait several weeks (!) before I pick up patches to trivial
tree that have been also sent to maintainers. Exactly to avoid this kind
of situation.
With treewide patches, the situation is of course a little bit
different in principle.
- I reject to apply any drivers/staging bits on a regular basis. I
consider drivers/staging a moving target, and I usually re-route
anything touching drivers/staging to Greg immediately. Admittedly, I
have failed to do so in this case, sorry about that.
- I consider the trivial tree to be really the 'tail' of the whole
development process, so whenever there is any merge conflict in
linux-next caused by anything in trivial tree, I always take the
responsibility to resolve the conflict so that subsystem maintainers are
not bothered

I will drop the staging bits, sorry again for missing those in the bulk.

I am still wondering how come that this is causing trouble to anyone
though -- is anyone really developing real code on top of linux-next
(which should be there to cross-check merge problems between subsystems
and test functionality) instead of particular subsystem tree?


Jiri Kosina

 \ /
  Last update: 2011-06-29 00:13    [W:0.073 / U:1.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site