Messages in this thread | | | Date | Wed, 29 Jun 2011 00:09:55 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [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?
Thanks,
-- Jiri Kosina SUSE Labs
| |