Re: Incubator Governance Change

[Bertrand Delacretaz]

Hi,

On Wed, Apr 26, 2017 at 8:04 AM, Niclas Hedhman  wrote:
> ...I have argued before for a single Mentor, with responsibilities just like
> the PMC Chairs and if failing the duties, duly replaced by IPMC...

Previous discussions led to proposals to have a "podling chair" with a
similar role to the PMC chair in a TLP.

Combined with Joe's proposal to elect deserving podling members as
IPMC members, we might decide to have a podling chair who's initially
a mentor but should transition to a podling committer soon and elect
that podling committer as IPMC member.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Joe Schaefer]

What exactly are we trying to achieve here?  There is a record number of
podlings in incubation and the best ideas so far are to shame more labor
out of the people that are already overloaded.  Sure that will work, as if
burnout wasn't already a problem for mentors.

What is the lesson for the podling?  That the only votes Apache cares about
are those performed by people who have never vetted a single commit to the
codebase?  Is this what community based development is all about, where
overworked bureaucrats put their fingers in various dykes pretending that
only they can function as the true gatekeepers to the arcane secrets of the
org?  Is it any wonder where animosity towards the org by those being
subjected to this mindset comes from, or that in the end what it breeds is
more harmful to the overall mission to graduate healthy projects than any
policy imperfections in podling releases overlooked by actual engineers
trying to get shit out the door?  Isn't that what the disclaimer is
supposed to be there for, instead of yet another imposition on the victims
of this nonsense?

Grow up folks.


On Wed, Apr 26, 2017 at 2:04 AM, Niclas Hedhman  wrote:

> Either you draw the parallels to the TLPs or you don't.
>
> If you do, TLPs don't have Mentors, but they do have a PMC, typically with
> engaged members and a 'phone line" to the board in forms of a Chair. If the
> "Chair" goes AWOL, then either the PMC members request help from the board
> to appoint a new Chair, typically by submission of a resolution, or the
> board notices that the phone is no longer ringing, in which case the PMC is
> asked if it has died or not.
>
> Translate;
> PMC -> Podling committers
> PMC Chair -> Mentor
> Board -> Incubator PMC
>
> Now, we have the complication that there are 3 mentors, sometimes all
> assuming that the "others" will handle it, and podlings are unwise about
> what is expected.
>
> I have argued before for a single Mentor, with responsibilities just like
> the PMC Chairs and if failing the duties, duly replaced by IPMC. The
> counter-argument to single Mentor is that podlings need 3 binding votes,
> and I suggest to change the role names here to perhaps "Supporter" and the
> Mentor simply emeritus any Supporter that is absent too long, and come to
> IPMC to request more help.
>
> Hopefully, we can get to a position where podlings are not asking for IPMC
> release votes, just like TLPs are not asking for Board's approval of
> releases.
>
> And I think that if the Mentors are then keeping a up-to-date rooster on
> Supporters, we have a pretty good overview of podlings' health.
>
>
> Cheers
> Niclas
>
>
>
> On Wed, Apr 26, 2017 at 1:37 PM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz 
> > wrote:
> > > ...I mostly agree, but would hesitate with the idea that a podling be
> > responsible for raising a red flag
> > > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> > us, not the projects we incubate
> >
> > The IPMC will typically not know before it's too late, so it's good
> > for the podlings to raise those red flags - and ask the IPMC for help.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Incubator Governance Change

[Niclas Hedhman]

Either you draw the parallels to the TLPs or you don't.

If you do, TLPs don't have Mentors, but they do have a PMC, typically with
engaged members and a 'phone line" to the board in forms of a Chair. If the
"Chair" goes AWOL, then either the PMC members request help from the board
to appoint a new Chair, typically by submission of a resolution, or the
board notices that the phone is no longer ringing, in which case the PMC is
asked if it has died or not.

Translate;
PMC -> Podling committers
PMC Chair -> Mentor
Board -> Incubator PMC

Now, we have the complication that there are 3 mentors, sometimes all
assuming that the "others" will handle it, and podlings are unwise about
what is expected.

I have argued before for a single Mentor, with responsibilities just like
the PMC Chairs and if failing the duties, duly replaced by IPMC. The
counter-argument to single Mentor is that podlings need 3 binding votes,
and I suggest to change the role names here to perhaps "Supporter" and the
Mentor simply emeritus any Supporter that is absent too long, and come to
IPMC to request more help.

Hopefully, we can get to a position where podlings are not asking for IPMC
release votes, just like TLPs are not asking for Board's approval of
releases.

And I think that if the Mentors are then keeping a up-to-date rooster on
Supporters, we have a pretty good overview of podlings' health.


Cheers
Niclas



On Wed, Apr 26, 2017 at 1:37 PM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz 
> wrote:
> > ...I mostly agree, but would hesitate with the idea that a podling be
> responsible for raising a red flag
> > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> us, not the projects we incubate
>
> The IPMC will typically not know before it's too late, so it's good
> for the podlings to raise those red flags - and ask the IPMC for help.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Joe Schaefer]

Continuing down the road of blaming each other for the problem is stupid.
Look the personnel is already ready, willing, and available to do the real
vetting.
All the IPMC has to do is recognize them and integrate them.

On Wed, Apr 26, 2017 at 1:37 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz 
> wrote:
> > ...I mostly agree, but would hesitate with the idea that a podling be
> responsible for raising a red flag
> > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> us, not the projects we incubate
>
> The IPMC will typically not know before it's too late, so it's good
> for the podlings to raise those red flags - and ask the IPMC for help.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Incubator Governance Change

[Bertrand Delacretaz]

On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz  wrote:
> ...I mostly agree, but would hesitate with the idea that a podling be 
> responsible for raising a red flag
> when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on us, 
> not the projects we incubate

The IPMC will typically not know before it's too late, so it's good
for the podlings to raise those red flags - and ask the IPMC for help.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Roman Shaposhnik]

On Tue, Apr 25, 2017 at 8:47 PM, P. Taylor Goetz  wrote:
>
>> On Apr 25, 2017, at 9:06 PM, Roman Shaposhnik  wrote:
>>
>> I honestly think its time for us to consider being more board like
>> around here at
>> IPMC. May be not exactly as strict as the board, but moving in that 
>> direction.
>>
>> After all, being a podling means being TLP-on-training-wheels. That's the 
>> whole
>> idea. If your PMC shrinks -- you have to know what it means. Same here. If 
>> your
>> mentors are not active -- you've got to raise hell around here on general@
>> before its too late.
>
> I mostly agree, but would hesitate with the idea that a podling be 
> responsible for
> raising a red flag when mentors are inactive. If the IPMC isn’t doing it’s 
> job,
> that’s on us, not the projects we incubate.

I am not saying IPMC is off the hook here, but rather I'm trying to instill
a sense of self-reliance in a future TLP.

While PPMC is mostly an artificial construct from the ASF's point of view,
the idea there is to teach podling how the TLP PMC should behave. One
of the traits of this behaviour is to recognize problems within the community
and try to resolve them instead of semi-passively waiting for either board
or IPMC to intervene.

Again, I'm not advocating for shifting the responsibility as much as
I'm advocating
for shift in perspective. I would still expect the IPMC members to be watchful,
but I would also expect them to use every opportunity like that as a teaching
moment. E.g. "oh, so we've noticed you're struggling with mentors being MIA,
we're sorry about that, but have you considered escalating to IPMC and perhaps
soliciting additional mentors?" instead of "oh, so we've noticed
you're struggling
with mentors being MIA, let us fix this for you" (I'm obviously
exaggerating, but you
catch my drift).

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[P. Taylor Goetz]

> On Apr 25, 2017, at 9:06 PM, Roman Shaposhnik  wrote:
> 
> I honestly think its time for us to consider being more board like
> around here at
> IPMC. May be not exactly as strict as the board, but moving in that direction.
> 
> After all, being a podling means being TLP-on-training-wheels. That's the 
> whole
> idea. If your PMC shrinks -- you have to know what it means. Same here. If 
> your
> mentors are not active -- you've got to raise hell around here on general@
> before its too late.

I mostly agree, but would hesitate with the idea that a podling be responsible 
for raising a red flag when mentors are inactive. If the IPMC isn’t doing it’s 
job, that’s on us, not the projects we incubate.

