Ted Leung wrote:
There are several different ways that issues like this are
handled in open source projects:
1) Linux - people submitting code to Linus for inclusion in the
kernel are subject to his review -- if he tells you to rewrite it,
you'd better or it won't get in.
2) Mozilla - each area of the code has a module owner who gets
the final say on technical decisions on the code. Disputes with a
module owner can
Because its interesting and relevant, I'll describe the mozilla model
in a little more detail:
1) You first get a peer review - the intent is someone that knows the
particular area of code somewhat well, and can make sure your code
correctly fixes the bug you describe, in a safe way consistent with the
module. This makes sure that one person doesn't become the only expert
in his/her area. (single-owner modules are highly discouraged, but are
inevitable due simply to there being a lot of modules, and yes even a
single 'owner' of a module needs a review)
2) Then, you get a 'super review' - a super reviewer is someone who has
demonstrated sufficient expertise across the entire codebase. A
super-review is a sort of style-and-integration review: It makes sure
the overall style/approach is consistent with the rest of the project,
matches best practices, and so forth.
This is one of the ways that the community keeps somewhat isolated
modules 'in check' with the current ways of doing things - the super
reviewer might say "That's not how we create that kind of object now,
instead you should be using this from this other module" - they've just
reviewed code in that other module, so it helps them keep on top of
things.
And for most of the codebase, you need BOTH of these reviews to check
in.
Alec
3) Apache - there is really no notion of code ownership, in fact
we actively discourage code ownership because we feel that it creates a
barrier to the
developement of a diverse and growing developer community. If
you are granted commit access to a piece of code, you are generally
granted access
to the entire codebase. Disputes are resolved in the context
of the entire community (really the portion that cares enough to get
involved).
The choice of which method we use to resolve these issues is
part of a larger question regarding the community norms/governance of
the project.
Ted
On Oct 20, 2005, at 10:20 AM, John Anderson wrote:
I've lived in worlds 1, 2 and 3, and in my
experience 1 has worked best.
The guy whose working on the code needs to feel that he has ownership,
which is important for his motivation. In the long run good and bad
ideas often sort themselves out through use and time, so even if the
owner chooses the wrong choice, he'll often change his mind if
experience bears out a bad decision, which turn out to be an important
learning experience.
I've almost never seen the owner abuse the privilege of overruling a
reviews opinion, that actually hurt the project.
John
Mike Taylor wrote:
Earlier today Heikki and I reached the point where we
could not find common ground on the result of a review I requested from
him about some changes to the Makefiles. I think that one of the
review points he raised is not a concern (a "style" issue to be exact)
where as he thinks the code is wrong because of duplication.
The exact code involved is not the question I'm raising right now, but
rather this is something we haven't considered in our review process -
what happens when the owner of the patch/code and the reviewer of the
patch/code just cannot agree?
After talking about this with Heikki, he asked that I submit it as a
discussion and vote to the dev list.
If the reviewer and the owner disagree, which of the following apply:
1. Owner's opinion prevails
2. Reviewer's opinion prevails
3. It's put to a vote before an impartial body - most of the time
that body will be the dev list
4. <insert alternative solution here>
thanks,
---
Bear
Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org
[EMAIL PROTECTED]
http://code-bear.com
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev"
mailing list
----
Ted
Leung Open Source Applications Foundation (OSAF)
PGP
Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
