Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-15 Thread Dave Fisher



> On Aug 14, 2019, at 3:59 AM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019, 22:31 David Nalley  wrote:
>> ...
> 
>> Greg - I propose that you, Ross (sorry for volunteering you), and I
>> pick an incubating project in need of mentor attention and make this
>> as streamlined as we can. Let's focus on educating and enabling and
>> not gatekeeping. Let's prove out the concept and stop beating this
>> poor horse so much. :)
>> 
> 
> This is not possible under the rules regime of the IPMC. A new PMC,
> operating under different rules, sanctioned by the Board, is required. With
> that, I am willing.

Apache Welcome? I’d join a new Incubator. Discuss at Apachecon NA?

Regards,
Dave

> 
> Cheers,
> -g


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-15 Thread Jim Jagielski
FTR: I think the biggest risk to the foundation are not these procedural 
aspects, like releases, but the gradual but inexorable decline in our culture 
and our principles. That is, or at least should be, the bigger concern. And I 
think the Incubator should take that risk much more seriously and to heart.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-15 Thread Sam Ruby
On Wed, Aug 14, 2019 at 9:47 PM Justin Mclean  wrote:
>
> Hi
>
> Thanks for the idea and offer of help.
>
> > 1) Concurrent with the start of a release vote by a PPMC, the IPMC is
> > to be notified that that vote is happening.  IPMC members are
> > encouraged to participate in the vote process on the PPMC list where
> > it is happening.
>
> This has been discussed before and I’m not sure the IPMC has the bandwidth 
> for this. Most releases go through a couple RCs, sometime that can be more. 
> This would be asking the IPMC to potentially review 3x-5x the number of 
> releases than it normally done.
>
> > 3) If the PPMC vote completes before there is a call for an IPMC vote,
> > the PPMC is free to make the release.
>
> How does fit with the requirement that 3 +1 PMC votes needed for a release? 
> Or is it doing away with it?

Sorry for being unclear.  My suggestion was that the IPMC only votes
in the exceptional case where an IPMC member requests a vote.  My
assertion is that oversight and the opportunity to intercede when
needed is sufficient.

> Thanks,
> Justin

- Sam Ruby

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-15 Thread Jim Jagielski



> On Aug 14, 2019, at 1:24 AM, Dave Fisher  wrote:
> 
>>> 
>>> Q: Does the IPMC want to produce non-ASF releases?
> 
> My answer is yes! I want podlings to be on a path towards graduation! I 
> recognize multiple requirements. The path may differ for each podling. I’m 
> the end there are two outcomes!
> 

What does it mean to be a "non-ASF release"?

To be clear: I want, when podlings do releases, that all podling members enjoy 
the legal protections inherent in doing a s/w release that all other people 
enjoy when *they* do a release. That is only possible if those releases are ASF 
releases. Heck, I would say that having protection at this stage is likely more 
important, and likely more needed, than when subversion, for example, does one.

HOWEVER, those releases are specifically noted as likely being of varying 
quality and compliance as typical ASF releases from TLP/PMCs.

So legally, they should be ASF releases. Culturally, and expectation-wise, they 
are non-typical releases.

Again, the Incubator is, or at least should be, a safe space where communities 
can learn about the Apache Way, and how to build communities and how to develop 
software and how to do releases... All of that stuff is inherently risky. 
That's what the Incubator is also there to do: assume that risk so that 
podlings can learn to the point where they can assume their own risk. This does 
not mean, however, that the Incubator should be constantly getting in the way 
of podlings, using risk-abatement as the reason for gatekeeping.


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Justin Mclean
Hi,

> That Infra and the board will allow a podling to put packages containing the 
> WIP-disclaimer on dist.a.o as long as those packages

Infra have already confirmed that’s OK, legal have said it OK with some 
conditions, including if incubator releases are considered special. There is a 
proposal in the incubator board report to do this, hopefully the board will 
accept it.

> This new disclaimer should allow mentors to allow the podlings to publish 
> packages for their users the way they probably did before entering incubation.

Not quite, but it does relax things, see [1]

>  The podlings will have the option to push the packages to dist.a.o and then, 
> if they want the legal shield protection, call for a vote from the IPMC if 
> they don't have 3 mentor votes.  

I’m not sure this should be optional, or up to the PPMC to decide, but it's an 
interesting idea to consider. Reason being is that the PPMC may not be in the 
best position (being new to the ASF) to recognise what the risk is. I’m not 
sure what the risk is or how (or if at all) it might impact on the insurance.

> The key risk here is whether the WIP disclaimer will help ward off possible 
> legal action by a user of the package.

A disclaimer ultimately is probably no protection. For instance, you can’t put 
up a sign in a shop that says “No Refunds” when you have a right to a refund 
under consumer law. But I think the intention is clear that podlings what to do 
the right thing.

>  The new disclaimer should greatly reduce the chances of a -1 vote.  Instead, 
> issues found will be logged in the podling's bug tracker.

Yep that was the whole idea.

>  Practically speaking, if Justin is one of the 3 mentors, the podiing is 
> probably in good shape heading towards graduation, of not, it probably is a 
> good idea to get Justin to review the packages at some point.

Well the objective should be learn how to review releases on their own, rather 
than rely on me to check it for you, as you’re going to have to do that as a 
TLP.

>  It was this late gate which was stricter with the old disclaimer that was 
> the problem for Zipkin.

There were a larger number of issue steer as well. (Also while in incubation 
Zipkin made non offical releases.)

Thanks,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-469

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Justin Mclean
Hi

Thanks for the idea and offer of help.

> 1) Concurrent with the start of a release vote by a PPMC, the IPMC is
> to be notified that that vote is happening.  IPMC members are
> encouraged to participate in the vote process on the PPMC list where
> it is happening.

This has been discussed before and I’m not sure the IPMC has the bandwidth for 
this. Most releases go through a couple RCs, sometime that can be more. This 
would be asking the IPMC to potentially review 3x-5x the number of releases 
than it normally done.

> 3) If the PPMC vote completes before there is a call for an IPMC vote,
> the PPMC is free to make the release.

How does fit with the requirement that 3 +1 PMC votes needed for a release? Or 
is it doing away with it?

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Alex Harui
IMO, the key change as already been made:  There is now a WIP-disclaimer.

AFAICT, the rest of this thread has been an attempt to create an objective 
process around a subjective topic (in this case risk).  The better use of time 
may be to just launch an experiment by making the one change suggested by Greg: 
 That Infra and the board will allow a podling to put packages containing the 
WIP-disclaimer on dist.a.o as long as those packages also include "-incubating" 
or "-incubator" in the package name.

IMO, if that can be agreed to by the stakeholders, those stakeholders are 
agreeing that any risks to the foundation and RMs posed by Justin are worth 
taking and we can hopefully just move on and find out what happens.

Ideally, the WIP-disclaimer makes the IPMC vote:
1) optional
2) helpful
3) advisory

...instead of "potentially blocking".

This new disclaimer should allow mentors to allow the podlings to publish 
packages for their users the way they probably did before entering incubation.  
The podlings will have the option to push the packages to dist.a.o and then, if 
they want the legal shield protection, call for a vote from the IPMC if they 
don't have 3 mentor votes.  The key risk here is whether the WIP disclaimer 
will help ward off possible legal action by a user of the package.  IOW, is it 
too risky that something really awful will be missed by the mentors and PPMC in 
these packages?  I doubt it.  There might be GPL or proprietary code that needs 
to be replaced eventually.  But the new disclaimer helps and I just think folks 
aren't going to try to sue the ASF or a podling RM during this transition 
period.

If a podling is lucky enough to have 3 mentors review the packages, then that 
should make those packages an official ASF release and thus protect the RM.  If 
there aren't 3 mentors reviewing the packages, then the podling will have a 
reason to call for an IPMC vote to get the 3 votes.  The new disclaimer should 
greatly reduce the chances of a -1 vote.  Instead, issues found will be logged 
in the podling's bug tracker.

If the 3 mentors are certain enough of their review of the packages, then the 
podling can go on its merry way towards graduation.  Otherwise, the podling 
should call for additional IPMC reviews of their packages in order to avoid 
major surprises before graduation.  They just don't need to do it prior to 
publishing their packages, which makes the IPMC review helpful and advisory 
instead of potentially blocking.  Yeah, there is a risk that a published 
package will be so awful it needs to be pulled in spite of the new disclaimer, 
but IMO, there is always a chance we've missed something.  Practically 
speaking, if Justin is one of the 3 mentors, the podiing is probably in good 
shape heading towards graduation, of not, it probably is a good idea to get 
Justin to review the packages at some point.

IMO, it shouldn't take a special team of Greg/Ross/David to do this experiment. 
 As long as podlings can publish before the vote/review, and the new disclaimer 
makes the chance of pulling something back almost zero, every podling can 
choose this new route and the IPMC vote will rarely if ever be a gate.  It was 
this late gate which was stricter with the old disclaimer that was the problem 
for Zipkin.

HTH,
-Alex