-Taylor

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sun, Apr 23, 2017 at 4:50 AM, Greg Stein  wrote:
> On Sat, Apr 22, 2017 at 7:46 PM, Roman Shaposhnik 
> wrote:
>>...
>
>> I'm starting to wonder whether the real solution here should be along the
>> lines
>> of what a board would do to a TLP if its active PMC shrinks to less
>> than 3 people.
>>
>
> Oh, that's easy, and has been done quite a few times. The Board moves them
> to the Attic. ... The Board will give the PMC several chances, and this can
> drag out for a year, but at the end of the day, the Board says "enough" and
> forces the issue. Done. Attic'd.

That's what I was implying.

> Now, I'm not sure if you were trying to draw an analogy between Board/PMC
> and IPMC/PPMC. From a legal/oversight perspective, these are very
> different. I don't think the IPMC should be so drastic. But the Board must,
> and will.

I honestly think its time for us to consider being more board like
around here at
IPMC. May be not exactly as strict as the board, but moving in that direction.

After all, being a podling means being TLP-on-training-wheels. That's the whole
idea. If your PMC shrinks -- you have to know what it means. Same here. If your
mentors are not active -- you've got to raise hell around here on general@
before its too late.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Ted Dunning]

On Tue, Apr 25, 2017 at 12:50 AM, Pierre Smits 
wrote:

> Now, we can argue that mentors have an obligation to vote on releases of an
> incubating project first before the vote is taken to this ml. But that
> could lead to unnecessary delays and frustration.
>

Having the mentors vote in the podling mailing list *saves* time in my
experience even if you don't get all three votes.

Re: Incubator Governance Change

[Bertrand Delacretaz]

On Tue, Apr 25, 2017 at 12:46 PM, John D. Ament  wrote:
> On Tue, Apr 25, 2017 at 3:56 AM Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>>... We want all podlings to be actively mentored, and if that doesn't
>> happen they should look for new mentors to make sure they have at
>> least one that's active which includes voting on releases.
>>
> How do we communicate this out more?...

A blog post maybe? We do have some at
https://blogs.apache.org/incubator/ already.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[John D. Ament]

On Tue, Apr 25, 2017 at 3:56 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Tue, Apr 25, 2017 at 9:50 AM, Pierre Smits 
> wrote:
> > ...we can argue that mentors have an obligation to vote on releases of an
> > incubating project first before the vote is taken to this ml...
>
> Mentors not voting on releases gives a very bad signal to me as to
> their engagement in the podling.
>
>
Huge +1 on this.


> We want all podlings to be actively mentored, and if that doesn't
> happen they should look for new mentors to make sure they have at
> least one that's active which includes voting on releases.
>
>
How do we communicate this out more? Several of us have been harping on
this, saw some progress, but not quite enough.


> -Bertrand (who's not perfect either as a mentor, and would accept
> being kicked out of that role as a result for podlings where I'm not
> doing my job)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Incubator Governance Change

[Bertrand Delacretaz]

On Tue, Apr 25, 2017 at 9:50 AM, Pierre Smits  wrote:
> ...we can argue that mentors have an obligation to vote on releases of an
> incubating project first before the vote is taken to this ml...

Mentors not voting on releases gives a very bad signal to me as to
their engagement in the podling.

We want all podlings to be actively mentored, and if that doesn't
happen they should look for new mentors to make sure they have at
least one that's active which includes voting on releases.

-Bertrand (who's not perfect either as a mentor, and would accept
being kicked out of that role as a result for podlings where I'm not
doing my job)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Mark Struberg]

PS to make it clear: I was just refering to the point of podlings being able to 
let jenkins publish nightly builds to the ASF snapshots Maven repo.

It was not meant as remark to any other of the discussed bullets.

LieGrue,
strub

> Am 24.04.2017 um 21:14 schrieb Mark Struberg :
> 
> Many dozen podlings do exactly that. 
> Why should that not be allowed? Hell freezing over?
> 
> LieGrue,
> strub
> 
> 
>> Am 23.04.2017 um 06:04 schrieb Niclas Hedhman :
>> 
>> On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik 
>> wrote:
>>> I don't
>>> think releasing something out of ASF that hasn't had at least 3 binding
>> votes
>>> would be advisable.
>> 
>> AFAIK, projects "publish" to
>> https://repository.apache.org/content/groups/snapshots/org/apache as part
>> of CI build without vetting and votes. There are also other snapshots
>> (example; https://ci.apache.org/projects/openoffice/install/win/) that are
>> not Maven artifacts.
>> 
>> IF we allow those, then why not allow podlings to do the same thing?
>> 
>> 
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://polygene.apache.org - New Energy for Java
> 
> 
> -
> 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

Re: Incubator Governance Change

[Mark Struberg]

Many dozen podlings do exactly that. 
Why should that not be allowed? Hell freezing over?

LieGrue,
strub


> Am 23.04.2017 um 06:04 schrieb Niclas Hedhman :
> 
> On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik 
> wrote:
>> I don't
>> think releasing something out of ASF that hasn't had at least 3 binding
> votes
>> would be advisable.
> 
> AFAIK, projects "publish" to
> https://repository.apache.org/content/groups/snapshots/org/apache as part
> of CI build without vetting and votes. There are also other snapshots
> (example; https://ci.apache.org/projects/openoffice/install/win/) that are
> not Maven artifacts.
> 
> IF we allow those, then why not allow podlings to do the same thing?
> 
> 
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Julian Hyde]

> On Apr 24, 2017, at 11:48 AM, P. Taylor Goetz  wrote:

> While podlings have an explicit set of mentors, the IPMC as a whole can be 
> thought of as an informal set of mentors. Reviewing and voting on podling 
> release candidates is one way for any IPMC member to help a podling whether a 
> mentor or not.

I agree.

Mentors are the first line of support for questions. They read all of the 
traffic on the dev and private lists. And yes, they vote on releases, but in 
practice podlings only have 1 or 2 active mentors. So, podlings need votes IPMC 
members need to vote. 

Anyone who doesn’t have time to vote on at least 2 release candidates a year 
should, in my opinion, resign from the IPMC. I’m sorry, but apathy really 
pisses me off. It drags us all down. I’d rather spend time with a few motivated 
people than a whole load of dead-weights.

Julian

Re: Incubator Governance Change

[P. Taylor Goetz]

> On Apr 23, 2017, at 11:09 AM, Shane Curcuru  wrote:
> 
> Pat Ferrel wrote on 4/22/17 11:46 AM:
>> Probably the wrong place for this but…
>> 
>> What do people think about a governance change for approving releases
>> through the IPMC to wit:
>> 
>> A week of no vote activity over the release proposal of a podling
>> should be considered a passing vote. In other words the IPMC is to
>> become a vetoing group.
> 
> No, because as noted in this thread the board and Legal Affairs
> Committee already have a policy for Apache software releases:
> 
>  https://www.apache.org/legal/release-policy.html#policy
> 
> This is the spot where all the little legal bits of having a corporation
> intersects with the Incubator's ability to mentor new podlings in how to
> effectively run projects in the Apache Way.  However that legal policy
> in particular is not going to change IMO.
> 
> Personally, I support any proposals that help ensure podling mentors are
> more actively engaged, and can better serve as the formal IPMC votes for
> podling releases.  Great to see some serious discussion about that in
> this thread and the upcoming IPMC chair election.  The incubator has
> been getting better organized as a whole over the past few years, and
> keeps improving, which is great to see.
> 
>> I propose this for 2 reasons: 1) lack of votes or attention from the
>> IPMC seems all too prevalent and puts an undo drag on the energy and
>> velocity of community involvement. 2) the release has already been
>> voted on and checked by at least 3 PMC members of the podling (which
>> has ASF mentors in most all cases) so a veto role by the IPMC seems
>> to have minimum danger to the ASF system of checks and balances.>
> 
> Yes, but the whole point of Incubation is that a podling is not yet a
> project.  Only Apache PMCs have the authority to make a release, thus
> only IPMC votes count.  On one hand this must feel incredibly annoying.
> On the other hand, it is the #1 reason we have the ASF as a corporation
> - to prevent the individual release manager from potentially getting
> sued *personally* for problems with the release.
> 
> The fact that we have these documented policies, and that the board and
> IPMC enforces them means that legally, releases are acts of the
> Foundation.  Thus if anyone ever were to sue, they'd sue the Foundation
> (which has insurance and legal counsel) and not individual committers.
> 
> -- 
> 
> - Shane, IPMC Member
>  https://www.apache.org/foundation/marks/resources
> 

