Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Christofer Dutz]

I agree,

I think that the "requirement" (Never really knew there was such a requirement) 
of being a Member sort of gives you the easy entry path as if you are a member 
people expect you to understand the Apache Way.

However that doesn't mean that people not being a member don't get the Apache 
Way and hereby should be excluded. 

Chris

PS: Sorry for being silent for quite some time ... was 100% swamped with 
TAC and ACEU preparations ...



Am 13.08.19, 08:29 schrieb "Julian Feinauer" :

Hi,

I'm a new IPMC Member (no foundation member) and come from a PLC4X which 
has graduated months ago.
I already started to help other Podlings a bit.

And I agree with Dave in the sense that we should seek our way not in 
locking-out people but in finding ways to draw in more people.
It was already said multiple times that people from "mature" podlings or 
freshly graduated projects would be a good call as mentors this should be ONE 
way to go.

Julian

Am 13.08.19, 01:42 schrieb "Dave Fisher" :



> On Aug 12, 2019, at 4:29 PM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 

> wrote:
> 
>> Hi,
>> 
>>> I will also note that if the IPMC switches to *voting* Members into 
the
>>> IPMC, that the Apache Member will be observing that vote take place 
on
>>> private@ through a subscription (they can reply!) or via the 
archives. …
>> 
>> Which is also the same for any project who votes in a ASF member as a
>> committer or PMC member.
>> 
> 
> I would counter that any project which creates such a bar for ASF 
Members
> may be doing it Wrong :)
> 
> (this goes into my general feeling that projects generally need to 
lower
> their bars, and become more inclusive)

I really think that we have long precedent to do most of what we need 
to do already in place.

I’m -1 on this proposal. I think it is a bad idea. It is so bad that I 
would seriously think about volunteering here less.

Just think about how many VOTEs we would need to do when a Podling 
comes in. Think about all the pro forma votes and discussions about people. 
BORING!

Frankly, I’m quite surprised that this is even being proposed.

Regards,
Dave

> 
> Cheers,
> -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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Julian Feinauer]

Hi,

I'm a new IPMC Member (no foundation member) and come from a PLC4X which has 
graduated months ago.
I already started to help other Podlings a bit.

And I agree with Dave in the sense that we should seek our way not in 
locking-out people but in finding ways to draw in more people.
It was already said multiple times that people from "mature" podlings or 
freshly graduated projects would be a good call as mentors this should be ONE 
way to go.

Julian

Am 13.08.19, 01:42 schrieb "Dave Fisher" :



> On Aug 12, 2019, at 4:29 PM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 
> wrote:
> 
>> Hi,
>> 
>>> I will also note that if the IPMC switches to *voting* Members into the
>>> IPMC, that the Apache Member will be observing that vote take place on
>>> private@ through a subscription (they can reply!) or via the archives. …
>> 
>> Which is also the same for any project who votes in a ASF member as a
>> committer or PMC member.
>> 
> 
> I would counter that any project which creates such a bar for ASF Members
> may be doing it Wrong :)
> 
> (this goes into my general feeling that projects generally need to lower
> their bars, and become more inclusive)

I really think that we have long precedent to do most of what we need to do 
already in place.

I’m -1 on this proposal. I think it is a bad idea. It is so bad that I 
would seriously think about volunteering here less.

Just think about how many VOTEs we would need to do when a Podling comes 
in. Think about all the pro forma votes and discussions about people. BORING!

Frankly, I’m quite surprised that this is even being proposed.

Regards,
Dave

> 
> Cheers,
> -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

[OFFER] Offer to Mentor one or two podlings

[Julian Feinauer]

Hi,

this goes to the IPMC as well as to podlings watching this list.
I just recently became IPMC member and am currently pretty active in the IoTDB 
Project as “informal mentor” (started there before becoming IPMC member) 
together with 3 other pretty active mentors.
As I received a lot of help from mentors and learned a lot about the Apache Way 
since I joined incubating projects, I think its time now to give something 
back. I could join one or two other podlings as Mentor if I am needed.

I gained a reasonable amount of “podling” experience hands-on during the last 2 
years after joining the PLC4X project and moving from release 0.1 to TLP and am 
active in other Podlings.
My main interest is in the IoT, Big Data and analytics area (I’m active in 
PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the JVM. So this 
is the area where I could help most, I guess.

So if someone has an idea where I can help, feel free to contact me!

Julian

Re: [DISCUSS] Graduate Apache Druid (incubating) as a TLP

[Dave Fisher]

Hi  -

I’ve been following as a member of the brand committee and have no concern 
about Druid graduation at this time.

Regards,
Dave

Sent from my iPhone

> On Aug 12, 2019, at 10:12 PM, Gian Merlino  wrote:
> 
> FYI- we gave the board a heads up too and received generally positive
> feedback. I will set up a vote shortly!
> 
> 
>> On Tue, Jul 23, 2019 at 8:24 PM Gian Merlino  wrote:
>> 
>> Hey Justin,
>> 
>> In summary it was clear from comments on the podling name search JIRA that
>> the community wanted to work to continue using the current name if at all
>> possible (mostly due to its long history, in use since 2011). And so we are
>> working towards that and would continue to do so throughout & after
>> becoming a TLP. I sent you an update about current status privately —
>> avoiding public comment for now since I am referencing conversations that
>> happened on private@druid. Maybe you can help me decide what would be
>> good to post publicly. The project is aware that if for some reason this
>> cannot be worked out, a name change may be required.
>> 
>> On Tue, Jul 23, 2019 at 6:59 PM Justin Mclean 
>> wrote:
>> 
>>> Hi,
>>> 
 Yes, they (we) are aware, and have been in discussion with Mark Thomas &
 other relevant parties since the podling name search concluded about
 straightening out potential issues that arose during the search.
>>> 
>>> My understanding is that this may require a name change and that it’s a
>>> possibility that the board may not accept the proposal to graduate because
>>> of this? Is that correct?
>>> 
>>> It might be good to get an update on where you are on this as the last
>>> email about this that I can find is several months old.
>>> 
>>> 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: [DISCUSS] Graduate Apache Druid (incubating) as a TLP

[Gian Merlino]

FYI- we gave the board a heads up too and received generally positive
feedback. I will set up a vote shortly!


On Tue, Jul 23, 2019 at 8:24 PM Gian Merlino  wrote:

> Hey Justin,
>
> In summary it was clear from comments on the podling name search JIRA that
> the community wanted to work to continue using the current name if at all
> possible (mostly due to its long history, in use since 2011). And so we are
> working towards that and would continue to do so throughout & after
> becoming a TLP. I sent you an update about current status privately —
> avoiding public comment for now since I am referencing conversations that
> happened on private@druid. Maybe you can help me decide what would be
> good to post publicly. The project is aware that if for some reason this
> cannot be worked out, a name change may be required.
>
> On Tue, Jul 23, 2019 at 6:59 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> > Yes, they (we) are aware, and have been in discussion with Mark Thomas &
>> > other relevant parties since the podling name search concluded about
>> > straightening out potential issues that arose during the search.
>>
>> My understanding is that this may require a name change and that it’s a
>> possibility that the board may not accept the proposal to graduate because
>> of this? Is that correct?
>>
>>  It might be good to get an update on where you are on this as the last
>> email about this that I can find is several months old.
>>
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Gian Merlino]

