Hi Mauro, thanks for replying and for the explanation. I'll skip most of your message, and just keep the bits I'd like to reply to. On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote: > The same happens here: All patches added at the staging tree are sent to > linuxtv-commits ML. So, they are there for discussions before my pull requests. > > The main difference is that, in the case of Greg, his staging tree is a quilt > one. On our case, our staging tree is mercurial. Hm, I am not sure, is Greg's quilt tree publically available? And how many actually use it? Whereas your hg tree is publically available and it looks like a few do use it. > We're currently merging about 900 patches per kernel window, on a window of > about 10-12 weeks. This means about 90 patches per week, or about 13 patches > per day (for a 7 days week), or 18 patches per day (for a 5 days week). > > So, if people just send one email per patch, this will increase our traffic by > 18 emails by day. It can be worse than that, if we consider that patches can be > replied, and that people use to write a patch 0 to describe a patch series. > > Considering about 50 messages per day, currently (today and yesterday's > statistics - not sure those are typical days), this would increase the ML by > about 36%. I still don't take this argument of increased traffic - I haven't seen a single complain "please, don't increase the traffic, it'll make it worse for me." > 1) trivial patches (typo fixes, coding style, simple board additions, Kbuild > fixes, etc); > > 2) bug fix patches at drivers; > > 3) new drivers; > > 4) core changes. > > However, several driver maintainers don't care (or just forget about they) for (1) > type. Before patchwork, lots of such patches were lost forever in the middle of > dvb and v4l mailing lists. They are happy when someone (me) get those patches > and apply at the tree or remind they to check and apply on their trees. > > patches of type (2) and (3) are in general sent via a driver maintainer and > generally doesn't generate discussions. I'm really happy we have subsistem maintainers that are such profecient in their work and such confident in their results that they don't need any reviews and discussions. I for one is not one of them, that's why I always first send my patches to the list. > Also, for the developer, using the pull request is better, since they can > better track when a patch series got merged. I never argumented against pull requests, I'm suggesting they should follow patches posted to the list. > The usage of a mix of PULL and PATCH requests has an extra trouble: it means > that we'll receive most of the patches duplicated. So, it means that I need to > manually mark all merged patches at patchwork queue, on _each_ pull request. Yes, I see what you mean, but 1) you cannot avoid it, there are always patches from various authors, that they send to the ML, that some driver-maintainer will then pull through his or her tree and ask you to pull it. So, we really have to learn to proces this case efficiently. > So, this adds an extra cost that will probably make life worse for everybody, > with almost no gain (since there are really very few complaints about badly > merged patches). > > That's said, I'm open to listen to opinions on how to improve our current process Well, I guess, I will have to subscribe to that hg-commit list (or whatever it's called), and use it. The problem is - it is a bit too late. But it's the best option available so far. Another question, if you pull patches from someone's tree for review of one of those pull-requests (as you described in this mail, but I've deleted that piece already), how do you then quote the code if you want to comment on it? You export the patch again, hit reply on the pull-request, and paste the patch into it? And then add the quotation marks "> " manually?... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
