Closing the loop on this thread: The Flume PPMC has discussed the diversity issue and have concluded to put all current committers as PMC when drafting the resolution.
Also, the wiki has been updated with details on how to contribute and commit. https://cwiki.apache.org/confluence/display/FLUME/How+to+Contribute https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit Thanks, Arvind Prabhakar On Sun, May 27, 2012 at 3:21 AM, Arvind Prabhakar <arv...@apache.org> wrote: > Thanks Jukka for your suggestions. > > 1. Regarding wiki - I have taken a note of that and will update it soon. > > 2. Regarding doing away with the difference between PPMC and committers, I > am told that other projects do this during graduation. I.e., they promote > all existing committers to PMC status during graduation. If we do that, the > diversity concern will be addressed and we can then debate the bylaws once > the PMC is formed. > > Thanks, > Arvind Prabhakar > > > On Sun, May 27, 2012 at 2:40 AM, Jukka Zitting <jukka.zitt...@gmail.com>wrote: > >> 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 >> >> >