Yep, that is definitely a good one. I joined their mailing list a couple of
weeks ago and have been chatting with Lee on it, after he mentioned on the
Druid list that he could use some help.

(Apologies for the digression btw)

On Mon, Aug 12, 2019 at 2:10 PM Julian Hyde  wrote:

> Thanks, Gian. I bet you’re familiar with DataSketches (as it has
> ancestry/people in common with Druid) and I recall that recently they
> needed more mentors.
>
>
> > On Aug 12, 2019, at 2:06 PM, Gian Merlino  wrote:
> >
> > One more voice here: I'm not an ASF member, but I'd be interested in
> > mentoring other podlings after Druid graduates. Julian has been very
> > helpful to us while we've been incubating and I'd like to pay it forward.
> >
> > On Mon, Aug 12, 2019 at 11:12 AM Julian Hyde  wrote:
> >
> >> I don’t have a strong opinion on the subject of this thread - whether it
> >> should be easy for ASF members to join the IPMC - but I have a strong
> >> opinion about a related matter - namely, how easy it should be for
> non-ASF
> >> members to join the IPMC.
> >>
> >> The IPMC should be actively recruiting members of recently-graduated
> >> projects to serve as mentors of the next generation of podlings.
> >>
> >> I bet quite a few people people think that you have to be an ASF member
> to
> >> be on the IPMC or mentor a project. And we certainly give the impression
> >> that ASF members make the best mentors. But I claim that people who have
> >> just been through the incubation process also make excellent mentors.
> They
> >> have experienced the pain, and they know the answers to many of the IT-
> and
> >> process-related questions because they have just solved them.
> >>
> >> Like Sheng, I joined the IPMC before I was a member. The project I
> >> founded, Calcite, was close to graduating and I was active on general@
> >> because being a podling is hard and raises many questions. Some other
> >> podlings were entering incubation and someone (I think Ted Dunning or
> Alan
> >> Gates) asked me to be a mentor. From that, I was drawn into other Apache
> >> projects, saw the broader Apache community, and was drawn into the
> worthy
> >> task of helping to govern the Foundation. For me, serving as a mentor
> was a
> >> way of saying ’thank you’ for the help I had received from mentors
> during
> >> incubation. And for the IPMC, it provided an active and engaged mentor,
> >> always a scarce resource.
> >>
> >> Julian
> >>
> >>
> >>> On Aug 8, 2019, at 10:29 PM, Sheng Wu 
> wrote:
> >>>
> >>> Hi
> >>>
> >>> My Apache journey started at Incubator, and as IPMC now(not asf
> member).
> >> I
> >>> noticed this requirement too.
> >>>
> >>> From the members I known personally, most indeed know Apache way very
> >> well.
> >>> And truely there is exception.
> >>>
> >>> Basically, I think removing this makes sense.
> >>>
> >>> 1. if this member has been incubator journey, such as being initial
> >>> committer of a podling, it is easy to know and should have taken part
> in
> >>> incubator ml much.
> >>>
> >>> 2. there are indeed asf members elected by other reasons, so, they are
> >> not
> >>> familiar w/ incubator, and need more time to learn too. Apache has so
> >> many
> >>> TLPs and ways to take part in, a member is not required used to be
> >>> incubator.
> >>>
> >>> My +1 on IPMC should have enough incubator experiences.
> >>>
> >>> Also, very open to know the history reason of this.
> >>>
> >>> Sheng
> >>>
> >>> Justin Mclean 于2019年8月9日 周五下午1:04写道：
> >>>
>  Hi,
> 
>  Current any ASF member can come along and ask to join the IPMC. I
> assume
>  this was put in place for two reasons: ( but don’t know the full
> history
>  behind it)
>  - There was a lack of mentors.
>  - Is is assumed that if you are an ASF member you know enough about
> the
>  Apache Way to mentor a project.
> 
>  I’m not sure if this is the case anymore. And while the mentor
> situation
>  has improved I don’t think the above has solved the problem of having
>  active members or mentors having the required knowledge and skills
> they
>  need.
> 
>  So if you want to be a IPMC member and mentor a project then I think
> you
>  need you have gone through the full incubation process yourself and/or
> >> help
>  out with other incubator duties and get voted in as an IPMC member.
> Just
>  like every other ASF project.
> 
>  What do other people think?
> 
>  Thanks,
>  Justin
>  -
>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  For additional commands, e-mail: general-h...@incubator.apache.org
> 
>  --
> >>> Sheng Wu
> >>> SkyWalking, Shardingsphere and Zipkin
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incu

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Willem Jiang]

