Hi,
On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar <arv...@apache.org> wrote:
> As you noted in your comments above - the Flume project tends to follow RTC
> with the reviewer committing the code. I happen to have taken up the role
> of the reviewer for the most part and hence you see the skewed commit
> counts.
It might be useful if you for example expanded the "How to Commit"
wiki page [1] with a better description of what a reviewer should take
in to account when committing reviewed changes. Things that might be
obvious to you and others who've been around for longer, but not
necessarily for newcomers. The more people you have committing code,
the less the project is dependent on the silent knowledge of any
single contributor.
> On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting <jukka.zitt...@gmail.com>wrote:
>> Do you think this is a problem for the community? If yes, how do you
>> plan to fix it? If not, why?
>
> I don't think this is a problem because while most Cloudera committers have
> the luxury of working on the project during regular working hours, others
> do that during their off hours. Hence the majority of contributions coming
> from Cloudera.
OK, fair enough.
Such a scenario exists or has existed also in other Apache projects
like Jackrabbit that I'm most familiar with. It can be a tricky
balance to maintain a level playing field in such cases, for example
by making sure that all relevant project discussions happen out in the
open and that some committers don't feel like "junior partners" with
less ability to influence the project.
It sounds like you have a reasonably good handle on that, so I'm not
too worried, but my instinct suggests that the strict RTC model and
distinction between committers and (P)PMC members may be structural
factors that could easily end up tripping that balance. Are these
really essential tools for the project or could you live without them?
Other solutions to the RTC model include separate maintenance branches
with stricter review and testing requirements, and the only cases
where I really see a need for the committer/(P)PMC separation is with
umbrella projects or special cases like GSoC students or co-operation
across project boundaries.
I know you have good arguments for the way things work in Flume now,
and ultimately you're the ones to decide how you want to work. So take
the above just as friendly suggestions for things you may want to
consider. Whatever the outcome, it would be good for Flume to document
such decisions and the rationale behind them as a set of project
bylaws. This is what the bylaws section of the graduation resolution
is about:
RESOLVED, that the initial Apache $project PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache $foo Project; and be it further
[1] https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