On 8/14/19, 8:50 AM, "Sam Ruby"  wrote:

On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean  
wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on 
releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF 
people, that only PMC votes are binding on releases and podlings are not 
mentioned in the ASF bylaws. Bylaw wise see section 6.3.  But you're right, it 
would be more precise to say, it's a combination of 6.3 of the bylaws of the 
ASF and the ASF's policy on voting on releases. [1]

Concrete suggestion, and an offer to help.

The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs.  Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].

Perhaps something similar can be made to work here.  Outline of
proposed process:

1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening.  IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.

2) If anybody on the IPMC calls for a IPMC vote on the release before
the release occurs, then the release is blocked from happening until
this 

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Sam Ruby
On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean  wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF 
> people, that only PMC votes are binding on releases and podlings are not 
> mentioned in the ASF bylaws. Bylaw wise see section 6.3.  But you're right, 
> it would be more precise to say, it's a combination of 6.3 of the bylaws of 
> the ASF and the ASF's policy on voting on releases. [1]

Concrete suggestion, and an offer to help.

The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs.  Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].

Perhaps something similar can be made to work here.  Outline of
proposed process:

1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening.  IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.

2) If anybody on the IPMC calls for a IPMC vote on the release before
the release occurs, then the release is blocked from happening until
this vote completes.

3) If the PPMC vote completes before there is a call for an IPMC vote,
the PPMC is free to make the release.

If such a process were in place, then the burden on the PPMC would be
normally be reduced to a single email per release.  Any IPMC member
could still -- for any reason -- call for a full IPMC vote, but my
sense is that that rarely will happen, and when it does, it will
generally be because there is a substantive issue that needs to be
resolved.

If something like this were adopted by the IPMC, I will offer to help
update [1] to reflect that a different process applies during
incubation.

- Sam Ruby

[1] https://www.apache.org/foundation/voting.html#ReleaseVotes
[2] https://whimsy.apache.org/board/minutes/PMC_Membership_Change_Process.html

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Justin Mclean
Hi,

I’m not referring to a recent thing, I’m referring to in part to this [1]. I 
suggest you read what Mark wrote there, but even before this JIRA  many Apache 
podlings have made non-offical releases for a number of reasons some in line 
with policy (and some not). I can point you to one podling that made 100+ 
releases in this this way.

Greg if you persist in this behaviour I’ll need to refer you to the code of 
conduct, in particular you need to show a little more empathy for people who 
may not hold the same views as yourself, and it would also help if you tried to 
collaborate with other IPMC members and be more careful in the words you chose.

Thanks,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-427


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Greg Stein
On Wed, Aug 14, 2019, 06:00 Julian Feinauer 
wrote:

> Hi Greg,
>
> I think Justins Answer refers to the WIP-Disclaimer


Aware of that, but disagree. It is way more: the IPMC vote is performed to
establish legal oversight and shield. I suggest that is burdensome and
should be tossed.

PS.: Allow me to add a very personal side note. But it seems to me that the
> tone in this discussion is from time to time rather harsh.


And I add to the harsh. Yes. Guilty. ... But it makes me angry to see
misleading comments, and misdirection, away from the intent of my emails.

Cheers,
-g


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Julian Feinauer
Hi Greg,

I think Justins Answer refers to the WIP-Disclaimer which was recently added to 
the incubator Policy Page:
https://incubator.apache.org/policy/incubation.html#disclaimers

A Podlings releasing with the WIP Disclaimer is no ASF release, so I consider 
Justins response is no misdirection and I would also agree on that.

Julian

PS.: Allow me to add a very personal side note. But it seems to me that the 
tone in this discussion is from time to time rather harsh. I know that many 
people here have a long history in the ASF and with each other but it just 
doesn’t seem right that two very seasoned and well established ASF mentors 
consider that one of them straight lies on purpose on a ML, which makes me a 
bit sad : /

Am 14.08.19, 12:51 schrieb "Greg Stein" :

On Wed, Aug 14, 2019, 00:33 Justin Mclean  wrote:

> Hi,
>
> > Q: Does the IPMC want to produce non-ASF releases?
>
> A: We already are


Not true, as you well know. Whether we call the above a lie, or
misdirection is left to the reader.

The IPMC currently attempts to ensure all podling releases conform to
policy, and then/thus calls them ASF releases.

This thread is to ask about stopping that approach. That we can/should make
a business decision to accept the moot risk of placing podling releases on
our distribution servers.

-g




Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Greg Stein
On Mon, Aug 12, 2019, 22:31 David Nalley  wrote:
>...

> Greg - I propose that you, Ross (sorry for volunteering you), and I
> pick an incubating project in need of mentor attention and make this
> as streamlined as we can. Let's focus on educating and enabling and
> not gatekeeping. Let's prove out the concept and stop beating this
> poor horse so much. :)
>

This is not possible under the rules regime of the IPMC. A new PMC,
operating under different rules, sanctioned by the Board, is required. With
that, I am willing.

Cheers,
-g


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-14 Thread Greg Stein
On Wed, Aug 14, 2019, 00:33 Justin Mclean  wrote:

> Hi,
>
> > Q: Does the IPMC want to produce non-ASF releases?
>
> A: We already are


Not true, as you well know. Whether we call the above a lie, or
misdirection is left to the reader.

The IPMC currently attempts to ensure all podling releases conform to
policy, and then/thus calls them ASF releases.

This thread is to ask about stopping that approach. That we can/should make
a business decision to accept the moot risk of placing podling releases on
our distribution servers.

-g


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

> Q: Does the IPMC want to produce non-ASF releases?

A: We already are, but there are some constraints around what to calling them, 
branding and when they can be placed. (And these are not IPMC policies.)

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

>> This is because of ASF bylaws i.e only PMC votes are binding on releases.
> 
> That is not in the Bylaws. Stop making stuff up.

That the way it’s been explained to me, several times, by experienced ASF 
people, that only PMC votes are binding on releases and podlings are not 
mentioned in the ASF bylaws. Bylaw wise see section 6.3.  But you're right, it 
would be more precise to say, it's a combination of 6.3 of the bylaws of the 
ASF and the ASF's policy on voting on releases. [1]

> That is the origin of this thread, because you only ever pose
> hypotheticals. You only pose "could" possibilities. But you *never* move
> things to conclusion.

I’ve done far more than just propose possibilities. If that is not evident on 
this list I suggest you read the last dozen incubator board reports for 
evidence. Is it just that’s the conclusion is not what you want or is it that 
it moving slower than you would like? Consensus in the IPMC is sometimes hard 
to reach, but don’t you think is worth trying to do that and engage in 
dialogue, rather than talking what seems on face value to me a rather combative 
position?

Thanks,
Justin

1. https://www.apache.org/foundation/voting.html#ReleaseVotes


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Dave Fisher
>> 
>> Q: Does the IPMC want to produce non-ASF releases?

My answer is yes! I want podlings to be on a path towards graduation! I 
recognize multiple requirements. The path may differ for each podling. I’m the 
end there are two outcomes!

Thanks Greg!

Regards,
Dave

>> 
>> -g
> 
> 
> -
> 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Dave Fisher



Sent from my iPhone

> On Aug 13, 2019, at 9:32 PM, Greg Stein  wrote:
> 
> On Tue, Aug 13, 2019 at 8:17 PM Justin Mclean 
> wrote:
> 
>> Hi,
>> 
>>> Hoops constructed by the IPMC. Like a secondary release vote on general@
>> 
>> This is because of ASF bylaws i.e only PMC votes are binding on releases.
> 
> 
> That is not in the Bylaws. Stop making stuff up.
> 
> 
>> So you're saying implementations of ASF bylaws are "arbitrarily defined
>> hoops”?
> 
> 
> See above.
> 
> 
>> There could be other ways of dealing with this bylaw that have been
>> suggested,
> 
> 
> What bylaw? Got a reference?
> 
> 
>> for example treating podling releases not as official Apache releases.
> 
> 
> That is the origin of this thread, because you only ever pose
> hypotheticals. You only pose "could" possibilities. But you *never* move
> things to conclusion. So this thread is an attempt to do so.
> 
> Your "could" emails on this thread is antithetical to its origin.
> 
> 
>> But that also has implications and concerns, which I’m not seeing being
>> addressed in this discussion.
>> 
> 
> Then help drive it, rather than take a back seat. Drive a decision.
> 
> Q: Does the IPMC want to produce non-ASF releases?
> 
> -g


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Greg Stein
On Tue, Aug 13, 2019 at 8:17 PM Justin Mclean 
wrote:

> Hi,
>
> > Hoops constructed by the IPMC. Like a secondary release vote on general@
>
> This is because of ASF bylaws i.e only PMC votes are binding on releases.


That is not in the Bylaws. Stop making stuff up.


> So you're saying implementations of ASF bylaws are "arbitrarily defined
> hoops”?


See above.


> There could be other ways of dealing with this bylaw that have been
> suggested,


What bylaw? Got a reference?


> for example treating podling releases not as official Apache releases.