+1 , we need a binding process to let the member know better about the
Incubating.
For me, even I attend serval Apache projects before I start mentoring
incubating project, there are still lot of thing I need to learn.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Aug 9, 2019 at 1:04 PM Justin Mclean  wrote:
>
> Hi,
>
> Current any ASF member can come along and ask to join the IPMC. I assume this 
> was put in place for two reasons: ( but don’t know the full history behind it)
> - There was a lack of mentors.
> - Is is assumed that if you are an ASF member you know enough about the 
> Apache Way to mentor a project.
>
> I’m not sure if this is the case anymore. And while the mentor situation has 
> improved I don’t think the above has solved the problem of having active 
> members or mentors having the required knowledge and skills they need.
>
> So if you want to be a IPMC member and mentor a project then I think you need 
> you have gone through the full incubation process yourself and/or help out 
> with other incubator duties and get voted in as an IPMC member. Just like 
> every other ASF project.
>
> What do other people think?
>
> 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)

[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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Kenneth Knowles]

On Mon, Aug 12, 2019 at 3:26 PM Justin Mclean 
wrote:

> Hi,
>
> > I will also note that if the IPMC switches to *voting* Members into the
> > IPMC, that the Apache Member will be observing that vote take place on
> > private@ through a subscription (they can reply!) or via the archives. …
>

> Which is also the same for any project who votes in a ASF member as a
> committer or PMC member.
>


> A vote in front a person is never going to be Fair. There is a natural
> > misgiving to speak out against a person, to their face. You will likely
> not
> > get the -1 votes that may be deserved.


This is already the case for PMC votes in general, since if it goes through
(now or ever) they can view the archives to see the -1 votes. I don't think
this case is very different from that, in terms of chilling effect.

Anyhow I'm -0 because I think the rationale is sound but I don't think the
cost/benefit pays off. Julian's idea of actively recruiting folks currently
going through incubation or recently graduated seems a better avenue.

Kenn




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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[P. Taylor Goetz]

I posted the following in a private@ thread:

Traditionally ASF membership + expressed interest has been the main path to the 
IPMC. Honestly, I think “someone who has significantly helped a project 
navigate incubation through to successful graduation” holds at least as much 
merit as ASF membership. 

There’s the added benefit of recent experience. My experience with the 
incubator 5-6 years ago is likely different than what podlings experience 
today. The core values haven’t changed, but some processes have. 

That is where I see new blood brings value.

———

I see value in lowing the bar for entry to the IPMC. I also see value in 
allowing interested Members to auto-join. Default to inclusivity.

-Taylor

> On Aug 12, 2019, at 7:29 PM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 
> wrote:
> 
>> Hi,
>> 
>>> I will also note that if the IPMC switches to *voting* Members into the
>>> IPMC, that the Apache Member will be observing that vote take place on
>>> private@ through a subscription (they can reply!) or via the archives. …
>> 
>> Which is also the same for any project who votes in a ASF member as a
>> committer or PMC member.
>> 
> 
> I would counter that any project which creates such a bar for ASF Members
> may be doing it Wrong :)
> 
> (this goes into my general feeling that projects generally need to lower
> their bars, and become more inclusive)
> 
> Cheers,
> -g

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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Dave Fisher]

> On Aug 12, 2019, at 4:29 PM, Greg Stein  wrote:
> 
> On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 
> wrote:
> 
>> Hi,
>> 
>>> I will also note that if the IPMC switches to *voting* Members into the
>>> IPMC, that the Apache Member will be observing that vote take place on
>>> private@ through a subscription (they can reply!) or via the archives. …
>> 
>> Which is also the same for any project who votes in a ASF member as a
>> committer or PMC member.
>> 
> 
> I would counter that any project which creates such a bar for ASF Members
> may be doing it Wrong :)
> 
> (this goes into my general feeling that projects generally need to lower
> their bars, and become more inclusive)

I really think that we have long precedent to do most of what we need to do 
already in place.

I’m -1 on this proposal. I think it is a bad idea. It is so bad that I would 
seriously think about volunteering here less.

Just think about how many VOTEs we would need to do when a Podling comes in. 
Think about all the pro forma votes and discussions about people. BORING!

Frankly, I’m quite surprised that this is even being proposed.

Regards,
Dave

> 
> Cheers,
> -g


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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Greg Stein]

On Mon, Aug 12, 2019 at 5:26 PM Justin Mclean 
wrote:

> Hi,
>
> > I will also note that if the IPMC switches to *voting* Members into the
> > IPMC, that the Apache Member will be observing that vote take place on
> > private@ through a subscription (they can reply!) or via the archives. …
>
> Which is also the same for any project who votes in a ASF member as a
> committer or PMC member.
>

I would counter that any project which creates such a bar for ASF Members
may be doing it Wrong :)

(this goes into my general feeling that projects generally need to lower
their bars, and become more inclusive)

Cheers,
-g

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[David Jencks]

I don’t understand how obstructing people from becoming mentors is going to 
increase their involvement.  In the unlikely event that I got interested enough 
in an incoming project to want to mentor it, no matter what rules are in place, 
my doing so depends on my commitment to actually mentoring. Putting additional 
hoops in place to jump through would just make me think that there’s too much 
bureaucracy not related to actually mentoring.

I think you want a way of asking potential mentors, “Are you sure you want to 
do this? Really? Truly? If you sign up to mentor and disappear you will be 
dragging the project down and pushing it away from Apache.  Are you still 
sure?” Why not just ask them directly?