I completely agree with Shane. To put it another way, podlings don’t make 
releases, the IPMC makes releases.

In the past I’ve seen others advocate that one active mentor is enough for a 
podling. I do not share that opinion and think release voting is another reason 
a podling should aim (notice I’m not saying “must” here) to have at least three 
mentors. Mentors, by virtue of being more intimately involved with a podling, 
are much more likely to vote on a release than non-mentor IPMC members.

To address the low level of IPMC members voting on podling releases, we need to 
understand why it happens. Is it just a lack of individuals’ time? Is it that 
IPMC members expect a podling’s mentors to review and vote on a release?

Historically I’ve tended toward the latter, but my thinking has changed over 
time. While podlings have an explicit set of mentors, the IPMC as a whole can 
be thought of as an informal set of mentors. Reviewing and voting on podling 
release candidates is one way for any IPMC member to help a podling whether a 
mentor or not.

-Taylor





-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[James Bognar]

My plan for PPMC votes is to simply send out "friendly reminder" emails
every 24 hours after the vote deadline has passed.

On Sun, Apr 23, 2017 at 11:09 AM, Shane Curcuru 
wrote:

> Pat Ferrel wrote on 4/22/17 11:46 AM:
> > Probably the wrong place for this but…
> >
> > What do people think about a governance change for approving releases
> > through the IPMC to wit:
> >
> > A week of no vote activity over the release proposal of a podling
> > should be considered a passing vote. In other words the IPMC is to
> > become a vetoing group.
>
> No, because as noted in this thread the board and Legal Affairs
> Committee already have a policy for Apache software releases:
>
>   https://www.apache.org/legal/release-policy.html#policy
>
> This is the spot where all the little legal bits of having a corporation
> intersects with the Incubator's ability to mentor new podlings in how to
> effectively run projects in the Apache Way.  However that legal policy
> in particular is not going to change IMO.
>
> Personally, I support any proposals that help ensure podling mentors are
> more actively engaged, and can better serve as the formal IPMC votes for
> podling releases.  Great to see some serious discussion about that in
> this thread and the upcoming IPMC chair election.  The incubator has
> been getting better organized as a whole over the past few years, and
> keeps improving, which is great to see.
>
> > I propose this for 2 reasons: 1) lack of votes or attention from the
> > IPMC seems all too prevalent and puts an undo drag on the energy and
> > velocity of community involvement. 2) the release has already been
> > voted on and checked by at least 3 PMC members of the podling (which
> > has ASF mentors in most all cases) so a veto role by the IPMC seems
> > to have minimum danger to the ASF system of checks and balances.>
>
> Yes, but the whole point of Incubation is that a podling is not yet a
> project.  Only Apache PMCs have the authority to make a release, thus
> only IPMC votes count.  On one hand this must feel incredibly annoying.
> On the other hand, it is the #1 reason we have the ASF as a corporation
> - to prevent the individual release manager from potentially getting
> sued *personally* for problems with the release.
>
> The fact that we have these documented policies, and that the board and
> IPMC enforces them means that legally, releases are acts of the
> Foundation.  Thus if anyone ever were to sue, they'd sue the Foundation
> (which has insurance and legal counsel) and not individual committers.
>
> --
>
> - Shane, IPMC Member
>   https://www.apache.org/foundation/marks/resources
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
James Bognar

Re: Incubator Governance Change

[Shane Curcuru]

Pat Ferrel wrote on 4/22/17 11:46 AM:
> Probably the wrong place for this but…
> 
> What do people think about a governance change for approving releases
> through the IPMC to wit:
> 
> A week of no vote activity over the release proposal of a podling
> should be considered a passing vote. In other words the IPMC is to
> become a vetoing group.

No, because as noted in this thread the board and Legal Affairs
Committee already have a policy for Apache software releases:

  https://www.apache.org/legal/release-policy.html#policy

This is the spot where all the little legal bits of having a corporation
intersects with the Incubator's ability to mentor new podlings in how to
effectively run projects in the Apache Way.  However that legal policy
in particular is not going to change IMO.

Personally, I support any proposals that help ensure podling mentors are
more actively engaged, and can better serve as the formal IPMC votes for
podling releases.  Great to see some serious discussion about that in
this thread and the upcoming IPMC chair election.  The incubator has
been getting better organized as a whole over the past few years, and
keeps improving, which is great to see.

> I propose this for 2 reasons: 1) lack of votes or attention from the
> IPMC seems all too prevalent and puts an undo drag on the energy and
> velocity of community involvement. 2) the release has already been
> voted on and checked by at least 3 PMC members of the podling (which
> has ASF mentors in most all cases) so a veto role by the IPMC seems
> to have minimum danger to the ASF system of checks and balances.>

Yes, but the whole point of Incubation is that a podling is not yet a
project.  Only Apache PMCs have the authority to make a release, thus
only IPMC votes count.  On one hand this must feel incredibly annoying.
On the other hand, it is the #1 reason we have the ASF as a corporation
- to prevent the individual release manager from potentially getting
sued *personally* for problems with the release.

The fact that we have these documented policies, and that the board and
IPMC enforces them means that legally, releases are acts of the
Foundation.  Thus if anyone ever were to sue, they'd sue the Foundation
(which has insurance and legal counsel) and not individual committers.

-- 

- Shane, IPMC Member
  https://www.apache.org/foundation/marks/resources

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Greg Stein]

On Sat, Apr 22, 2017 at 7:46 PM, Roman Shaposhnik 
wrote:
>...

> I'm starting to wonder whether the real solution here should be along the
> lines
> of what a board would do to a TLP if its active PMC shrinks to less
> than 3 people.
>

Oh, that's easy, and has been done quite a few times. The Board moves them
to the Attic. ... The Board will give the PMC several chances, and this can
drag out for a year, but at the end of the day, the Board says "enough" and
forces the issue. Done. Attic'd.

Now, I'm not sure if you were trying to draw an analogy between Board/PMC
and IPMC/PPMC. From a legal/oversight perspective, these are very
different. I don't think the IPMC should be so drastic. But the Board must,
and will.

Cheers,
-g

Re: Incubator Governance Change

[Greg Stein]

On Sat, Apr 22, 2017 at 7:13 PM, Ted Dunning  wrote:

> On Sat, Apr 22, 2017 at 11:27 AM, Joe Schaefer  wrote:
> > Your proposal violates foundation policy on releases and is therefore a
> > nonstarter.  The ipmc isn't empowered to restructure release policy.
>
> Specifically, the problem Joe is pointing out is that three actual PMC
> members are required to vote +1 on a release.
>

Note the above.

This is one of the strongest policies put in place by the Foundation. Three
*affirmative* votes are required, so lazy consensus is not applicable. The
Board and its right hand, Legal Affairs, will not budge on that
requirement. (and good luck trying to do so)

Cheers,
-g

Re: Incubator Governance Change

[John D. Ament]

On Sun, Apr 23, 2017 at 12:05 AM Niclas Hedhman  wrote:

> On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik 
> wrote:
> > I don't
> > think releasing something out of ASF that hasn't had at least 3 binding
> votes
> > would be advisable.
>
> AFAIK, projects "publish" to
> https://repository.apache.org/content/groups/snapshots/org/apache as part
> of CI build without vetting and votes. There are also other snapshots
> (example; https://ci.apache.org/projects/openoffice/install/win/) that are
> not Maven artifacts.
>
> IF we allow those, then why not allow podlings to do the same thing?
>
>
Podlings are allowed to do both.  Infra sets them up for either.  There's a
call out for TLPs that these snapshots are meant for dev preview/testing of
new functionality.  This call out applies to podlings as well.

Note that this isn't a "outside the ASF" release.


>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Incubator Governance Change

[Niclas Hedhman]

On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik 
wrote:
> I don't
> think releasing something out of ASF that hasn't had at least 3 binding
votes
> would be advisable.

AFAIK, projects "publish" to
https://repository.apache.org/content/groups/snapshots/org/apache as part
of CI build without vetting and votes. There are also other snapshots
(example; https://ci.apache.org/projects/openoffice/install/win/) that are
not Maven artifacts.

IF we allow those, then why not allow podlings to do the same thing?


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 7:24 PM, Niclas Hedhman  wrote:
> On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik 
> wrote:
>
>>
>> I'm starting to wonder whether the real solution here should be along the
>> lines
>> of what a board would do to a TLP if its active PMC shrinks to less
>> than 3 people.
>
>
> That will inevitable lead to definition of "what is active" and the whole
> "pity me/them for not having time" discussion that always arises when
> Mentor responsibilities are brought up.

True. But this is exactly what happens to a TLP, isn't it?

It is true that this will re-define mentorship expectations, but I think it
we may benefit from this re-definition in the long run. As it stands, being
a mentor today is way less commital than being a PMC member and
I don't think this is right.

I also suspect that re-defining commitment this way would serve
as a forcing function for potential podlings that don't get enough
engaged mentors up-front to fail fast (they won't be able to enter
Incubator) instead of getting stuck in limbo.

> I have been Mentor on 8 podlings;
>   * I was inactive on 1 of those (can't recall the reason)
>   * On 2 projects one other mentor was active.
>   * Remaining 5 projects, none of the other mentors did anything
> substantial, most nothing at all.
>
> Am I unlucky, scare others to inactivity, or is this what I think; people
> don't take the responsibility particularly seriously. "Oh cool project, I
> would like to be associated with that."
>
> Pat's suggestion is understandable, but not really viable.
>
> I would like to make a counter-suggestion, and I am sure IPMC won't like
> it, since it is filled with inactive, but sensitive, mentors;
>
>* If the release is left dangling (not enough votes) for IPMC approval
> beyond 72 hours,
>  1. The release may be placed in the dist snapshot areas, so active
> community members have some stable milestone to work with,
>  2. An Incubator page (for instance the /projects page) is updated with
> a "Attempted Release - failed not enough votes" with dates and votes
> received. This will accumulate the data points for IF there is a real
> problem in the Incubator and we can gather the stats if we have
> irresponsible mentors or not. It also gives the podling a vent for the
> frustration.

This is exactly the kind of stats gathering I was referring to. At the
same time,
I think the line in the sand is pretty clear -- it only is stats
gathering. I don't
think releasing something out of ASF that hasn't had at least 3 binding votes
would be advisable.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Niclas Hedhman]

On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik 
wrote:

>
> I'm starting to wonder whether the real solution here should be along the
> lines
> of what a board would do to a TLP if its active PMC shrinks to less
> than 3 people.


That will inevitable lead to definition of "what is active" and the whole
"pity me/them for not having time" discussion that always arises when
Mentor responsibilities are brought up.

I have been Mentor on 8 podlings;
  * I was inactive on 1 of those (can't recall the reason)
  * On 2 projects one other mentor was active.
  * Remaining 5 projects, none of the other mentors did anything
substantial, most nothing at all.

Am I unlucky, scare others to inactivity, or is this what I think; people
don't take the responsibility particularly seriously. "Oh cool project, I
would like to be associated with that."

Pat's suggestion is understandable, but not really viable.

I would like to make a counter-suggestion, and I am sure IPMC won't like
it, since it is filled with inactive, but sensitive, mentors;

   * If the release is left dangling (not enough votes) for IPMC approval
beyond 72 hours,
 1. The release may be placed in the dist snapshot areas, so active
community members have some stable milestone to work with,
 2. An Incubator page (for instance the /projects page) is updated with
a "Attempted Release - failed not enough votes" with dates and votes
received. This will accumulate the data points for IF there is a real
problem in the Incubator and we can gather the stats if we have
irresponsible mentors or not. It also gives the podling a vent for the
frustration.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 5:14 PM, John D. Ament  wrote:
> On Sat, Apr 22, 2017 at 8:10 PM Ted Dunning  wrote:
>
>> Another solution is to do back door politicking where you contact IPMC
>> members individually and ask them to take a look. Start with members who
>> have voted on Mahout releases in the past and be specific about what you
>> would like them do and provide links to artifacts and discussions to make
>> the job easy.
>>
>> That has usually been my best way to succeed on that.
>>
>>
> 9 times out of 10, I ignore those emails.  If its someone I don't know,
> I'll send them over to http://incubator.apache.org/whoweare.html .  I'm not
> sure who created that page but I like it.
>
> We rely first and foremost of podling mentors to review releases.  Its much
> easier to review a release if the mentors have reviewed and given it a once
> over.  We're all volunteers here.  To me its also a good sign of mentor
> engagement seeing the mentors review the releases.

And that's exactly why my constant advice to all the podlings is to get at least
3 mentors so that at least in theory those are the ones from IPMC who would
care.

Interestingly enough, it hasn't really worked 100% but it is definitely better
than hoping for random IPMC votes.

I'm starting to wonder whether the real solution here should be along the lines
of what a board would do to a TLP if its active PMC shrinks to less
than 3 people.

This actually reminds me that I need to write my positioning statement since
this is definitely one of the issues I'd like to keep exploring more and more
instead of waiting for emails like the one that started this thread to kick us
in the collective IPMC butt.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 10:02 AM, Julian Hyde  wrote:
> I agree that lack of IPMC votes is a problem. I don’t think that lowering the 
> bar to making a release is the solution.

+1 to that.

> I wish that each IPMC member would personally commit to voting on two release
> candidates per year. There are so many members of the IPMC that this would
> easily cover all of the votes that come up.

It would be interesting to start gathering the stats as we used to see
a few trends
and also consider how can we reverse them. For instance, I'd like to see the
percentage of votes that comes from mentors, etc.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Governance Change

[John D. Ament]

On Sat, Apr 22, 2017 at 8:10 PM Ted Dunning  wrote:

> Another solution is to do back door politicking where you contact IPMC
> members individually and ask them to take a look. Start with members who
> have voted on Mahout releases in the past and be specific about what you
> would like them do and provide links to artifacts and discussions to make
> the job easy.
>
> That has usually been my best way to succeed on that.
>
>
9 times out of 10, I ignore those emails.  If its someone I don't know,
I'll send them over to http://incubator.apache.org/whoweare.html .  I'm not
sure who created that page but I like it.

We rely first and foremost of podling mentors to review releases.  Its much
easier to review a release if the mentors have reviewed and given it a once
over.  We're all volunteers here.  To me its also a good sign of mentor
engagement seeing the mentors review the releases.


>
>
> On Sat, Apr 22, 2017 at 10:19 AM, Pat Ferrel 
> wrote:
>
> > That works if human nature is not involved and would still produce the
> > same affect so I’d second your request in any case.
> >
> > However human nature is involved and my proposal would at least guarantee
> > that human nature could not hold innocent projects hostage. BTW notice
> the
> > include vote request, now over a week in with no binding up or down
> votes.
> >
> >
> > On Apr 22, 2017, at 10:02 AM, Julian Hyde  wrote:
> >
> > I agree that lack of IPMC votes is a problem. I don’t think that lowering
> > the bar to making a release is the solution.
> >
> > I wish that each IPMC member would personally commit to voting on two
> > release candidates per year. There are so many members of the IPMC that
> > this would easily cover all of the votes that come up.
> >
> > Julian
> >
> >
> > > On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> > >
> > > Probably the wrong place for this but…
> > >
> > > What do people think about a governance change for approving releases
> > through the IPMC to wit:
> > >
> > > A week of no vote activity over the release proposal of a podling
> should
> > be considered a passing vote. In other words the IPMC is to become a
> > vetoing group.
> > >
> > > I propose this for 2 reasons: 1) lack of votes or attention from the
> > IPMC seems all too prevalent and puts an undo drag on the energy and
> > velocity of community involvement. 2) the release has already been voted
> on
> > and checked by at least 3 PMC members of the podling (which has ASF
> mentors
> > in most all cases) so a veto role by the IPMC seems to have minimum
> danger
> > to the ASF system of checks and balances.
> > >
> > >
> > >
> > >
> > > On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> > >
> > > +1 non-binding
> > >
> > > Next release we could exclude the doc site. Do build files like .sbt
> > require licenses? I suppose it can be done in comments. But again can we
> > push to next release
> > >
> > > Can other binding voters have a look? I know everyone is busy but hey,
> > tax day is past ;-)
> > >
> > >
> > > On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> > >
> > > Hi Luciano,
> > >
> > > Thanks for your review. I will file JIRAs regarding these files. They
> are
> > > project build files and documentation.
> > >
> > > Regards,
> > > Donald
> > >
> > > On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende  >
> > > wrote:
> > >
> > >> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> > wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> > >> good
> > >>> for a source-only release. This thread is to facilitate a voting for
> > the
> > >>> IPMC before a final official source-only release.
> > >>>
> > >>> Vote result on dev@:
> > >>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> > >>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> > >>>
> > >>> The original vote thread on dev@:
> > >>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> > >>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> > >>>
> > >>> The release candidate Git commit is:
> > >>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> > >>>
> > >>> The release candidate Git tag is:
> > >>> v0.11.0-incubating-rc2
> > >>>
> > >>> The source-only release candidate artifacts can be downloaded here:
> > >>>
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> > >>> incubating-rc2/
> > >>>
> > >>> Test results of RC2 can be found here:
> > >>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> > >>>
> > >>> Build instructions of previous versions can be used on this RC:
> > >>> http://predictionio.incubator.apache.org/install/install-sourcecode/
> > >>>
> > >>> Maven artifacts are built from the release candidate artifacts above,
> > and
> > >>> are provided 

