Re: A smaller IPMC

[Furkan KAMACI]

Hi All,

+1 for #4

I think that we should focus on what is the underlying reason. I suggest
starting a new thread to point for such purpose. We need to address the
problem for both newcomers and long-standing members. For example, I
personally think that it is not fluid at some points how incubator works,
what is the general flow of a mentor's task, how to verify a release for a
newcomer. As another example, there are many people who know what is a
majority vote (
https://www.apache.org/foundation/glossary.html#MajorityApproval) but does
not know `which requires a majority vote and which lazy consensus (
https://www.apache.org/foundation/glossary.html#LazyConsensus) So, such
lack of knowledge may prevent people to engage with the community.

We can start a poll about detecting underlying problems (both for getting
feedback and try to understand the knowledge level). Also, these may be
addressed via Apache Training (how to maintain an open source project -
Apache/non-Apache).

However, since this is another topic, as I suggested we should talk about
it at another thread.

Kind Regards,
Furkan KAMACI

On Fri, Mar 8, 2019 at 9:27 AM Justin Mclean 
wrote:

> Hi,
>
> > I think this thread misses the point of the original observation.
>
> Several people has said the issue is that the IPMC is too big and you
> yourself said how IPMC members join was an issue. This email was trying to
> address that. Your response means I guess that you changed your mind?
>
> > What I've seen is a suggestion that active IPMC members on general@
> should be expected to be on the private list.
>
> At least one person said they should be removed. We’ve contacted them all
> one by one several months ago and asked them to sign up. This was mentioned
> in an incubator board report. We also added more moderations to the private
> list. A couple did sign up and a couple stood down form the IPMC, but the
> majority did nothing. Looking at them, most are totally inactive, the few
> who are slightly active occasionally do helpful things. I’m not sure we can
> force them to sign up. (Although I did notice one did today.) Any
> suggestions?
>
> > Secondly, I think the framing of #4 (which I agree with in the context
> of this thread, given the above observation) incorrectly identifies the
> "real" problem. While inactive mentors a problem for individual podlings I
> don't believe they are the cause of the inteference the IPMC can display
> when it comes to things like podling releases.
>
> Do you consider voting on releases by the IPMC to be interference? If
> mentors are not active how do podlings make releases if they cannot get 3
> +1 mentor votes on their list?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [Result][VOTE] Accept Apache TVM into the incubator

[Furkan KAMACI]

Congratulations!

On Thu, Mar 7, 2019 at 9:55 PM Henry Saputra 
wrote:

> Congrats to TVM community. Let's get to work
>
> - Henry
>
> On Wed, Mar 6, 2019 at 5:10 PM Tianqi Chen 
> wrote:
>
> > Thank you, everyone.
> > I will follow up by cross-posting in the TVM community as well as give
> > a public roadmap regarding next steps together with the help from our
> > mentors.  I am traveling this week and will draft and cross-post the
> public
> > roadmap of incubator transition this weekend.
> >
> > Tianqi
> >
> > On Wed, Mar 6, 2019 at 1:47 PM Markus Weimer  wrote:
> >
> > > The vote has concluded with 13 binding and 5 non-binding and 1 unclear
> +1
> > > votes,
> > > no other votes were cast. TVM has been accepted into the incubator. The
> > > voring
> > > tally is below
> > >
> > > Thanks!
> > >
> > > Markus
> > >
> > > Binding +1:
> > >
> > >
> > >   * Sebastian
> > >   * Gon
> > >   * Markus
> > >   * Henry
> > >   * Furkan
> > >   * Felix
> > >   * Timothy
> > >   * Willem
> > >   * Mohammad
> > >   * Sheng
> > >   * Vinayakumar
> > >   * Gosling
> > >   * Jason
> > >
> > >
> > > Non-Binding
> > >
> > >   * Sheng
> > >   * Kellen
> > >   * Cihad
> > >   * Huxing
> > >   * Tianqui
> > >
> > > Undeclared:
> > >
> > >   * Matt
> > >
> > >
> > > On Mon, Mar 4, 2019 at 12:18 AM Jason Dai  wrote:
> > > >
> > > > +1 (binding)
> > > >
> > > > Thanks,
> > > > -Jason
> > > >
> > > > On Mon, Mar 4, 2019 at 2:50 PM Gosling Von 
> > wrote:
> > > >
> > > > > +1, binding
> > > > >
> > > > >
> > > > > Best Regards,
> > > > > Von Gosling
> > > > >
> > > > > > 在 2019年2月28日，下午12:44，Markus Weimer  写道：
> > > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > we've discussed the proposal for the TVM project in [1]. The
> > proposal
> > > > > itself can
> > > > > > be found on the wiki [2].
> > > > > >
> > > > > > According to the Incubator rules[3] I'd like to call a vote to
> > accept
> > > > > the new
> > > > > > TVM project as a podling in the Apache Incubator.
> > > > > >
> > > > > > A vote for accepting a new Apache Incubator podling is a majority
> > > vote.
> > > > > Everyone
> > > > > > is welcome to vote, only Incubator PMC member votes are binding.
> It
> > > > > would be
> > > > > > helpful (but not required) if you could add a comment stating
> > whether
> > > > > your vote
> > > > > > is binding or non-binding.
> > > > > >
> > > > > > This vote will run for at least 72 hours (but I expect to keep it
> > > open
> > > > > for
> > > > > > longer). Please VOTE as follows:
> > > > > >
> > > > > > [ ] +1 Accept TVM into the Apache Incubator
> > > > > > [ ] +0 Abstain
> > > > > > [ ] -1 Do not accept TVM into the Apache Incubator because ...
> > > > > >
> > > > > > Thank you for everyone who decided to join in in the past
> > > discussions!
> > > > > >
> > > > > > Markus
> > > > > >
> > > > > > [1]:
> > > > >
> > >
> >
> https://lists.apache.org/thread.html/e2b1fe9ca76422ec80b146a6b120091f2419e2f1c27d57080f39cf6f@%3Cgeneral.incubator.apache.org%3E
> > > > > >
> > > > > > [2]: https://wiki.apache.org/incubator/TVMProposal
> > > > > >
> > > > > > [3]: https://incubator.apache.org/guides/proposal.html#the_vote
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > > > For additional commands, e-mail:
> general-h...@incubator.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > > >
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: A smaller IPMC

[Justin Mclean]

Hi,

> I think this thread misses the point of the original observation.

Several people has said the issue is that the IPMC is too big and you yourself 
said how IPMC members join was an issue. This email was trying to address that. 
Your response means I guess that you changed your mind?

> What I've seen is a suggestion that active IPMC members on general@ should be 
> expected to be on the private list.

At least one person said they should be removed. We’ve contacted them all one 
by one several months ago and asked them to sign up. This was mentioned in an 
incubator board report. We also added more moderations to the private list. A 
couple did sign up and a couple stood down form the IPMC, but the majority did 
nothing. Looking at them, most are totally inactive, the few who are slightly 
active occasionally do helpful things. I’m not sure we can force them to sign 
up. (Although I did notice one did today.) Any suggestions?

> Secondly, I think the framing of #4 (which I agree with in the context of 
> this thread, given the above observation) incorrectly identifies the "real" 
> problem. While inactive mentors a problem for individual podlings I don't 
> believe they are the cause of the inteference the IPMC can display when it 
> comes to things like podling releases.

Do you consider voting on releases by the IPMC to be interference? If mentors 
are not active how do podlings make releases if they cannot get 3 +1 mentor 
votes on their list?  

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

Re: A smaller IPMC

[Davor Bonaci]

As framed herein, #4 for sure. (But, that doesn't necessarily exclude
support for various ideas that rework how IPMC operates, and where reducing
the size may be a small part of something larger and intentional.)

On Thu, Mar 7, 2019 at 9:13 PM Ross Gardler  wrote:

> I think this thread misses the point of the original observation.
>
> Firstly, I've not seen anyone suggest that removing inactive IPMC members
> will make any difference. What I've seen is a suggestion that active IPMC
> members on general@ should be expected to be on the private list.
>
> While there aren't many conversations over there. When there is one it is
> important.
>
> Secondly, I think the framing of #4 (which I agree with in the context of
> this thread, given the above observation) incorrectly identifies the "real"
> problem. While inactive mentors a problem for individual podlings I don't
> believe they are the cause of the inteference the IPMC can display when it
> comes to things like podling releases.
>
> In other words I consider this whole thread a distraction.
>
> Get Outlook for Android
>
> 
> From: Kenneth Knowles 
> Sent: Thursday, March 7, 2019 7:49:29 PM
> To: general@incubator.apache.org
> Subject: Re: A smaller IPMC
>
> +1 for #4 noop, at least until there's evidence of a problem.
>
> Kenn
>
> On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:
>
> > On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > > It’s been suggested that the IPMC is too large, what do other IPMC
> > members think might be a way to address this?
> > >
> > > Please discuss and indicate +1 what you would think would help, you can
> > vote for more than one.
> > >
> > > Some suggestions:
> > > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> > see who steps down. Being inactive they are probably not following this
> > list so we need to identify and send each one email them personally.
> > > 2. There were some questions around merit raised, remove all IPMC
> > members who were not on the initial proposal and who were voted in. Those
> > left on the IPMC vote back in those who are currently active.
> > > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> > binding - not sure how else it could be done?) currently active ones back
> > in.
> > > 4. Do nothing as this is not actually a problem but instead address
> > other underlying issues. e.g. lack of mentor engagement.
> >
> > +1 to my modified version from #2 (and 0 to the others as I don't
> > think they will help a lot):
> > "Remove all IPMC members who were not on the initial proposal and who
> > were voted in. Those left on the IPMC vote for those, as members, who
> > can recruit, guide mentors, and review podling graduations, and they
> > also vote for those, as mentors (committers), who have ever been
> > active mentors for podlings."
> >
> > Mentors are committers: if someone starts contributing in this
> > community, they are to be recognized and invited to a mentor
> > (committer) in this project; if they contribute more for the community
> > consistently, they are to be invited to a IPMC member. In smaller
> > IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> > graduations in various aspects, and mentors focus more on detail
> > issues in podlings, providing enough overview and information to IPMC.
> > I think this will make it a fairer merit-earning game, to new comers
> > getting helps from mentors and (graduation and/or high-level) reviews
> > from members, watchers considering to help, mentors eager to help
> > graduations, more focused members, ...
> >
> > >
> > > Also re point 2 do you think we should drop that ASF members can
> > automatically get IPMC membership and change it to requiring a vote by
> the
> > IPMC? It’s has always seem odd to me that this is the case. We’ve
> recently
> > voted more people in that we’ve had requests from ASF members.
> >
> > +1 to always be voting, whether they are ASF members or not, like other
> > PMCs.
> >
> > >
> > > Any other sugestions?
> > >
> > > Options 2 and 3 may cause some issues around mentors, but if they were
> > not active then I guess it’s no big loss.
> >
> > My modified version includes all active people as mentors (committers)
> > at least, so there's no loss as well.
> >
> > Regards,
> >
> > Woonsan
> >
> > >
> > > And any suggestions on level of activity? Such as:
> > > - Emailed the list in the last year.
> > > - Reviewed at least one release in that time.
> > >
> > > It’s already been determined that some (about 15%) of the less than
> > active PMC members (out of the 100 odd that are not signed up to the IPMC
> > private list) do help out infrequently but that help is very useful. That
> > may also apply to other inactive IPMC members, so I would suggest the bar
> > for what consider active be kept low.
> > >
> > > Thanks,
> > > Justin
> > > 

Re: A smaller IPMC

[Ross Gardler]

I think this thread misses the point of the original observation.

Firstly, I've not seen anyone suggest that removing inactive IPMC members will 
make any difference. What I've seen is a suggestion that active IPMC members on 
general@ should be expected to be on the private list.

While there aren't many conversations over there. When there is one it is 
important.

Secondly, I think the framing of #4 (which I agree with in the context of this 
thread, given the above observation) incorrectly identifies the "real" problem. 
While inactive mentors a problem for individual podlings I don't believe they 
are the cause of the inteference the IPMC can display when it comes to things 
like podling releases.

In other words I consider this whole thread a distraction.

Get Outlook for Android


From: Kenneth Knowles 
Sent: Thursday, March 7, 2019 7:49:29 PM
To: general@incubator.apache.org
Subject: Re: A smaller IPMC

+1 for #4 noop, at least until there's evidence of a problem.

Kenn

On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:

> On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > It’s been suggested that the IPMC is too large, what do other IPMC
> members think might be a way to address this?
> >
> > Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
> >
> > Some suggestions:
> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> > 2. There were some questions around merit raised, remove all IPMC
> members who were not on the initial proposal and who were voted in. Those
> left on the IPMC vote back in those who are currently active.
> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> > 4. Do nothing as this is not actually a problem but instead address
> other underlying issues. e.g. lack of mentor engagement.
>
> +1 to my modified version from #2 (and 0 to the others as I don't
> think they will help a lot):
> "Remove all IPMC members who were not on the initial proposal and who
> were voted in. Those left on the IPMC vote for those, as members, who
> can recruit, guide mentors, and review podling graduations, and they
> also vote for those, as mentors (committers), who have ever been
> active mentors for podlings."
>
> Mentors are committers: if someone starts contributing in this
> community, they are to be recognized and invited to a mentor
> (committer) in this project; if they contribute more for the community
> consistently, they are to be invited to a IPMC member. In smaller
> IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> graduations in various aspects, and mentors focus more on detail
> issues in podlings, providing enough overview and information to IPMC.
> I think this will make it a fairer merit-earning game, to new comers
> getting helps from mentors and (graduation and/or high-level) reviews
> from members, watchers considering to help, mentors eager to help
> graduations, more focused members, ...
>
> >
> > Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
>
> +1 to always be voting, whether they are ASF members or not, like other
> PMCs.
>
> >
> > Any other sugestions?
> >
> > Options 2 and 3 may cause some issues around mentors, but if they were
> not active then I guess it’s no big loss.
>
> My modified version includes all active people as mentors (committers)
> at least, so there's no loss as well.
>
> Regards,
>
> Woonsan
>
> >
> > And any suggestions on level of activity? Such as:
> > - Emailed the list in the last year.
> > - Reviewed at least one release in that time.
> >
> > It’s already been determined that some (about 15%) of the less than
> active PMC members (out of the 100 odd that are not signed up to the IPMC
> private list) do help out infrequently but that help is very useful. That
> may also apply to other inactive IPMC members, so I would suggest the bar
> for what consider active be kept low.
> >
> > 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] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler]

Projects are free to set their own bylaws. As long as the community as a whole 
agree to removal of inactive members then they can do that. Though merit does 
not and should not expire.

It is my opinion, and the opinion of many others, that keeping busy work to a 
minimum is important to the health of a community. Removing inactive committers 
is busy work. If they come back in x months and provide new patches, bringing 
them back as committers is busy work. If their commit bit remains active but 
they never commit again is not busy work.

Note, at the foundation level a committer remains recognized (their apache.org 
account remains active, for example).

Ross

Get Outlook for Android


From: Dmitriy Pavlov 
Sent: Wednesday, March 6, 2019 12:08:49 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy 
general@ subs check (was:  introduce "[DISCUSS]" threads for podling ... 
release candidates))

Hi Ross,

Thank you for your reply. Apache Ignite PMCs do not support this idea, so
inactive PMCs will be still there.

But still, it is not clear for me in general, why following
projects/guidelines contains removal procedure for Committer PMC:
- 
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmnemonic.apache.org%2Fdevelop%2Fbylaws%2Fdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=qq8L7D0w7Au6yursya5M%2BEVHEDbSMQqVMTYQ1hAEFYk%3Dreserved=0
  after 6 months of inactivity
both PMC and Committer status may be removed.
- Default Incubator guidelines
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.apache.org%2Fincubator%2FDefaultProjectGuidelinesdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=ctQ%2BmlgRbSXVYe5tEQdUhLSZIugzYgVZiPw5nYPna%2FI%3Dreserved=0
 It contains
procedures of consensus-based removal, - it is ok to remove for Incubator?
is it ok for TLP?

If both PMC & Committer roles are merit-based, and merit does not expire,
how it even possible to remove TLP committer/PMC (excepting some extreme
cases)?

This question is not only mine, but it is also often asked and I would like
to know the answer.

Sincerely,
Dmitriy Pavlov

ср, 6 мар. 2019 г. в 18:47, Ross Gardler :

> Merit does not expire. People who are not active today should be able to
> become active tomorrow without having to jump through approval hoops.
>
> In projects there is no concept of emeritus PMC. Here in the IPMC the
> issue is very different. Most people earn merit transitively - become a
> member, become a mentor, become an IPMC member. It's different.
>
> Please don't use what is being discussed here as being transitive to a PMC
> based entirely on directly earned merit.
>
> Get Outlook for 
> Android
>
> 
> From: Dmitriy Pavlov 
> Sent: Tuesday, March 5, 2019 4:46:09 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was:  introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> I absolutely agree with Greg Stein. I can't find any single reason to keep
> unsubscribed members of IPMC in the roster. These members can be asked to
> subscribe, and if they do, then ok; if don't - it is perfectly ok to
> remove.
>
> Similarly, I don't see reasons for having inactive TLP PMC members. I've
> suggested the same change in Apache Ignite, but I don't clearly understand
> why remained members resisting this change.
>
>
> пн, 4 мар. 2019 г. в 09:58, Ross Gardler :
>
> > That's right Greg. And since we are filling in gaps for people...
> >
> > I was originally against the pTLP concept (though I supported the
> > experiments) or any of the derivatives that came from it. I think I have
> > changed my position. Largely based on the fact that every single project
> > I've discussed the ASF with in the last 3-5 years has had a very
> inaccurate
> > perception of how the ASF works. I believe a large part of this is due,
> in
> > part, to the issues being discussed in this thread.
> >
> > I do not understand how a foundation which prides itself in having very
> > little bureaucratic red tape can be seen as having so much red tape. The
> > projects I talk to just want to build software. It used to be that the
> ASF
> > focused on running the legal and operational aspects of the foundation
> > projects and developers on projects wrote code. I'm not sure that's true
> > anymore.
> >
> > We need to fix it.
> >
> > I look forward to hearing how the IPMC will seek to strip down the

[ANNOUNCE] Apache Pinot (incubating) 0.1.0 released

[Seunghyun Lee]

Hello community,

We are pleased to announce that Apache Pinot (incubating) 0.1.0 is released!

Apache Pinot (incubating) is a distributed columnar storage engine that can
ingest data in realtime and serve analytical queries at low latency.

The release can be downloaded at: https://pinot.apache.org/download

The release note is available at:
https://github.com/apache/incubator-pinot/releases

If you want to know more about Pinot, please visit our project website:
https://pinot.apache.org

Also, you are welcome to join and participate to Pinot community by
subscribing to d...@pinot.apache.org

Best Regards,
Apache Pinot (incubating) Team



*DISCLAIMER*
Apache Pinot (incubating) is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection of
the completeness or stability of the code, it does indicate that the
project has yet to be fully endorsed by the ASF.

Re: A smaller IPMC

[Kenneth Knowles]

+1 for #4 noop, at least until there's evidence of a problem.

Kenn

On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:

> On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > It’s been suggested that the IPMC is too large, what do other IPMC
> members think might be a way to address this?
> >
> > Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
> >
> > Some suggestions:
> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> > 2. There were some questions around merit raised, remove all IPMC
> members who were not on the initial proposal and who were voted in. Those
> left on the IPMC vote back in those who are currently active.
> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> > 4. Do nothing as this is not actually a problem but instead address
> other underlying issues. e.g. lack of mentor engagement.
>
> +1 to my modified version from #2 (and 0 to the others as I don't
> think they will help a lot):
> "Remove all IPMC members who were not on the initial proposal and who
> were voted in. Those left on the IPMC vote for those, as members, who
> can recruit, guide mentors, and review podling graduations, and they
> also vote for those, as mentors (committers), who have ever been
> active mentors for podlings."
>
> Mentors are committers: if someone starts contributing in this
> community, they are to be recognized and invited to a mentor
> (committer) in this project; if they contribute more for the community
> consistently, they are to be invited to a IPMC member. In smaller
> IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> graduations in various aspects, and mentors focus more on detail
> issues in podlings, providing enough overview and information to IPMC.
> I think this will make it a fairer merit-earning game, to new comers
> getting helps from mentors and (graduation and/or high-level) reviews
> from members, watchers considering to help, mentors eager to help
> graduations, more focused members, ...
>
> >
> > Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
>
> +1 to always be voting, whether they are ASF members or not, like other
> PMCs.
>
> >
> > Any other sugestions?
> >
> > Options 2 and 3 may cause some issues around mentors, but if they were
> not active then I guess it’s no big loss.
>
> My modified version includes all active people as mentors (committers)
> at least, so there's no loss as well.
>
> Regards,
>
> Woonsan
>
> >
> > And any suggestions on level of activity? Such as:
> > - Emailed the list in the last year.
> > - Reviewed at least one release in that time.
> >
> > It’s already been determined that some (about 15%) of the less than
> active PMC members (out of the 100 odd that are not signed up to the IPMC
> private list) do help out infrequently but that help is very useful. That
> may also apply to other inactive IPMC members, so I would suggest the bar
> for what consider active be kept low.
> >
> > 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: A smaller IPMC

[Ted Dunning]

Woonsan

I think that there may be some cross-talk between discussions. This latest
discussion was about the Ipmc ,not about the podling PMCs.



On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:

> On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > It’s been suggested that the IPMC is too large, what do other IPMC
> members think might be a way to address this?
> >
> > Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
> >
> > Some suggestions:
> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> > 2. There were some questions around merit raised, remove all IPMC
> members who were not on the initial proposal and who were voted in. Those
> left on the IPMC vote back in those who are currently active.
> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> > 4. Do nothing as this is not actually a problem but instead address
> other underlying issues. e.g. lack of mentor engagement.
>
> +1 to my modified version from #2 (and 0 to the others as I don't
> think they will help a lot):
> "Remove all IPMC members who were not on the initial proposal and who
> were voted in. Those left on the IPMC vote for those, as members, who
> can recruit, guide mentors, and review podling graduations, and they
> also vote for those, as mentors (committers), who have ever been
> active mentors for podlings."
>
> Mentors are committers: if someone starts contributing in this
> community, they are to be recognized and invited to a mentor
> (committer) in this project; if they contribute more for the community
> consistently, they are to be invited to a IPMC member. In smaller
> IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> graduations in various aspects, and mentors focus more on detail
> issues in podlings, providing enough overview and information to IPMC.
> I think this will make it a fairer merit-earning game, to new comers
> getting helps from mentors and (graduation and/or high-level) reviews
> from members, watchers considering to help, mentors eager to help
> graduations, more focused members, ...
>
> >
> > Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
>
> +1 to always be voting, whether they are ASF members or not, like other
> PMCs.
>
> >
> > Any other sugestions?
> >
> > Options 2 and 3 may cause some issues around mentors, but if they were
> not active then I guess it’s no big loss.
>
> My modified version includes all active people as mentors (committers)
> at least, so there's no loss as well.
>
> Regards,
>
> Woonsan
>
> >
> > And any suggestions on level of activity? Such as:
> > - Emailed the list in the last year.
> > - Reviewed at least one release in that time.
> >
> > It’s already been determined that some (about 15%) of the less than
> active PMC members (out of the 100 odd that are not signed up to the IPMC
> private list) do help out infrequently but that help is very useful. That
> may also apply to other inactive IPMC members, so I would suggest the bar
> for what consider active be kept low.
> >
> > 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: A smaller IPMC

[Woonsan Ko]

On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean  wrote:
>
> Hi,
>
> It’s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?
>
> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.
> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.

+1 to my modified version from #2 (and 0 to the others as I don't
think they will help a lot):
"Remove all IPMC members who were not on the initial proposal and who
were voted in. Those left on the IPMC vote for those, as members, who
can recruit, guide mentors, and review podling graduations, and they
also vote for those, as mentors (committers), who have ever been
active mentors for podlings."

Mentors are committers: if someone starts contributing in this
community, they are to be recognized and invited to a mentor
(committer) in this project; if they contribute more for the community
consistently, they are to be invited to a IPMC member. In smaller
IPMC, IPMC members focus more on helping/guiding mentors and reviewing
graduations in various aspects, and mentors focus more on detail
issues in podlings, providing enough overview and information to IPMC.
I think this will make it a fairer merit-earning game, to new comers
getting helps from mentors and (graduation and/or high-level) reviews
from members, watchers considering to help, mentors eager to help
graduations, more focused members, ...

>
> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently 
> voted more people in that we’ve had requests from ASF members.

+1 to always be voting, whether they are ASF members or not, like other PMCs.

>
> Any other sugestions?
>
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it’s no big loss.

My modified version includes all active people as mentors (committers)
at least, so there's no loss as well.

Regards,

Woonsan

>
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
>
> It’s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.
>
> 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: A smaller IPMC

[Justin Mclean]

Hi,

> Of course, we could consider to send mail to the IPMC members, who haven't 
> subscribed the private ml, and ask them to do so.

That has already done several months ago - a few decided to set down and a few 
decided to sign up, but not much changed.

Thanks,
Justin


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

Re: A smaller IPMC

[???? Sheng Wu]

+1 for #4


From I known, member of Incubator PMC is either already Apache Member or People 
already are/were active and helpful for other incubator project.
Even they are not active today, removing them from IPMC could have negative 
effects when they want to be back in some day.


Of course, we could consider to send mail to the IPMC members, who haven't 
subscribed the private ml, and ask them to do so.


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108


 




-- Original --
From:  "roman";
Date:  Fri, Mar 8, 2019 07:39 AM
To:  "general";

Subject:  Re: A smaller IPMC



On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean  wrote:
>
> Hi,
>
> It??s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?

Personally, I believe that "IPMC is too large" argument is only applicable to
how quickly/easily consensus can be built. That's literally the only situation
when the size of IPMC gets in the way (sometimes).

Is anyone aware of any other situations where "IPMC is too large" argument
is actually legit?

At any rate, the rest of my feedback will be from that single perspective:

> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.
> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.

I would like to suggest a 5th alternative (again this is from the
above's perspective):
   * Don't change anything, but for any situation that requires
consensus building just be a tad more formal with how we close loops
and track if we really get as many obstructionists as we thing that
the size of the IPMC allows. If not -- we don't have a problem.

> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It??s has always seem odd to me that this is the case. We??ve recently 
> voted more people in that we??ve had requests from ASF members.
>
> Any other sugestions?
>
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it??s no big loss.
>
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
>
> It??s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.

I honestly don't see how all of these options of getting people in and
out of IPMC can actually help with this consensus building thing. So
yeah -- I'd say #5.

Thanks,
Roman.

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

Re: A smaller IPMC

[Kevin A. McGrail]

I am not aware of the problem we are trying to fix.  I don't even know if I
am a mentor not subscribed to private@.

Without knowing what we are trying to solve, it is hard to weigh in on
fixes.

So my ask is what is the issue?

On Thu, Mar 7, 2019, 19:25 Liang Chen  Hi
>
> One more suggestion: How about maintaining one table, and ask IPMC to
> freely
> provide info by them-self which part they are mentoring or will be going to
> mentor as volunteer.
> For example myself : Helping new project (DataSketches)  to prepare
> incubator proposal. and participate in some vote for new releases and new
> projects.
>
> Regards
> Liang
>
>
> Ted Dunning wrote
> > I don't think that the number of inactive IPMC members is a factor in
> > anything. They are, by definition, inactive.
> >
> > So I would vote for the no-op action (#4, I think).
> >
> >
> >
> > On Thu, Mar 7, 2019 at 3:39 PM Roman Shaposhnik 
>
> > roman@
>
> > 
> > wrote:
> >
> >> On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean 
>
> > justin@
>
> > 
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > It’s been suggested that the IPMC is too large, what do other IPMC
> >> members think might be a way to address this?
> >>
> >> Personally, I believe that "IPMC is too large" argument is only
> >> applicable
> >> to
> >> how quickly/easily consensus can be built. That's literally the only
> >> situation
> >> when the size of IPMC gets in the way (sometimes).
> >>
> >> Is anyone aware of any other situations where "IPMC is too large"
> >> argument
> >> is actually legit?
> >>
> >> At any rate, the rest of my feedback will be from that single
> >> perspective:
> >>
> >> > Please discuss and indicate +1 what you would think would help, you
> can
> >> vote for more than one.
> >> >
> >> > Some suggestions:
> >> > 1. Ask all inactive IPMC if they want to continue being on the IPMC
> and
> >> see who steps down. Being inactive they are probably not following this
> >> list so we need to identify and send each one email them personally.
> >> > 2. There were some questions around merit raised, remove all IPMC
> >> members who were not on the initial proposal and who were voted in.
> Those
> >> left on the IPMC vote back in those who are currently active.
> >> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> >> binding - not sure how else it could be done?) currently active ones
> back
> >> in.
> >> > 4. Do nothing as this is not actually a problem but instead address
> >> other underlying issues. e.g. lack of mentor engagement.
> >>
> >> I would like to suggest a 5th alternative (again this is from the
> >> above's perspective):
> >>* Don't change anything, but for any situation that requires
> >> consensus building just be a tad more formal with how we close loops
> >> and track if we really get as many obstructionists as we thing that
> >> the size of the IPMC allows. If not -- we don't have a problem.
> >>
> >> > Also re point 2 do you think we should drop that ASF members can
> >> automatically get IPMC membership and change it to requiring a vote by
> >> the
> >> IPMC? It’s has always seem odd to me that this is the case. We’ve
> >> recently
> >> voted more people in that we’ve had requests from ASF members.
> >> >
> >> > Any other sugestions?
> >> >
> >> > Options 2 and 3 may cause some issues around mentors, but if they were
> >> not active then I guess it’s no big loss.
> >> >
> >> > And any suggestions on level of activity? Such as:
> >> > - Emailed the list in the last year.
> >> > - Reviewed at least one release in that time.
> >> >
> >> > It’s already been determined that some (about 15%) of the less than
> >> active PMC members (out of the 100 odd that are not signed up to the
> IPMC
> >> private list) do help out infrequently but that help is very useful.
> That
> >> may also apply to other inactive IPMC members, so I would suggest the
> bar
> >> for what consider active be kept low.
> >>
> >> I honestly don't see how all of these options of getting people in and
> >> out of IPMC can actually help with this consensus building thing. So
> >> yeah -- I'd say #5.
> >>
> >> Thanks,
> >> Roman.
> >>
> >> -
> >> To unsubscribe, e-mail:
>
> > general-unsubscribe@.apache
>
> >> For additional commands, e-mail:
>
> > general-help@.apache
>
> >>
> >>
>
>
>
>
>
> --
> Sent from: http://apache-incubator-general.996316.n3.nabble.com/
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: A smaller IPMC

[Liang Chen]

Hi

One more suggestion: How about maintaining one table, and ask IPMC to freely
provide info by them-self which part they are mentoring or will be going to
mentor as volunteer.
For example myself : Helping new project (DataSketches)  to prepare
incubator proposal. and participate in some vote for new releases and new
projects.

Regards
Liang


Ted Dunning wrote
> I don't think that the number of inactive IPMC members is a factor in
> anything. They are, by definition, inactive.
> 
> So I would vote for the no-op action (#4, I think).
> 
> 
> 
> On Thu, Mar 7, 2019 at 3:39 PM Roman Shaposhnik 

> roman@

> 
> wrote:
> 
>> On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean 

> justin@

> 
>> wrote:
>> >
>> > Hi,
>> >
>> > It’s been suggested that the IPMC is too large, what do other IPMC
>> members think might be a way to address this?
>>
>> Personally, I believe that "IPMC is too large" argument is only
>> applicable
>> to
>> how quickly/easily consensus can be built. That's literally the only
>> situation
>> when the size of IPMC gets in the way (sometimes).
>>
>> Is anyone aware of any other situations where "IPMC is too large"
>> argument
>> is actually legit?
>>
>> At any rate, the rest of my feedback will be from that single
>> perspective:
>>
>> > Please discuss and indicate +1 what you would think would help, you can
>> vote for more than one.
>> >
>> > Some suggestions:
>> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
>> see who steps down. Being inactive they are probably not following this
>> list so we need to identify and send each one email them personally.
>> > 2. There were some questions around merit raised, remove all IPMC
>> members who were not on the initial proposal and who were voted in. Those
>> left on the IPMC vote back in those who are currently active.
>> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
>> binding - not sure how else it could be done?) currently active ones back
>> in.
>> > 4. Do nothing as this is not actually a problem but instead address
>> other underlying issues. e.g. lack of mentor engagement.
>>
>> I would like to suggest a 5th alternative (again this is from the
>> above's perspective):
>>* Don't change anything, but for any situation that requires
>> consensus building just be a tad more formal with how we close loops
>> and track if we really get as many obstructionists as we thing that
>> the size of the IPMC allows. If not -- we don't have a problem.
>>
>> > Also re point 2 do you think we should drop that ASF members can
>> automatically get IPMC membership and change it to requiring a vote by
>> the
>> IPMC? It’s has always seem odd to me that this is the case. We’ve
>> recently
>> voted more people in that we’ve had requests from ASF members.
>> >
>> > Any other sugestions?
>> >
>> > Options 2 and 3 may cause some issues around mentors, but if they were
>> not active then I guess it’s no big loss.
>> >
>> > And any suggestions on level of activity? Such as:
>> > - Emailed the list in the last year.
>> > - Reviewed at least one release in that time.
>> >
>> > It’s already been determined that some (about 15%) of the less than
>> active PMC members (out of the 100 odd that are not signed up to the IPMC
>> private list) do help out infrequently but that help is very useful. That
>> may also apply to other inactive IPMC members, so I would suggest the bar
>> for what consider active be kept low.
>>
>> I honestly don't see how all of these options of getting people in and
>> out of IPMC can actually help with this consensus building thing. So
>> yeah -- I'd say #5.
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: 

> general-unsubscribe@.apache

>> For additional commands, e-mail: 

> general-help@.apache

>>
>>





--
Sent from: http://apache-incubator-general.996316.n3.nabble.com/

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

Re: A smaller IPMC

[Craig Russell]

+1 for #4

I think IPMC members not subscribed to the private list is only an issue for 
mentors. 

So at the risk of adding "yet another rule", I'd vote for #4 and look into 
*requiring* mentors to subscribe to the incubator private list and their mentee 
podlings' private lists.

Craig

> On Mar 7, 2019, at 3:33 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> It’s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?
> 
> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
> 
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.
> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.
> 
> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently 
> voted more people in that we’ve had requests from ASF members.
> 
> Any other sugestions?
> 
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it’s no big loss.
> 
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
> 
> It’s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: A smaller IPMC

[Dave Fisher]

Hi -

I lean heavily towards #4.

> On Mar 7, 2019, at 3:33 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> It’s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?
> 
> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
> 
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.

+0

> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.

-1000

> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.

-100

> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.

+1

Let’s address lack of mentoring. I’m working on fixing the clutch report and 
making good progress today.

Good new data sources are:
https://whimsy.apache.org/public/public_ldap_projects.json 

https://gitbox.apache.org/repositories.json 


Regards,
Dave

> 
> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently 
> voted more people in that we’ve had requests from ASF members.
> 
> Any other sugestions?
> 
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it’s no big loss.
> 
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
> 
> It’s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: A smaller IPMC

[Ted Dunning]

I don't think that the number of inactive IPMC members is a factor in
anything. They are, by definition, inactive.

So I would vote for the no-op action (#4, I think).



On Thu, Mar 7, 2019 at 3:39 PM Roman Shaposhnik 
wrote:

> On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > It’s been suggested that the IPMC is too large, what do other IPMC
> members think might be a way to address this?
>
> Personally, I believe that "IPMC is too large" argument is only applicable
> to
> how quickly/easily consensus can be built. That's literally the only
> situation
> when the size of IPMC gets in the way (sometimes).
>
> Is anyone aware of any other situations where "IPMC is too large" argument
> is actually legit?
>
> At any rate, the rest of my feedback will be from that single perspective:
>
> > Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
> >
> > Some suggestions:
> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> > 2. There were some questions around merit raised, remove all IPMC
> members who were not on the initial proposal and who were voted in. Those
> left on the IPMC vote back in those who are currently active.
> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> > 4. Do nothing as this is not actually a problem but instead address
> other underlying issues. e.g. lack of mentor engagement.
>
> I would like to suggest a 5th alternative (again this is from the
> above's perspective):
>* Don't change anything, but for any situation that requires
> consensus building just be a tad more formal with how we close loops
> and track if we really get as many obstructionists as we thing that
> the size of the IPMC allows. If not -- we don't have a problem.
>
> > Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
> >
> > Any other sugestions?
> >
> > Options 2 and 3 may cause some issues around mentors, but if they were
> not active then I guess it’s no big loss.
> >
> > And any suggestions on level of activity? Such as:
> > - Emailed the list in the last year.
> > - Reviewed at least one release in that time.
> >
> > It’s already been determined that some (about 15%) of the less than
> active PMC members (out of the 100 odd that are not signed up to the IPMC
> private list) do help out infrequently but that help is very useful. That
> may also apply to other inactive IPMC members, so I would suggest the bar
> for what consider active be kept low.
>
> I honestly don't see how all of these options of getting people in and
> out of IPMC can actually help with this consensus building thing. So
> yeah -- I'd say #5.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: A smaller IPMC

[Roman Shaposhnik]

On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean  wrote:
>
> Hi,
>
> It’s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?

Personally, I believe that "IPMC is too large" argument is only applicable to
how quickly/easily consensus can be built. That's literally the only situation
when the size of IPMC gets in the way (sometimes).

Is anyone aware of any other situations where "IPMC is too large" argument
is actually legit?

At any rate, the rest of my feedback will be from that single perspective:

> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.
> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.

I would like to suggest a 5th alternative (again this is from the
above's perspective):
   * Don't change anything, but for any situation that requires
consensus building just be a tad more formal with how we close loops
and track if we really get as many obstructionists as we thing that
the size of the IPMC allows. If not -- we don't have a problem.

> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently 
> voted more people in that we’ve had requests from ASF members.
>
> Any other sugestions?
>
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it’s no big loss.
>
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
>
> It’s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.

I honestly don't see how all of these options of getting people in and
out of IPMC can actually help with this consensus building thing. So
yeah -- I'd say #5.

Thanks,
Roman.

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

A smaller IPMC

[Justin Mclean]

Hi,

It’s been suggested that the IPMC is too large, what do other IPMC members 
think might be a way to address this?

Please discuss and indicate +1 what you would think would help, you can vote 
for more than one.

Some suggestions:
1. Ask all inactive IPMC if they want to continue being on the IPMC and see who 
steps down. Being inactive they are probably not following this list so we need 
to identify and send each one email them personally.
2. There were some questions around merit raised, remove all IPMC members who 
were not on the initial proposal and who were voted in. Those left on the IPMC 
vote back in those who are currently active.
3. Get rid of all IPMC members, and vote (with ASF members vote being binding - 
not sure how else it could be done?) currently active ones back in.
4. Do nothing as this is not actually a problem but instead address other 
underlying issues. e.g. lack of mentor engagement.

Also re point 2 do you think we should drop that ASF members can automatically 
get IPMC membership and change it to requiring a vote by the IPMC? It’s has 
always seem odd to me that this is the case. We’ve recently voted more people 
in that we’ve had requests from ASF members.

Any other sugestions?

Options 2 and 3 may cause some issues around mentors, but if they were not 
active then I guess it’s no big loss.

And any suggestions on level of activity? Such as:
- Emailed the list in the last year.
- Reviewed at least one release in that time.

It’s already been determined that some (about 15%) of the less than active PMC 
members (out of the 100 odd that are not signed up to the IPMC private list) do 
help out infrequently but that help is very useful. That may also apply to 
other inactive IPMC members, so I would suggest the bar for what consider 
active be kept low.

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

Re: March Board report

[Justin Mclean]

Hi,

> not sure if you want us to edit typos etc. directly or whether you want
> them listed here?

Feel free to edit on the wiki.

Thanks,
Justin

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

Re: March Board report

[Lars Francke]

Hi Justin,

not sure if you want us to edit typos etc. directly or whether you want
them listed here?

Cheers,
Lars

On Thu, Mar 7, 2019 at 11:06 PM Justin Mclean 
wrote:

> Hi,
>
> While I'm yet to fill in some of the mechanical items (releases and the
> like) some feedback on the report would be appreciated. [1]
>
> Just keep in mind that it covers what happened in February and doesn’t
> need to include the most recent events as those go in the next report.
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/March2019
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Mentor sign off on reports due Tuesday March 12

[Justin Mclean]

Hi,

A few days to go but currently we are missing signoff on these reports:
- Crail
- Druid
- Marvin-AI
- Myriad
- OpenWhisk
- Pinot
- Pony Mail
- Singa
- Tamaya

Congratulation to Omid, Tephra and Training for having all mentors sign off the 
report.

Four codlings failed to report and will be asked to report next month. They are:
- Iceberg
- Spot
- Taverna
- Warble

Thanks,
Justin



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

Re: [ANNOUNCE] Apache Dubbo(incubating) 2.6.6 has been released

[sebb]

On Thu, 7 Mar 2019 at 15:54, Minxuan Zhuang  wrote:
>
> Hello Incubator Community,
>
> The Apache Dubbo(incubating) team is pleased to announce that the
> 2.6.6 has just been released.
>

What is the project about? Why should I be interested in it?
[rhetorical questions]

Announce emails are sent to people not on the developer or user lists.
Many will have no idea what the project is about.

So the e-mails should contain at least brief details of what the
product does, and some info on why the new release might be of
interest to them.

Readers should not have to click the link to find out the basic information
(although of course it is useful to have such links for further detail).

Please can you add that information to future announce mails?

Thanks!
> Both the source release[1] and the maven binary release[2] are available
> now, you can also find the detailed release notes in here[3].
>
>
> If you have any usage questions, or have problems when upgrading or find
> any problems about enhancements included in this release, please don’t
> hesitate to let us know by sending feedback to this mailing list or filing
> an issue on GitHub[4].
>
>
> =
> *Disclaimer*
>
> Apache Dubbo is an effort undergoing incubation at The Apache Software
> Foundation (ASF), sponsored by the Incubator. Incubation is required of all
> newly accepted projects until a further review indicates that the
> infrastructure, communications, and decision making process have stabilized
> in a manner consistent with other successful ASF projects. While incubation
> status is not necessarily a reflection of the completeness or stability of
> the code, it does indicate that the project has yet to be fully endorsed by
> the ASF.
>
>
> [1]
> https://www.apache.org/dyn/closer.cgi?path=incubator/dubbo/2.6.6/apache-dubbo-incubating-2.6.6-source-release.zip
> [2] http://central.maven.org/maven2/com/alibaba/dubbo
> [3] https://github.com/apache/incubator-dubbo/releases
> [4] https://github.com/apache/incubator-dubbo/issues

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

March Board report

[Justin Mclean]

Hi,

While I'm yet to fill in some of the mechanical items (releases and the like) 
some feedback on the report would be appreciated. [1]

Just keep in mind that it covers what happened in February and doesn’t need to 
include the most recent events as those go in the next report.

Thanks,
Justin

1. https://wiki.apache.org/incubator/March2019
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Justin Mclean]

Hi,

> Yes, we should start recommending your approach.

I think the IPMC need to decide as a whole on that first. Perhaps call a vote?

> I am actually for this as normal course and instituting the “pTLP” as the new 
> normal as it is actually makes the PPMC more like a TLP from the start.

And perhaps keep this seperate from above.

One idea did occur to me and that is one solution may not fit all podlings and 
actually give podlings some choice of what system they want to use when 
entering the incubator.

I also think it needs to be made very clear that some of the alternative 
suggestions, while sound appealing (e.g. no IPMC votes mean we can get releases 
out faster), may in some cases result in:
a) Podlings taking a lot longer to graduate
b) Issues being found where trying to graduate causing disappointment and delays
c) Mentors need to put in more effort especially when to come to steps 
pre-graduation, at a time when not all of them may be as active
d) The IPMC may need to do more work at graduation time to check that 
everything is in order.

Now this might only be the case for the small number of codlings that run into 
trouble, and for the majority it’s fine no matter what system is used.

Also I’ll note a -1 vote on a release shouldn't be a big deal (it’s not a 
veto), but a -1 vote on a graduations would be a much bigger issue. Hopefully 
this wouldn’t happen and it should be obvious in the discussion about the 
graduation that more needs to be done, but podlings are going to be be keen to 
graduate and may overlook some advice at this point.

> (1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC 
> members on their dev list then they can release and use a [DISCUSS] thread to 
> solicit improvements for the next release rather than have a “useless” second 
> round of voting on general@

I can point to many many case where the second round voting has been far from 
useless.

> (3) If “Unofficial” Apache Releases are allowed on the normal podling Apache 
> Distribution Channels then this [DISCUSS] thread can be used until the 
> podling is ready for an “Official” Apache Release. As I understand it this 
> needs approval from Infrastructure.

And probably legal. i.e. Would the currently legal shield still apply and is 
the current disclaimer adequate? Would it have an impact of the cost of that 
insurance?

Thanks,
Justin


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

[jira] [Updated] (INCUBATOR-231) Cleanup Git-generated Incubator website

[David Fisher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Fisher updated INCUBATOR-231:
---
Attachment: gitbox.svn.diff.txt
gitbox.clutch.data.txt

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch2data.txt, gitbox.clutch.data.txt, 
> gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (INCUBATOR-231) Cleanup Git-generated Incubator website

[David Fisher (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787155#comment-16787155
 ] 

David Fisher commented on INCUBATOR-231:


I have an svn update for clutch.py and content/clutch/index.xml
 # Queries gitbox.apache.org/repositories.json to get the dictionary of all ASF 
git repos.
 # Reads Git tags out of status files, but prefers gitbox information to status 
file.
 # Changes hasSvn column in clutch to a hasRepo column.
 # Stores the selected/computes gitUrl to the pickle file.
 # Stores the project's sorted gitbox repositories to the pickle file.

I will attach a diff including to the generated clutch files.

I will wait until tomorrow to commit my changes.

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch2data.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[DISCUSS] Include Incubator as part of Community Track at Apachecon NA?

[Sharan Foga]

Hi All

I’m helping to manage the Community track for ApacheCon NA in Las Vegas 
http://www.apachecon.com/acna19/index.html

and would like to know what people think about including Incubator as part of 
the Community track. I know that some incubating projects might be included as 
part of the other tracks such as big data, iot or integration so this would 
give some potential schedule space to projects that don’t fit those categories.

What do people think?

Thanks
Sharan

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

[RESULT] [VOTE] Release Apache Pinot (incubating) 0.1.0 RC0

[Seunghyun Lee]

Thank you for everyone who participated to the vote. The voting is now
closed and it has passed with 3 +1 (binding), and no 0 or -1 votes.

Binding:
+1 Felix Cheung
+1 Mohammad Asif Siddiqui
+1 Olivier Lamy

Voting thread:
https://lists.apache.org/thread.html/1e1e57cdd5361371f813b67f8caa0de9bc6bf81559bf4cd0b6de7dba@%3Cgeneral.incubator.apache.org%3E

Thanks,
Apache Pinot (incubating) community

Re: [Result][VOTE] Accept Apache TVM into the incubator

[Henry Saputra]

Congrats to TVM community. Let's get to work

- Henry

On Wed, Mar 6, 2019 at 5:10 PM Tianqi Chen  wrote:

> Thank you, everyone.
> I will follow up by cross-posting in the TVM community as well as give
> a public roadmap regarding next steps together with the help from our
> mentors.  I am traveling this week and will draft and cross-post the public
> roadmap of incubator transition this weekend.
>
> Tianqi
>
> On Wed, Mar 6, 2019 at 1:47 PM Markus Weimer  wrote:
>
> > The vote has concluded with 13 binding and 5 non-binding and 1 unclear +1
> > votes,
> > no other votes were cast. TVM has been accepted into the incubator. The
> > voring
> > tally is below
> >
> > Thanks!
> >
> > Markus
> >
> > Binding +1:
> >
> >
> >   * Sebastian
> >   * Gon
> >   * Markus
> >   * Henry
> >   * Furkan
> >   * Felix
> >   * Timothy
> >   * Willem
> >   * Mohammad
> >   * Sheng
> >   * Vinayakumar
> >   * Gosling
> >   * Jason
> >
> >
> > Non-Binding
> >
> >   * Sheng
> >   * Kellen
> >   * Cihad
> >   * Huxing
> >   * Tianqui
> >
> > Undeclared:
> >
> >   * Matt
> >
> >
> > On Mon, Mar 4, 2019 at 12:18 AM Jason Dai  wrote:
> > >
> > > +1 (binding)
> > >
> > > Thanks,
> > > -Jason
> > >
> > > On Mon, Mar 4, 2019 at 2:50 PM Gosling Von 
> wrote:
> > >
> > > > +1, binding
> > > >
> > > >
> > > > Best Regards,
> > > > Von Gosling
> > > >
> > > > > 在 2019年2月28日，下午12:44，Markus Weimer  写道：
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > we've discussed the proposal for the TVM project in [1]. The
> proposal
> > > > itself can
> > > > > be found on the wiki [2].
> > > > >
> > > > > According to the Incubator rules[3] I'd like to call a vote to
> accept
> > > > the new
> > > > > TVM project as a podling in the Apache Incubator.
> > > > >
> > > > > A vote for accepting a new Apache Incubator podling is a majority
> > vote.
> > > > Everyone
> > > > > is welcome to vote, only Incubator PMC member votes are binding. It
> > > > would be
> > > > > helpful (but not required) if you could add a comment stating
> whether
> > > > your vote
> > > > > is binding or non-binding.
> > > > >
> > > > > This vote will run for at least 72 hours (but I expect to keep it
> > open
> > > > for
> > > > > longer). Please VOTE as follows:
> > > > >
> > > > > [ ] +1 Accept TVM into the Apache Incubator
> > > > > [ ] +0 Abstain
> > > > > [ ] -1 Do not accept TVM into the Apache Incubator because ...
> > > > >
> > > > > Thank you for everyone who decided to join in in the past
> > discussions!
> > > > >
> > > > > Markus
> > > > >
> > > > > [1]:
> > > >
> >
> https://lists.apache.org/thread.html/e2b1fe9ca76422ec80b146a6b120091f2419e2f1c27d57080f39cf6f@%3Cgeneral.incubator.apache.org%3E
> > > > >
> > > > > [2]: https://wiki.apache.org/incubator/TVMProposal
> > > > >
> > > > > [3]: https://incubator.apache.org/guides/proposal.html#the_vote
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Dave Fisher]

Hi Myrle,

Yes, we should start recommending your approach. I am actually for this as 
normal course and instituting the “pTLP” as the new normal as it is actually 
makes the PPMC more like a TLP from the start.

Given our current interpretation of rules that An Official Apache Release 
requires 3 +1 IPMC Votes:

(1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC 
members on their dev list then they can release and use a [DISCUSS] thread to 
solicit improvements for the next release rather than have a “useless” second 
round of voting on general@

(2) If a podling is making an non-Apache Release as they are transitioning to 
Apache they can use this mechanism to solicit reviews about how close they are 
to being able to produce an Official Apache Release.

(3) If “Unofficial” Apache Releases are allowed on the normal podling Apache 
Distribution Channels then this [DISCUSS] thread can be used until the podling 
is ready for an “Official” Apache Release. As I understand it this needs 
approval from Infrastructure. Allowing this approach brings podlings more 
quickly into Apache Releases, but has disadvantages like yet another 
distinction that may be hard to explain.

(4) “pTLP” with some lower number of IPMC votes become the approved podling 
model for producing “Official” Apache Releases. If this is the model then the 
IPMC would make the 3 +1 IPMC Vote on a podling's most recent releases a clear 
graduation requirement.

Regards,
Dave

> On Mar 6, 2019, at 8:15 AM, Myrle Krantz  wrote:
> 
> Hey all,
> 
> I've only heard positive feedback on this proposal.  It doesn't solve all
> our problems, but it would provide a path around some of the bureaucracy.
> 
> Would the other mentors be willing to bring this suggestion to their
> podlings?  Especially the "young" ones who still need releases outside of
> the ASF?
> 
> Best Regards,
> Myrle
> 
> On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz  wrote:
> 
>> Motivation:
>> 
>> Some podlings want or need feedback on their releases before they are
>> ready to make official Apache releases.  They want to discuss releases that
>> are not yet ready for a VOTE, or that they are not sure they are ready for
>> a vote.  They may wish to make an early release outside of the foundation,
>> but still test the ASF waters.  They prefer to "fail early, fail often and
>> fail forward". [1]
>> 
>> 
>> Proposal:
>> 
>> Podlings should be able to request feedback by starting a "[DISCUSS]"
>> thread instead of a "[VOTE]" thread.  Discussion should give podlings
>> feedback on what they would need to do to bring their release in line with
>> the requirements for graduation to TLP.  Podlings will be responsible for
>> capturing feedback that they accept in work items for their project.
>> Feedback provided in a discussion thread will not block a non-ASF release.
>> 
>> Asking for feedback using this mechanism is not obligatory, but rather a
>> service that the incubator offers.
>> 
>> 
>> Arguments for this proposal:
>> 
>> * It's a very small change which may make it easier to implement than some
>> of the "throw it all away and start over" proposals circulating, but...
>> * It doesn't prevent us from making other larger changes.
>> * It's not a rule.  It's an offering of an additional service + an
>> incremental reduction in stringency of the incubator.
>> * It captures some of the value in what we are doing now while increasing
>> the degrees of freedom provided to podlings.
>> * It is consistent with our values of transparency, collaboration,
>> community, pragmatism, meritocracy, and charity.
>> 
>> Best Regards,
>> Myrle
>> 
>> 1.)
>> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success
>> 


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

[ANNOUNCE] Apache Dubbo(incubating) 2.6.6 has been released

[Minxuan Zhuang]

Hello Incubator Community,

The Apache Dubbo(incubating) team is pleased to announce that the
2.6.6 has just been released.

Both the source release[1] and the maven binary release[2] are available
now, you can also find the detailed release notes in here[3].


If you have any usage questions, or have problems when upgrading or find
any problems about enhancements included in this release, please don’t
hesitate to let us know by sending feedback to this mailing list or filing
an issue on GitHub[4].



=
*Disclaimer*

Apache Dubbo is an effort undergoing incubation at The Apache Software
Foundation (ASF), sponsored by the Incubator. Incubation is required of all
newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.


[1]
https://www.apache.org/dyn/closer.cgi?path=incubator/dubbo/2.6.6/apache-dubbo-incubating-2.6.6-source-release.zip
[2] http://central.maven.org/maven2/com/alibaba/dubbo
[3] https://github.com/apache/incubator-dubbo/releases
[4] https://github.com/apache/incubator-dubbo/issues

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Minxuan Zhuang]

Hi community,

72 hours has passed, the vote has passed with 3 +1 binding votes and
no -1 binding vote.

+1 binding:
* Mohammad Asif Siddiqui
* Mark Thomas
* Sheng Wu
I will proceed to publish the artifacts.

Thanks for everyone who voted!

On Thu, Mar 7, 2019 at 8:18 PM 吴晟 Sheng Wu  wrote:

> Hi
>
>
> Strange thing. I noticed my +1 binding mail didn't arrive the ML, but I do
> send.
>
>
> Anyway, here is  My +1 binding
>
>
> - asc checked
> - sha512 checked
> - incubating in name
> - maven compile passed
> - notice and license exist
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "吴晟 Sheng Wu";
> Date:  Thu, Mar 7, 2019 06:07 PM
> To:  "Incubator General";"general"<
> general@incubator.apache.org>;
>
> Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> Hi
>
>
> Thanks for clear that, you have discussed this  before.
>
>
> My +1 binding
> - asc checked
> - sha512 checked
> - incubating in name
> - maven compile passed
> - notice and license exist
>
>
>
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
>
> From Wu Sheng 's phone.
>
>
> -- Original --
> From: Minxuan Zhuang 
> Date: Thu,Mar 7,2019 5:54 PM
> To: general 
> Subject: Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> Hi,
>  there is a discuss about the NOTICE file here:
>
> https://lists.apache.org/thread.html/9c26cb1750bc72c5cc3fd6ff1620721f4160ec20250c9328fb102e11@%3Cdev.dubbo.apache.org%3E
> ,
> I think it's fine not to include the whole netty NOTICE file.
>
> On Thu, Mar 7, 2019 at 5:09 PM 吴晟 Sheng Wu  wrote:
>
> > Hi
> >
> >
> > From my understanding, there is a possible issue in your source release
> > and bin.
> >
> >
> > I found a very simple NOTICE
> >
> >
> > --
> > Apache Dubbo (incubating)
> > Copyright 2018-2019 The Apache Software Foundation
> >
> >
> > This product includes software developed at
> > The Apache Software Foundation (http://www.apache.org/).
> >
> >
> > This product contains code form the Netty Project:
> >
> >
> > The Netty Project
> > =
> > Please visit the Netty web site for more information:
> >   * http://netty.io/
> >
> >
> > Copyright 2014 The Netty Project
> >
> > --
> >
> >
> > But I checked the NOTICE in Netty project[1]. It includes more.
> >
> >
> > Could you clear why don't you include the whole netty's NOTICE file?
> > Do I miss something?
> >
> >
> >
> >
> > [1] https://github.com/netty/netty
> >
> >
> > --
> > Sheng Wu
> > Apache SkyWalking, ShardingSphere, Zipkin
> > Twitter, wusheng1108
> >
> >
> >
> >
> >
> >
> >
> > -- Original --
> > From:  "hux...@apache.org";
> > Date:  Thu, Mar 7, 2019 03:53 PM
> > To:  "Incubator General";
> >
> > Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
> >
> >
> >
> > +1 (non-binding)
> >
> > Still need one more binding vote here...
> >
> > On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang 
> wrote:
> > >
> > > Hello Incubator Community,
> > >
> > > The Apache Dubbo community has voted on and approved a proposal to
> > release
> > > Apache Dubbo (Incubating) version 2.6.6.
> > >
> > > We now kindly request the Incubator PMC members review and vote on this
> > > incubator release.
> > >
> > > Apache Dubbo™ (incubating) is a high-performance, java based, open
> source
> > > RPC framework. Dubbo offers three key functionalities, which include
> > > interface based remote call, fault tolerance & load balancing, and
> > > automatic service registration & discovery.
> > >
> > > Dubbo community vote and result thread:
> > >
> >
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> > >
> > > The release candidates (RC2):
> > > https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> > >
> > > Git tag for the release (RC2):
> > > https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> > >
> > > Hash for the release tag:
> > > ba7f6f38c36675268ba64f21e97d02bda7a731dc
> > >
> > > Release Notes:
> > > https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> > >
> > > The artifacts have been signed with Key : DA2108479B0C1E71, which can
> be
> > > found in the keys file:
> > > https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> > >
> > > The vote will be open for at least 72 hours or until necessary number
> of
> > > votes are reached.
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Thanks,
> > > The Apache Dubbo (Incubating) Team
> >
> >
> >
> > --
> > Best Regards！
> > Huxing
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional 

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[吴晟 Sheng Wu]

Hi


Strange thing. I noticed my +1 binding mail didn't arrive the ML, but I do send.


Anyway, here is  My +1 binding


- asc checked
- sha512 checked
- incubating in name
- maven compile passed
- notice and license exist


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108


 




-- Original --
From:  "吴晟 Sheng Wu";
Date:  Thu, Mar 7, 2019 06:07 PM
To:  "Incubator 
General";"general";

Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]



Hi 


Thanks for clear that, you have discussed this  before.


My +1 binding
- asc checked
- sha512 checked
- incubating in name
- maven compile passed
- notice and license exist



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Minxuan Zhuang 
Date: Thu,Mar 7,2019 5:54 PM
To: general 
Subject: Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]



Hi,
 there is a discuss about the NOTICE file here:
https://lists.apache.org/thread.html/9c26cb1750bc72c5cc3fd6ff1620721f4160ec20250c9328fb102e11@%3Cdev.dubbo.apache.org%3E
,
I think it's fine not to include the whole netty NOTICE file.

On Thu, Mar 7, 2019 at 5:09 PM 吴晟 Sheng Wu  wrote:

> Hi
>
>
> From my understanding, there is a possible issue in your source release
> and bin.
>
>
> I found a very simple NOTICE
>
>
> --
> Apache Dubbo (incubating)
> Copyright 2018-2019 The Apache Software Foundation
>
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
>
> This product contains code form the Netty Project:
>
>
> The Netty Project
> =
> Please visit the Netty web site for more information:
>   * http://netty.io/
>
>
> Copyright 2014 The Netty Project
>
> --
>
>
> But I checked the NOTICE in Netty project[1]. It includes more.
>
>
> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?
>
>
>
>
> [1] https://github.com/netty/netty
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "hux...@apache.org";
> Date:  Thu, Mar 7, 2019 03:53 PM
> To:  "Incubator General";
>
> Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> +1 (non-binding)
>
> Still need one more binding vote here...
>
> On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang  wrote:
> >
> > Hello Incubator Community,
> >
> > The Apache Dubbo community has voted on and approved a proposal to
> release
> > Apache Dubbo (Incubating) version 2.6.6.
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Dubbo™ (incubating) is a high-performance, java based, open source
> > RPC framework. Dubbo offers three key functionalities, which include
> > interface based remote call, fault tolerance & load balancing, and
> > automatic service registration & discovery.
> >
> > Dubbo community vote and result thread:
> >
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> >
> > The release candidates (RC2):
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> >
> > Git tag for the release (RC2):
> > https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> >
> > Hash for the release tag:
> > ba7f6f38c36675268ba64f21e97d02bda7a731dc
> >
> > Release Notes:
> > https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> >
> > The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> > found in the keys file:
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> >
> > The vote will be open for at least 72 hours or until necessary number of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Thanks,
> > The Apache Dubbo (Incubating) Team
>
>
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: Differences in voting rules between Apache Maturity Model and Incubator Default Project Guidelines

[Greg Stein]

On Thu, Mar 7, 2019 at 5:30 AM Christofer Dutz 
wrote:
>...

> Not quite sure which rules should be applied.
>

The Incubator rules, clearly.

The "maturity model" is simply a web page produced by ComDev. It has zero
application to the Incubator, or to the Foundation.

Regards,
-g

Differences in voting rules between Apache Maturity Model and Incubator Default Project Guidelines

[Christofer Dutz]

Hi all,

we’re currently working on some pre-graduation work and stumbled over something:
In the Apache Maturity Model [1] is says that:

CS40 - In Apache projects, vetoes are only valid for code commits and are 
justified by a technical explanation, as per the Apache voting rules defined in 
CS30.


However the Incubator Default Project Guidelines [2] suggest code changes are 
“lazy consensus” and stuff like Comitter, PMC, Chai changes are “Consensus 
approval” which is described as:

Consensus approval requires 3 
binding +1 votes 
and no -1 votes (vetoes).

So these two seem to be contradicting each other.

Not quite sure which rules should be applied.

Chris


[1] https://community.apache.org/apache-way/apache-project-maturity-model.html
[2] https://wiki.apache.org/incubator/DefaultProjectGuidelines

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[???? Sheng Wu]

Hi Justin


I have read the discussion. Make sense to me.


Thanks.



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Justin Mclean 
Date: Thu,Mar 7,2019 7:00 PM
To: general 
Subject: Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]



Hi,

> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?

Only parts of the NOTICE file that are relevant need to be included, some 
projects find analysis of that difficult and include the whole file to be on 
the safe side, some with only small parts of other projects included decide to 
only include the pieces they think are relevant.

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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Justin Mclean]

Hi,

> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?

Only parts of the NOTICE file that are relevant need to be included, some 
projects find analysis of that difficult and include the whole file to be on 
the safe side, some with only small parts of other projects included decide to 
only include the pieces they think are relevant.

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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Huxing Zhang]

Hi,


On Thu, Mar 7, 2019 at 5:09 PM 吴晟 Sheng Wu  wrote:
>
> Hi
>
>
> From my understanding, there is a possible issue in your source release and 
> bin.
>
>
> I found a very simple NOTICE

I think keeping a NOTICE simple is not an issue.

In the ASF documentation[1], it says:

It is important to keep NOTICE as brief and simple as possible, as
each addition places a burden on downstream consumers.

[1] http://www.apache.org/dev/licensing-howto.html#mod-notice

>
>
> --
> Apache Dubbo (incubating)
> Copyright 2018-2019 The Apache Software Foundation
>
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
>
> This product contains code form the Netty Project:
>
>
> The Netty Project
> =
> Please visit the Netty web site for more information:
>   * http://netty.io/
>
>
> Copyright 2014 The Netty Project
>
> --
>
>
> But I checked the NOTICE in Netty project[1]. It includes more.
>
>
> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?
>
>
>
>
> [1] https://github.com/netty/netty
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "hux...@apache.org";
> Date:  Thu, Mar 7, 2019 03:53 PM
> To:  "Incubator General";
>
> Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> +1 (non-binding)
>
> Still need one more binding vote here...
>
> On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang  wrote:
> >
> > Hello Incubator Community,
> >
> > The Apache Dubbo community has voted on and approved a proposal to release
> > Apache Dubbo (Incubating) version 2.6.6.
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Dubbo™ (incubating) is a high-performance, java based, open source
> > RPC framework. Dubbo offers three key functionalities, which include
> > interface based remote call, fault tolerance & load balancing, and
> > automatic service registration & discovery.
> >
> > Dubbo community vote and result thread:
> > https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> >
> > The release candidates (RC2):
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> >
> > Git tag for the release (RC2):
> > https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> >
> > Hash for the release tag:
> > ba7f6f38c36675268ba64f21e97d02bda7a731dc
> >
> > Release Notes:
> > https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> >
> > The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> > found in the keys file:
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> >
> > The vote will be open for at least 72 hours or until necessary number of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Thanks,
> > The Apache Dubbo (Incubating) Team
>
>
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org



--
Best Regards！
Huxing

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Myrle Krantz]

On Thu, Mar 7, 2019 at 11:07 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> a) Asking PMC members if they want to step down from the PMC if they
> seem to be inactive for a long time
>
> b) Forcibly removing PMC members that the PMC considers inactive
>
> IMO a) is fine if a PMC wants to have a roster that reflects reality,
> but b) is bad in terms of community
>
> And yes in any case removals have to be ratified by the Board as per
> http://www.apache.org/dev/pmc.html#pmc-removal


Minor correction (and perhaps this is what you meant):  In the case of
voluntary resignation, the board does not have to ratify.

Quote from the document you linked:
"Once the PMC member's resignation is received on a mailing list of the
Foundation, the resignation is considered effective (however, the PMC
member has 72 hours to withdraw their resignation). Notifying the board is
not required, but encouraged to ease tracking."

We're not quite the Hotel California. : o)

Greets,
Myrle

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[???? Sheng Wu]

Hi 


Thanks for clear that, you have discussed this  before.


My +1 binding
- asc checked
- sha512 checked
- incubating in name
- maven compile passed
- notice and license exist



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Minxuan Zhuang 
Date: Thu,Mar 7,2019 5:54 PM
To: general 
Subject: Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]



Hi,
 there is a discuss about the NOTICE file here:
https://lists.apache.org/thread.html/9c26cb1750bc72c5cc3fd6ff1620721f4160ec20250c9328fb102e11@%3Cdev.dubbo.apache.org%3E
,
I think it's fine not to include the whole netty NOTICE file.

On Thu, Mar 7, 2019 at 5:09 PM  Sheng Wu  wrote:

> Hi
>
>
> From my understanding, there is a possible issue in your source release
> and bin.
>
>
> I found a very simple NOTICE
>
>
> --
> Apache Dubbo (incubating)
> Copyright 2018-2019 The Apache Software Foundation
>
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
>
> This product contains code form the Netty Project:
>
>
> The Netty Project
> =
> Please visit the Netty web site for more information:
>   * http://netty.io/
>
>
> Copyright 2014 The Netty Project
>
> --
>
>
> But I checked the NOTICE in Netty project[1]. It includes more.
>
>
> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?
>
>
>
>
> [1] https://github.com/netty/netty
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "hux...@apache.org";
> Date:  Thu, Mar 7, 2019 03:53 PM
> To:  "Incubator General";
>
> Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> +1 (non-binding)
>
> Still need one more binding vote here...
>
> On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang  wrote:
> >
> > Hello Incubator Community,
> >
> > The Apache Dubbo community has voted on and approved a proposal to
> release
> > Apache Dubbo (Incubating) version 2.6.6.
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Dubbo?6?4 (incubating) is a high-performance, java based, open source
> > RPC framework. Dubbo offers three key functionalities, which include
> > interface based remote call, fault tolerance & load balancing, and
> > automatic service registration & discovery.
> >
> > Dubbo community vote and result thread:
> >
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> >
> > The release candidates (RC2):
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> >
> > Git tag for the release (RC2):
> > https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> >
> > Hash for the release tag:
> > ba7f6f38c36675268ba64f21e97d02bda7a731dc
> >
> > Release Notes:
> > https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> >
> > The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> > found in the keys file:
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> >
> > The vote will be open for at least 72 hours or until necessary number of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Thanks,
> > The Apache Dubbo (Incubating) Team
>
>
>
> --
> Best Regards??
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Bertrand Delacretaz]

Hi,

On Wed, Mar 6, 2019 at 11:41 PM Ted Dunning  wrote:
> ...inactive PMC members are not a problem
> (Apache culture is heavily designed to make this work) and they could be an
> asset in the future. So removing the inactive members is actually a slight
> negative to the project...

I think it's important to differentiate between

a) Asking PMC members if they want to step down from the PMC if they
seem to be inactive for a long time

b) Forcibly removing PMC members that the PMC considers inactive

IMO a) is fine if a PMC wants to have a roster that reflects reality,
but b) is bad in terms of community

And yes in any case removals have to be ratified by the Board as per
http://www.apache.org/dev/pmc.html#pmc-removal

-Bertrand

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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Minxuan Zhuang]

Hi,
 there is a discuss about the NOTICE file here:
https://lists.apache.org/thread.html/9c26cb1750bc72c5cc3fd6ff1620721f4160ec20250c9328fb102e11@%3Cdev.dubbo.apache.org%3E
,
I think it's fine not to include the whole netty NOTICE file.

On Thu, Mar 7, 2019 at 5:09 PM 吴晟 Sheng Wu  wrote:

> Hi
>
>
> From my understanding, there is a possible issue in your source release
> and bin.
>
>
> I found a very simple NOTICE
>
>
> --
> Apache Dubbo (incubating)
> Copyright 2018-2019 The Apache Software Foundation
>
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
>
> This product contains code form the Netty Project:
>
>
> The Netty Project
> =
> Please visit the Netty web site for more information:
>   * http://netty.io/
>
>
> Copyright 2014 The Netty Project
>
> --
>
>
> But I checked the NOTICE in Netty project[1]. It includes more.
>
>
> Could you clear why don't you include the whole netty's NOTICE file?
> Do I miss something?
>
>
>
>
> [1] https://github.com/netty/netty
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "hux...@apache.org";
> Date:  Thu, Mar 7, 2019 03:53 PM
> To:  "Incubator General";
>
> Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]
>
>
>
> +1 (non-binding)
>
> Still need one more binding vote here...
>
> On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang  wrote:
> >
> > Hello Incubator Community,
> >
> > The Apache Dubbo community has voted on and approved a proposal to
> release
> > Apache Dubbo (Incubating) version 2.6.6.
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Dubbo™ (incubating) is a high-performance, java based, open source
> > RPC framework. Dubbo offers three key functionalities, which include
> > interface based remote call, fault tolerance & load balancing, and
> > automatic service registration & discovery.
> >
> > Dubbo community vote and result thread:
> >
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> >
> > The release candidates (RC2):
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> >
> > Git tag for the release (RC2):
> > https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> >
> > Hash for the release tag:
> > ba7f6f38c36675268ba64f21e97d02bda7a731dc
> >
> > Release Notes:
> > https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> >
> > The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> > found in the keys file:
> > https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> >
> > The vote will be open for at least 72 hours or until necessary number of
> > votes are reached.
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Thanks,
> > The Apache Dubbo (Incubating) Team
>
>
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[吴晟 Sheng Wu]

Hi


From my understanding, there is a possible issue in your source release and bin.


I found a very simple NOTICE


--
Apache Dubbo (incubating)
Copyright 2018-2019 The Apache Software Foundation


This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).


This product contains code form the Netty Project:


The Netty Project
=
Please visit the Netty web site for more information:
  * http://netty.io/


Copyright 2014 The Netty Project

--


But I checked the NOTICE in Netty project[1]. It includes more.


Could you clear why don't you include the whole netty's NOTICE file?
Do I miss something?




[1] https://github.com/netty/netty


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108


 




-- Original --
From:  "hux...@apache.org";
Date:  Thu, Mar 7, 2019 03:53 PM
To:  "Incubator General";

Subject:  Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]



+1 (non-binding)

Still need one more binding vote here...

On Mon, Mar 4, 2019 at 7:35 PM Minxuan Zhuang  wrote:
>
> Hello Incubator Community,
>
> The Apache Dubbo community has voted on and approved a proposal to release
> Apache Dubbo (Incubating) version 2.6.6.
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Apache Dubbo™ (incubating) is a high-performance, java based, open source
> RPC framework. Dubbo offers three key functionalities, which include
> interface based remote call, fault tolerance & load balancing, and
> automatic service registration & discovery.
>
> Dubbo community vote and result thread:
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
>
> The release candidates (RC2):
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
>
> Git tag for the release (RC2):
> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
>
> Hash for the release tag:
> ba7f6f38c36675268ba64f21e97d02bda7a731dc
>
> Release Notes:
> https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
>
> The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> found in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
>
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Thanks,
> The Apache Dubbo (Incubating) Team



-- 
Best Regards！
Huxing

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