David Jencks

> On Aug 12, 2019, at 3:34 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Is there a problem we are trying to solve or is this just a concern that
>> it might become a problem as we scale?
> 
> It’s already a problem. I suggest you look at the missing mentors / mentors 
> who don’t sign off report and look at how they were appointed. I can post the 
> stats if you want, but perhaps not to this list.
> 
> Changing this would also mean people who want to be IPMC members need to do a 
> little work at the IPMC (and it should be a low bar), that hopefully means 
> more a bit more knowledge transfer / active mentors self select and a few 
> more people helping the IPMC out.
> 
> Plus it’s different to how every other PMC appoints people, I don't see why 
> the incubator needs to be special in this regard.
> 
> 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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[sebb]

On Mon, 12 Aug 2019 at 23:35, Justin Mclean  wrote:
>
> Hi,
>
> > Is there a problem we are trying to solve or is this just a concern that
> > it might become a problem as we scale?
>
> It’s already a problem. I suggest you look at the missing mentors / mentors 
> who don’t sign off report and look at how they were appointed. I can post the 
> stats if you want, but perhaps not to this list.
>
> Changing this would also mean people who want to be IPMC members need to do a 
> little work at the IPMC (and it should be a low bar), that hopefully means 
> more a bit more knowledge transfer / active mentors self select and a few 
> more people helping the IPMC out.
>
> Plus it’s different to how every other PMC appoints people, I don't see why 
> the incubator needs to be special in this regard.

I think this may cause more work for the Incubator.
Instead of ASF members offering themselves, the PMC will have to
actively seek out new candidates.

Also, I don't think there is anything stopping the IPMC from inviting
new members now.


> 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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Justin Mclean]

Hi,

> Is there a problem we are trying to solve or is this just a concern that
> it might become a problem as we scale?

It’s already a problem. I suggest you look at the missing mentors / mentors who 
don’t sign off report and look at how they were appointed. I can post the stats 
if you want, but perhaps not to this list.

Changing this would also mean people who want to be IPMC members need to do a 
little work at the IPMC (and it should be a low bar), that hopefully means more 
a bit more knowledge transfer / active mentors self select and a few more 
people helping the IPMC out.

Plus it’s different to how every other PMC appoints people, I don't see why the 
incubator needs to be special in this regard.

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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Justin Mclean]

Hi,

> I will also note that if the IPMC switches to *voting* Members into the
> IPMC, that the Apache Member will be observing that vote take place on
> private@ through a subscription (they can reply!) or via the archives. …

Which is also the same for any project who votes in a ASF member as a committer 
or PMC member.

Thanks,
Justin



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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Kevin A. McGrail]

On 8/12/2019 5:28 PM, Greg Stein wrote:
> I'm -0 on removal of the precedent.

Is there a problem we are trying to solve or is this just a concern that
it might become a problem as we scale?

-- 
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


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

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Greg Stein]

On Fri, Aug 9, 2019 at 12:04 AM Justin Mclean 
wrote:

> Hi,
>
> Current any ASF member can come along and ask to join the IPMC. I assume
> this was put in place for two reasons: ( but don’t know the full history
> behind it)
> - There was a lack of mentors.
> - Is is assumed that if you are an ASF member you know enough about the
> Apache Way to mentor a project.
>

The latter, definitely. I don't recall if the former is true.

I'm -0 on removal of the precedent.

I will also note that if the IPMC switches to *voting* Members into the
IPMC, that the Apache Member will be observing that vote take place on
private@ through a subscription (they can reply!) or via the archives. ...
A vote in front a person is never going to be Fair. There is a natural
misgiving to speak out against a person, to their face. You will likely not
get the -1 votes that may be deserved.

Cheers,
-g

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Julian Hyde]

Thanks, Gian. I bet you’re familiar with DataSketches (as it has 
ancestry/people in common with Druid) and I recall that recently they needed 
more mentors.


> On Aug 12, 2019, at 2:06 PM, Gian Merlino  wrote:
> 
> One more voice here: I'm not an ASF member, but I'd be interested in
> mentoring other podlings after Druid graduates. Julian has been very
> helpful to us while we've been incubating and I'd like to pay it forward.
> 
> On Mon, Aug 12, 2019 at 11:12 AM Julian Hyde  wrote:
> 
>> I don’t have a strong opinion on the subject of this thread - whether it
>> should be easy for ASF members to join the IPMC - but I have a strong
>> opinion about a related matter - namely, how easy it should be for non-ASF
>> members to join the IPMC.
>> 
>> The IPMC should be actively recruiting members of recently-graduated
>> projects to serve as mentors of the next generation of podlings.
>> 
>> I bet quite a few people people think that you have to be an ASF member to
>> be on the IPMC or mentor a project. And we certainly give the impression
>> that ASF members make the best mentors. But I claim that people who have
>> just been through the incubation process also make excellent mentors. They
>> have experienced the pain, and they know the answers to many of the IT- and
>> process-related questions because they have just solved them.
>> 
>> Like Sheng, I joined the IPMC before I was a member. The project I
>> founded, Calcite, was close to graduating and I was active on general@
>> because being a podling is hard and raises many questions. Some other
>> podlings were entering incubation and someone (I think Ted Dunning or Alan
>> Gates) asked me to be a mentor. From that, I was drawn into other Apache
>> projects, saw the broader Apache community, and was drawn into the worthy
>> task of helping to govern the Foundation. For me, serving as a mentor was a
>> way of saying ’thank you’ for the help I had received from mentors during
>> incubation. And for the IPMC, it provided an active and engaged mentor,
>> always a scarce resource.
>> 
>> Julian
>> 
>> 
>>> On Aug 8, 2019, at 10:29 PM, Sheng Wu  wrote:
>>> 
>>> Hi
>>> 
>>> My Apache journey started at Incubator, and as IPMC now(not asf member).
>> I
>>> noticed this requirement too.
>>> 
>>> From the members I known personally, most indeed know Apache way very
>> well.
>>> And truely there is exception.
>>> 
>>> Basically, I think removing this makes sense.
>>> 
>>> 1. if this member has been incubator journey, such as being initial
>>> committer of a podling, it is easy to know and should have taken part in
>>> incubator ml much.
>>> 
>>> 2. there are indeed asf members elected by other reasons, so, they are
>> not
>>> familiar w/ incubator, and need more time to learn too. Apache has so
>> many
>>> TLPs and ways to take part in, a member is not required used to be
>>> incubator.
>>> 
>>> My +1 on IPMC should have enough incubator experiences.
>>> 
>>> Also, very open to know the history reason of this.
>>> 
>>> Sheng
>>> 
>>> Justin Mclean 于2019年8月9日 周五下午1:04写道：
>>> 
 Hi,
 
 Current any ASF member can come along and ask to join the IPMC. I assume
 this was put in place for two reasons: ( but don’t know the full history
 behind it)
 - There was a lack of mentors.
 - Is is assumed that if you are an ASF member you know enough about the
 Apache Way to mentor a project.
 
 I’m not sure if this is the case anymore. And while the mentor situation
 has improved I don’t think the above has solved the problem of having
 active members or mentors having the required knowledge and skills they
 need.
 
 So if you want to be a IPMC member and mentor a project then I think you
 need you have gone through the full incubation process yourself and/or