Re: Incubator Governance Change

[Ted Dunning]

On Sat, Apr 22, 2017 at 11:27 AM, Joe Schaefer  wrote:

> Your proposal violates foundation policy on releases and is therefore a
> nonstarter.  The ipmc isn't empowered to restructure release policy.
>

Specifically, the problem Joe is pointing out is that three actual PMC
members are required to vote +1 on a release.

Re: Incubator Governance Change

[Ted Dunning]

Another solution is to do back door politicking where you contact IPMC
members individually and ask them to take a look. Start with members who
have voted on Mahout releases in the past and be specific about what you
would like them do and provide links to artifacts and discussions to make
the job easy.

That has usually been my best way to succeed on that.



On Sat, Apr 22, 2017 at 10:19 AM, Pat Ferrel  wrote:

> That works if human nature is not involved and would still produce the
> same affect so I’d second your request in any case.
>
> However human nature is involved and my proposal would at least guarantee
> that human nature could not hold innocent projects hostage. BTW notice the
> include vote request, now over a week in with no binding up or down votes.
>
>
> On Apr 22, 2017, at 10:02 AM, Julian Hyde  wrote:
>
> I agree that lack of IPMC votes is a problem. I don’t think that lowering
> the bar to making a release is the solution.
>
> I wish that each IPMC member would personally commit to voting on two
> release candidates per year. There are so many members of the IPMC that
> this would easily cover all of the votes that come up.
>
> Julian
>
>
> > On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> >
> > Probably the wrong place for this but…
> >
> > What do people think about a governance change for approving releases
> through the IPMC to wit:
> >
> > A week of no vote activity over the release proposal of a podling should
> be considered a passing vote. In other words the IPMC is to become a
> vetoing group.
> >
> > I propose this for 2 reasons: 1) lack of votes or attention from the
> IPMC seems all too prevalent and puts an undo drag on the energy and
> velocity of community involvement. 2) the release has already been voted on
> and checked by at least 3 PMC members of the podling (which has ASF mentors
> in most all cases) so a veto role by the IPMC seems to have minimum danger
> to the ASF system of checks and balances.
> >
> >
> >
> >
> > On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> >
> > +1 non-binding
> >
> > Next release we could exclude the doc site. Do build files like .sbt
> require licenses? I suppose it can be done in comments. But again can we
> push to next release
> >
> > Can other binding voters have a look? I know everyone is busy but hey,
> tax day is past ;-)
> >
> >
> > On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> >
> > Hi Luciano,
> >
> > Thanks for your review. I will file JIRAs regarding these files. They are
> > project build files and documentation.
> >
> > Regards,
> > Donald
> >
> > On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> > wrote:
> >
> >> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> >> good
> >>> for a source-only release. This thread is to facilitate a voting for
> the
> >>> IPMC before a final official source-only release.
> >>>
> >>> Vote result on dev@:
> >>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> >>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The original vote thread on dev@:
> >>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> >>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The release candidate Git commit is:
> >>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >>>
> >>> The release candidate Git tag is:
> >>> v0.11.0-incubating-rc2
> >>>
> >>> The source-only release candidate artifacts can be downloaded here:
> >>> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> >>> incubating-rc2/
> >>>
> >>> Test results of RC2 can be found here:
> >>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >>>
> >>> Build instructions of previous versions can be used on this RC:
> >>> http://predictionio.incubator.apache.org/install/install-sourcecode/
> >>>
> >>> Maven artifacts are built from the release candidate artifacts above,
> and
> >>> are provided as convenience for testing with PredictionIO engine
> >> templates.
> >>> The Maven artifacts are provided at the Maven staging repo here:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachepredictionio-1016/
> >>>
> >>> All JIRAs completed for this release are tagged with 'FixVersion =
> >>> 0.11.0-incubating'. You can view them here:
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> projectId=12320420=12338381
> >>>
> >>> The artifacts have been signed with Key : 8BF4ABEB
> >>>
> >>> Please vote accordingly:
> >>>
> >>> [ ] +1, accept RC as the official 0.11.0 release
> >>> [ ] 0, neutral because...
> >>> [ ] -1, do not accept RC as the official 0.11.0 release because...
> >>>
> >>> The vote will be open for 72 hours and close at 12pm PDT 

Re: Incubator Governance Change

[Joe Schaefer]

Your proposal violates foundation policy on releases and is therefore a
nonstarter.  The ipmc isn't empowered to restructure release policy.

That said, talk to your project mentors about nominating competent release
managers and others participating constructively in the vetting process at
the podling level to the ipmc.  It seems we've dropped the ball again on a
problem we solved years ago by not keeping up with the pace of growth.


On Sat, Apr 22, 2017 at 1:47 PM Pat Ferrel  wrote:

> While I agree, asking is not enforcing. This would add enforcement that
> would allow the IPMC to function but have an enforceable clause that also
> does not allow it to roadblock by neglect.
>
> Plus about 1/2 the reason I bring this up is trying to get more votes on
> PredictionIO :-)
>
>
> On Apr 22, 2017, at 10:41 AM, Julian Hyde  wrote:
>
> Growing the IPMC is of no use if the members don’t show up and vote.
>
> The IPMC performs an important gatekeeper role, ensuring that podling
> releases are of sufficient quality to bear the “Apache (Incubating)” stamp.
> In my view, all IPMC members have a duty to help with that gatekeeping
> role. If they don’t, the extra burden falls on other IPMC members, and
> podlings have a crappy experience.
>
> I don’t think two votes per year is too much to ask. If you’re not up to
> it, resign from the IPMC.
>
> Julian
>
>
>
> > On Apr 22, 2017, at 10:15 AM, Joe Schaefer  wrote:
> >
> > The traditional response to this issue is to grow the ipmc to incorporate
> > more podling committers.
> >
> > On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:
> >
> >> I agree that lack of IPMC votes is a problem. I don’t think that
> lowering
> >> the bar to making a release is the solution.
> >>
> >> I wish that each IPMC member would personally commit to voting on two
> >> release candidates per year. There are so many members of the IPMC that
> >> this would easily cover all of the votes that come up.
> >>
> >> Julian
> >>
> >>
> >>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> >>>
> >>> Probably the wrong place for this but…
> >>>
> >>> What do people think about a governance change for approving releases
> >> through the IPMC to wit:
> >>>
> >>> A week of no vote activity over the release proposal of a podling
> should
> >> be considered a passing vote. In other words the IPMC is to become a
> >> vetoing group.
> >>>
> >>> I propose this for 2 reasons: 1) lack of votes or attention from the
> >> IPMC seems all too prevalent and puts an undo drag on the energy and
> >> velocity of community involvement. 2) the release has already been
> voted on
> >> and checked by at least 3 PMC members of the podling (which has ASF
> mentors
> >> in most all cases) so a veto role by the IPMC seems to have minimum
> danger
> >> to the ASF system of checks and balances.
> >>>
> >>>
> >>>
> >>>
> >>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> >>>
> >>> +1 non-binding
> >>>
> >>> Next release we could exclude the doc site. Do build files like .sbt
> >> require licenses? I suppose it can be done in comments. But again can we
> >> push to next release
> >>>
> >>> Can other binding voters have a look? I know everyone is busy but hey,
> >> tax day is past ;-)
> >>>
> >>>
> >>> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> >>>
> >>> Hi Luciano,
> >>>
> >>> Thanks for your review. I will file JIRAs regarding these files. They
> are
> >>> project build files and documentation.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende  >
> >>> wrote:
> >>>
>  On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> >> wrote:
> 
> > Hi all,
> >
> > The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
>  good
> > for a source-only release. This thread is to facilitate a voting for
> >> the
> > IPMC before a final official source-only release.
> >
> > Vote result on dev@:
> > https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> > 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >
> > The original vote thread on dev@:
> > https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> > 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >
> > The release candidate Git commit is:
> > e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >
> > The release candidate Git tag is:
> > v0.11.0-incubating-rc2
> >
> > The source-only release candidate artifacts can be downloaded here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> > incubating-rc2/
> >
> > Test results of RC2 can be found here:
> > https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >
> > Build instructions 