That is the origin of this thread, because you only ever pose
hypotheticals. You only pose "could" possibilities. But you *never* move
things to conclusion. So this thread is an attempt to do so.

Your "could" emails on this thread is antithetical to its origin.


> But that also has implications and concerns, which I’m not seeing being
> addressed in this discussion.
>

Then help drive it, rather than take a back seat. Drive a decision.

Q: Does the IPMC want to produce non-ASF releases?

-g


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

As an aside for any project looking for mentors you can see what projects they 
mentor at teh bottom of this page:
https://incubator.apache.org/clutch/

And you can also check if they have been signing off reports here (if you are 
an ASF member or IPMC member):
https://whimsy.apache.org/incubator/signoff.cgi

Thanks,
Justin


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Ted Dunning
A vanity mentor is a person with a big name and a small amount of time.

Projects go for the name, the mentor goes for the ego boost and then
reality catches up. But, hey, you are "mentoring" 12 projects!



On Tue, Aug 13, 2019 at 5:18 PM David Jencks 
wrote:

> What’s a “vanity mentor“? How do I recognize one before a podling has a
> significant history? Who is currently accepting these vanity mentors and
> how would they stop doing so?
>
> Hindsight is 20-20... I have no crystal ball.
>
> David Jencks
>
> Sent from my iPhone
>
> > On Aug 13, 2019, at 5:10 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> Here's an idea... The IPMC focuses on supporting mentors to do their
> job rather than forcing project developers and their mentors to jump
> through arbitrarily defined hoops.
> >
> > What "arbitrarily defined hoops” are you referring to? ASF policy or
> something else?
> >
> >> The IPMC doesn't need to enforce policy of any kind, except at the
> point of graduation.
> >
> > That seems less than ideal to me, why would a IPMC volunteer want to do
> that job? And again IMO it introduces a hard gate that podlings are going
> to dislike, probably more so than they do now.
> >
> >> When things change for individuals and they can no longer be good
> mentors then the IPMC  needs to make it a priority to help find a new,
> truly dedicated mentor. It's a problem that needs to be solved, but let's
> worry about that when it's actually a problem rather than a hypothetical
> one.
> >
> > It’s currently a problem, not a hypothetical, see for instance votes
> coming to this list without 3 mentors +1 votes, or the missing reports or
> missing sign-offs on the current incubator report to the board. This
> problem isn’t going unrecognised either, you’ll also note that recently
> nearly every month new mentors have been found and added to podlings that
> need them.
> >
> > Thanks,
> > Justin
> >
> >
> >
> > -
> > 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

> They are gated day by day by day. Empirically, we already know the podlings
> dislike this.

Empirically? I would say it’s more anecdotally, (and the anonymous podling 
survey has actually never brought this up as an issue), and “day by day by day” 
is an exaggeration. Other than the occasional -1 on a release (which is not a 
veto) how else does the IPMC gate podlings other than at graduation? We could 
ask all of the current podlings in a more formal way and see what they do think 
which might be helpful? And/or as was also suggested try this out with a couple 
of podlings as an experiment and see what happens. Perhaps a first step is to 
ask for a podling/mentors to volunteer for this?

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

> Hoops constructed by the IPMC. Like a secondary release vote on general@

This is because of ASF bylaws i.e only PMC votes are binding on releases. So 
you're saying implementations of ASF bylaws are "arbitrarily defined hoops”? 
There could be other ways of dealing with this bylaw that have been suggested, 
for example treating podling releases not as official Apache releases. But that 
also has implications and concerns, which I’m not seeing being addressed in 
this discussion.

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Greg Stein
On Tue, Aug 13, 2019 at 7:10 PM Justin Mclean 
wrote:

> Hi,
>
> > Here's an idea... The IPMC focuses on supporting mentors to do their job
> rather than forcing project developers and their mentors to jump through
> arbitrarily defined hoops.
>
> What "arbitrarily defined hoops” are you referring to? ASF policy or
> something else?
>

Hoops constructed by the IPMC. Like a secondary release vote on general@


> >  The IPMC doesn't need to enforce policy of any kind, except at the
> point of graduation.
>
> That seems less than ideal to me, why would a IPMC volunteer want to do
> that job? And again IMO it introduces a hard gate that podlings are going
> to dislike, probably more so than they do now.
>

They are gated day by day by day. Empirically, we already know the podlings
dislike this.

Let the podlings do their work. And say "nope. can't graduate now." ...
until they can.

>...

Cheers,
-g


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread David Jencks
What’s a “vanity mentor“? How do I recognize one before a podling has a 
significant history? Who is currently accepting these vanity mentors and how 
would they stop doing so?

Hindsight is 20-20... I have no crystal ball.

David Jencks 

Sent from my iPhone

> On Aug 13, 2019, at 5:10 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Here's an idea... The IPMC focuses on supporting mentors to do their job 
>> rather than forcing project developers and their mentors to jump through 
>> arbitrarily defined hoops.
> 
> What "arbitrarily defined hoops” are you referring to? ASF policy or 
> something else?
> 
>> The IPMC doesn't need to enforce policy of any kind, except at the point of 
>> graduation. 
> 
> That seems less than ideal to me, why would a IPMC volunteer want to do that 
> job? And again IMO it introduces a hard gate that podlings are going to 
> dislike, probably more so than they do now.
> 
>> When things change for individuals and they can no longer be good mentors 
>> then the IPMC  needs to make it a priority to help find a new, truly 
>> dedicated mentor. It's a problem that needs to be solved, but let's worry 
>> about that when it's actually a problem rather than a hypothetical one.
> 
> It’s currently a problem, not a hypothetical, see for instance votes coming 
> to this list without 3 mentors +1 votes, or the missing reports or missing 
> sign-offs on the current incubator report to the board. This problem isn’t 
> going unrecognised either, you’ll also note that recently nearly every month 
> new mentors have been found and added to podlings that need them.
> 
> Thanks,
> Justin
> 
> 
> 
> -
> 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

> Here's an idea... The IPMC focuses on supporting mentors to do their job 
> rather than forcing project developers and their mentors to jump through 
> arbitrarily defined hoops.

What "arbitrarily defined hoops” are you referring to? ASF policy or something 
else?

>  The IPMC doesn't need to enforce policy of any kind, except at the point of 
> graduation. 

That seems less than ideal to me, why would a IPMC volunteer want to do that 
job? And again IMO it introduces a hard gate that podlings are going to 
dislike, probably more so than they do now.

> When things change for individuals and they can no longer be good mentors 
> then the IPMC  needs to make it a priority to help find a new, truly 
> dedicated mentor. It's a problem that needs to be solved, but let's worry 
> about that when it's actually a problem rather than a hypothetical one.

It’s currently a problem, not a hypothetical, see for instance votes coming to 
this list without 3 mentors +1 votes, or the missing reports or missing 
sign-offs on the current incubator report to the board. This problem isn’t 
going unrecognised either, you’ll also note that recently nearly every month 
new mentors have been found and added to podlings that need them.

Thanks,
Justin



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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Ross Gardler
Here's an idea... The IPMC focuses on supporting mentors to do their job rather 
than forcing project developers and their mentors to jump through arbitrarily 
defined hoops.

That means stay out of the way until the mentor asks for a graduation vote. The 
IPMC doesn't need to enforce policy of any kind, except at the point of 
graduation. Policy is set and enforced by VP Legal, infra marketing, trademarks 
etc. The mentor can work directly with them as necessary.

I know holding mentors accountable is a tough job in itself, but if we quit 
accepting vanity mentors and instead focus on supporting mentors who have a 
personal interest in the success of the podling it shouldn't be too hard.

When things change for individuals and they can no longer be good mentors then 
the IPMC  needs to make it a priority to help find a new, truly dedicated 
mentor. It's a problem that needs to be solved, but let's worry about that when 
it's actually a problem rather than a hypothetical one.

Ross

---

Sent from my phone, you know what that means - sorry


From: Justin Mclean 
Sent: Tuesday, August 13, 2019 3:04:46 PM
To: general@incubator.apache.org 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

Hi,

> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
> the podling is fully compliant with Apache Release Policy and goes through 
> the usual process. Abiding by the Apache Release Policy would remain a 
> Graduation Requirement.

I’ll note not a single podling has asked for a [REVIEW].

> So, we treat these releases as not fully approved the same way we treat 
> Binary Conveniences.