>> help
 out with other incubator duties and get voted in as an IPMC member. Just
 like every other ASF project.
 
 What do other people think?
 
 Thanks,
 Justin
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 --
>>> Sheng Wu
>>> SkyWalking, Shardingsphere and Zipkin
>> 
>> 
>> -
>> 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: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Gian Merlino]

One more voice here: I'm not an ASF member, but I'd be interested in
mentoring other podlings after Druid graduates. Julian has been very
helpful to us while we've been incubating and I'd like to pay it forward.

On Mon, Aug 12, 2019 at 11:12 AM Julian Hyde  wrote:

> I don’t have a strong opinion on the subject of this thread - whether it
> should be easy for ASF members to join the IPMC - but I have a strong
> opinion about a related matter - namely, how easy it should be for non-ASF
> members to join the IPMC.
>
> The IPMC should be actively recruiting members of recently-graduated
> projects to serve as mentors of the next generation of podlings.
>
> I bet quite a few people people think that you have to be an ASF member to
> be on the IPMC or mentor a project. And we certainly give the impression
> that ASF members make the best mentors. But I claim that people who have
> just been through the incubation process also make excellent mentors. They
> have experienced the pain, and they know the answers to many of the IT- and
> process-related questions because they have just solved them.
>
> Like Sheng, I joined the IPMC before I was a member. The project I
> founded, Calcite, was close to graduating and I was active on general@
> because being a podling is hard and raises many questions. Some other
> podlings were entering incubation and someone (I think Ted Dunning or Alan
> Gates) asked me to be a mentor. From that, I was drawn into other Apache
> projects, saw the broader Apache community, and was drawn into the worthy
> task of helping to govern the Foundation. For me, serving as a mentor was a
> way of saying ’thank you’ for the help I had received from mentors during
> incubation. And for the IPMC, it provided an active and engaged mentor,
> always a scarce resource.
>
> Julian
>
>
> > On Aug 8, 2019, at 10:29 PM, Sheng Wu  wrote:
> >
> > Hi
> >
> > My Apache journey started at Incubator, and as IPMC now(not asf member).
> I
> > noticed this requirement too.
> >
> > From the members I known personally, most indeed know Apache way very
> well.
> > And truely there is exception.
> >
> > Basically, I think removing this makes sense.
> >
> > 1. if this member has been incubator journey, such as being initial
> > committer of a podling, it is easy to know and should have taken part in
> > incubator ml much.
> >
> > 2. there are indeed asf members elected by other reasons, so, they are
> not
> > familiar w/ incubator, and need more time to learn too. Apache has so
> many
> > TLPs and ways to take part in, a member is not required used to be
> > incubator.
> >
> > My +1 on IPMC should have enough incubator experiences.
> >
> > Also, very open to know the history reason of this.
> >
> > Sheng
> >
> > Justin Mclean 于2019年8月9日 周五下午1:04写道：
> >
> >> Hi,
> >>
> >> Current any ASF member can come along and ask to join the IPMC. I assume
> >> this was put in place for two reasons: ( but don’t know the full history
> >> behind it)
> >> - There was a lack of mentors.
> >> - Is is assumed that if you are an ASF member you know enough about the
> >> Apache Way to mentor a project.
> >>
> >> I’m not sure if this is the case anymore. And while the mentor situation
> >> has improved I don’t think the above has solved the problem of having
> >> active members or mentors having the required knowledge and skills they
> >> need.
> >>
> >> So if you want to be a IPMC member and mentor a project then I think you
> >> need you have gone through the full incubation process yourself and/or
> help
> >> out with other incubator duties and get voted in as an IPMC member. Just
> >> like every other ASF project.
> >>
> >> What do other people think?
> >>
> >> Thanks,
> >> Justin
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >> --
> > Sheng Wu
> > SkyWalking, Shardingsphere and Zipkin
>
>
> -
> 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)

