incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: my pTLP view
Date Sun, 25 Jan 2015 19:49:43 GMT
> This is *exactly* the way things work in a TLP.

Yes, everyone new to the Foundation on the PPMC has a sense of equal
ownership in the process. The PPMC makes a decision together as equals,
then the decision is reviewed as a whole. But this is not how things would
work in a pTLP, right? Individuals there would effectively cast votes +1
(binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc.,
depending if they are a Member or not. Maybe in practice the pTLP PMC
wouldn't write down their votes like that, but somehow the distinction must
be presented in the tallies to be meaningful.



On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej <brane@apache.org> wrote:

> On 25.01.2015 19:51, Andrew Purtell wrote:
> >> That hardly ever happens (it's most likely when there are problems with
> > ​> ​
> > a podling's first few releases), which is why you get the impression
> > ​> ​
> > that the PPMC can make binding decisions.
> >
> > ​Close. The PPMC membership feels they have made a decision that matters
> > with equal input.
> > Certainly on PPMCs I've been on,
> > ​there is awareness that everything is
> > provisional
> > ​. Still, a
> >  process takes place on PPMC mailing lists leading to a tallied outcome.
> > The input that leads to this output is the consensus or voting of *a
> group
> > of equal peers*.
> > ​ This output is handed to the IPMC in aggregate. ​
> > When casting votes on the PPMC lists there are no +1 (binding) or +1
> > (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
> > feeling some level of ownership having just participated in a decision
> > making process as equal
> > ​s​
> > . (Or at least so I think, in some perhaps quaint notion.) Of course in
> > IPMC voting it is different, but the IPMC is where supervision happens,
> or
> > doesn't, as some argue.
>
> This is *exactly* the way things work in a TLP. Any committer can
> propose a release. The PMC must (!) start a (public) vote. Anyone can
> vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
> member or plain committer, should block the release and trigger a
> discussion to find a solution; and in this discussion (which purpose is
> to reach consensus on a solution), PMC members have no more voice than
> any other community member.
>
> If the PMC decides to ignore a -1 on a release vote, they'd better have
> really good reasons for that, or I'd expect the Board to come down like
> a ton of bricks on that PMC.
>
> The situation is slightly different with new committer/PMC member
> nominations and votes, which are private; you have a point there.
>
> -- Brane
>
> > On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej <brane@apache.org> wrote:
> >
> >> On 25.01.2015 19:16, Andrew Purtell wrote:
> >>> With a PPMC we invite newcomers to make votes we call binding on
> matters
> >> of
> >>> their own project.
> >> As other people have said, PPMC members (that are not also IPMC members)
> >> do not have binding votes, neither for releases nor for inviting new
> >> committers/PPMC members. The "binding" bit lies with the IPMC, which can
> >> revoke any formal decision made by the PPMC.
> >>
> >> That hardly ever happens (it's most likely when there are problems with
> >> a podling's first few releases), which is why you get the impression
> >> that the PPMC can make binding decisions. In this respect, there's no
> >> practical difference between the current IPMC model and the proposed
> >> pTLP model.
> >>
> >> Of course, when it comes to /technical/ decisions, there's no such thing
> >> as a vote, so the term "binding" does not apply. Consensus, of one form
> >> or another, always rules: and the IPMC or mentors can't meddle in this
> >> case.
> >>
> >> -- Brane
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message