Hey Alan, Great point -- thanks for highlighting the concern, and yes, Benson, I'd like the Incubator PMC to request this clarification from the board. BTW, not frustrated with you guys at all and wish you the best. Just trying to help (even if it didn't seem like it) based on my existing experience with several of Apache's largest umbrella projects :/
Cheers, Chris On 2/14/13 8:31 AM, "Alan Gates" <ga...@hortonworks.com> wrote: >I'd like second and extend Benson's point about clarifying how these >things should work. In addition to clarifying what it means to graduate >into a subproject now that that is frowned upon, clarifying how these >votes work would help. I think Chris felt that we ignored his vote and >pushed ahead. From my reading of the docs it was supposed to be a >majority vote and thus to view the -1s as a veto would be to improperly >ignore the 5 +1s. If the rules were clear in advance for the next group >that faces this situation it will help to avoid these misunderstandings >and frustrations. > >Alan. > >On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: > >> I'm not so much opinionated as confused here, perhaps because I have a >> very linear view of governance. >> >> I like to know how a vote fits into a governance structure or process, >> and I've felt for some time that this case (podling goes to existing >> TLP) is not well-explained by our structure. >> >> Back in the days when subprojects were normal and valid, the incubator >> had a role on behalf of' an existing TLP in supervising IP and >> community behavior. Graduation meant: "OK, umbrella, we certify that >> these people can behave like a project and have clean IP." And, >> perhaps, the board actually established subprojects? It's all before >> my time. >> >> Now that subprojects are no longer in the picture, I don't even know >> why the IPMC should ever incubate a podling *if the plan, from the >> start, is to be part of some existing TLP.* So I have assumed that >> HCatalog started out with the intention to grow into an entire TLP, >> and came up with the Hive plan as a fallback. >> >> To try to make this long story shorter, I think that we should make a >> proposal to the board with a schema for handling this case that makes >> sense in current conditions. I'm happy for it to be your schema, which >> amounts, as I see it, to the board having a supervisory moment when >> this happens, with an IPMC vote providing the same sort of strong >> recommendation one way or the other that it does for establishing a >> TLP. >> >> >> >> >> >> On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) >> <chris.a.mattm...@jpl.nasa.gov> wrote: >>> Hi Benson, >>> >>> I saw your later email(s) and Incubator board report. It's fine and I >>> think the message of my objection comes across. >>> So thanks for that. >>> >>> One thing I wanted to comment on: >>> >>> On 2/13/13 4:10 AM, "Benson Margulies" <bimargul...@gmail.com> wrote: >>> >>>> Chris, >>>> >>>> The obvious compromise is to ask them to report the vote result as it >>>> happened, it seems to me, -1's and all. But where do you think that >>>> they are reporting anything? There's nothing happening here at the >>>> board level. There's no board resolution needed for a Hive committer >>>> to type 'svn cp' on the hcatalog tree, >>> >>> Not by my counts. There's a *community* resolution and a >>>recommendation to >>> be made by the IPMC, nonetheless. >>> Otherwise, the IPMC is pretty useless IMO, and more importantly, so is >>>the >>> Incubator. >>> >>> Why bother even incubating HCatalog? Hive could have simply svn cp'ed >>> whatever code came in, or whatever code the podling arrived at, and >>> Incubation would have stopped then. But we both know that's not the >>>way it >>> works. Even if a podling graduates to an existing TLP, go check out the >>> past resolutions. You'll note there's a section in there that >>>discharges >>> the responsibility of the IPMC for the podling. So, yes, the IPMC *is* >>> involved. And yes, the IPMC vote matters. >>> >>> Cheers, >>> Chris >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
