Hi, In other projects that I've worked on, we've used a system where the core developers can either give a +1 or a -1 on a contributed patch. If a patch receives two +1's or more, it is accepted (if there are no -1's) and committed by one of the developers.
This lowers the pressure on the maintainers, and hopefully will speed up the development. Though, the core developers need to be a bit careful. They should not give +1's or -1's on a patch that they either (1) do not fully understand, or that (2) applies to a section of the code that they are not knowledgeable about. It is then better to either state that they do not know the area well enough, and maybe give the patch a +0, or be silent. The downside is that some developers will never feel that they are knowledgeable enough to comment on a contribution; resulting in that the maintainer will have to do it. The same situation we are in now, more or less. The upside is that the maintainers can focus on other things than just reviewing patches; maybe getting some new features in. Also, trivial and small patches will get quicker review and get merged into the tree in a swift manner. Please note: This is in no way an attempt to overrun any of our maintainers, it is just an attempt to make things go a bit smoother and faster in the times when the maintainers are busy with other things. Please note: I'm not saying I'm in any way a core developer, just sharing my experiences from other projects. Okuji, Marco, others; comments? ~j _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
