[CT-NG] Patch approval process

[Yann E. MORIN]

Hello all!

As it turns out, reviewing submissions incurs quite some burden onto me,
and takes quite a good amount of the time I could otherwise dedicate to
enhancing crosstool-NG.

A while back, I've suggested a patch submission and approval process [1]
and I would like your feedback on this plan.

Let me summarise it again below:

- patches shall be posted here (crossgcc ML), and CCed to me
  - patch submission is explained in the documentation, section
    CONTRIBUTING, in the file docs/overview.txt
  - the README points to this file
  - the homepage will be updated to match

- people have a few days to comment and rate the patch, on the list:
  - reply, and quote the entire patch:
    - CC OP (might not be subscribed)
  - inspect the patch from both POV:
    - feature-wise: is it a good feature _for_crosstool-NG_ ?
    - code-wise: is the patch clean, does it fit well in crosstool-NG?
  - as first line _after_ the quoted patch, either rate with '+1'
    (for approval), or '-1' (for disapproval)
  - if you disaprove the patch, add explanations interpersed in the
    corresponding part of the patch

- at the end of the voting period, inspects results:
  - if ( total_ratings < minimum_ratings)
    - drop the patch
  - if strong concerns have been raised about the patch,
    - drop the patch, and ask for fixes. or explain why it is refused
  - if ( ( positive_ratings / total_ratings ) >= 2/3 ),
    - apply the patch
  - else,
    - drop the patch

minimum_ratings:
  the minimum number of ratings required to inspect the results. Too low,
  it is meaningless; too high, there will not be enough people on this
  list. 5 ratings seem like to be a good choice.

voting period:
  the number of day people have to post patch reviews. Too short, people
  won't have time to perform a correct review; too long, we'd forget about
  the patch and/or it will bit-ot on the list. 3 days seem appropriate.

2/3rd majority:
  required majority before a patch is applied, unless strong and valid
  objections have been raised.

All-mighty Maintainer:
  Aha! I reserve the right to referee in case of dispute! :-]

I also receive patches directly, and for those patch I'd answer with
something along the lines of:
  Please resend to crossgcc@... and cc: me, or
  your patch will be dropped without furher notice.


What do you people think about this plan?

Regards,
Yann E. MORIN.

1. http://sourceware.org/ml/crossgcc/2009-09/msg00065.html

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| [phone] | Software  Designer | \ / CAMPAIGN     |  ___               |
| [phone] `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Thomas Petazzoni-2]

Hello Yann,

Le Mon, 12 Oct 2009 20:27:26 +0200,
"Yann E. MORIN" <yann.morin.1998@...> a écrit :

> What do you people think about this plan?

I think it is far too much formal for the current size of the project.
Most of the open-source projects handle the issue of scaling the
reviewing process by nominating maintainers for sub-systems of the
project, these maintainers being fully-responsible for reviewing and
acknowledging the patches.

I don't think that a complicated voting-based process is going to work,
and I'm not aware of any open source project using such a formal
process.

Cheers!

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Oron Peled]

On Tuesday, 20 בOctober 2009 23:32:10 Thomas Petazzoni wrote:
> I think it is far too much formal for the current size of the project.
> Most of the open-source projects handle the issue of scaling the
> reviewing process by nominating maintainers for sub-systems of the
> project, these maintainers being fully-responsible for reviewing and
> acknowledging the patches.

IMHO, this structure may impose a lot more formalities (who are the
subsystem maintainer, how to appoint them, defining clear boundaries, etc.)
So it's justified with big projects that have a long history.

> I don't think that a complicated voting-based process is going to work,

I agree that it shouldn't be overly formal and if I understood Yann's
correctly it basically boils down to something like "thumbs up/down"
with some rough guidelines about pass/reject criteria.

Since Yann made it clear he intends to keep his position as the
benevolent dictator, I'm looking at the proposed process as some
kind of a "recommendation system" to make it easier for Yann in
the most common cases -- sounds good to me.

BTW: I happened to "test" this when I sent a minor patch to the list
few days ago -- got a small reject from Alan Clark about a specific
part (regretfully in private mail and not to the list) and later a
more thorough response (reject) from Yann -- that was a quick
process and validated my doubts about the necessity of this patch.
[rpmlint problems]

Bye,

--
Oron Peled                                 Voice: [phone]
oron@...                  http://users.actcom.co.il/~oron
No, You Can't Have My Rights, I'm Still Using Them

--
For unsubscribe information see http://sourceware.org/lists.html#faq