Please don’t cry out for something simple, you know what my answer is but you don’t like hearing it.
The bottom line is that we need to provide to the board, possibly on a per-podling basis, a list of people we have approved for making binding decisions about release votes. Why you want to tie that into mentoring, personnel voting, etc. makes little sense unless you intend for that list to be self-populating too, in which case I’d agree that PPMC alignment would make the most sense. The ultimate question is that do you want to fiddle around at the ends of the status quo or induce a sea-change into how release voting works in this part of the org? I’d expect support for your position will depend more on this answer than anything else you cook up. On Nov 20, 2013, at 4:13 AM, ant elder <ant.el...@gmail.com> wrote: > Its not totally clear to me what that would look like. What would then > be the difference between an "IP Stewards" and what we currently call > "mentor", where would they discuss and vote on adding new "IP > Stewards"? I'm not saying it couldn't be made to work and i guess this > is the sort of thing an experiment would help sort out, but it does > seem like its starting to make things unnecessarily complicated. The > original pTLP approach where the PMC is all the PPMC + some others > providing oversight is easy and simple. If it looks like they're going > off course the ones providing the oversight step in, if necessary with > -1s, if those are ignored the pTLP gets sent back to the Incubator. > > ...ant > > On Tue, Nov 19, 2013 at 10:51 AM, Joseph Schaefer > <joe_schae...@yahoo.com> wrote: >> >> Then lets disambiguate by not referring to the >> “IP Stewards” as being the PPMC. Seems simple >> enough. >> >> On Nov 19, 2013, at 4:34 AM, ant elder <ant.el...@gmail.com> wrote: >> >>> The reason it might be dis-empowering is that currently one of the main >>> roles of the PPMC is voting in new committers so if the PPMC is initially >>> just the mentors then the other podling members wont be involved in that. >>> It might still be worth trying the approach as an experiment if a willing >>> podling can be found, but i doubt all new podlings would be very happy with >>> the approach. >>> >>> ...ant >>> >>> >>> >>> On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer >>> <joe_schae...@yahoo.com>wrote: >>> >>>> I don’t see how the situation is any worse >>>> than it is now, where no one on the project >>>> currently has a binding vote on a release. >>>> Going from that to “a few” may seem unfair, >>>> but we have to start somewhere and we need >>>> to keep in mind that this is partly a training >>>> exercise, where we need to see people actually >>>> demonstrate good judgement on policy matters. >>>> >>>> Unfortunately this doesn’t solve the bootstrapping >>>> issue directly with the first release, unless we >>>> use it as a remedy for letting release votes stall. >>>> >>>> >>>> On Nov 18, 2013, at 6:41 AM, Andy Seaborne <a...@apache.org> wrote: >>>> >>>>> On 17/11/13 11:17, Upayavira 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. >>>>> >>>>> I am concerned that it would be dis-empowering to the incoming community >>>> if at least the active and major developers of the podling were not on the >>>> PPMC at the start. >>>>> >>>>> Andy >>>>> >>>>>> >>>>>> 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 >> > > --------------------------------------------------------------------- > 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
