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. > > Now I am lead to wonder if perhaps my emails are not getting delivered > to your inbox. Can you just reply to this mail so that I at least > know that you've received it? If you have a reason for holding off on > the merge, could you please say so -- I don't know what's happening > when you dont respond at all. > > This merge request contains fixes that must go to upstream for the > 2.6.32 merge window -- I definitely sent you a pull request with > enough time for review for the merge window, but I see you've already > sent your pull request to Linus. :-( > > At this point, there are two separate merge requests that deal with > the tda18271. First, tda18271-only changes: > > First, and urgently, please pull from: > > http://kernellabs.com/hg/~mkrufky/tda18271-fix > > for the following: > > - tda18271: add support for additional low-power standby modes > - tda18271: add debug to show which standby mode is in use > - tda18271: add new standby mode: slave tuner output / loop thru on > - tda18271: change output feature configuration to a bitmask > - tda18271: move tda18271_sleep directly below tda18271_init > - tda18271: move small_i2c assignment to the state config block > - tda18271: ensure that configuration options are set for multiple instances > - tda18271: improve error log in function tda18271_write_regs > - tda18271: fix comments and make tda18271_agc debug less verbose > - tda18271: update temperature compensation calculatation formula > - tda18271: fix bad data in tda18271_cid_target table > > tda18271-common.c | 3 > tda18271-fe.c | 127 +++++++++++++++++++++------------- > tda18271-maps.c | 3 > tda18271-priv.h | 3 > tda18271.h | 38 ++++++---- > 5 files changed, 110 insertions(+), 64 deletions(-) > > Next, utilization of the low-power standby modes of the tda18271 tuner > in three drivers. Please merge: > > http://kernellabs.com/hg/~mkrufky/tda18271-standby > > - saa7134: disable tda18271 slave tuner output / loop thru in standby mode > - pvrusb2: disable tda18271 slave tuner output / loop thru in standby mode > - cx23885: disable tda18271 slave tuner output / loop thru in standby mode > > cx23885/cx23885-dvb.c | 4 ++++ > pvrusb2/pvrusb2-devattr.c | 2 ++ > saa7134/saa7134-dvb.c | 1 + > 3 files changed, 7 insertions(+) > > Please note, there is a "merge" changeset that I did not include in > the above diffstat output. > > Again, a response that indicates that you cant merge right away for > whatever reason is *much* better than no response at all. It's very > frustrating to be a member of the linuxtv team for such a long time, > to be a driver author and to send in a pull request and get absolutely > no response. > > If I hadn't seen so many other merges going on, I would have just > assumed that you're busy.... Please let me know what's going on > here. 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. We also have the staging patches, where the go7007 version merged on our tree doesn't seem to match the one upstream, and we still need some glue to merge the two other staging drivers. Finally, we have the V4L/DVB API merging upstream, as DocBook. Due to that, I'm trying to organize the pending stuff into groups of patches. The first git pull request basically contains what we had before the open of the merge window, without the arch patches. During the merge window, I work with basically two trees: linux-2.6, with upstream plus patches that are ok to apply; pending, with patches that need something to be applied. Since I may need to rebase my local copy of linux-2.6, pending tree contains just upstream plus the patches that are waiting for something (in this case, waiting for arch commits). However, Hans did a changeset of patches that touches on all drivers: the ones at linux-2.6 and the ones at pending, breaking my merging process. So, I urge to fix it, in order to be capable of proceed. After the merge of linux-2.6 patches, I can rebase my pending patches and add Hans API cleanup changeset, keeping them there until being sure that -arch patches got merged, and being capable of sending the other patches to linux-next for a couple of days. Also with this, I can proceed with the merge, fixing the go7007 changeset and send another series of patches. 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. 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. 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