[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: [VOTE] Release Apache Druid (incubating) 0.15.1 [RC2]

[Julian Hyde]

+1 (binding)

Checked hashes; in -src.tar.gz, checked license, notice, disclaimer, readme; 
compiled from source (skipping tests) on Ubuntu/JDK 8; ran RAT; checked that 
src tarball contents match git commit c698daa.

Did not examine -bin.tar.gz.

Julian


> On Aug 9, 2019, at 5:28 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> +1 (binding)
> 
> I checked:
> - incubating in name
> - signatures and hashes fine
> - LICENSE is fine
> - NOTICE may need a little work
> - No unexpected binary files
> - Source files have ASF headers
> - Can compile from source
> 
> NOTICE mentions using code From Apache Hive, Apache Lucerne, Apache Hadoop 
> and Apache Calcite. Only Calcite is mentioned in your NOTICE file and all of 
> those projects have NOTICE files, Jets3t contains a NOTICE file [3] so I 
> think more needs to go in your NOTICE file.
> 
> I am sort of curious how this is licensed [1] and if that should go in 
> LICENSE? (which I don’t think is an issue) and if you had permission from the 
> people to use and distribute the content in [2]
> 
> Thanks,
> Justin
> 
> 1. core/src/test/resources/loremipsum.txt
> 2. 
> apache-druid-0.15.1-incubating-src/examples/quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz
> 3. https://bitbucket.org/jmurty/jets3t/src/default/NOTICE.txt
> -
> 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: [VOTE] Release Apache Druid (incubating) 0.15.1 [RC2]

[Clint Wylie]

Hi Justin,

Thank you so much for taking the time to have a look and for the +1 vote.

> NOTICE mentions using code From Apache Hive, Apache Lucerne, Apache
Hadoop and Apache Calcite. Only Calcite is mentioned in your NOTICE file
and all of those projects have NOTICE files, Jets3t contains a NOTICE file
[3] so I think more needs to go in your NOTICE file.

I was not directly involved in this, but it is my understanding that the
modifications to our source NOTICE file between 0.15.0-incubating and this
version are a result of this thread on the IPMC vote,
https://mail-archives.apache.org/mod_mbox/incubator-general/201906.mbox/%3CCAOGo0VZoqnNuMdBsbiPB1gzqdR_WAp8wyBx7jeANaKKkm6pavQ%40mail.gmail.com%3E.
which suggested that the NOTICE files should contain only what is strictly
required for the files actually contained in the bundle to which they
apply. Based on this, only code we adapted from Apache Calcite fits this
interpretation of how to construct NOTICE files, so we have removed the
others that you listed for the source distribution NOTICE. NOTICE.BINARY
still has the NOTICE file contents for those that you listed which we
bundle (we don't bundle Lucene so it isn't present).
https://github.com/apache/incubator-druid/pull/7945 is the pull request
where the changes were done for reference.

> I am sort of curious how this is licensed [1] and if that should go in
LICENSE? (which I don’t think is an issue) and if you had permission from
the people to use and distribute the content in [2]

With regards to the 'lorem ipsum' text, I am unsure of how this is licensed
and somewhat surprised how hard this seems to be to find out, but I will
try to determine this (or replace the text with something else since it is
just used for a compression test) before the next release. I believe the
wikiticker-2015-09-12-sampled.json.gz data was collected by Gian Merlino
from an IRC channel where a bot prints out all wikipedia edit activity in
real-ish time. I don't know and haven't yet found out the ownership details
of the contents of that IRC channel, I will try to follow-up and resolve
this as soon as I figure out how to do so.

Cheers,
Clint

On Fri, Aug 9, 2019 at 5:28 PM Justin Mclean 
wrote:

> Hi,
>
> +1 (binding)
>
> I checked:
> - incubating in name
> - signatures and hashes fine
> - LICENSE is fine
> - NOTICE may need a little work
> - No unexpected binary files
> - Source files have ASF headers
> - Can compile from source
>
> NOTICE mentions using code From Apache Hive, Apache Lucerne, Apache Hadoop
> and Apache Calcite. Only Calcite is mentioned in your NOTICE file and all
> of those projects have NOTICE files, Jets3t contains a NOTICE file [3] so I
> think more needs to go in your NOTICE file.
>
> I am sort of curious how this is licensed [1] and if that should go in
> LICENSE? (which I don’t think is an issue) and if you had permission from
> the people to use and distribute the content in [2]
>
> Thanks,
> Justin
>
> 1. core/src/test/resources/loremipsum.txt
> 2.
> apache-druid-0.15.1-incubating-src/examples/quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz
> 3. https://bitbucket.org/jmurty/jets3t/src/default/NOTICE.txt
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Drop requirement that ASF members can join IPMC by just asking

[Julian Hyde]

I don’t have a strong opinion on the subject of this thread - whether it should 
be easy for ASF members to join the IPMC - but I have a strong opinion about a 
related matter - namely, how easy it should be for non-ASF members to join the 
IPMC.

The IPMC should be actively recruiting members of recently-graduated projects 
to serve as mentors of the next generation of podlings.

I bet quite a few people people think that you have to be an ASF member to be 
on the IPMC or mentor a project. And we certainly give the impression that ASF 
members make the best mentors. But I claim that people who have just been 
through the incubation process also make excellent mentors. They have 
experienced the pain, and they know the answers to many of the IT- and 
process-related questions because they have just solved them.

Like Sheng, I joined the IPMC before I was a member. The project I founded, 
Calcite, was close to graduating and I was active on general@ because being a 
podling is hard and raises many questions. Some other podlings were entering 
incubation and someone (I think Ted Dunning or Alan Gates) asked me to be a 
mentor. From that, I was drawn into other Apache projects, saw the broader 
Apache community, and was drawn into the worthy task of helping to govern the 
Foundation. For me, serving as a mentor was a way of saying ’thank you’ for the 
help I had received from mentors during incubation. And for the IPMC, it 
provided an active and engaged mentor, always a scarce resource.

Julian
 

> On Aug 8, 2019, at 10:29 PM, Sheng Wu  wrote:
> 
> Hi
> 
> My Apache journey started at Incubator, and as IPMC now(not asf member). I
> noticed this requirement too.
> 
> From the members I known personally, most indeed know Apache way very well.
> And truely there is exception.
> 
> Basically, I think removing this makes sense.
> 
> 1. if this member has been incubator journey, such as being initial
> committer of a podling, it is easy to know and should have taken part in
> incubator ml much.
> 
> 2. there are indeed asf members elected by other reasons, so, they are not
> familiar w/ incubator, and need more time to learn too. Apache has so many
> TLPs and ways to take part in, a member is not required used to be
> incubator.
> 
> My +1 on IPMC should have enough incubator experiences.
> 
> Also, very open to know the history reason of this.
> 
> Sheng
> 
> Justin Mclean 于2019年8月9日 周五下午1:04写道：
> 
>> Hi,
>> 
>> Current any ASF member can come along and ask to join the IPMC. I assume
>> this was put in place for two reasons: ( but don’t know the full history
>> behind it)
>> - There was a lack of mentors.
>> - Is is assumed that if you are an ASF member you know enough about the
>> Apache Way to mentor a project.
>> 
>> I’m not sure if this is the case anymore. And while the mentor situation
>> has improved I don’t think the above has solved the problem of having
>> active members or mentors having the required knowledge and skills they
>> need.
>> 
>> So if you want to be a IPMC member and mentor a project then I think you
>> need you have gone through the full incubation process yourself and/or help
>> out with other incubator duties and get voted in as an IPMC member. Just
>> like every other ASF project.
>> 
>> What do other people think?
>> 
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> --
> Sheng Wu
> SkyWalking, Shardingsphere and Zipkin


-
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)

