Em Tue, 15 Sep 2009 09:16:36 -0400 Michael Krufky <mkrufky@xxxxxxxxxxxxxx> escreveu: > On Tue, Sep 15, 2009 at 9:05 AM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxxxxx> wrote: > > Michael, > > > > Em Tue, 15 Sep 2009 08:15:59 -0400 > > Michael Krufky <mkrufky@xxxxxxxxxxxxxx> escreveu: > > > >> Mauro, > >> > >> I made a pull request to you over a week ago and I have seen you merge > >> *many* other developer repositories since then, many of whom only sent > >> pull requests within the past three days. As my pending changes > >> affect the tda18271 driver, only, I know that no other drivers are > >> affected by my changes, other than some new devices who must wait for > >> this to be merged first as a dependency. > > [snip] > > > Michael, > > > > As I pointed at the thread related to sysfs x ioctl, this merge is particularly > > complicated, since we have merges that depends on two arch merges, and we have > > a set of patches in the middle of the patches merged before the open of the merge > > window that touches on every driver, including the pending ones. > > Thank you for your reply -- I am just glad to know that you have > indeed received my mail :-) > > You mentioned that you replied to me in the "sysfs x ioctl" thread -- > the thread was so long and I didn't have time to read it, so I had no > idea that you responded to *my* pull request there :-P Next time, > maybe you should cc me if you think I should read something. :-) Yes, most of us are focused on merging things instead of discussing API changes. In fact, it was one of the first replies to that thread, where I asked to postpone such discussions, explaining my merge plans. Merge window is not the right time for discussing any API changes, since developers should be focusing on merging their stuff, solving merge conflicts and checking if patches applied via other trees (especially the backported ones) won't break the drivers. I plan to re-open the API changes discussion after the end of the merge window. > > > So, we'll basically have more than one git pull request, in order to solve the > > merging conflicts. > > > > There are a few remaining pull requests on my tree, including new drivers and > > your tuner redesign. I haven't actually looked at the code, since I'm very busy > > merging the code we have, but assuming that this changeset could be touching on > > several drivers, I opted to hold its analysis after fixing the arch > > cross-dependencies, to avoid the risk of not having a tree to put those patches, > > holding the process again. > > > Maybe there is a misunderstanding -- I did *not* do any tuner redesign > -- there were no API changes -- these are feature improvements and bug > fixes for the tda18271 driver, ONLY. > > I do have a RFC outstanding for a method to handle DVB frontend > operations at the bridge driver level, but I did not yet issue a pull > request for that -- I was actually planning to wait for *after* the > merge window before requesting a merge for those changes. Ah, I had the understanding that this series were part of the bridge driver changes. Ok, if they don't touch on other drivers, nor depend that I merge any new driver, I'll apply them sooner. Anyway, I noticed on your last email that you've grouped several pull requests at the same email. As I said before, please don't do it, since my control is one patch or pull request by email. So, or you can fold everything into one hg tree, or just send them as separate pull requests, if they are independent. > > As I'm saying, the fact that we're not using clones of upstream -git trees for > > development makes everything hard, during the merge window. > > I understand. I think there may have been a misunderstanding -- The > merge requests that I have pending are localized changes that dont > affect other drivers. No redesign at all... I'd appreciate it if you > could handle these tda18271 pull requests soon for 2.6.32, so that I > can continue on with development -- I'll continue to hold off the > larger changes for after the merge window. Ok. Cheers, Mauro -- 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