Re: Incubator Governance Change

[Pat Ferrel]

While I agree, asking is not enforcing. This would add enforcement that would 
allow the IPMC to function but have an enforceable clause that also does not 
allow it to roadblock by neglect.

Plus about 1/2 the reason I bring this up is trying to get more votes on 
PredictionIO :-)


On Apr 22, 2017, at 10:41 AM, Julian Hyde  wrote:

Growing the IPMC is of no use if the members don’t show up and vote. 

The IPMC performs an important gatekeeper role, ensuring that podling releases 
are of sufficient quality to bear the “Apache (Incubating)” stamp. In my view, 
all IPMC members have a duty to help with that gatekeeping role. If they don’t, 
the extra burden falls on other IPMC members, and podlings have a crappy 
experience.

I don’t think two votes per year is too much to ask. If you’re not up to it, 
resign from the IPMC.

Julian



> On Apr 22, 2017, at 10:15 AM, Joe Schaefer  wrote:
> 
> The traditional response to this issue is to grow the ipmc to incorporate
> more podling committers.
> 
> On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:
> 
>> I agree that lack of IPMC votes is a problem. I don’t think that lowering
>> the bar to making a release is the solution.
>> 
>> I wish that each IPMC member would personally commit to voting on two
>> release candidates per year. There are so many members of the IPMC that
>> this would easily cover all of the votes that come up.
>> 
>> Julian
>> 
>> 
>>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
>>> 
>>> Probably the wrong place for this but…
>>> 
>>> What do people think about a governance change for approving releases
>> through the IPMC to wit:
>>> 
>>> A week of no vote activity over the release proposal of a podling should
>> be considered a passing vote. In other words the IPMC is to become a
>> vetoing group.
>>> 
>>> I propose this for 2 reasons: 1) lack of votes or attention from the
>> IPMC seems all too prevalent and puts an undo drag on the energy and
>> velocity of community involvement. 2) the release has already been voted on
>> and checked by at least 3 PMC members of the podling (which has ASF mentors
>> in most all cases) so a veto role by the IPMC seems to have minimum danger
>> to the ASF system of checks and balances.
>>> 
>>> 
>>> 
>>> 
>>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
>>> 
>>> +1 non-binding
>>> 
>>> Next release we could exclude the doc site. Do build files like .sbt
>> require licenses? I suppose it can be done in comments. But again can we
>> push to next release
>>> 
>>> Can other binding voters have a look? I know everyone is busy but hey,
>> tax day is past ;-)
>>> 
>>> 
>>> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
>>> 
>>> Hi Luciano,
>>> 
>>> Thanks for your review. I will file JIRAs regarding these files. They are
>>> project build files and documentation.
>>> 
>>> Regards,
>>> Donald
>>> 
>>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
>>> wrote:
>>> 
 On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
>> wrote:
 
> Hi all,
> 
> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
 good
> for a source-only release. This thread is to facilitate a voting for
>> the
> IPMC before a final official source-only release.
> 
> Vote result on dev@:
> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> 
> The original vote thread on dev@:
> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> 
> The release candidate Git commit is:
> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> 
> The release candidate Git tag is:
> v0.11.0-incubating-rc2
> 
> The source-only release candidate artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> incubating-rc2/
> 
> Test results of RC2 can be found here:
> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> 
> Build instructions of previous versions can be used on this RC:
> http://predictionio.incubator.apache.org/install/install-sourcecode/
> 
> Maven artifacts are built from the release candidate artifacts above,
>> and
> are provided as convenience for testing with PredictionIO engine
 templates.
> The Maven artifacts are provided at the Maven staging repo here:
> https://repository.apache.org/content/repositories/
> orgapachepredictionio-1016/
> 
> All JIRAs completed for this release are tagged with 'FixVersion =
> 0.11.0-incubating'. You can view them here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12320420=12338381
> 
> The artifacts have been 

Re: Incubator Governance Change

[Joe Schaefer]

Incorrect.  These people I'm talking about are already voting on (their
own) releases, we just fail to count their votes as binding because we are
anally retentitive about our own status.

On Sat, Apr 22, 2017 at 1:41 PM Julian Hyde  wrote:

> Growing the IPMC is of no use if the members don’t show up and vote.
>
> The IPMC performs an important gatekeeper role, ensuring that podling
> releases are of sufficient quality to bear the “Apache (Incubating)” stamp.
> In my view, all IPMC members have a duty to help with that gatekeeping
> role. If they don’t, the extra burden falls on other IPMC members, and
> podlings have a crappy experience.
>
> I don’t think two votes per year is too much to ask. If you’re not up to
> it, resign from the IPMC.
>
> Julian
>
>
>
> > On Apr 22, 2017, at 10:15 AM, Joe Schaefer  wrote:
> >
> > The traditional response to this issue is to grow the ipmc to incorporate
> > more podling committers.
> >
> > On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:
> >
> >> I agree that lack of IPMC votes is a problem. I don’t think that
> lowering
> >> the bar to making a release is the solution.
> >>
> >> I wish that each IPMC member would personally commit to voting on two
> >> release candidates per year. There are so many members of the IPMC that
> >> this would easily cover all of the votes that come up.
> >>
> >> Julian
> >>
> >>
> >>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> >>>
> >>> Probably the wrong place for this but…
> >>>
> >>> What do people think about a governance change for approving releases
> >> through the IPMC to wit:
> >>>
> >>> A week of no vote activity over the release proposal of a podling
> should
> >> be considered a passing vote. In other words the IPMC is to become a
> >> vetoing group.
> >>>
> >>> I propose this for 2 reasons: 1) lack of votes or attention from the
> >> IPMC seems all too prevalent and puts an undo drag on the energy and
> >> velocity of community involvement. 2) the release has already been
> voted on
> >> and checked by at least 3 PMC members of the podling (which has ASF
> mentors
> >> in most all cases) so a veto role by the IPMC seems to have minimum
> danger
> >> to the ASF system of checks and balances.
> >>>
> >>>
> >>>
> >>>
> >>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> >>>
> >>> +1 non-binding
> >>>
> >>> Next release we could exclude the doc site. Do build files like .sbt
> >> require licenses? I suppose it can be done in comments. But again can we
> >> push to next release
> >>>
> >>> Can other binding voters have a look? I know everyone is busy but hey,
> >> tax day is past ;-)
> >>>
> >>>
> >>> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> >>>
> >>> Hi Luciano,
> >>>
> >>> Thanks for your review. I will file JIRAs regarding these files. They
> are
> >>> project build files and documentation.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende  >
> >>> wrote:
> >>>
>  On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> >> wrote:
> 
> > Hi all,
> >
> > The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
>  good
> > for a source-only release. This thread is to facilitate a voting for
> >> the
> > IPMC before a final official source-only release.
> >
> > Vote result on dev@:
> > https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> > 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >
> > The original vote thread on dev@:
> > https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> > 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >
> > The release candidate Git commit is:
> > e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >
> > The release candidate Git tag is:
> > v0.11.0-incubating-rc2
> >
> > The source-only release candidate artifacts can be downloaded here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> > incubating-rc2/
> >
> > Test results of RC2 can be found here:
> > https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >
> > Build instructions of previous versions can be used on this RC:
> > http://predictionio.incubator.apache.org/install/install-sourcecode/
> >
> > Maven artifacts are built from the release candidate artifacts above,
> >> and
> > are provided as convenience for testing with PredictionIO engine
>  templates.
> > The Maven artifacts are provided at the Maven staging repo here:
> > https://repository.apache.org/content/repositories/
> > orgapachepredictionio-1016/
> >
> > All JIRAs completed for this release are tagged with 'FixVersion =
> > 0.11.0-incubating'. You can view them here:
> > 

