Hi Andrew, On Wed, 6 Jul 2016, Andrew Lunn wrote:
Thanks for the explanation. I'm used to the Linux kernel way of doing things. Patches land in my mailbox, and if i find them interesting, or are in an area of the kernel i'm familiarly with, i will often take the time to hit reply and review the patch.
If it does not land in my mailbox, i will never see it, and never review it.
That's sort of how it worked in earlier days to a degree. The balance of maintainers to contributors was enough that it worked. Though, stuff could fall through the cracks. Under that kind of system it's not very clear to contributors whether a patch has been deliberately ignored as "uninteresting", or whether it's just been overlooked.
The 'patchwork' instance David Lamparter runs helps with that a bit, allowing integrators to keep track of what's outstanding. It has some limitations, so it /may/ be we try requiring contributions to come in via 'bugzilla', instead of just emailled to the list.
Another conclusion I drew is that at any given point in time you need a specific, clearly defined person to be responsible for dealing with outstanding patches. Otherwise, it's easy for patches to 'fall through the middle' between different integrators (especially anything difficult).
The kernel thinking seems to be that there are plenty of people writing patches, but fewer reviewing patches. So make it easy for the reviewer. Similarly, since there are more patch writers than reviewers and mergers, it is the patch writers job to shepherd their patch through the process. That helps with scalability.
Absolutely agreed. The prior does _not_ mean a contributor can just think the onus is all on integrators and reviewers. As you say, that doesn't scale.
A contributor should do their best to make reviewing their contribution easy - especially for anything non-super-trivial. The easier something is to review, the easier the path it will follow and the more time reviewers have for reviewing other things (and working on their own stuff). Also, just dealing with queries and comments in a friendly way also helps. Good commit messages (and even design docs, when appropriate) go a _long_ way to giving reviewers warm fuzzy feelings.
regards, -- Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Everyone is a genius. It's just that some people are too stupid to realize it. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