They are not the same as binary conveniences, as they are derived from a voted 
on approved release. Thinking about (F) if they are not official releases could 
a podling:
a) Call them Apache releases? (Not doing may have a number of implications 
including naming of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what 
would be required to make it clear they are not approved releases?

We might want to check with branding and legal and get their input on this.

My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at 
the releases or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a 
community proposed graduation and it found it’s releases have serious issue?

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Justin Mclean
Hi,

> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
> the podling is fully compliant with Apache Release Policy and goes through 
> the usual process. Abiding by the Apache Release Policy would remain a 
> Graduation Requirement.

I’ll note not a single podling has asked for a [REVIEW].

> So, we treat these releases as not fully approved the same way we treat 
> Binary Conveniences.

They are not the same as binary conveniences, as they are derived from a voted 
on approved release. Thinking about (F) if they are not official releases could 
a podling:
a) Call them Apache releases? (Not doing may have a number of implications 
including naming of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what 
would be required to make it clear they are not approved releases?

We might want to check with branding and legal and get their input on this.

My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at 
the releases or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a 
community proposed graduation and it found it’s releases have serious issue?

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Ross Gardler
I see I was volunteer... OK let's do it.

---

Sent from my phone, you know what that means - sorry


From: David Nalley 
Sent: Monday, August 12, 2019 8:31:29 PM
To: general@incubator.apache.org 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

>
> I'd like to see the IPMC get out of the way of the podlings' releases. I
> see no reason for us to be a gate, and many more reasons to back off and
> let podlings get their work done.
>

I strongly agree with your sentiment, even if I differ with your tactics a bit.

I think that they are releases (e.g. we the foundation accrues a bit
of risk when releasing, and in turn shield our contributors from risk
as we've promised) Obviously we aren't claiming that they are perfect
apache releases that meet the minimum apache guidelines for
cleanliness) and that we should recognize that risk by having the fact
that they are incubating clearly in the name. (Oh wait, we already do
that.) We also have the new disclaimer in there for good measure.

This, IMO, exposes the ASF to a very (teensy weensy) slight increase
in risk, but for a much greater community gain. We have DMCA safe
harbor process to shield us from a good deal of the risk. The podling
gets to move faster, and hopefully learn and grow faster in the
process.

Failure isn't the problem, IMO. In fact we should be pushing people to
fail faster, so that each time the release gets a little better, and
each time the community grows, and more people understand the
processes and problems.

Greg - I propose that you, Ross (sorry for volunteering you), and I
pick an incubating project in need of mentor attention and make this
as streamlined as we can. Let's focus on educating and enabling and
not gatekeeping. Let's prove out the concept and stop beating this
poor horse so much. :)

--David

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Ross Gardler
When I used to do endless apache way talks I used to say "if you are using an 
Incubator project expect to invest in both engineering and legal, but once a 
project is a TLP your legal can reduce and engineering becomes about your use 
rather than community progrwe towards TLP"

In other words Jim is right IMHO

---

Sent from my phone, you know what that means - sorry


From: Dave Fisher 
Sent: Tuesday, August 13, 2019 9:22:26 AM
To: general 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

Hi Ted,

This subthread as named by Greg is really about this:

> On Aug 11, 2019, at 5:56 PM, Greg Stein  wrote:
>
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
>
> 
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——

I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
the podling is fully compliant with Apache Release Policy and goes through the 
usual process. Abiding by the Apache Release Policy would remain a Graduation 
Requirement.

So, we treat these releases as not fully approved the same way we treat Binary 
Conveniences.

I think that this pattern grows the PPMC into a true PMC better by expecting 
that licensing issues which require vigilance become part of the Project’s DNA 
in a more organic way.

Regards,
Dave

> On Aug 13, 2019, at 9:09 AM, Ted Dunning  wrote:
>
> Dave,
>
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
>
> 90% of project release still require additional votes. How will that change?
>
> Every other change is peripheral.
>
>
>
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher  wrote:
>
>>
>>
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning  wrote:
>>>
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher > w...@apache.org>> wrote:
>>>


> On Aug 12, 2019, at 10:02 AM, Ted Dunning 
>> wrote:
>
> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
>
>>
>>
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning 
 wrote:
>> ...
 "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
 pointers here). We have 3 (or more) binding votes from mentors. We
>> are
 giving the IPMC and additional 72 hours to vote on said release."

>>>
>>>
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>>
>>> The 10% that do have enough votes can easily follow this process.
>>
>> Then the ones that don't have enough mentors still require the 3 +1
>> binding votes. The idea is that if the podling already has it, then
>> the
>> IPMC "vote" is more procedural than anything else. If they don't, then
>> either the mentors need to step up or the IPMC fills in the gap.
>>
>> The goal is to avoid having the Incubator be a gate-keeper.
>>
>
>
> I don't understand how this is all that different from what we have
>> now.
 If
> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
 to
> include the IPMC is just like what you said, "we have three votes
>> already
> and unless somebody points out something heinous, this is going to be a
> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
 cases
> is a tiny matter of nomenclature because the effect is typically a
>> rubber
> stamp (although some of these releases are examined carefully and
>> things
> turn up).
>
> In the large majority of cases, the Incubator is definitely not a
> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
 allow
> a release to go forward when it would otherwise fail.

 A week or two (an uncertain time) to do release votes as opposed to what
 may already be a significant increase to a minimum 3 days will FEEL
>> like a
 closed GATE. (For example Zipkin really felt gated.)

>>>
>>>
>>>
>>> Dave,
>>>
>>> I don't understand your point.
>>
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>>
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>>
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>>
>> Regards,
>> Dave
>>
>> [1]
>> 

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Dave Fisher
Hi Ted,

This subthread as named by Greg is really about this:

> On Aug 11, 2019, at 5:56 PM, Greg Stein  wrote:
> 
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
> 
> 
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——

I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
the podling is fully compliant with Apache Release Policy and goes through the 
usual process. Abiding by the Apache Release Policy would remain a Graduation 
Requirement.

So, we treat these releases as not fully approved the same way we treat Binary 
Conveniences.

I think that this pattern grows the PPMC into a true PMC better by expecting 
that licensing issues which require vigilance become part of the Project’s DNA 
in a more organic way.

Regards,
Dave

> On Aug 13, 2019, at 9:09 AM, Ted Dunning  wrote:
> 
> Dave,
> 
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
> 
> 90% of project release still require additional votes. How will that change?
> 
> Every other change is peripheral.
> 
> 
> 
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher  wrote:
> 
>> 
>> 
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning  wrote:
>>> 
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher > w...@apache.org>> wrote:
>>> 
 
 
> On Aug 12, 2019, at 10:02 AM, Ted Dunning 
>> wrote:
> 
> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
> 
>> 
>> 
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning 
 wrote:
>> ...
 "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
 pointers here). We have 3 (or more) binding votes from mentors. We
>> are
 giving the IPMC and additional 72 hours to vote on said release."
 
>>> 
>>> 
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>> 
>>> The 10% that do have enough votes can easily follow this process.
>> 
>> Then the ones that don't have enough mentors still require the 3 +1
>> binding votes. The idea is that if the podling already has it, then
>> the
>> IPMC "vote" is more procedural than anything else. If they don't, then
>> either the mentors need to step up or the IPMC fills in the gap.
>> 
>> The goal is to avoid having the Incubator be a gate-keeper.
>> 
> 
> 
> I don't understand how this is all that different from what we have
>> now.
 If
> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
 to
> include the IPMC is just like what you said, "we have three votes
>> already
> and unless somebody points out something heinous, this is going to be a
> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
 cases
> is a tiny matter of nomenclature because the effect is typically a
>> rubber
> stamp (although some of these releases are examined carefully and
>> things
> turn up).
> 
> In the large majority of cases, the Incubator is definitely not a
> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
 allow
> a release to go forward when it would otherwise fail.
 
 A week or two (an uncertain time) to do release votes as opposed to what
 may already be a significant increase to a minimum 3 days will FEEL
>> like a
 closed GATE. (For example Zipkin really felt gated.)
 
>>> 
>>> 
>>> 
>>> Dave,
>>> 
>>> I don't understand your point.
>> 
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>> 
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>> 
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>> 
>> Regards,
>> Dave
>> 
>> [1]
>> https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E
>> 
>>> 
>>> Currently, a podling does a vote. If they (it does happen, but rarely)
>> get
>>> 3 mentor votes, then they can immediately call for comments / votes on
>> the
>>> IPMC list. If nothing bad turns up, they are done.
>>> 
>>> If something really bad gets found at that point, it isn't the fault of
>> the
>>> process. It is the nature of release votes with different people looking
>> at
>>> different things. 

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Ted Dunning
Dave,

I understand the problem with long delays. What I don't understand is how
the proposal changes any of that.

90% of project release still require additional votes. How will that change?

Every other change is peripheral.



On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher  wrote:

>
>
> > On Aug 12, 2019, at 1:34 PM, Ted Dunning  wrote:
> >
> > On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher  w...@apache.org>> wrote:
> >
> >>
> >>
> >>> On Aug 12, 2019, at 10:02 AM, Ted Dunning 
> wrote:
> >>>
> >>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
> >>>
> 
> 
> > On Aug 12, 2019, at 10:44 AM, Ted Dunning 
> >> wrote:
>  ...
> >> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> >> pointers here). We have 3 (or more) binding votes from mentors. We
> are
> >> giving the IPMC and additional 72 hours to vote on said release."
> >>
> >
> >
> > This is good in theory, but as Justin has pointed out, 90% of podling
> > releases don't have enough mentor votes to follow this path.
> >
> > The 10% that do have enough votes can easily follow this process.
> 
>  Then the ones that don't have enough mentors still require the 3 +1
>  binding votes. The idea is that if the podling already has it, then
> the
>  IPMC "vote" is more procedural than anything else. If they don't, then
>  either the mentors need to step up or the IPMC fills in the gap.
> 
>  The goal is to avoid having the Incubator be a gate-keeper.
> 
> >>>
> >>>
> >>> I don't understand how this is all that different from what we have
> now.
> >> If
> >>> three mentors (and thus IPMC members) vote yes, then opening up the
> vote
> >> to
> >>> include the IPMC is just like what you said, "we have three votes
> already
> >>> and unless somebody points out something heinous, this is going to be a
> >>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
> >> cases
> >>> is a tiny matter of nomenclature because the effect is typically a
> rubber
> >>> stamp (although some of these releases are examined carefully and
> things
> >>> turn up).
> >>>
> >>> In the large majority of cases, the Incubator is definitely not a
> >>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
> >> allow
> >>> a release to go forward when it would otherwise fail.
> >>
> >> A week or two (an uncertain time) to do release votes as opposed to what
> >> may already be a significant increase to a minimum 3 days will FEEL
> like a
> >> closed GATE. (For example Zipkin really felt gated.)
> >>
> >
> >
> >
> > Dave,
> >
> > I don't understand your point.
>
> My point is that what you describe below are the ideal results. We all
> know that while the podling itself can do release votes in 72 hours it
> often takes the IPMC much more than 72 hours to vote. It used to be weeks
> and has improved significantly to where most podlings can be done inside of
> one week.
>
> The timing and uncertainty of this is too much for some previously
> established communities. For instance I think that this indeterminate lag
> is one of the causes that made Zipkin a poor fit here.
>
> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
> situation, or should we do another small step and essentially follow
> Myrle’s Review plan[1] for all general@ votes?
>
> Regards,
> Dave
>
> [1]
> https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E
>
> >
> > Currently, a podling does a vote. If they (it does happen, but rarely)
> get
> > 3 mentor votes, then they can immediately call for comments / votes on
> the
> > IPMC list. If nothing bad turns up, they are done.
> >
> > If something really bad gets found at that point, it isn't the fault of
> the
> > process. It is the nature of release votes with different people looking
> at
> > different things. Further, a release wouldn't necessarily be blocked at
> > that point, but if the problem really is bad, then it is good practice
> for
> > all +1 votes to switch to -1 so the vote fails and a new candidate can be
> > rolled.
> >
> > The proposal Jim made said that there would be 72 additional hours to
> > review after the vote passes the podling vote. It may be that there is a
> > suggestion that this additional 72 hours could start immediately upon
> > getting three mentor votes but this is very much a corner case since it
> > would be a fraction of the 10% of the time that three mentors actually do
> > vote. If the three mentors take a day or two to vote, then the only
> > difference in the 10% case is a day or so acceleration.
> >
> > This just doesn't sound like it helps all that much. It changes 3 days +
> 3
> > days into 3 days + 3 days 90% of the time and has some potential to
> change
> > it into 3 days + 1-2 days less than 10% of the time.
> >
> > That is my point. Either I completely misunderstand what is being
> proposed
> > 

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-13 Thread Dave Fisher


> On Aug 12, 2019, at 1:34 PM, Ted Dunning  wrote:
> 
> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher  > wrote:
> 
>> 
>> 
>>> On Aug 12, 2019, at 10:02 AM, Ted Dunning  wrote:
>>> 
>>> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
>>> 
 
 
> On Aug 12, 2019, at 10:44 AM, Ted Dunning 
>> wrote:
 ...
>> "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>> pointers here). We have 3 (or more) binding votes from mentors. We are
>> giving the IPMC and additional 72 hours to vote on said release."
>> 
> 
> 
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
> 
> The 10% that do have enough votes can easily follow this process.
 
 Then the ones that don't have enough mentors still require the 3 +1
 binding votes. The idea is that if the podling already has it, then the
 IPMC "vote" is more procedural than anything else. If they don't, then
 either the mentors need to step up or the IPMC fills in the gap.
 
 The goal is to avoid having the Incubator be a gate-keeper.
 
>>> 
>>> 
>>> I don't understand how this is all that different from what we have now.
>> If
>>> three mentors (and thus IPMC members) vote yes, then opening up the vote
>> to
>>> include the IPMC is just like what you said, "we have three votes already
>>> and unless somebody points out something heinous, this is going to be a
>>> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
>> cases
>>> is a tiny matter of nomenclature because the effect is typically a rubber
>>> stamp (although some of these releases are examined carefully and things
>>> turn up).
>>> 
>>> In the large majority of cases, the Incubator is definitely not a
>>> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
>> allow
>>> a release to go forward when it would otherwise fail.
>> 
>> A week or two (an uncertain time) to do release votes as opposed to what
>> may already be a significant increase to a minimum 3 days will FEEL like a
>> closed GATE. (For example Zipkin really felt gated.)
>> 
> 
> 
> 
> Dave,
> 
> I don't understand your point.

My point is that what you describe below are the ideal results. We all know 
that while the podling itself can do release votes in 72 hours it often takes 
the IPMC much more than 72 hours to vote. It used to be weeks and has improved 
significantly to where most podlings can be done inside of one week.

The timing and uncertainty of this is too much for some previously established 
communities. For instance I think that this indeterminate lag is one of the 
causes that made Zipkin a poor fit here.

We've relaxed DISCLAIMERs. Should we wait to see if this improves the 
situation, or should we do another small step and essentially follow Myrle’s 
Review plan[1] for all general@ votes?

Regards,
Dave

[1] 
https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E

> 
> Currently, a podling does a vote. If they (it does happen, but rarely) get
> 3 mentor votes, then they can immediately call for comments / votes on the
> IPMC list. If nothing bad turns up, they are done.
> 
> If something really bad gets found at that point, it isn't the fault of the
> process. It is the nature of release votes with different people looking at
> different things. Further, a release wouldn't necessarily be blocked at
> that point, but if the problem really is bad, then it is good practice for
> all +1 votes to switch to -1 so the vote fails and a new candidate can be
> rolled.
> 
> The proposal Jim made said that there would be 72 additional hours to
> review after the vote passes the podling vote. It may be that there is a
> suggestion that this additional 72 hours could start immediately upon
> getting three mentor votes but this is very much a corner case since it
> would be a fraction of the 10% of the time that three mentors actually do
> vote. If the three mentors take a day or two to vote, then the only
> difference in the 10% case is a day or so acceleration.
> 
> This just doesn't sound like it helps all that much. It changes 3 days + 3
> days into 3 days + 3 days 90% of the time and has some potential to change
> it into 3 days + 1-2 days less than 10% of the time.
> 
> That is my point. Either I completely misunderstand what is being proposed
> or it doesn't really make a significant difference. If I misunderstood, I
> would love to hear how and it seems like it would good to improve the
> description of the change. If it doesn't matter, we can make the change or
> not and there shouldn't be much argument either way (because it doesn't
> matter).



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread David Nalley
>
> I'd like to see the IPMC get out of the way of the podlings' releases. I
> see no reason for us to be a gate, and many more reasons to back off and
> let podlings get their work done.
>

I strongly agree with your sentiment, even if I differ with your tactics a bit.

I think that they are releases (e.g. we the foundation accrues a bit
of risk when releasing, and in turn shield our contributors from risk
as we've promised) Obviously we aren't claiming that they are perfect
apache releases that meet the minimum apache guidelines for
cleanliness) and that we should recognize that risk by having the fact
that they are incubating clearly in the name. (Oh wait, we already do
that.) We also have the new disclaimer in there for good measure.

This, IMO, exposes the ASF to a very (teensy weensy) slight increase
in risk, but for a much greater community gain. We have DMCA safe
harbor process to shield us from a good deal of the risk. The podling
gets to move faster, and hopefully learn and grow faster in the
process.

Failure isn't the problem, IMO. In fact we should be pushing people to
fail faster, so that each time the release gets a little better, and
each time the community grows, and more people understand the
processes and problems.

Greg - I propose that you, Ross (sorry for volunteering you), and I
pick an incubating project in need of mentor attention and make this
as streamlined as we can. Let's focus on educating and enabling and
not gatekeeping. Let's prove out the concept and stop beating this
poor horse so much. :)

--David

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Ted Dunning
On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher  wrote:

>
>
> > On Aug 12, 2019, at 10:02 AM, Ted Dunning  wrote:
> >
> > On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
> >
> >>
> >>
> >>> On Aug 12, 2019, at 10:44 AM, Ted Dunning 
> wrote:
> >> ...
>   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>  pointers here). We have 3 (or more) binding votes from mentors. We are
>  giving the IPMC and additional 72 hours to vote on said release."
> 
> >>>
> >>>
> >>> This is good in theory, but as Justin has pointed out, 90% of podling
> >>> releases don't have enough mentor votes to follow this path.
> >>>
> >>> The 10% that do have enough votes can easily follow this process.
> >>
> >> Then the ones that don't have enough mentors still require the 3 +1
> >> binding votes. The idea is that if the podling already has it, then the
> >> IPMC "vote" is more procedural than anything else. If they don't, then
> >> either the mentors need to step up or the IPMC fills in the gap.
> >>
> >> The goal is to avoid having the Incubator be a gate-keeper.
> >>
> >
> >
> > I don't understand how this is all that different from what we have now.
> If
> > three mentors (and thus IPMC members) vote yes, then opening up the vote
> to
> > include the IPMC is just like what you said, "we have three votes already
> > and unless somebody points out something heinous, this is going to be a
> > release". Whether the IPMC is a gatekeeper or a rubber stamp in these
> cases
> > is a tiny matter of nomenclature because the effect is typically a rubber
> > stamp (although some of these releases are examined carefully and things
> > turn up).
> >
> > In the large majority of cases, the Incubator is definitely not a
> > gatekeeper. If anything, the non-mentor IPMC votes are enablers that
> allow
> > a release to go forward when it would otherwise fail.
>
> A week or two (an uncertain time) to do release votes as opposed to what
> may already be a significant increase to a minimum 3 days will FEEL like a
> closed GATE. (For example Zipkin really felt gated.)
>



Dave,

I don't understand your point.

Currently, a podling does a vote. If they (it does happen, but rarely) get
3 mentor votes, then they can immediately call for comments / votes on the
IPMC list. If nothing bad turns up, they are done.

If something really bad gets found at that point, it isn't the fault of the
process. It is the nature of release votes with different people looking at
different things. Further, a release wouldn't necessarily be blocked at
that point, but if the problem really is bad, then it is good practice for
all +1 votes to switch to -1 so the vote fails and a new candidate can be
rolled.

The proposal Jim made said that there would be 72 additional hours to
review after the vote passes the podling vote. It may be that there is a
suggestion that this additional 72 hours could start immediately upon
getting three mentor votes but this is very much a corner case since it
would be a fraction of the 10% of the time that three mentors actually do
vote. If the three mentors take a day or two to vote, then the only
difference in the 10% case is a day or so acceleration.

This just doesn't sound like it helps all that much. It changes 3 days + 3
days into 3 days + 3 days 90% of the time and has some potential to change
it into 3 days + 1-2 days less than 10% of the time.

That is my point. Either I completely misunderstand what is being proposed
or it doesn't really make a significant difference. If I misunderstood, I
would love to hear how and it seems like it would good to improve the
description of the change. If it doesn't matter, we can make the change or
not and there shouldn't be much argument either way (because it doesn't
matter).


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Dave Fisher



> On Aug 12, 2019, at 10:02 AM, Ted Dunning  wrote:
> 
> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
> 
>> 
>> 
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning  wrote:
>> ...
  "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
 pointers here). We have 3 (or more) binding votes from mentors. We are
 giving the IPMC and additional 72 hours to vote on said release."
 
>>> 
>>> 
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>> 
>>> The 10% that do have enough votes can easily follow this process.
>> 
>> Then the ones that don't have enough mentors still require the 3 +1
>> binding votes. The idea is that if the podling already has it, then the
>> IPMC "vote" is more procedural than anything else. If they don't, then
>> either the mentors need to step up or the IPMC fills in the gap.
>> 
>> The goal is to avoid having the Incubator be a gate-keeper.
>> 
> 
> 
> I don't understand how this is all that different from what we have now. If
> three mentors (and thus IPMC members) vote yes, then opening up the vote to
> include the IPMC is just like what you said, "we have three votes already
> and unless somebody points out something heinous, this is going to be a
> release". Whether the IPMC is a gatekeeper or a rubber stamp in these cases
> is a tiny matter of nomenclature because the effect is typically a rubber
> stamp (although some of these releases are examined carefully and things
> turn up).
> 
> In the large majority of cases, the Incubator is definitely not a
> gatekeeper. If anything, the non-mentor IPMC votes are enablers that allow
> a release to go forward when it would otherwise fail.

A week or two (an uncertain time) to do release votes as opposed to what may 
already be a significant increase to a minimum 3 days will FEEL like a closed 
GATE. (For example Zipkin really felt gated.)

Regards,
Dave


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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Jim Jagielski
No, I don't mean to blame the mentors... It is a hard job, mostly uncelebrated 
and thankless and the 1st place people point to when problems arise.

Also, in general, most mentors are those who suffer from volunteeritis and tend 
to bite off more than they can chew. But the reality is that they have signed 
up and that the podling does need them and depend on them. There is no shame in 
saying "I need to resign as mentor... I just don't have the time anymore".

Agreed, BTW, that the Champion role needs to be really emphasized...

> On Aug 12, 2019, at 1:22 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Aug 12, 2019, at 9:24 AM, Jim Jagielski  wrote:
>> 
>> 
>> 
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning  wrote:
>>> 
>>> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:
>>> 
 ...
 This does NOT mean that the IPMC should be gatekeepers though... Just as
 PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
 ears of the IPMC". The IPMC "vote" should be little more than a formality.
 IMO, if mentors are IPMC members, and there are at least 3 binding votes on
 the podling list, and the mentors are acting as IPMC members when they
 vote, then any other additional vote in the IPMC is not required... in
 essence, consider it like extending the vote for a lazy consensus, so to
 speak:
 
 
 "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
 pointers here). We have 3 (or more) binding votes from mentors. We are
 giving the IPMC and additional 72 hours to vote on said release."
 
>>> 
>>> 
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>> 
>>> The 10% that do have enough votes can easily follow this process.
>> 
>> Then the ones that don't have enough mentors still require the 3 +1 binding 
>> votes. The idea is that if the podling already has it, then the IPMC "vote" 
>> is more procedural than anything else. If they don't, then either the 
>> mentors need to step up or the IPMC fills in the gap.
>> 
>> The goal is to avoid having the Incubator be a gate-keeper.
> 
> You state here the paradox if the podling does not have enough engaged 
> mentors then the IPMC is the effective gateway.
> 
> FWIW - there are currently 47 Podlings[1] and 85 Mentors. [2] There are 
> several mentors who mentor 4-6 podlings. I’ve done the analysis before, but 
> it breaks down to about half the mentors having only a single Podling and a 
> quarter with only two.
> 
> Also, let’s not blame the mentors as a lot of times a podling has trouble 
> establishing themselves and the mentors move on for various reasons. 
> Typically mentors are all volunteers. (That some are paid by a third party is 
> perfectly fine.)
> 
> Do we need more mentors? Sure. We do have over 10% of the membership 
> mentoring and up to 30% on the IPMC. I sent a request to members@ some six 
> months ago and I think we got two or three.
> 
> Regards,
> Dave
> 
> [1] http://incubator.apache.org/clutch/#clutch 
> 
> [2] http://incubator.apache.org/clutch/#mentors 
> 
> 
> 
>> -
>> 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Dave Fisher
Hi -

> On Aug 12, 2019, at 8:44 AM, Julian Feinauer  
> wrote:
> 
> Hi Ted,
> 
> dont get me wrong, I'm rather new to the ASF, the incubator and especially 
> the IPMC. So my perspective might be different. But, I understand the 
> frustration that some may have and I leant that there have been many trials 
> to change things which didn’t go the way we wanted.
> The "fear" or concerns I have is that loosening some requirements feels a bit 
> like resigning which would be a horrible thing as the incubator is one of the 
> (if not the) most important projects in the ASF.
> 
> And I don’t object that much with having different classes of releases (its 
> not elegant but acceptable IMHO) but the thing I'm really concerned about is 
> the lack of possibilities to learn for podlings.
> If we come at the end to the modus operandi of "Yeah, simply release as is 
> but use this disclaimer or that NOTICE and later in the project we will do it 
> 'right'" that would be pretty bad.
> But perhaps I'm too spoiled as I had the luck to be in several podlings with 
> Justin and Chris Dutz who both took lots of time and did an excellent job in 
> helping me and all other freshmen to really learn what this Apache Release 
> policy is about and how to do it right.
> And this is something so important that I want every other podling / 
> newcomers to the ASF to experience.
> 
> I know that this might sound provocative and perhaps some people might 
> disagree but perhaps, if we know that we have not enough "mentor-power" we 
> should be more careful about picking up new projects in the incubator if we 
> are not sure how to bring them to TLP successful?

We definitely do need to be more careful. I think that we need to empower and 
better define the Champion role so that two things are done:

(1) The Champion makes sure that the incoming project is truly on board. This 
means testing the incoming community both donor and the initial committer list 
that they understand how Apache Way governance works. This is more than release 
policy, it is about using the dev@ list to make asynchronous decisions within 
the podling community. I think that this does not happen enough and mentors 
lose track of podlings because they can’t see what is happening without being 
entwined in GitHub issues and commit emails.

