> > > I discarded them _because_ Eric handled them, which is what I said in the > > > comments when I discarded them. > > > > Ok, I did do my best to get patches in the right order in the mainline, > > but it all failed. AFAICS, v4l and sh are already in the mainline with a > > _wrongly_ resolved mefge conflict, which, most likely, breaks the > > sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for > > which should have been applied before both those trees and still haven't > > been applied are broken until the patches do get in and the later those > > patches get applied the longer the interval with the broken for them > > bisection is going to be. > > Meanwhile I have to consider that we have several bug fixes outstanding, > and since I can't send Linus a pull request every day (max once a week) > I have to be very careful about when I send stuff. > > So I only get _two_ opportunities during a merge window to send a pull > request. Well, you should certainly try to keep your tree unbroken, but when it breaks, fixing it asap should be a priority. I don't know where you got the 'once a week' rule, but it seems stupid. > I'm going to wait until tomorrow before sending my final pull for this > window, which is the penultimate day before the window closes. > > Don't blame me for these delays - it's not my choice to impose such > delays. I'd really like to fix those broken platforms right now. I > just can't do so without causing additional delays for other issues. > Blame Linus for imposing the "max one pull a week" rule on me. Do you have maillist reference? Not even Linus should slow down development like that. If Linus really insists on that, perhaps possible solution would be to make subarch maintainers send pull requests for simple fixes directly to Linus? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
