Let core developers "vote" to accept patches.

Let core developers "vote" to accept patches.

[Johan Rydberg]

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

Re: Let core developers "vote" to accept patches.

[Hollis Blanchard]

On Tue, 2006-08-15 at 00:37 +0200, Johan Rydberg wrote:
> 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.  

I think this idea makes a lot of sense.

-Hollis

Re: Let core developers "vote" to accept patches.

[Marco Gerards]

Johan Rydberg <jrydberg@night.trouble.net> writes:

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.  

Interesting, I like this idea.

> 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.

:-)

Although I am a maintainer, I do not know some parts of the code as
well as some regular contributors do.  I do not feel overrun at all.
Actually, this will help me evaluate patches I have no clue about.
For example, take your latest patch regarding the build system.  It
looks sane to me, but I have no idea at all if it is acceptable or
not.

If I do know about a patch, I hope people remind me often enough to
have a look, in case I missed a patch in the past.

--
Marco

Re: Let core developers "vote" to accept patches.

[Yoshinori K. Okuji]

On Tuesday 15 August 2006 00:37, Johan Rydberg wrote:
> 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.

You can vote for a patch, but I'm not planning to apply "majority rule" to 
GRUB. As you can see in various countries, majority-based decisions do not 
always work very well. I rather believe in aristocracy in software 
development.

Our rules are:

- When you are a committer and a patch is trivial enough, you can (and should) 
check in the patch by yourself.

- If not, you should ask others in grub-devel.

- I retain final words as the designer of GRUB 2. For some certain parts, I 
completely rely on other developers. For instance, Hollis would even precede 
me in PowerPC-specific changes.

- If a change is involved with political issues, official maintainers must 
approve or disapprove. This is required for the GNU Project.

Our way is mostly trust-based, and authority-based for important decisions. I 
do not think this way is working badly.

Okuji

Re: Let core developers "vote" to accept patches.

[Johan Rydberg]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> Our rules are:
>
> - When you are a committer and a patch is trivial enough, you can
> (and should) check in the patch by yourself.
>
> - If not, you should ask others in grub-devel.

It was for these two scenarios I suggested we could vote on patches.
But it might not be needed.  I was after all just a suggestion.

> - I retain final words as the designer of GRUB 2. For some certain
> parts, I completely rely on other developers. For instance, Hollis
> would even precede me in PowerPC-specific changes.

Agreed.

> - If a change is involved with political issues, official
> maintainers must approve or disapprove. This is required for the GNU
> Project.

Of course.

~j

Re: Let core developers "vote" to accept patches.

[Jeff Bailey]

On Tue, Aug 15, 2006 at 12:37:23AM +0200, Johan Rydberg wrote:

> 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.  

Do the core devs and maintainers not feel empowered to just commit the
patch if they would otherwise +1 it?  It seems like grub is a
sufficiently small project that moves sufficiently slowly that rolling
back a contentious patch would be easier than any sort of beaurocratic
overhead.

Tks,
Jeff Bailey

-- 
I do not agree with a word you say, but I will defend to the death your
right to say it. 
 - Voltaire