(2) The Champion makes sure that there are enough Mentors who have taken a 
podling through the Incubator. A good mix of “Junior” Mentors like I was once 
and Julian is now is good, but having old veterans like Jim, Jean-Baptiste, 
Julian, Justin, and Bertrand among others is truly critical.

See [1] for a good graph showing the ebb and flow of Incubator podlings through 
time.

Regards,
Dave

[1] https://projects.apache.org


> 
> Julian
> 
> Am 12.08.19, 17:34 schrieb "Ted Dunning" :
> 
>Julian,
> 
>I love the sentiment, but increasing the probability of mentor-only
>approval by 10x is going to take a lot of something that we haven't had the
>last five times we have tried to do this. The current system is a bit
>frustrating, but having what amounts to mentors-at-large like Justin and a
>few others is the only way we have right now to solve the problem of
>inspecting releases (and helping to improve them).
> 
>And regarding two level of artifacts, we already have two kinds of podling
>release artifacts. Those are releasable and defective (and thus not
>releasable). That can't change since it is inherent in the release ground
>rules and the fact that incoming podlings don't know the ground rules. The
>only change is to make the defective artifacts provisionally releasable.
> 
> 
> 
>On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
>j.feina...@pragmaticminds.de> wrote:
> 
>> Hi Ted,
>> 
>> but instead of questioning the Bylaws or introducing two classes of
>> artifacts I would rather try to improve mentor votes as this is something
>> we can do incubator internal.
>> And its always better to cure the cause then the symptoms : )
>> 
>> Julian
>> 
>> Am 12.08.19, 16:44 schrieb "Ted Dunning" :
>> 
>>On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:
>> 
>>> ...
>>> This does NOT mean that the IPMC should be gatekeepers though...
>> Just as
>>> PMC chairs are the "eyes and ears of the board", mentors are the
>> "eyes and
>>> ears of the IPMC". The IPMC "vote" should be little more than a
>> formality.
>>> IMO, if mentors are IPMC members, and there are at least 3 binding
>> votes on
>>> the podling list, and the mentors are acting as IPMC members when
>> they
>>> vote, then any other additional vote in the IPMC is not required...
>> in
>>> essence, consider it like extending the vote for a lazy consensus,
>> so to
>>> speak:
>>> 
>>> 
>>>   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>> pointers here). We have 3 (or more) binding votes from mentors. We
>> are
>>> giving the IPMC and additional 72 hours to vote on said release."
>>> 
>> 
>> 
>>  

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Dave Fisher



> On Aug 12, 2019, at 9:24 AM, Jim Jagielski  wrote:
> 
> 
> 
>> On Aug 12, 2019, at 10:44 AM, Ted Dunning  wrote:
>> 
>> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:
>> 
>>> ...
>>> This does NOT mean that the IPMC should be gatekeepers though... Just as
>>> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
>>> ears of the IPMC". The IPMC "vote" should be little more than a formality.
>>> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
>>> the podling list, and the mentors are acting as IPMC members when they
>>> vote, then any other additional vote in the IPMC is not required... in
>>> essence, consider it like extending the vote for a lazy consensus, so to
>>> speak:
>>> 
>>> 
>>>  "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>>> pointers here). We have 3 (or more) binding votes from mentors. We are
>>> giving the IPMC and additional 72 hours to vote on said release."
>>> 
>> 
>> 
>> This is good in theory, but as Justin has pointed out, 90% of podling
>> releases don't have enough mentor votes to follow this path.
>> 
>> The 10% that do have enough votes can easily follow this process.
> 
> Then the ones that don't have enough mentors still require the 3 +1 binding 
> votes. The idea is that if the podling already has it, then the IPMC "vote" 
> is more procedural than anything else. If they don't, then either the mentors 
> need to step up or the IPMC fills in the gap.
> 
> The goal is to avoid having the Incubator be a gate-keeper.

You state here the paradox if the podling does not have enough engaged mentors 
then the IPMC is the effective gateway.

FWIW - there are currently 47 Podlings[1] and 85 Mentors. [2] There are several 
mentors who mentor 4-6 podlings. I’ve done the analysis before, but it breaks 
down to about half the mentors having only a single Podling and a quarter with 
only two.

Also, let’s not blame the mentors as a lot of times a podling has trouble 
establishing themselves and the mentors move on for various reasons. Typically 
mentors are all volunteers. (That some are paid by a third party is perfectly 
fine.)

Do we need more mentors? Sure. We do have over 10% of the membership mentoring 
and up to 30% on the IPMC. I sent a request to members@ some six months ago and 
I think we got two or three.

Regards,
Dave

[1] http://incubator.apache.org/clutch/#clutch
[2] http://incubator.apache.org/clutch/#mentors


> -
> 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: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Ted Dunning
On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:

>
>
> > On Aug 12, 2019, at 10:44 AM, Ted Dunning  wrote:
> ...
> >>   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> >> pointers here). We have 3 (or more) binding votes from mentors. We are
> >> giving the IPMC and additional 72 hours to vote on said release."
> >>
> >
> >
> > This is good in theory, but as Justin has pointed out, 90% of podling
> > releases don't have enough mentor votes to follow this path.
> >
> > The 10% that do have enough votes can easily follow this process.
>
> Then the ones that don't have enough mentors still require the 3 +1
> binding votes. The idea is that if the podling already has it, then the
> IPMC "vote" is more procedural than anything else. If they don't, then
> either the mentors need to step up or the IPMC fills in the gap.
>
> The goal is to avoid having the Incubator be a gate-keeper.
>


I don't understand how this is all that different from what we have now. If
three mentors (and thus IPMC members) vote yes, then opening up the vote to
include the IPMC is just like what you said, "we have three votes already
and unless somebody points out something heinous, this is going to be a
release". Whether the IPMC is a gatekeeper or a rubber stamp in these cases
is a tiny matter of nomenclature because the effect is typically a rubber
stamp (although some of these releases are examined carefully and things
turn up).

In the large majority of cases, the Incubator is definitely not a
gatekeeper. If anything, the non-mentor IPMC votes are enablers that allow
a release to go forward when it would otherwise fail.


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Jim Jagielski



> On Aug 12, 2019, at 10:44 AM, Ted Dunning  wrote:
> 
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:
> 
>> ...
>> This does NOT mean that the IPMC should be gatekeepers though... Just as
>> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
>> ears of the IPMC". The IPMC "vote" should be little more than a formality.
>> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
>> the podling list, and the mentors are acting as IPMC members when they
>> vote, then any other additional vote in the IPMC is not required... in
>> essence, consider it like extending the vote for a lazy consensus, so to
>> speak:
>> 
>> 
>>   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
>> pointers here). We have 3 (or more) binding votes from mentors. We are
>> giving the IPMC and additional 72 hours to vote on said release."
>> 
> 
> 
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
> 
> The 10% that do have enough votes can easily follow this process.

Then the ones that don't have enough mentors still require the 3 +1 binding 
votes. The idea is that if the podling already has it, then the IPMC "vote" is 
more procedural than anything else. If they don't, then either the mentors need 
to step up or the IPMC fills in the gap.

The goal is to avoid having the Incubator be a gate-keeper.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Julian Feinauer
Hi Ted,

dont get me wrong, I'm rather new to the ASF, the incubator and especially the 
IPMC. So my perspective might be different. But, I understand the frustration 
that some may have and I leant that there have been many trials to change 
things which didn’t go the way we wanted.
The "fear" or concerns I have is that loosening some requirements feels a bit 
like resigning which would be a horrible thing as the incubator is one of the 
(if not the) most important projects in the ASF.

And I don’t object that much with having different classes of releases (its not 
elegant but acceptable IMHO) but the thing I'm really concerned about is the 
lack of possibilities to learn for podlings.
If we come at the end to the modus operandi of "Yeah, simply release as is but 
use this disclaimer or that NOTICE and later in the project we will do it 
'right'" that would be pretty bad.
But perhaps I'm too spoiled as I had the luck to be in several podlings with 
Justin and Chris Dutz who both took lots of time and did an excellent job in 
helping me and all other freshmen to really learn what this Apache Release 
policy is about and how to do it right.
And this is something so important that I want every other podling / newcomers 
to the ASF to experience.

I know that this might sound provocative and perhaps some people might disagree 
but perhaps, if we know that we have not enough "mentor-power" we should be 
more careful about picking up new projects in the incubator if we are not sure 
how to bring them to TLP successful?

Julian

Am 12.08.19, 17:34 schrieb "Ted Dunning" :

Julian,

I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).

And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.



On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" :
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  
wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> >"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>




Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Ted Dunning
Julian,

I love the sentiment, but increasing the probability of mentor-only
approval by 10x is going to take a lot of something that we haven't had the
last five times we have tried to do this. The current system is a bit
frustrating, but having what amounts to mentors-at-large like Justin and a
few others is the only way we have right now to solve the problem of
inspecting releases (and helping to improve them).

And regarding two level of artifacts, we already have two kinds of podling
release artifacts. Those are releasable and defective (and thus not
releasable). That can't change since it is inherent in the release ground
rules and the fact that incoming podlings don't know the ground rules. The
only change is to make the defective artifacts provisionally releasable.



