Em Tue, 12 May 2009 01:36:17 -0500 (CDT) Mike Isely <isely@xxxxxxxxx> escreveu: > On Mon, 11 May 2009, Mauro Carvalho Chehab wrote: > > > Em Mon, 11 May 2009 22:09:26 -0300 > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> escreveu: > > > > > Em Sat, 9 May 2009 16:49:31 -0500 (CDT) > > > Mike Isely <isely@xxxxxxxxx> escreveu: > > > > > > > > > > > Mauro: > > > > > > > > Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for various > > > > pvrusb2 changesets. Several have to do with IR as previously discussed > > > > with Jean Delvare. He's waiting for these changes. Other stuff is more > > > > of a miscellaneous / cleanup nature. > > > > Hmm... this one failed when importing on -git: > > > > Changeset: 11749 > > From: Greg Kroah-Hartman <gregkh@xxxxxxx> > > Commiter: Mike Isely <isely@xxxxxxxxx> > > Date: Fri May 01 22:36:33 2009 -0500 > > Subject: pvrusb2: remove driver_data direct access of struct device > > > > In the near future, the driver core is going to not allow direct access > > to the driver_data pointer in struct device. Instead, the functions > > dev_get_drvdata() and dev_set_drvdata() should be used. These functions > > have been around since the beginning, so are backwards compatible with > > all older kernel versions. > > > > Priority: normal > > > > Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> > > Cc: linux-media@xxxxxxxxxxxxxxx > > > > $ patch -p1 -i 11749.patch > > patching file drivers/media/video/pvrusb2/pvrusb2-sysfs.c > > Reversed (or previously applied) patch detected! Assume -R? [n] > > > > It seems that you've got a Greg's patch, removed the parts that touch on other > > files, applied on your tree and asked me to merge it. Please, never do it, > > since this will cause merge problems when exporting the patches to git. Next > > time, just reply with an acked-by, and let Patchwork to add your ack on the > > original patch. > > > > I in fact did what you are asking for here (i.e. wait for it to show up > on its own) before for another change that got rid of usb_settoggle(). > It took a LONG time - WEEKS - for that fix to get back into v4l-dvb via > the mechanism you just described. And this had the effect of breaking > the v4l-dvb repository for a period of time when the kernel mainline > then unpublished the usb_settoggle() function. I do NOT like to see > that happen. That caused me to decide not to rely on what you are now > telling me to do. > > I also disagree with this for another reason. What happens if, say, > Greg generates a patch that I need before I can proceed with other > changes? Do I just sit around and wait for it to trickle back before I > can continue? That seems wrong. In addition in the past when there > have been pvrusb2 changes generated from upstream you have asked if I > was planning on pulling them in myself - which I've done in the past. > > It seems wrong on its face to tell me that I can't go get a patch that > affects my driver. > > AND... In the case of the "remove usb_settoggle()" patch, I *DID* in > fact add my acked-by to that patch. Greg dutifully took note of this > and ensured it was part of the git patch. However when it got back into > v4l-dvb, the acked-by attribution was missing. I complained about this > to you and your response was that this was a fault of the pathway / > mechanism and that I should basically accept this. So now you're > telling me to do this anyway? Mike, As I've explained you in priv, and already talked several times at the ML, our entire mechanism of using -hg is broken, for several reasons. We should really move to -git. My intention were to start discussing it just after the end of the last merging cycle, but, unfortunately, I haven't enough time to finish some scripts to allow people to use a git sub-tree. What are the main problems with -hg and with our current merging proccess? 1) The way we work don't allow us to have the full Signed-off-by/Acked-by historic on -hg. For example, all patches submitted upstream should have the maintainers Signed-off-by (SOB). However, by doing hg pull, I can't add my SOB. If, on the other hand, I just cherry pick all patches from your tree and add my SOB, you'll need to drop your tree and clone again from mine, since the patches they will be understood by hg as a different patch. This means also that, if you have a second tree that has your patches, plus some newer patches, that you'll have to cherry-pick the newer patches on that tree, drop it and re-create [1]; 2) We have several extra efforts when picking a patch that are upstream and merge it back on our tree. This requires me to do a diff between our tree (with all backport symbols stripped) and -git, and manually seeking for each diff line on -git, in order to identify what -git patch added such line. Then, for each -git patch, I need to cherry-pick the patch and apply on our tree. On most cases, the patch doesn't apply cleanly, so I need to manually apply it. Also, in general, those patches are generally KABI changes, so they touch not only on the files at our tree, but also on external files; 3) The manually applied patches are different than the original ones, since it generally contains a subset of the files, and, on several cases, it will need some #ifs to allow the changes to work with older kernels; 4) Our hg mailbomb script is smart enough to send emails to the patch author and to everybody that signed that patch. However, it currently doesn't handle backported patch. Due to that, if we preserve the original SOB's at the patch, it will bomb the original authors about the addition, on our tree, for a patch that is already upstream. For sure this is not right; 5) As the patches that are applied on our tree were modified (by stripping files from it and/or adding backported code), it doesn't seem right to just preserve the original SOB/acked-by/tested-by blocks. 6) As the manual process of backporting patches in general requires me a lot of time, I generally run it very seldom. I always run it during or close the merge window. I try to run it a few times during the -rc phase, but this depends on my spare time for it. 7) On several cases, I receive acked-by/tested-by/reviewed-by tags after the patch is merged at -hg. Such tags can't be added on an already applied patch, without destroying the tree and re-generating it again. If I do it, all clones of my tree would need to be destroyed also. Due to all the above troubles, among others, our -hg tree should be seen, from development perspective, as _just_ a staging tree (as stated at README.patches). If you want to see the full SOB/acked-by/tested-by flags, please go to -git. That's said, in the specific case of the patch you've added, you were preserving Greg's SOB, but you've stripped the parts that were touched on other drivers. So, you assumed that the rest of his patch will be applied somehow. However, as you've stripped parts of his patch, you were, in fact, you applied something else. Due to the hg-mailbomb works, you also sent to Greg a copy of the stripped version of his patch. Also, since I've applied his original patch as-is (in this case, he didn't asked me to merge his patch directly upstream), he received a second copy of the patch (this time the correct one). At the time I was generating the -git patches, I got your version of Greg's patch (that weren't tagged with kernel-sync - that could be used to avoid it to be migrated upstream) and his original patch. Lucky, the original patch went before the stripped one, so I just discarded yours. If, otherwise, the stripped copy would arrive before the correct one, two problems could happen: 1) If I haven't submitted your copy upstream yet, I would need to go back to a patch before yours, manually remove your patch, rebase my tree and apply the correct one; 2) If otherwise the patch were already submitted to Linus, then the problem would be worse, since Linus never rebase his tree. The dirty patch would be forever there. I would need to write a reverse patch for it, and then apply the correct one. --- So, how would be the correct procedure? In this case, where the patch will go upstream via my tree, the better is just to add your acked-by and wait for me to pick it. As you assumed that the others would be ok with the patch (since you've added it on your tree), you could instead add your acked-by and apply the complete patch on your tree, and send a PULL request explaining that you've already catched that one. If otherwise you need to pick a patch, or part of a patch, that are already upstream, then you can pick it, change as needed, in order to backport it, remove uneeded files, and apply on your tree. However, in this case, you'll need to remove all SOB's/Acked-by and similar tags from the original patch (otherwise, mailbomb will do the wrong thing), and add a -git reference, for people to see the original tags at the git tree, if needed. You should tag it with "kernel-sync:" to say to my -git import scripts that such patch needs to be discarded. In the case of linux-next patches, there's no safe way to preserve the patch history at -hg, since the patch is not stable yet (so, it can be changed). Also, its md5sum can change inside linux-next tree and for sure will change when applied upstream. So, if you ever need to get one of such patches, the better is to discuss with me about the better alternatives. [1] hg has now hg rebase extension that would allow you to do such process automatically. However, on my tests, this haven't worked fine. So, I can't recommend its usage at the current stage. 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