Re: Incubator Governance Change

[Julian Hyde]

Growing the IPMC is of no use if the members don’t show up and vote. 

The IPMC performs an important gatekeeper role, ensuring that podling releases 
are of sufficient quality to bear the “Apache (Incubating)” stamp. In my view, 
all IPMC members have a duty to help with that gatekeeping role. If they don’t, 
the extra burden falls on other IPMC members, and podlings have a crappy 
experience.

I don’t think two votes per year is too much to ask. If you’re not up to it, 
resign from the IPMC.

Julian



> On Apr 22, 2017, at 10:15 AM, Joe Schaefer  wrote:
> 
> The traditional response to this issue is to grow the ipmc to incorporate
> more podling committers.
> 
> On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:
> 
>> I agree that lack of IPMC votes is a problem. I don’t think that lowering
>> the bar to making a release is the solution.
>> 
>> I wish that each IPMC member would personally commit to voting on two
>> release candidates per year. There are so many members of the IPMC that
>> this would easily cover all of the votes that come up.
>> 
>> Julian
>> 
>> 
>>> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
>>> 
>>> Probably the wrong place for this but…
>>> 
>>> What do people think about a governance change for approving releases
>> through the IPMC to wit:
>>> 
>>> A week of no vote activity over the release proposal of a podling should
>> be considered a passing vote. In other words the IPMC is to become a
>> vetoing group.
>>> 
>>> I propose this for 2 reasons: 1) lack of votes or attention from the
>> IPMC seems all too prevalent and puts an undo drag on the energy and
>> velocity of community involvement. 2) the release has already been voted on
>> and checked by at least 3 PMC members of the podling (which has ASF mentors
>> in most all cases) so a veto role by the IPMC seems to have minimum danger
>> to the ASF system of checks and balances.
>>> 
>>> 
>>> 
>>> 
>>> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
>>> 
>>> +1 non-binding
>>> 
>>> Next release we could exclude the doc site. Do build files like .sbt
>> require licenses? I suppose it can be done in comments. But again can we
>> push to next release
>>> 
>>> Can other binding voters have a look? I know everyone is busy but hey,
>> tax day is past ;-)
>>> 
>>> 
>>> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
>>> 
>>> Hi Luciano,
>>> 
>>> Thanks for your review. I will file JIRAs regarding these files. They are
>>> project build files and documentation.
>>> 
>>> Regards,
>>> Donald
>>> 
>>> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
>>> wrote:
>>> 
 On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
>> wrote:
 
> Hi all,
> 
> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
 good
> for a source-only release. This thread is to facilitate a voting for
>> the
> IPMC before a final official source-only release.
> 
> Vote result on dev@:
> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> 
> The original vote thread on dev@:
> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> 
> The release candidate Git commit is:
> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> 
> The release candidate Git tag is:
> v0.11.0-incubating-rc2
> 
> The source-only release candidate artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> incubating-rc2/
> 
> Test results of RC2 can be found here:
> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> 
> Build instructions of previous versions can be used on this RC:
> http://predictionio.incubator.apache.org/install/install-sourcecode/
> 
> Maven artifacts are built from the release candidate artifacts above,
>> and
> are provided as convenience for testing with PredictionIO engine
 templates.
> The Maven artifacts are provided at the Maven staging repo here:
> https://repository.apache.org/content/repositories/
> orgapachepredictionio-1016/
> 
> All JIRAs completed for this release are tagged with 'FixVersion =
> 0.11.0-incubating'. You can view them here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12320420=12338381
> 
> The artifacts have been signed with Key : 8BF4ABEB
> 
> Please vote accordingly:
> 
> [ ] +1, accept RC as the official 0.11.0 release
> [ ] 0, neutral because...
> [ ] -1, do not accept RC as the official 0.11.0 release because...
> 
> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
> 
> Regards,
> Donald
> 

Re: Incubator Governance Change

[Pat Ferrel]

That works if human nature is not involved and would still produce the same 
affect so I’d second your request in any case. 

However human nature is involved and my proposal would at least guarantee that 
human nature could not hold innocent projects hostage. BTW notice the include 
vote request, now over a week in with no binding up or down votes. 


On Apr 22, 2017, at 10:02 AM, Julian Hyde  wrote:

I agree that lack of IPMC votes is a problem. I don’t think that lowering the 
bar to making a release is the solution.

I wish that each IPMC member would personally commit to voting on two release 
candidates per year. There are so many members of the IPMC that this would 
easily cover all of the votes that come up.

Julian


> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> 
> Probably the wrong place for this but…
> 
> What do people think about a governance change for approving releases through 
> the IPMC to wit:
> 
> A week of no vote activity over the release proposal of a podling should be 
> considered a passing vote. In other words the IPMC is to become a vetoing 
> group.
> 
> I propose this for 2 reasons: 1) lack of votes or attention from the IPMC 
> seems all too prevalent and puts an undo drag on the energy and velocity of 
> community involvement. 2) the release has already been voted on and checked 
> by at least 3 PMC members of the podling (which has ASF mentors in most all 
> cases) so a veto role by the IPMC seems to have minimum danger to the ASF 
> system of checks and balances.
> 
> 
> 
> 
> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> 
> +1 non-binding
> 
> Next release we could exclude the doc site. Do build files like .sbt require 
> licenses? I suppose it can be done in comments. But again can we push to next 
> release
> 
> Can other binding voters have a look? I know everyone is busy but hey, tax 
> day is past ;-)
> 
> 
> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> 
> Hi Luciano,
> 
> Thanks for your review. I will file JIRAs regarding these files. They are
> project build files and documentation.
> 
> Regards,
> Donald
> 
> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> wrote:
> 
>> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto  wrote:
>> 
>>> Hi all,
>>> 
>>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
>> good
>>> for a source-only release. This thread is to facilitate a voting for the
>>> IPMC before a final official source-only release.
>>> 
>>> Vote result on dev@:
>>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
>>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
>>> 
>>> The original vote thread on dev@:
>>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
>>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
>>> 
>>> The release candidate Git commit is:
>>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
>>> 
>>> The release candidate Git tag is:
>>> v0.11.0-incubating-rc2
>>> 
>>> The source-only release candidate artifacts can be downloaded here:
>>> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
>>> incubating-rc2/
>>> 
>>> Test results of RC2 can be found here:
>>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
>>> 
>>> Build instructions of previous versions can be used on this RC:
>>> http://predictionio.incubator.apache.org/install/install-sourcecode/
>>> 
>>> Maven artifacts are built from the release candidate artifacts above, and
>>> are provided as convenience for testing with PredictionIO engine
>> templates.
>>> The Maven artifacts are provided at the Maven staging repo here:
>>> https://repository.apache.org/content/repositories/
>>> orgapachepredictionio-1016/
>>> 
>>> All JIRAs completed for this release are tagged with 'FixVersion =
>>> 0.11.0-incubating'. You can view them here:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> projectId=12320420=12338381
>>> 
>>> The artifacts have been signed with Key : 8BF4ABEB
>>> 
>>> Please vote accordingly:
>>> 
>>> [ ] +1, accept RC as the official 0.11.0 release
>>> [ ] 0, neutral because...
>>> [ ] -1, do not accept RC as the official 0.11.0 release because...
>>> 
>>> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
>>> 
>>> Regards,
>>> Donald
>>> 
>> 
>> 
>> I was running RAT on the source distribution and there are a lot of unknown
>> licenses, some might be ok, but many are not, such as:
>> 
>> *.sbt in projects and sub-projects
>> *.css in docs
>> 
>> Other things like signatures, etc seems ok
>> 
>> 
>> 
>> --
>> Luciano Resende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 

