Will do. Not sure we can do a single vote with multiple options since it represents a change to the bylaws and it would be possible for both votes to pass. I'll start a vote for #3 and if that fails someone can start a vote for #2.
Thanks, Eli On Thu, Aug 23, 2012 at 7:11 PM, Vinod Kumar Vavilapalli <vino...@hortonworks.com> wrote: > > Thanks for the clarification. > > Seems like we can start a vote on those lines. But let's do that separately > on a fresh thread. This one has stretched for far too long after the original > vote thread concluded. > > Thanks, > +Vinod > > On Aug 23, 2012, at 11:33 AM, Eli Collins wrote: > >> On Thu, Aug 23, 2012 at 11:13 AM, Vinod Kumar Vavilapalli >> <vino...@hortonworks.com> wrote: >>> >>> On Aug 22, 2012, at 11:43 AM, Eli Collins wrote: >>> >>>> On Wed, Aug 22, 2012 at 11:38 AM, Doug Cutting <cutt...@apache.org> wrote: >>>>>> 2. Distinct MR, HDFS and YARN committers >>>>>> 3. Combine MR, YARN, HDFS committers >>>>> >>>>> So we might better just vote on (2) >>>>> versus (3)? >>>> >>>> Works for me. What do others think? >>> >>> Can you clarify more on what you are proposing we vote on? >>> >>> What does (2) mean? >> >> "Distinct MR, HDFS and YARN committers" means that MR, HDFS, and YARN >> each have their own set of committers. Today we have two sets (MR and >> HDFS) so under this option we would have three sets of committers. >> (And technically a 4th set which is the PMC which is shared across >> sub-projects and can commit to all of them). >> >>> Since (1) was dropped, does it mean we seed the YARN list with folks who >>> have been contributing/reviewing patches on YARN? >> >> The vote would need to spell out how we would seed the YARN list. Per >> above I'd suggest seeding it with the current MR committers - ie the >> people who can commit to YARN today - there's no need to actively >> exclude people we already trust to commit to this code, and there's >> obvious downside to excluding them, for example, some patches need to >> span sub-projects (same reason all HDFS/MR committers can commit to >> Common). If/when the sub-projects become TLPs (ie when there are real >> distinct boundaries between the projects) seems like a good time to >> divvy things up. >> >> Personally I'm in favor of #3, I liked Chris D's original proposal to >> just merge all the committer lists and call it a day! >> >> Thanks, >> Eli >
