2009/4/23 Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx>: > On Thu, 23 Apr 2009 15:21:41 +0200 > Jean-Francois Moine <moinejf@xxxxxxx> wrote: > >> On Thu, 23 Apr 2009 09:42:07 -0300 >> Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: >> > On Mon, 20 Apr 2009 21:21:53 +0200 >> > Erik Andrén <erik.andren@xxxxxxxxx> wrote: >> > > Hi Jean-Francois. >> > > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more >> > > 2.6.30+ related changeset. >> > > >> > > If Mauro has imposed some kind of changeset limit on you that forces >> > > you to issue a pull request to Mauro each time you have pulled from >> > > my repository then we might have a process issue which probably we >> > > should discuss. >> > > If you think it's too much work to issue these kinds of extra >> > > requests then I can submit pull requests directly to Mauro, as my >> > > code only touches the m5602 part of the gspca driver and any patch >> > > touching the gspca core would first be posted to the list for >> > > review. >> > >> > Wow! 196 patches! >> > >> > Instead of submitting such large pull requests, you should had, >> > instead, submit more frequent smaller pull requests. I'll handle it >> > directly, but you should be warned that eventually some of those >> > patches will require changes. On that case, I'll point you the >> > troubles I may found on the offending patch, and I'll wait for your >> > fixes or comments about it. Only then I'll proceed (since it has some >> > chances that you'll need to touch on other patches of this large >> > series if such case happens). >> > >> > > That said I'm currently trying to push a backlog of changesets which >> > > thankfully soon is done. The driver is currently in quite a stable >> > > state and I'm not doing any active work on it for the moment, IOW >> > > the steady stream of frequent pull requests will soon end. >> >> Hi Mauro, >> >> Well, as I told him many times, the best for Erik should be to ask you >> directly to pull his changesets, but we started in an other way. > > Ok. Probably he sending patches that don't touch on gspca core would improve > the process. > >> Actually, I have two repositories: 'v4l-dvb' which is under the main >> v4l-dvb, and 'gspca' which is desynchronized and is used for tests. >> Erik's repository is under this last one. > > Ok, that explains why it hits 196 patches here. > >> When I get pull requests from >> him, I do 'hg export' from his repository and 'hg import' to my test >> repository. Then I do again export and import from my test to my main >> for a pull request to you. Eventually, when I get a new pull request >> from Erik, 'hg incoming' from Erik to my test repository gives me again >> the previous changesets. So, I have to check them and apply only the >> new changesets. Is there any method to avoid such a problem? > > Unfortunately, hg has some troubles when you have a more distributed model like > what we have with gspca. > > Hg now have the rebase extension that could eventually help to exceed its > limitations, but my experiences with this went into more troubles than > solutions. > > IMO, the better would be if he uses the main v4l-dvb as the basis for his > sub-tree. This works for most of the patches. This will not work for the few > ones that touches on gspca core files, but this is probably the exception. > > So, if you decide to go to this approach, you'll have to submit him patches > that touches on his files, and he'll have to submit you the patches that > touches on core. > > Yet, you'll have troubles if I reject one patch from the tree. > Hi, I'm truly sorry for creating this mess. I wasn't aware of that the previously pulled changesets still were registred after a pull. I'm all for submitting pull requests to you Mauro. Just to avoid these kind of situations in the future please review this process. 1. Perform various commits to my local v4l-dvb tree 2. Pull the main tree 3. Resolve any conflicts 4. Push my local tree 5. Send mail asking for a pull Do I need to do anything further or could I just repeat this process in the future? Best regards, Erik -- 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