On Sun, Nov 17, 2013 at 1:32 PM, Upayavira <u...@odoko.co.uk> wrote: > Benson, > > How does that relate to my post? Not sure if I can see the connection.
I thought I was replying to Alex, but my sentiment is applicable to what you write below. The IPMC is a group of people with a job. It's not a 'project community' in the usual sense of the term at the Foundation. My view is that a person who has shown a firm grip on how to operate inside a PPMC could be trusted to join that group. I think it's possible to explain to a proposed IPMC member that they are being invited to join a group with responsibility across all the podlings, but with the understanding that they will stick to their podling to start with. The point of my email was to emphasize the low risk to the function of the IPMC and the Foundation from this strategy -- which I appreciate is not the only consideration. If the board were offering us another structural approach, this would be a different discussion. But, unless I've gotten lost in the torrent of email, the board isn't offering an alternative. The legal framework requires three PMC members to approve a release, not three 'something else's'. So I see this as a choice of the lesser of weevils: bug #1 is releases that never get their votes, and bug #2 is this scheme of adding IPMC members based on PPMC merit. So, yes, I accept your point that inviting PPMC members to join the IPMC is not delux. While I'm using my metered window of verbiage around here, I'll add: much as I value the careful curation of NOTICE and LICENSE, those aren't where the legal risks come in. They come in every day, when code is committed. If someone goes and commits some misappropriated code into SVN with Apache headers tacked on, the chances of a 'release inspector' detecting it are small. Once a project is up and running, this is a matter of appropriate grant of commit access and appropriate supervision by PMC members -- though it's not like we supply them with Black Duck. > > Are you suggesting that we should be okay voting PPMC members who are > taking responsibility within their project into the Incubator PMC? To > me, that would be equivalent to granting a new committer ASF membership > while we're at it. Sure, it'll probably be alright, but best to offer > someone something at a point when they have some appreciation of what > they are joining, no? > > Upayavira > > On Sun, Nov 17, 2013, at 01:24 PM, Benson Margulies wrote: >> Joining a PMC does not meaning being handed even one of the keys to >> the launch console for a nuclear missile. Joining a PMC means >> accepting responsibility for the supervision of a project. We vote to >> add someone to a PMC when they have shown the necessary commitment >> and, well, common sense. Part of 'common sense' is knowing what you >> know and what you don't know. Not every PMC member needs to be >> prepared to wade into every swamp, just as not every committer is >> qualified to modify every class in the source code. We add committers >> when have evidence to justify trusting them to do the right thing >> (with the PMC as backstop supervision), and we add PMC members >> similarly, with the backstop of the rest of the PMC. >> >> >> On Sun, Nov 17, 2013 at 6:17 AM, Upayavira <u...@odoko.co.uk> wrote: >> > >> > >> > On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: >> >> >> >> >> >> On 11/16/13 8:47 AM, "Upayavira" <u...@odoko.co.uk> wrote: >> >> >> >> > >> >> > >> >> > >> >> >Alex, >> >> > >> >> >I'm not sure I see the difference between a release auditor and an IPMC >> >> >member. If someone is sufficiently clued up to audit a release, then >> >> >they're surely ready to join the Incubator PMC. Am I missing something? >> >> To me, there is more responsibility in being on the IPMC, like reviewing >> >> proposals for new podlings and voting on their graduation and becoming a >> >> mentor. Personally, that's why I don't want to be on the IPMC, but I >> >> might be willing to help IP audit a podling's release. Just like some >> >> projects don't have all committers on the PMC, a Release Auditor is just >> >> someone who can do that specific task, and there is no need to vote them >> >> in if they are already on some other TLP PMC because any member of a TLP >> >> PMC supposedly knows how to do release auditing. >> >> >> >> > >> >> >My interest is in a lesser level of involvement, where someone has shown >> >> >merit within their own PPMC and can get a binding vote there, but >> >> >no-where else. That feels to me like a very useful intermediate step to >> >> >have. >> >> I agree, except for the no-where else part. If you know how to check a >> >> RAT report and have an idea of what should be in the NOTICE files, you >> >> should be able to help out any other podling by reviewing their release >> >> and casting a binding vote so they can learn how to do that. I'd say >> >> that >> >> 3 IPMC members must vote to give a person Release Auditor status if they >> >> are not already on a TLP PMC. Consider this: I am an the Flex PMC but >> >> not the IPMC, but if I join the PPMC of some new podling, why shouldn't I >> >> be able to cast a binding vote for that podling's releases? >> > >> > With a two tier model - with PPMC membership granting voting rights on >> > podling releases, then a podling would start with just mentors on its >> > PPMC. If you clearly knew what you were doing, you'd get voted onto the >> > PPMC pretty quickly, and thus you'd be able to vote on your releases. >> > >> > Upayavira >> > >> > --------------------------------------------------------------------- >> > 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