On Mon, Aug 12, 2019 at 7:56 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi Ted,
>
> but instead of questioning the Bylaws or introducing two classes of
> artifacts I would rather try to improve mentor votes as this is something
> we can do incubator internal.
> And its always better to cure the cause then the symptoms : )
>
> Julian
>
> Am 12.08.19, 16:44 schrieb "Ted Dunning" :
>
> On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:
>
> > ...
> > This does NOT mean that the IPMC should be gatekeepers though...
> Just as
> > PMC chairs are the "eyes and ears of the board", mentors are the
> "eyes and
> > ears of the IPMC". The IPMC "vote" should be little more than a
> formality.
> > IMO, if mentors are IPMC members, and there are at least 3 binding
> votes on
> > the podling list, and the mentors are acting as IPMC members when
> they
> > vote, then any other additional vote in the IPMC is not required...
> in
> > essence, consider it like extending the vote for a lazy consensus,
> so to
> > speak:
> >
> >
> >"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> > pointers here). We have 3 (or more) binding votes from mentors. We
> are
> > giving the IPMC and additional 72 hours to vote on said release."
> >
>
>
> This is good in theory, but as Justin has pointed out, 90% of podling
> releases don't have enough mentor votes to follow this path.
>
> The 10% that do have enough votes can easily follow this process.
>
>
>


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Julian Feinauer
Hi Ted,

but instead of questioning the Bylaws or introducing two classes of artifacts I 
would rather try to improve mentor votes as this is something we can do 
incubator internal.
And its always better to cure the cause then the symptoms : )

Julian

Am 12.08.19, 16:44 schrieb "Ted Dunning" :

On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:

> ...
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes 
on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
>"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>


This is good in theory, but as Justin has pointed out, 90% of podling
releases don't have enough mentor votes to follow this path.

The 10% that do have enough votes can easily follow this process.




Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Ted Dunning
On Mon, Aug 12, 2019 at 5:20 AM Jim Jagielski  wrote:

> ...
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
>"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>


This is good in theory, but as Justin has pointed out, 90% of podling
releases don't have enough mentor votes to follow this path.

The 10% that do have enough votes can easily follow this process.


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Matt Sicker
We were handling votes like that in OpenWhisk up until graduation. Mentor
votes carry over to the IPMC vote.

On Mon, Aug 12, 2019 at 07:20, Jim Jagielski  wrote:

> We have always had a mindset that we (the foundation) want to make it as
> "brain dead easy" for people to download, use, and consume ASF projects.
> This means that they don't need to worry about compliance, IP provenance,
> etc.
>
> Incubator releases are a special case. The expectation is, and should be,
> that these releases may have issues. In fact, it is quite likely they will.
> Again, as long as those downloading these releases are aware of that, and
> we've done all we could to ensure that they are aware of it, then we have
> satisfied our requirements. IMO, with the naming and the DISCLAIMER and
> other such touches, we are achieving that.
>
> And they are, in fact, *releases*. We need to recall that one function of
> the foundation, and PMCs, is to provide legal protection to those who are
> creating the software artifacts, and when a release is done, as a "formal"
> act of the foundation (via the PMC), it is when they legal coverage is at
> its most clear and explicit. So in order for those within the podling to
> enjoy the legal protection this foundation exists to provide, these do need
> to be releases. I would be opposed to not providing such coverage for those
> in our podlings, since they should be safe spaces to learn about the Apache
> Way and how to build communities and how to release software.
>
> This does NOT mean that the IPMC should be gatekeepers though... Just as
> PMC chairs are the "eyes and ears of the board", mentors are the "eyes and
> ears of the IPMC". The IPMC "vote" should be little more than a formality.
> IMO, if mentors are IPMC members, and there are at least 3 binding votes on
> the podling list, and the mentors are acting as IPMC members when they
> vote, then any other additional vote in the IPMC is not required... in
> essence, consider it like extending the vote for a lazy consensus, so to
> speak:
>
>
>"The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
> pointers here). We have 3 (or more) binding votes from mentors. We are
> giving the IPMC and additional 72 hours to vote on said release."
>
> Comments?
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Matt Sicker 


Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-12 Thread Jim Jagielski
We have always had a mindset that we (the foundation) want to make it as "brain 
dead easy" for people to download, use, and consume ASF projects. This means 
that they don't need to worry about compliance, IP provenance, etc.

Incubator releases are a special case. The expectation is, and should be, that 
these releases may have issues. In fact, it is quite likely they will. Again, 
as long as those downloading these releases are aware of that, and we've done 
all we could to ensure that they are aware of it, then we have satisfied our 
requirements. IMO, with the naming and the DISCLAIMER and other such touches, 
we are achieving that.

And they are, in fact, *releases*. We need to recall that one function of the 
foundation, and PMCs, is to provide legal protection to those who are creating 
the software artifacts, and when a release is done, as a "formal" act of the 
foundation (via the PMC), it is when they legal coverage is at its most clear 
and explicit. So in order for those within the podling to enjoy the legal 
protection this foundation exists to provide, these do need to be releases. I 
would be opposed to not providing such coverage for those in our podlings, 
since they should be safe spaces to learn about the Apache Way and how to build 
communities and how to release software.

This does NOT mean that the IPMC should be gatekeepers though... Just as PMC 
chairs are the "eyes and ears of the board", mentors are the "eyes and ears of 
the IPMC". The IPMC "vote" should be little more than a formality. IMO, if 
mentors are IPMC members, and there are at least 3 binding votes on the podling 
list, and the mentors are acting as IPMC members when they vote, then any other 
additional vote in the IPMC is not required... in essence, consider it like 
extending the vote for a lazy consensus, so to speak:


   "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and pointers 
here). We have 3 (or more) binding votes from mentors. We are giving the IPMC 
and additional 72 hours to vote on said release."

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



Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

2019-08-11 Thread Ross Gardler
Thanks Greg, I am fully in support of your position here.

The ASF is supposed to make it easier for developers to develop. It is not 
supposed to be creating red tape to guard the entrance to the hallowed halls.

Ross


From: Greg Stein 
Sent: Sunday, August 11, 2019 5:56 PM
To: general@incubator.apache.org
Subject: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

See further below for an unfortunately trimmed thread. A couple paragraphs
that I wrote early-thread are important to add:


Option (F): stop calling them official ASF releases, which means PMC votes
are not required.


> In that case voting would not be required and they wouldn’t have to follow
> ASF policy.


Right.


> If they are not official releases then we probably can’t release or
> distribute them on ASF infrastructure.


I see no problem with using our infrastructure to distribute F/OSS
materials. Why would the Foundation want to be against that? If it is
labeled properly, then ... roll with it. We distribute a *ton* of stuff
that wasn't produced by the ASF. We incorporate that stuff into a larger
work, but it isn't "ours". Yet we put it onto our servers.

Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe
somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use
it ... but John and Jane and Joe certainly want to, and *can*. Isn't that
our goal?


I see no problems with the purported "risk" mentioned below. Would some
mis-licensing occur? Likely. Is it material to the Foundation's mission?
Nah. What if something appears on our servers without a clear F/OSS
license? Does John or Jane care? Nopes. But we fix it in a future release.
Move along, everybody is happy.

I'd like to see the IPMC get out of the way of the podlings' releases. I
see no reason for us to be a gate, and many more reasons to back off and
let podlings get their work done.

Cheers,
-g

On Sun, Aug 11, 2019 at 7:46 PM Greg Stein  wrote:

> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> > I see no problem with using our infrastructure to distribute F/OSS
>> > materials. Why would the Foundation want to be against that? If it is
>> > labeled properly, then ... roll with it.
>>
>> It often isn’t labelled properly.  There’s a reasonable risk that some of
>> what would be placed there and distributed isn’t actually F/OSS.
>
>
> And what would be the blowback of something on our server with incorrect
> information? Very little. Mostly, we'd just move on. Maybe we delete it.
>
>
>> I can point you to several example of this. I’m not sure how the
>> incubator (or the board) would feel about that risk, so that would be
>> something we would be need to consider further. Also
>
>
> Welp. Then I will pose that question, rather than this endless
> pontificating about "risk".
>
>
>> while Jane and John may be fine with that, a lot of companies that use
>> Apache releases may not be.
>>
>
> I already acknowledged that. Many people could use software regardless of
> its licensing. The license typically only matters in *redistribution*
> scenarios. Things like the AGPL affect *usage*, but that is very, very
> atypical. I'd think 99% of downstream could use our software, even with
> gummed-up licensing.
>
>
>> > You're conflating *learning* with *releases*. These can be handled
>> separately.
>>
>> How exactly?
>
>
> You're saying that releases are the control point to learning. I say just
> let the releases go.
>
> You want to teach? Then you can use the releases like "that wasn't good.
> next time: do A and B". Over time, releases will get fixed. But the IPMC
> should not have to manage the releases.
>
> Cheers,
> -g
>
>

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