[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)

[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: [DISCUSS] IPMC votes on releases

[Dave Fisher]

Hi -

> On Aug 12, 2019, at 6:41 AM, Matt Sicker  wrote:
> 
> This observer IPMC role sounds interesting. That would make it less
> intimidating for people who can help verify a generic release but are
> unfamiliar with the domain itself.

We currently have Shepherds to look into podlings at report time. This is for 
how they are doing in the community.

If we have an observer role, I don’t think it needs to be formal. It would 
simply be to be a freelance release auditor. Perhaps those people willing to be 
an extra IPMC on a community dev@ vote could subscribe to a special mailing 
list. When a podling starts a release and suspects they don’t have enough 
Mentors engaged they can send a email to revi...@incubator.apache.org 
requesting help. (Some might say use general@ that’s ok too.)

This is similar to Mryle’s REVIEW proposal. It just becomes about timing.

Also, if a podling regularly has trouble with enough IPMC votes for their dev@ 
releases then a discussion is needed about finding new volunteer mentors.

Regards,
Dave


> 
> On Mon, Aug 12, 2019 at 03:37, Julian Feinauer 
> wrote:
> 
>> Hi,
>> 
>> I'm answering to this (old) thread as the new one branched up with a
>> different topic.
>> Personally, during my time in the first podling I learned a lot by doing
>> Apache Releases.
>> First, as contributor, then as PPMC and finally as RM.
>> And this is something valuable and if a project wants to become a TLP
>> something people have to learn.
>> And not only one or two but better every PPMC member (and some even able
>> to RM).
>> 
>> So I suggest to encourage Podlings as much as possible to to ASF releases.
>> I would suggest to solve all the current issues by setting the rules up in
>> a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC
>> Vote which are then carried over and make the IPMC Vote basically "lazy
>> consensus".
>> 
>> To do this I would suggest to set up / change the "Mentor Guideline" that
>> a Mentor "should" vote on PPMC releases.
>> Furthermore, in addition to 3 (active?!) Mentors we could add 2-3
>> "assessors" or "observers" (from the IPMC) who do not help actively but are
>> on the list and whos dutie is to support Releases.
>> That would make a pool of 5-6 IPMC members for each podling which should
>> be encouraged to VOTE on releases.
>> 
>> Then, we could, step by step, tackle podlings to bring their Vote to the
>> IPMC only if they have 3 +1 votes.
>> 
>> This would allow us to keep all global rules of the ASF as is and only
>> change Incubator "internals".
>> I think we should really start to see Mentoring as something which needs
>> time and work and which people should only call in if they feel like they
>> can do.
>> For everything else we could have this "observer" role where people that
>> find the project interesting could simply take to watch and monitor it but
>> with their Votes also help the incubator a lot.
>> 
>> Julian
>> 
>> Am 12.08.19, 02:46 schrieb "Greg Stein" :
>> 
>>On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <
>> jus...@classsoftware.com>
>>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 unsubsc

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

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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: [DISCUSS] IPMC votes on releases

[Matt Sicker]

This observer IPMC role sounds interesting. That would make it less
intimidating for people who can help verify a generic release but are
unfamiliar with the domain itself.

On Mon, Aug 12, 2019 at 03:37, Julian Feinauer 
wrote:

> Hi,
>
> I'm answering to this (old) thread as the new one branched up with a
> different topic.
> Personally, during my time in the first podling I learned a lot by doing
> Apache Releases.
> First, as contributor, then as PPMC and finally as RM.
> And this is something valuable and if a project wants to become a TLP
> something people have to learn.
> And not only one or two but better every PPMC member (and some even able
> to RM).
>
> So I suggest to encourage Podlings as much as possible to to ASF releases.
> I would suggest to solve all the current issues by setting the rules up in
> a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC
> Vote which are then carried over and make the IPMC Vote basically "lazy
> consensus".
>
> To do this I would suggest to set up / change the "Mentor Guideline" that
> a Mentor "should" vote on PPMC releases.
> Furthermore, in addition to 3 (active?!) Mentors we could add 2-3
> "assessors" or "observers" (from the IPMC) who do not help actively but are
> on the list and whos dutie is to support Releases.
> That would make a pool of 5-6 IPMC members for each podling which should
> be encouraged to VOTE on releases.
>
> Then, we could, step by step, tackle podlings to bring their Vote to the
> IPMC only if they have 3 +1 votes.
>
> This would allow us to keep all global rules of the ASF as is and only
> change Incubator "internals".
> I think we should really start to see Mentoring as something which needs
> time and work and which people should only call in if they feel like they
> can do.
> For everything else we could have this "observer" role where people that
> find the project interesting could simply take to watch and monitor it but
> with their Votes also help the incubator a lot.
>
> Julian
>
> Am 12.08.19, 02:46 schrieb "Greg Stein" :
>
> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <
> jus...@classsoftware.com>
> 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
>
-- 
Matt Sicker 

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

[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)

[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: [DISCUSS] Incubation Proposal of MesaTEE

[Mingshen Sun]

Hi Matt, thanks. We’re glad to have you as a mentor.

--
Mingshen

On Sat, Aug 10, 2019 at 8:13 AM Matt Sicker  wrote:

> I’d most likely be interested in mentoring this project, but I’m not that
> experienced in incubator mentorship. If we have another more experienced
> mentor to work with us, I’d be happy to mentor as well.
>
> On Sat, Aug 10, 2019 at 04:13, Mingshen Sun  wrote:
>
> > Thanks Justin, regarding to your questions:
> >
> > On Thu, Aug 8, 2019 at 2:46 AM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > Thanks for the proposal, it sound like a really interesting project.
> > >
> > > > == Core Developers ==
> > > >
> > > > Current core developers work at Baidu. We are confident that
> > incubation will
> > > > help us grow a diverse community in an open and collaborative way.
> > > >
> > > > The risk of abandonment of MesaTEE is low. MesaTEE has been incubated
> > at Baidu
> > > > for over two years. Baidu is committed to the further development of
> > the project
> > > > and will keep investing resources towards the Apache processes and
> > community
> > > > building, during the incubation period.
> > >
> > > Incubation can sometimes take 2 years or more. Given few people with
> > experience at Apache are involved with this project and the core
> developers
> > are from one company, it may take longer that indicated in this proposal.
> >
> > We understand the incubation could take 2 years or more. Recently, we
> > have already received some pull requests from third-parties.
> > Therefore, during the incubation period, we will try to
> > attract/involved engineers from other companies as constant
> > committers.
> >
> > >
> > > > == Continuous Integration Service ==
> > > >
> > > > MesaTEE currently uses self-hosted continuous integration (CI)
> service
> > which can
> > > > help developers to automatically test commits. The CI service
> involves
> > several
> > > > nodes which support Intel SGX. We would like to continue doing so.
> > >
> > > This may not be possible, what would the project do if that was the
> > case? Have you discussed this with your proposed mentors or infra?
> >
> > About the CI infrastructure, actually, the "self-hosted CI" is not our
> > internal infra, we are using a open source CI service (Drone CI) with
> > our servers/NUC with SGX supported. To answer your questions, we have
> > several solutions:
> >   - we can use simulation mode for basic CI testing (by using existing
> > infra in Apache for example). And before merging a pull request, full
> > testing on a SGX supported machine is required
> >   - donating our SGX machines for CI services to Apache is another
> > option we may consider, but this should be further discussed
> >
> > > >  * Zhijie Shen 
> > >
> > > Is not currently an IPMC member, only IPMC members can officially be
> > mentors.
> > >
> > > Of the three mentors listed 2 have never been mentors to my knowledge,
> > have they been involved with any other projects going through the
> > incubating process at Apache? The third mentor may be a little
> overextended
> > given the number of podlings they mentors. Having only one experienced
> > mentor may be a risk to the project. What will you do if your mentors go
> > missing or unable to help?
> >
> > I have talked with Zhijie Shen. He is very interested in helping us.
> > Currently, he is a member of incubator and can apply for IPMC. In
> > addition to Zhijie Shen, Jianyong Dai, and Luciano Resende, Furkan
> > Kamaci also volunteered to become one of our mentors after posting
> > this proposal in the mailing list. We understand this is a large
> > project and need experienced mentors. We are very open to include more
> > mentors who are interested in the project.
> >
> > -
> > Mingshen
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Matt Sicker 
>

Re: [DISCUSS] IPMC votes on releases

[Julian Feinauer]

Hi,

I'm answering to this (old) thread as the new one branched up with a different 
topic.
Personally, during my time in the first podling I learned a lot by doing Apache 
Releases.
First, as contributor, then as PPMC and finally as RM.
And this is something valuable and if a project wants to become a TLP something 
people have to learn.
And not only one or two but better every PPMC member (and some even able to RM).

So I suggest to encourage Podlings as much as possible to to ASF releases.
I would suggest to solve all the current issues by setting the rules up in a 
way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC Vote 
which are then carried over and make the IPMC Vote basically "lazy consensus".

To do this I would suggest to set up / change the "Mentor Guideline" that a 
Mentor "should" vote on PPMC releases.
Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 "assessors" 
or "observers" (from the IPMC) who do not help actively but are on the list and 
whos dutie is to support Releases.
That would make a pool of 5-6 IPMC members for each podling which should be 
encouraged to VOTE on releases.

Then, we could, step by step, tackle podlings to bring their Vote to the IPMC 
only if they have 3 +1 votes.

This would allow us to keep all global rules of the ASF as is and only change 
Incubator "internals".
I think we should really start to see Mentoring as something which needs time 
and work and which people should only call in if they feel like they can do.
For everything else we could have this "observer" role where people that find 
the project interesting could simply take to watch and monitor it but with 
their Votes also help the incubator a lot.

Julian

Am 12.08.19, 02:46 schrieb "Greg Stein" :

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