Re: Incubator Governance Change

[Joe Schaefer]

The traditional response to this issue is to grow the ipmc to incorporate
more podling committers.

On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde  wrote:

> I agree that lack of IPMC votes is a problem. I don’t think that lowering
> the bar to making a release is the solution.
>
> I wish that each IPMC member would personally commit to voting on two
> release candidates per year. There are so many members of the IPMC that
> this would easily cover all of the votes that come up.
>
> Julian
>
>
> > On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> >
> > Probably the wrong place for this but…
> >
> > What do people think about a governance change for approving releases
> through the IPMC to wit:
> >
> > A week of no vote activity over the release proposal of a podling should
> be considered a passing vote. In other words the IPMC is to become a
> vetoing group.
> >
> > I propose this for 2 reasons: 1) lack of votes or attention from the
> IPMC seems all too prevalent and puts an undo drag on the energy and
> velocity of community involvement. 2) the release has already been voted on
> and checked by at least 3 PMC members of the podling (which has ASF mentors
> in most all cases) so a veto role by the IPMC seems to have minimum danger
> to the ASF system of checks and balances.
> >
> >
> >
> >
> > On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> >
> > +1 non-binding
> >
> > Next release we could exclude the doc site. Do build files like .sbt
> require licenses? I suppose it can be done in comments. But again can we
> push to next release
> >
> > Can other binding voters have a look? I know everyone is busy but hey,
> tax day is past ;-)
> >
> >
> > On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> >
> > Hi Luciano,
> >
> > Thanks for your review. I will file JIRAs regarding these files. They are
> > project build files and documentation.
> >
> > Regards,
> > Donald
> >
> > On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> > wrote:
> >
> >> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
> >> good
> >>> for a source-only release. This thread is to facilitate a voting for
> the
> >>> IPMC before a final official source-only release.
> >>>
> >>> Vote result on dev@:
> >>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> >>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The original vote thread on dev@:
> >>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> >>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
> >>>
> >>> The release candidate Git commit is:
> >>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
> >>>
> >>> The release candidate Git tag is:
> >>> v0.11.0-incubating-rc2
> >>>
> >>> The source-only release candidate artifacts can be downloaded here:
> >>> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> >>> incubating-rc2/
> >>>
> >>> Test results of RC2 can be found here:
> >>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
> >>>
> >>> Build instructions of previous versions can be used on this RC:
> >>> http://predictionio.incubator.apache.org/install/install-sourcecode/
> >>>
> >>> Maven artifacts are built from the release candidate artifacts above,
> and
> >>> are provided as convenience for testing with PredictionIO engine
> >> templates.
> >>> The Maven artifacts are provided at the Maven staging repo here:
> >>> https://repository.apache.org/content/repositories/
> >>> orgapachepredictionio-1016/
> >>>
> >>> All JIRAs completed for this release are tagged with 'FixVersion =
> >>> 0.11.0-incubating'. You can view them here:
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> projectId=12320420=12338381
> >>>
> >>> The artifacts have been signed with Key : 8BF4ABEB
> >>>
> >>> Please vote accordingly:
> >>>
> >>> [ ] +1, accept RC as the official 0.11.0 release
> >>> [ ] 0, neutral because...
> >>> [ ] -1, do not accept RC as the official 0.11.0 release because...
> >>>
> >>> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
> >>>
> >>> Regards,
> >>> Donald
> >>>
> >>
> >>
> >> I was running RAT on the source distribution and there are a lot of
> unknown
> >> licenses, some might be ok, but many are not, such as:
> >>
> >> *.sbt in projects and sub-projects
> >> *.css in docs
> >>
> >> Other things like signatures, etc seems ok
> >>
> >>
> >>
> >> --
> >> Luciano Resende
> >> http://twitter.com/lresende1975
> >> http://lresende.blogspot.com/
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> 

Re: Incubator Governance Change

[Julian Hyde]

I agree that lack of IPMC votes is a problem. I don’t think that lowering the 
bar to making a release is the solution.

I wish that each IPMC member would personally commit to voting on two release 
candidates per year. There are so many members of the IPMC that this would 
easily cover all of the votes that come up.

Julian


> On Apr 22, 2017, at 8:46 AM, Pat Ferrel  wrote:
> 
> Probably the wrong place for this but…
> 
> What do people think about a governance change for approving releases through 
> the IPMC to wit:
> 
> A week of no vote activity over the release proposal of a podling should be 
> considered a passing vote. In other words the IPMC is to become a vetoing 
> group.
> 
> I propose this for 2 reasons: 1) lack of votes or attention from the IPMC 
> seems all too prevalent and puts an undo drag on the energy and velocity of 
> community involvement. 2) the release has already been voted on and checked 
> by at least 3 PMC members of the podling (which has ASF mentors in most all 
> cases) so a veto role by the IPMC seems to have minimum danger to the ASF 
> system of checks and balances.
> 
> 
> 
> 
> On Apr 19, 2017, at 9:33 AM, Pat Ferrel  wrote:
> 
> +1 non-binding
> 
> Next release we could exclude the doc site. Do build files like .sbt require 
> licenses? I suppose it can be done in comments. But again can we push to next 
> release
> 
> Can other binding voters have a look? I know everyone is busy but hey, tax 
> day is past ;-)
> 
> 
> On Apr 18, 2017, at 1:00 PM, Donald Szeto  wrote:
> 
> Hi Luciano,
> 
> Thanks for your review. I will file JIRAs regarding these files. They are
> project build files and documentation.
> 
> Regards,
> Donald
> 
> On Mon, Apr 17, 2017 at 1:29 PM, Luciano Resende 
> wrote:
> 
>> On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto  wrote:
>> 
>>> Hi all,
>>> 
>>> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be
>> good
>>> for a source-only release. This thread is to facilitate a voting for the
>>> IPMC before a final official source-only release.
>>> 
>>> Vote result on dev@:
>>> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
>>> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
>>> 
>>> The original vote thread on dev@:
>>> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
>>> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
>>> 
>>> The release candidate Git commit is:
>>> e34a853d0e89baed09b3d3b0c25b244162a3bdea
>>> 
>>> The release candidate Git tag is:
>>> v0.11.0-incubating-rc2
>>> 
>>> The source-only release candidate artifacts can be downloaded here:
>>> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
>>> incubating-rc2/
>>> 
>>> Test results of RC2 can be found here:
>>> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
>>> 
>>> Build instructions of previous versions can be used on this RC:
>>> http://predictionio.incubator.apache.org/install/install-sourcecode/
>>> 
>>> Maven artifacts are built from the release candidate artifacts above, and
>>> are provided as convenience for testing with PredictionIO engine
>> templates.
>>> The Maven artifacts are provided at the Maven staging repo here:
>>> https://repository.apache.org/content/repositories/
>>> orgapachepredictionio-1016/
>>> 
>>> All JIRAs completed for this release are tagged with 'FixVersion =
>>> 0.11.0-incubating'. You can view them here:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> projectId=12320420=12338381
>>> 
>>> The artifacts have been signed with Key : 8BF4ABEB
>>> 
>>> Please vote accordingly:
>>> 
>>> [ ] +1, accept RC as the official 0.11.0 release
>>> [ ] 0, neutral because...
>>> [ ] -1, do not accept RC as the official 0.11.0 release because...
>>> 
>>> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
>>> 
>>> Regards,
>>> Donald
>>> 
>> 
>> 
>> I was running RAT on the source distribution and there are a lot of unknown
>> licenses, some might be ok, but many are not, such as:
>> 
>> *.sbt in projects and sub-projects
>> *.css in docs
>> 
>> Other things like signatures, etc seems ok
>> 
>> 
>> 
>> --
>> Luciano Resende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>> 
> 
> 
> 
> -
> 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