On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote: > On Tue, 16 Jun 2009, Trent Piepho wrote: > > On Tue, 16 Jun 2009, Guennadi Liakhovetski wrote: > > > > 01/14: compat: handle __fls > > > > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273 > > > > > > > > 02/14: v4l2: Create helper function for bounding and aligning images > > > > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d > > > > > > I am sorry, I will not bother with saving, reformatting, pasting... Just > > > wanted to ask about this place: > > > > I guess you do not use Mercurial like all other v4l-dvb developers? > > I do use hg, though not for development, but for interacting with "all > other v4l-dvb developers" > > > Because you are making a big deal about a simple operation than can be done > > with a few keystrokes. If I wanted this patch quoted in my editor, I can > > simply type: !!cd ~/v4l-dvb ; hg export b4d3ec8d363d | sed 's/^/> /' > > No, typing this is not a big deal, as you say. But I do not understand > _wny_ everyone, wishing to review / comment on your patches has to do > that. And another problem of your approach you confirm yourself in this > post: Using pull requests is something all v4l developers, besides you, do as well. No one, besides you, seems to find it a problem. It's been this way for years. I'm not the one who came up with this system. Sometimes one needs to go the mountain instead of expecting the mountain to come to oneself. > See? Now hg will have two patches, which Mauro will then have to merge > into one when exporting to git, and which then will be very difficult to Oh well. It's happened plenty of times before. I try not to make a habit of it. One can find many many patches in the linux git tree that have bugs in them. Often there are patches that fix these bugs included in the same upstream merge. IOW, the bug was found and fixed before the patch was merged upstream but the fix wasn't folded into the original patch, because the original patch was already in git and someone didn't want to do a git-rebase. One advantage of the hg tree is we get an extra opportunity to fix these things before sending them to git. > everyone gets to see and review your patches only when they are already in > your external repository ready to be pulled by the maintainer. s/in your/posted in the/; s/repository/mailing list/; s/pulled/applied/; everyone gets to see and review your patches only when they are already posted in the external mailing list ready to be applied by the maintainer. Is that really any different? -- 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
