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. With git, the workflow would probably be much more easier, since you can create several branches on your tree, and patch migration/rebasing between the branches is very easy. You can even undo several git operations, since it has a history tracking what happened, in terms or merging. > About this pull request, 'hg incoming' gives me only 56 changesets, but > I think that 30 ones were alrady applied... Probably due to some "rebase" did by one of you. Since his work is against your tree, I have no other option but waiting until you cleanup the mess and send me a pull request. 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
