[RESULT] [VOTE] Release Apache brpc(incubating) 0.9.8-rc01

[tan zhongyi]

Hi,
The vote to release Apache brpc(incubating) 0.9.8-rc01 has passed with 3 +1
binding votes.

[3] +1 Binding votes:
- Justin Mclean
- Willem Jiang
- Sheng Wu
[ 0 ] +0  Binding votes
[ 0 ] -1  Binding votes

The vote is successful.

Vote thread:
https://lists.apache.org/thread.html/re44c77f98de4260a3efe4a53bc870790f2a710cc6b4edb8ef4e0342a%40%3Cgeneral.incubator.apache.org%3E

Thank you to the above IPMC members for taking the time to review and
provide guidance on our release!

We will proceed with publishing the approved artifacts and sending out the
appropriate announcements in the coming days.

On behalf of brpc community,

Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[David Nalley]

On Tue, Aug 4, 2020 at 11:01 PM Justin Mclean 
wrote:

> Hi,
>
> >  1.  Change all MXNet to Apache MXNet (incubating) from documentation
> where it necessary
> >  2.  Change maven package description ” MXNet Engine Adapter for DJL”
> to  "Deep Java Library (DJL) Engine Adapter for Apache MXNet" for
> clarification
>
> Thanks for doing that. ASF generally prefers “powdered by” so I would
> double check with trademarks (trademarks@a.o) if this is acceptable use.
> [1]
>

The brand management committee has no issue with "Deep Java Library (DJL)
Engine Adapter for Apache MXnet" as it's nominative use[1] and has been
documented as such.


[1] https://www.apache.org/foundation/marks/pmcs#other

Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Dave Fisher]

Hi -

Sent from my iPhone

> On Aug 4, 2020, at 8:01 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> 1.  Change all MXNet to Apache MXNet (incubating) from documentation where 
>> it necessary
>> 2.  Change maven package description ” MXNet Engine Adapter for DJL” to  
>> "Deep Java Library (DJL) Engine Adapter for Apache MXNet" for clarification
> 
> Thanks for doing that. ASF generally prefers “powdered by” so I would double 
> check with trademarks (trademarks@a.o) if this is acceptable use. [1]

That’s “Powered by”, but “for” can also be acceptable. Agreed that trademark@ 
is the place for the PPMC to ask.

Regards,
Dave

> 
>> For [3], this package contains no source code from Apache MXNet and only 
>> contains the binary that built from source through the Apache MXNet source 
>> code without modification. It also brought necessary License and binary 
>> attribution from Apache MXNet.
> 
> I still have some concerns here’s for instance is a page [2] that says:
>• The binaries are built from source from Apache MXNet without 
> modification.
>• The binaries are obtained from the Apache MXNet python pip wheel.
> 
> The issue here is those pip “releases" contain unreleased versions of Apache 
> MxNet [2] and probably should not have been released by the MXNet project and 
> shouldn’t be used by the general public. [4] ("must not be distributed 
> through channels which encourage use by anyone outside the project 
> development community”)
> 
> There is currently a draft policy on downstream distribution [5] but I don’t 
> think it covers this situation. Now I would agree that the ALv2 allow you to 
> use Apache MXNet code, even if it is unreleased, but I’m not sure if you can 
> say the the resulting product is “for MXNet". That may be need a discussion 
> on the legal@a.o or trademarks@a.o lists.
> 
> And to be clear this is not really a DJL issue at this point, it's more an 
> issue for the PPMC of MXNet to sort out.
> 
> Thanks,
> Justin
> 
> 1. https://www.apache.org/foundation/marks/faq/#products
> 2. https://djl.ai/mxnet/native/
> 3. https://pypi.org/project/mxnet/#history
> 4. https://infra.apache.org/release-distribution#unreleased
> 5. http://www.apache.org/foundation/marks/downstream.html
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Justin Mclean]

Hi,

>  1.  Change all MXNet to Apache MXNet (incubating) from documentation where 
> it necessary
>  2.  Change maven package description ” MXNet Engine Adapter for DJL” to  
> "Deep Java Library (DJL) Engine Adapter for Apache MXNet" for clarification

Thanks for doing that. ASF generally prefers “powdered by” so I would double 
check with trademarks (trademarks@a.o) if this is acceptable use. [1]

> For [3], this package contains no source code from Apache MXNet and only 
> contains the binary that built from source through the Apache MXNet source 
> code without modification. It also brought necessary License and binary 
> attribution from Apache MXNet.

I still have some concerns here’s for instance is a page [2] that says:
• The binaries are built from source from Apache MXNet without 
modification.
• The binaries are obtained from the Apache MXNet python pip wheel.

The issue here is those pip “releases" contain unreleased versions of Apache 
MxNet [2] and probably should not have been released by the MXNet project and 
shouldn’t be used by the general public. [4] ("must not be distributed through 
channels which encourage use by anyone outside the project development 
community”)

There is currently a draft policy on downstream distribution [5] but I don’t 
think it covers this situation. Now I would agree that the ALv2 allow you to 
use Apache MXNet code, even if it is unreleased, but I’m not sure if you can 
say the the resulting product is “for MXNet". That may be need a discussion on 
the legal@a.o or trademarks@a.o lists.

And to be clear this is not really a DJL issue at this point, it's more an 
issue for the PPMC of MXNet to sort out.

Thanks,
Justin

1. https://www.apache.org/foundation/marks/faq/#products
2. https://djl.ai/mxnet/native/
3. https://pypi.org/project/mxnet/#history
4. https://infra.apache.org/release-distribution#unreleased
5. http://www.apache.org/foundation/marks/downstream.html





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

Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Qing Lan]

Hi Justin,

I am here to response the issues you mentioned in [2] [3] and [5].

For [2] and [5], I monitored the DJL project that addressed the folliowing:


  1.  Change all MXNet to Apache MXNet (incubating) from documentation where it 
necessary
  2.  Change maven package description ” MXNet Engine Adapter for DJL” to  
"Deep Java Library (DJL) Engine Adapter for Apache MXNet" for clarification
  3.  Other necessary changes to address the concerns

For [3], this package contains no source code from Apache MXNet and only 
contains the binary that built from source through the Apache MXNet source code 
without modification. It also brought necessary License and binary attribution 
from Apache MXNet. Hope this can help unblock Apache MXNet release.

Thanks,
Qing


From: Justin Mclean 
Sent: Saturday, July 25, 2020 18:27
To: general@incubator.apache.org 
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

Hi,

-1 (binding) as this release contains code that hasn’t gone though IP clearance 
(mshadow).

I checked:
- incubating in name
- disclaimer exists
- LICENSE and NOTICE have improved but I did not do an exhaustive check
-  No unexpected binary file
- ASF files have ASF headers
- unable to compile from source

It also seems that this code may have been released before the PPMC/IPMC vote 
is over see [1][2][3][4] There are also branding and trademark issue with this 
site [5] This is in addition to the issues previously noted with releases, 
branding and trademarks.[6]

Thanks,
Justin


1. https://sourceforge.net/projects/apache-mxnet.mirror/
2. 
https://repo.gradle.org/gradle/simple/repo/ai/djl/mxnet/mxnet-native-mkl/1.7.0-b/
3. https://mvnrepository.com/artifact/ai.djl.mxnet
4. 
https://aur.archlinux.org/packages/?O=0=nd=mxnet=v=d=50_Search=Go
5. https://djl.ai
6. https://jira.apache.org/jira/browse/INCUBATOR-253
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Problems with Committer Invite Documentation

[Matt Sicker]

The private list is important to watch anyways as a project that can't
provide oversight to said mailing list is typically in danger of
dying. Adding moderators for the list would certainly help.

On Tue, 4 Aug 2020 at 17:56, Dave Fisher  wrote:
>
>
>
> > On Aug 4, 2020, at 2:52 PM, leerho  wrote:
> >
> > John,
> > Thank you for your comments.
> >
> > First understand that this site (community.a.o) is maintained by comdev.
> >> Podlings should be following the processes at http://incubator.apache.org/
> >
> >
> > I searched incubator.a.o and could not find any comparable documentation
> > that is step-by-step with example template emails.  There are several pages
> > devoted to educating new committers, but I could not find much on inviting
> > new committers.  So in the absence of good documentation I used what I
> > could find.   Also, I have never read anywhere that podlings should not be
> > reading or following the ASF documentation.  Presumably, the ASF
> > documentation preempts incubator documentation in most cases.
> >
> > No.  Why do you think it will disappear into the "bit-bucket"?  The
> >> candidate would have the email in their inbox and would be able to archive
> >> it/save it for reference however they choose fit.
> >
> >
> > Because it has been over 24 hours since our candidate replied and it still
> > does not show up in our private@ mail list. If our mentors have the
> > responsibility to moderate the private list, why is it that none of our 5
> > mentors have not forwarded it?  Whether it is technically a bit-bucket or
> > not is irrelevant.  If our mentors don't moderate the list and forward an
> > important email such as a committer invite, it is effectively a
> > bit-bucket!   So our candidate is sitting waiting for the next steps and is
> > hearing nothing!  That is unacceptable.
>
> Not all mentors are moderators. I am not.
>
> These three are moderators.
> chenliang...@apache.org 
> , 
> kam...@apache.org , 
> k...@apache.org 
>
> The information is here: https://whimsy.apache.org/roster/ppmc/datasketches
>
> >
> > WRT:  Being a committer enables you to more easily make changes without
> > needing to go through the patch submission process. --- (A ill-advised
> > implication)
> >
> > That's a fair point, but not all projects follow this pattern.  In
> >> addition, the template is free to be modified by each project, you're under
> >> no obligation to follow the published format verbatim; so if your project
> >> chooses to invite someone and wants to reword the text you can.
> >>
> >
> > I recognize that these templates can be changed by the user.  But you are
> > missing my point.  Why start with a recommendation that is ill-advised to
> > start with?  Many folks simply copy these templates making as few changes
> > as possible without reading the content and thinking about the
> > implications.  And I have proof of this happening with senior ASF folks.
> >
> > I am a bit puzzled why you are pushing back so hard on my recommendations.
> > I am a great fan of the ASF and I just want to improve the documentation
> > and make it better!
> >
> > Regards,
> > Lee.
> >
> >
> >
> > On Tue, Aug 4, 2020 at 1:54 PM Dave Fisher  wrote:
> >
> >>
> >>
> >>> On Aug 4, 2020, at 1:31 PM, John D. Ament  wrote:
> >>>
> >>> On Tue, Aug 4, 2020 at 4:19 PM leerho  wrote:
> >>>
>  Folks,
> 
>  It is our first time going through the recommended New Committer process
>  and we have uncovered some significant problems with the documentation
>  .
> 
> 
> >>> First understand that this site (community.a.o) is maintained by comdev.
> >>> Podlings should be following the processes at
> >> http://incubator.apache.org/
> >>>
> >>>
>   - The most serious problem is step A: of the "Committer Invite
> >> Template"
>   on the above page:
> 
>  A. This personal invitation is a chance for you to
> > accept or decline in private.  Either way, please
> > let us know in reply to the [priv...@project.apache.org]
> > address only.
> >
> > This is a potential disaster, since the candidate will not have read or
>  write privileges to the private mail list, the candidate's reply will
>  simply disappear into the bit-bucket! I would recommend changing this
>  paragraph to:
> 
>  A. Please reply directly to me if you wish to accept (or not accept)
> >> this
> > invitation.
> 
> 
> >>> No.  Why do you think it will disappear into the "bit-bucket"?  The
> >>> candidate would have the email in their inbox and would be able to
> >> archive
> >>> it/save it for reference however they choose fit.  private mailing lists
> >>> may have moderation in place, but since it's a legitimate email the
> >>> 

Re: Problems with Committer Invite Documentation

[Dave Fisher]

> On Aug 4, 2020, at 2:52 PM, leerho  wrote:
> 
> John,
> Thank you for your comments.
> 
> First understand that this site (community.a.o) is maintained by comdev.
>> Podlings should be following the processes at http://incubator.apache.org/
> 
> 
> I searched incubator.a.o and could not find any comparable documentation
> that is step-by-step with example template emails.  There are several pages
> devoted to educating new committers, but I could not find much on inviting
> new committers.  So in the absence of good documentation I used what I
> could find.   Also, I have never read anywhere that podlings should not be
> reading or following the ASF documentation.  Presumably, the ASF
> documentation preempts incubator documentation in most cases.
> 
> No.  Why do you think it will disappear into the "bit-bucket"?  The
>> candidate would have the email in their inbox and would be able to archive
>> it/save it for reference however they choose fit.
> 
> 
> Because it has been over 24 hours since our candidate replied and it still
> does not show up in our private@ mail list. If our mentors have the
> responsibility to moderate the private list, why is it that none of our 5
> mentors have not forwarded it?  Whether it is technically a bit-bucket or
> not is irrelevant.  If our mentors don't moderate the list and forward an
> important email such as a committer invite, it is effectively a
> bit-bucket!   So our candidate is sitting waiting for the next steps and is
> hearing nothing!  That is unacceptable.

Not all mentors are moderators. I am not.

These three are moderators.
chenliang...@apache.org 
, 
kam...@apache.org , 
k...@apache.org 

The information is here: https://whimsy.apache.org/roster/ppmc/datasketches

> 
> WRT:  Being a committer enables you to more easily make changes without
> needing to go through the patch submission process. --- (A ill-advised
> implication)
> 
> That's a fair point, but not all projects follow this pattern.  In
>> addition, the template is free to be modified by each project, you're under
>> no obligation to follow the published format verbatim; so if your project
>> chooses to invite someone and wants to reword the text you can.
>> 
> 
> I recognize that these templates can be changed by the user.  But you are
> missing my point.  Why start with a recommendation that is ill-advised to
> start with?  Many folks simply copy these templates making as few changes
> as possible without reading the content and thinking about the
> implications.  And I have proof of this happening with senior ASF folks.
> 
> I am a bit puzzled why you are pushing back so hard on my recommendations.
> I am a great fan of the ASF and I just want to improve the documentation
> and make it better!
> 
> Regards,
> Lee.
> 
> 
> 
> On Tue, Aug 4, 2020 at 1:54 PM Dave Fisher  wrote:
> 
>> 
>> 
>>> On Aug 4, 2020, at 1:31 PM, John D. Ament  wrote:
>>> 
>>> On Tue, Aug 4, 2020 at 4:19 PM leerho  wrote:
>>> 
 Folks,
 
 It is our first time going through the recommended New Committer process
 and we have uncovered some significant problems with the documentation
 .
 
 
>>> First understand that this site (community.a.o) is maintained by comdev.
>>> Podlings should be following the processes at
>> http://incubator.apache.org/
>>> 
>>> 
  - The most serious problem is step A: of the "Committer Invite
>> Template"
  on the above page:
 
 A. This personal invitation is a chance for you to
> accept or decline in private.  Either way, please
> let us know in reply to the [priv...@project.apache.org]
> address only.
> 
> This is a potential disaster, since the candidate will not have read or
 write privileges to the private mail list, the candidate's reply will
 simply disappear into the bit-bucket! I would recommend changing this
 paragraph to:
 
 A. Please reply directly to me if you wish to accept (or not accept)
>> this
> invitation.
 
 
>>> No.  Why do you think it will disappear into the "bit-bucket"?  The
>>> candidate would have the email in their inbox and would be able to
>> archive
>>> it/save it for reference however they choose fit.  private mailing lists
>>> may have moderation in place, but since it's a legitimate email the
>>> moderators of the list should moderate it through if it does get
>>> moderated.  The acceptance should also be on the podling's private list
>> to
>>> allow the ASF to have a permanent record of the acceptance.
>> 
>> I have moderated numerous such requests in the past. Usually within 24
>> hours, but occasionally within 104 hours.
>> 
>> I have a Smart Mail filter to make sure that I see all moderation emails
>> even though the vast 

[MENTORS] Podling reports due today

[Justin Mclean]

Hi,

Podling report are due today and currently we’re waiting on the following 
projects.

Annotator
BlueMarlin
Doris
Liminal
Livy
NLPCraft
Pinot
S2Graph
SDAP
Sedona
Training
Tuweni
Warble

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

Re: Problems with Committer Invite Documentation

[Justin Mclean]

Hi,

> I searched incubator.a.o and could not find any comparable documentation
> that is step-by-step with example template emails.  

See:
http://incubator.apache.org/guides/ppmc.html#adding_new_committers

(Which points to other ASF documentation)

> Because it has been over 24 hours since our candidate replied and it still
> does not show up in our private@ mail list. If our mentors have the
> responsibility to moderate the private list, why is it that none of our 5
> mentors have not forwarded it?

PPMC members can be moderators for that list as well, I would suggest you add 
some to moderate that list. If your mentors are not being active then find out 
why they are not being so, it may be that your project needs a new mentor or 
two.


> I recognize that these templates can be changed by the user.  But you are
> missing my point.  Why start with a recommendation that is ill-advised to
> start with?

Many project don’t operate that they, and any commit can be easily reverted so 
many project don’t see that advice as ill advised.

> I am a bit puzzled why you are pushing back so hard on my recommendations.
> I am a great fan of the ASF and I just want to improve the documentation
> and make it better!

Pull request and patches are welcome but just consider that not all projects 
operate in exactly the same way.

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

Re: Problems with Committer Invite Documentation

[leerho]

John,
Thank you for your comments.

First understand that this site (community.a.o) is maintained by comdev.
> Podlings should be following the processes at http://incubator.apache.org/


I searched incubator.a.o and could not find any comparable documentation
that is step-by-step with example template emails.  There are several pages
devoted to educating new committers, but I could not find much on inviting
new committers.  So in the absence of good documentation I used what I
could find.   Also, I have never read anywhere that podlings should not be
reading or following the ASF documentation.  Presumably, the ASF
documentation preempts incubator documentation in most cases.

No.  Why do you think it will disappear into the "bit-bucket"?  The
> candidate would have the email in their inbox and would be able to archive
> it/save it for reference however they choose fit.


Because it has been over 24 hours since our candidate replied and it still
does not show up in our private@ mail list. If our mentors have the
responsibility to moderate the private list, why is it that none of our 5
mentors have not forwarded it?  Whether it is technically a bit-bucket or
not is irrelevant.  If our mentors don't moderate the list and forward an
important email such as a committer invite, it is effectively a
bit-bucket!   So our candidate is sitting waiting for the next steps and is
hearing nothing!  That is unacceptable.

WRT:  Being a committer enables you to more easily make changes without
needing to go through the patch submission process. --- (A ill-advised
implication)

That's a fair point, but not all projects follow this pattern.  In
> addition, the template is free to be modified by each project, you're under
> no obligation to follow the published format verbatim; so if your project
> chooses to invite someone and wants to reword the text you can.
>

I recognize that these templates can be changed by the user.  But you are
missing my point.  Why start with a recommendation that is ill-advised to
start with?  Many folks simply copy these templates making as few changes
as possible without reading the content and thinking about the
implications.  And I have proof of this happening with senior ASF folks.

I am a bit puzzled why you are pushing back so hard on my recommendations.
I am a great fan of the ASF and I just want to improve the documentation
and make it better!

Regards,
Lee.



On Tue, Aug 4, 2020 at 1:54 PM Dave Fisher  wrote:

>
>
> > On Aug 4, 2020, at 1:31 PM, John D. Ament  wrote:
> >
> > On Tue, Aug 4, 2020 at 4:19 PM leerho  wrote:
> >
> >> Folks,
> >>
> >> It is our first time going through the recommended New Committer process
> >> and we have uncovered some significant problems with the documentation
> >> .
> >>
> >>
> > First understand that this site (community.a.o) is maintained by comdev.
> > Podlings should be following the processes at
> http://incubator.apache.org/
> >
> >
> >>   - The most serious problem is step A: of the "Committer Invite
> Template"
> >>   on the above page:
> >>
> >> A. This personal invitation is a chance for you to
> >>> accept or decline in private.  Either way, please
> >>> let us know in reply to the [priv...@project.apache.org]
> >>> address only.
> >>>
> >>> This is a potential disaster, since the candidate will not have read or
> >> write privileges to the private mail list, the candidate's reply will
> >> simply disappear into the bit-bucket! I would recommend changing this
> >> paragraph to:
> >>
> >> A. Please reply directly to me if you wish to accept (or not accept)
> this
> >>> invitation.
> >>
> >>
> > No.  Why do you think it will disappear into the "bit-bucket"?  The
> > candidate would have the email in their inbox and would be able to
> archive
> > it/save it for reference however they choose fit.  private mailing lists
> > may have moderation in place, but since it's a legitimate email the
> > moderators of the list should moderate it through if it does get
> > moderated.  The acceptance should also be on the podling's private list
> to
> > allow the ASF to have a permanent record of the acceptance.
>
> I have moderated numerous such requests in the past. Usually within 24
> hours, but occasionally within 104 hours.
>
> I have a Smart Mail filter to make sure that I see all moderation emails
> even though the vast majority are spam.
>
> >
> >
> >>
> >> Presumably the person sending this message will be someone from the PMC
> /
> >> PPMC that the candidate already has had some contact with. Also,
> hopefully,
> >> the sender has enough good sense to not CC non-private mail lists or
> other
> >> people on the invite, which will make the exchange as private as
> possible.
> >>
> >>
> > Yes, the person sending the invite needs to be on the PMC/PPMC.
> Typically
> > this is done by whoever actually did the nomination but there is no
> formal
> > rule about who must or must not send 

Re: Problems with Committer Invite Documentation

[Dave Fisher]

> On Aug 4, 2020, at 1:31 PM, John D. Ament  wrote:
> 
> On Tue, Aug 4, 2020 at 4:19 PM leerho  wrote:
> 
>> Folks,
>> 
>> It is our first time going through the recommended New Committer process
>> and we have uncovered some significant problems with the documentation
>> .
>> 
>> 
> First understand that this site (community.a.o) is maintained by comdev.
> Podlings should be following the processes at http://incubator.apache.org/
> 
> 
>>   - The most serious problem is step A: of the "Committer Invite Template"
>>   on the above page:
>> 
>> A. This personal invitation is a chance for you to
>>> accept or decline in private.  Either way, please
>>> let us know in reply to the [priv...@project.apache.org]
>>> address only.
>>> 
>>> This is a potential disaster, since the candidate will not have read or
>> write privileges to the private mail list, the candidate's reply will
>> simply disappear into the bit-bucket! I would recommend changing this
>> paragraph to:
>> 
>> A. Please reply directly to me if you wish to accept (or not accept) this
>>> invitation.
>> 
>> 
> No.  Why do you think it will disappear into the "bit-bucket"?  The
> candidate would have the email in their inbox and would be able to archive
> it/save it for reference however they choose fit.  private mailing lists
> may have moderation in place, but since it's a legitimate email the
> moderators of the list should moderate it through if it does get
> moderated.  The acceptance should also be on the podling's private list to
> allow the ASF to have a permanent record of the acceptance.

I have moderated numerous such requests in the past. Usually within 24 hours, 
but occasionally within 104 hours.

I have a Smart Mail filter to make sure that I see all moderation emails even 
though the vast majority are spam.

> 
> 
>> 
>> Presumably the person sending this message will be someone from the PMC /
>> PPMC that the candidate already has had some contact with. Also, hopefully,
>> the sender has enough good sense to not CC non-private mail lists or other
>> people on the invite, which will make the exchange as private as possible.
>> 
>> 
> Yes, the person sending the invite needs to be on the PMC/PPMC.  Typically
> this is done by whoever actually did the nomination but there is no formal
> rule about who must or must not send it (in some TLPs I think they expect
> the chair to do it, podlings don't have chairs).

Typically a response is required in 30 days and the PPMC and Mentors will need 
to track the result.

Sometimes a nominee has to ask their company if they can sign an ICLA and not 
every one can.

Regards,
Dave

> 
> 
>> 
>> 
>>   - The next problem is the wording of the first sentence of the
>>   2nd paragraph:
>> 
>> Being a committer enables you to more easily make
>>> changes without needing to go through the patch
>>> submission process.
>>> 
>>> 
>> This is basically recommending bad programming practice! We encourage all
>> our committers to use the PR and review process on all but the most trivial
>> commits (e.g., documentation typos).  I would recommend simplifying this
>> sentence to:
>> 
>> Being a committer grants you write access to the project repositories.
>> 
>> 
>> 
> That's a fair point, but not all projects follow this pattern.  In
> addition, the template is free to be modified by each project, you're under
> no obligation to follow the published format verbatim; so if your project
> chooses to invite someone and wants to reword the text you can.
> 
> 
>> 
>> 
>>   - This next issue is somewhat a matter of style, but I would recommend
>>   replacing the entire section "B" with:
>> 
>> B. If you accept, you will receive a follow-up message with the next steps
>>> for establishing you as a committer.
>> 
>> 
>> 
>> The above changes will make the invite letter simpler and more
>> straightforward.
>> 
>> 
> Once you've invited the person to be a committer, they should be able to
> submit the ICLA on their own.  Someone on the PMC/PPMC shouldn't need to
> tell them how to do it, but the instructions included in B are pretty clear
> and help that committer figure out how to submit the forms as needed.
> 
> 
>> I would be happy to submit these changes as a PR but someone will have to
>> tell me where to do this.
>> 
>> Cheers,
>> 
>> Lee.
>> 


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

Re: Problems with Committer Invite Documentation

[John D. Ament]

On Tue, Aug 4, 2020 at 4:19 PM leerho  wrote:

> Folks,
>
> It is our first time going through the recommended New Committer process
> and we have uncovered some significant problems with the documentation
> .
>
>
First understand that this site (community.a.o) is maintained by comdev.
Podlings should be following the processes at http://incubator.apache.org/


>- The most serious problem is step A: of the "Committer Invite Template"
>on the above page:
>
> A. This personal invitation is a chance for you to
> > accept or decline in private.  Either way, please
> > let us know in reply to the [priv...@project.apache.org]
> > address only.
> >
> > This is a potential disaster, since the candidate will not have read or
> write privileges to the private mail list, the candidate's reply will
> simply disappear into the bit-bucket! I would recommend changing this
> paragraph to:
>
> A. Please reply directly to me if you wish to accept (or not accept) this
> > invitation.
>
>
No.  Why do you think it will disappear into the "bit-bucket"?  The
candidate would have the email in their inbox and would be able to archive
it/save it for reference however they choose fit.  private mailing lists
may have moderation in place, but since it's a legitimate email the
moderators of the list should moderate it through if it does get
moderated.  The acceptance should also be on the podling's private list to
allow the ASF to have a permanent record of the acceptance.


>
> Presumably the person sending this message will be someone from the PMC /
> PPMC that the candidate already has had some contact with. Also, hopefully,
> the sender has enough good sense to not CC non-private mail lists or other
> people on the invite, which will make the exchange as private as possible.
>
>
Yes, the person sending the invite needs to be on the PMC/PPMC.  Typically
this is done by whoever actually did the nomination but there is no formal
rule about who must or must not send it (in some TLPs I think they expect
the chair to do it, podlings don't have chairs).


>
>
>- The next problem is the wording of the first sentence of the
>2nd paragraph:
>
> Being a committer enables you to more easily make
> > changes without needing to go through the patch
> > submission process.
> >
> >
> This is basically recommending bad programming practice! We encourage all
> our committers to use the PR and review process on all but the most trivial
> commits (e.g., documentation typos).  I would recommend simplifying this
> sentence to:
>
>  Being a committer grants you write access to the project repositories.
>
>
>
That's a fair point, but not all projects follow this pattern.  In
addition, the template is free to be modified by each project, you're under
no obligation to follow the published format verbatim; so if your project
chooses to invite someone and wants to reword the text you can.


>
>
>- This next issue is somewhat a matter of style, but I would recommend
>replacing the entire section "B" with:
>
> B. If you accept, you will receive a follow-up message with the next steps
> > for establishing you as a committer.
>
>
>
> The above changes will make the invite letter simpler and more
> straightforward.
>
>
Once you've invited the person to be a committer, they should be able to
submit the ICLA on their own.  Someone on the PMC/PPMC shouldn't need to
tell them how to do it, but the instructions included in B are pretty clear
and help that committer figure out how to submit the forms as needed.


> I would be happy to submit these changes as a PR but someone will have to
> tell me where to do this.
>
> Cheers,
>
> Lee.
>

Problems with Committer Invite Documentation

[leerho]

Folks,

It is our first time going through the recommended New Committer process
and we have uncovered some significant problems with the documentation
.

   - The most serious problem is step A: of the "Committer Invite Template"
   on the above page:

A. This personal invitation is a chance for you to
> accept or decline in private.  Either way, please
> let us know in reply to the [priv...@project.apache.org]
> address only.
>
> This is a potential disaster, since the candidate will not have read or
write privileges to the private mail list, the candidate's reply will
simply disappear into the bit-bucket! I would recommend changing this
paragraph to:

A. Please reply directly to me if you wish to accept (or not accept) this
> invitation.


Presumably the person sending this message will be someone from the PMC /
PPMC that the candidate already has had some contact with. Also, hopefully,
the sender has enough good sense to not CC non-private mail lists or other
people on the invite, which will make the exchange as private as possible.



   - The next problem is the wording of the first sentence of the
   2nd paragraph:

Being a committer enables you to more easily make
> changes without needing to go through the patch
> submission process.
>
>
This is basically recommending bad programming practice! We encourage all
our committers to use the PR and review process on all but the most trivial
commits (e.g., documentation typos).  I would recommend simplifying this
sentence to:

 Being a committer grants you write access to the project repositories.




   - This next issue is somewhat a matter of style, but I would recommend
   replacing the entire section "B" with:

B. If you accept, you will receive a follow-up message with the next steps
> for establishing you as a committer.



The above changes will make the invite letter simpler and more
straightforward.

I would be happy to submit these changes as a PR but someone will have to
tell me where to do this.

Cheers,

Lee.

Re: [VOTE] Release Apache Superset (incubating) version 0.37.0

[Felix Cheung]

(Carry my vote, as stated already)
+1


On Tue, Aug 4, 2020 at 10:20 AM Ville Brofeldt 
wrote:

> Hello IPMC,
>
> The Apache Superset (incubating) community has voted on and approved a
> proposal to
> release Apache Superset (incubating) version 0.37.0.
> The voting thread can be found here:
> https://lists.apache.org/thread.html/r76d4a5f850546aed4f5ba94c5c8f7b3cb901d8842ed32832512e715b%40%3Cdev.superset.apache.org%3E
>
>
> Here are the binding +1 votes from mentors, carrying over from the podling
> vote:
> - Felix
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Apache Superset (incubating) is a modern, enterprise-ready business
> intelligence web application
>
> The release candidate:
> https://dist.apache.org/repos/dist/dev/incubator/superset/0.37.0rc4/
>
> Git tag for the release:
> https://github.com/apache/incubator-superset/tree/0.37.0rc4
>
> The Change Log for the release:
> https://github.com/apache/incubator-superset/blob/0.37.0rc4/CHANGELOG.md
>
> public keys are available at:
>
> https://www.apache.org/dist/incubator/superset/KEYS
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Thanks,
> The Apache Superset (Incubating) Team

Re: [DISCUSS] EventMesh Proposal

[Kevin Ratnasekera]

Hi Easen,

+1, Having worked in a similar domain so far, I have to say this is an
interesting project. If you are seeking new mentors, please consider adding
me as a mentor to the project.

Regards
Kevin

On Tue, Aug 4, 2020 at 3:34 PM Eason Chen  wrote:

> Good time of the time to all!
>
>
> I'd like to bring this new interesting project for the discussion,
> comments and feedback with the aim of starting a formal [VOTE] of its
> acceptance into Incubator.
>
>
> People behind this project aren't new to Apache: some of them were behind
> the Apache RocketMQ, which I consider a huge success(especially in China)as
> the community is literally thriving almost 3 years after the graduation.
>
>
> I have been involved a little bit with this project when it just started
> in WeBank a few years ago. And I'd like to emphasize that the community
> however small it might look so far, has been aligned with Apache ways of
> doing things. Heng Du (from RocketMQ PMC) is very instrumental in
> tirelessly helping this group to learn what it means to be a truly open
> source project.
>
>
> The code is already under ALv2 and is publicly available. As you will see
> it has a lot of dependency connections with the rest of Apache ecosystem
> and IMO will fit very well here and continue to grow the community.
>
>
> The project's proposal is available at [1].
>
>
> Thank you very much for the feedback you're willing to provide!
>
>
> With best regards,
>
> Eason Chen
>
>
>
> [1]
> https://cwiki.apache.org/confluence/display/INCUBATOR/EventMeshProposal

[VOTE] Release Apache Superset (incubating) version 0.37.0

[Ville Brofeldt]

Hello IPMC,

The Apache Superset (incubating) community has voted on and approved a proposal 
to
release Apache Superset (incubating) version 0.37.0.
The voting thread can be found here: 
https://lists.apache.org/thread.html/r76d4a5f850546aed4f5ba94c5c8f7b3cb901d8842ed32832512e715b%40%3Cdev.superset.apache.org%3E


Here are the binding +1 votes from mentors, carrying over from the podling vote:
- Felix

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Apache Superset (incubating) is a modern, enterprise-ready business 
intelligence web application

The release candidate:
https://dist.apache.org/repos/dist/dev/incubator/superset/0.37.0rc4/

Git tag for the release:
https://github.com/apache/incubator-superset/tree/0.37.0rc4

The Change Log for the release:
https://github.com/apache/incubator-superset/blob/0.37.0rc4/CHANGELOG.md

public keys are available at:

https://www.apache.org/dist/incubator/superset/KEYS

The vote will be open for at least 72 hours or until the necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Superset (Incubating) Team

smime.p7s
Description: S/MIME cryptographic signature

[ANNOUNCE] Release Apache TubeMQ(incubating) 0.5.0-incubating

[Goson zhang]

Hi all,

The Apache TubeMQ(incubating) community is pleased to announce that Apache
TubeMQ (incubating) 0.5.0-incubating has been released!

Apache TubeMQ is a trillion-records-scale distributed messaging queue (MQ)
system,
focuses on data transmission and storage under massive data.

Download Links:
https://downloads.apache.org/incubator/tubemq/0.5.0-incubating/

Release Notes:
https://github.com/apache/incubator-tubemq/blob/release-0.5.0/CHANGES.md

Website: https://tubemq.apache.org/

TubeMQ Resources:
- Issue: https://issues.apache.org/jira/projects/TUBEMQ/issues
- Mailing list: d...@tubemq.apache.org

Thanks
On behalf of Apache TubeMQ (Incubating) community

[DISCUSS] EventMesh Proposal

[Eason Chen]

Good time of the time to all!


I'd like to bring this new interesting project for the discussion, comments and 
feedback with the aim of starting a formal [VOTE] of its acceptance into 
Incubator.


People behind this project aren't new to Apache: some of them were behind the 
Apache RocketMQ, which I consider a huge success(especially in China)as the 
community is literally thriving almost 3 years after the graduation.


I have been involved a little bit with this project when it just started in 
WeBank a few years ago. And I'd like to emphasize that the community however 
small it might look so far, has been aligned with Apache ways of doing things. 
Heng Du (from RocketMQ PMC) is very instrumental in tirelessly helping this 
group to learn what it means to be a truly open source project.


The code is already under ALv2 and is publicly available. As you will see it 
has a lot of dependency connections with the rest of Apache ecosystem and IMO 
will fit very well here and continue to grow the community.


The project's proposal is available at [1].


Thank you very much for the feedback you're willing to provide!


With best regards,

Eason Chen



[1] https://cwiki.apache.org/confluence/display/INCUBATOR/EventMeshProposal

Re: [VOTE] Release Apache brpc(incubating) 0.9.8-rc01

[Sheng Wu]

+1 binding

1. ASC and sha512 exist
2. incubating in the name.
3. LICENSE and NOTICE exist
4. DISCLAIMER-WIP used.

Good luck.

Sheng Wu 吴晟
Twitter, wusheng1108


tan zhongyi  于2020年8月4日周二 上午9:59写道：

> Thanks, Willem.
> We have removed incubator-brpc-0.9.8-rc01.tar.gz.
>
> Now , we have two +1 (binding) from Willem and Justin.
> We still need at least one +1(binding) vote.
>
> Can some guys help to add more +1 vote?
> Thanks
>
>
> On 2020/08/02 13:32:03, Willem Jiang  wrote:
> > +1. (binding)>
> >
> > Here are my checks,>
> > 1. Signature and Hashed are good.>
> > 2. Release commit and Tag are good.>
> > 3. LICENSE and NOTICE files are good for me.>
> > 4. I can build the binary from the Source release kit by going through>
> > the build readme.>
> > 5. DISCLAIMER-WIP is included.>
> >
> > BTW, We need to remove the file of incubator-brpc-0.9.8-rc01.tar.gz>
> > from the release staging directory.>
> >
> > Willem Jiang>
> >
> > Twitter: willemjiang>
> > Weibo: 姜宁willem>
> >
> >
> > On Wed, Jul 15, 2020 at 7:02 PM tan zhongyi  wrote:>
> > >>
> > > Hi， guys，>
> > >>
> > >>
> > >>
> > > I am pleased to be calling this vote for the release of Apache brpc
> (incubating) 0.9.8-rc01>
> > >>
> > >  BTW: there is still some license issues to be fixed, so we keep
> DISCLAIMER-WIP there, we will fix them in later releases.>
> > >>
> > >>
> > >>
> > > Apache brpc community has voted and approved the release.>
> > >>
> > >>
> > >>
> > > Vote thread:
> https://lists.apache.org/thread.html/r5b76897ad047c326d4b580a6c110e17ec26f7cb1db95425248827df8%40%3Cdev.brpc.apache.org%3E
> >
> > >>
> > >  Results thread:
> https://lists.apache.org/thread.html/rd6667c2aad6a94238234e07461831cadf08e7ae7e66170dd4b25a694%40%3Cdev.brpc.apache.org%3E
> >
> > >>
> > >>
> > >>
> > > The release candidate to be voted over is available at:>
> > >>
> > >
> https://dist.apache.org/repos/dist/dev/incubator/brpc/0.9.8-rc01/incubator-brpc-0.9.8-rc01.tar.gz
> >
> > >>
> > >>
> > >>
> > >>
> > >>
> > > The SHA-512 checksum is:>
> > >>
> > >
> 972744e0915b2bf881ad04bae393761170bf91003b44c82dff8ba5306e8081abb5c4108c469a58ac4e4162838a04191fcf681594d89a7d97bbbfa0943cc2f41d>
> > >>
> > > which can be found via:>
> > >>
> > >
> https://dist.apache.org/repos/dist/dev/incubator/brpc/0.9.8-rc01/incubator-brpc-0.9.8-rc01.tar.gz.sha512
> >
> > >>
> > > The signature can be found via:>
> > >>
> > >
> https://dist.apache.org/repos/dist/dev/incubator/brpc/0.9.8-rc01/incubator-brpc-0.9.8-rc01.tar.gz.asc
> >
> > >>
> > > KEYS file is available here:>
> > >>
> > > https://dist.apache.org/repos/dist/dev/incubator/brpc/KEYS>
> > >>
> > >>
> > >>
> > >>
> > >>
> > > [Release Note]>
> > >>
> > > * Fix bug that time unit is not listed in grpc timeout options.>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1036>
> > >>
> > > * Fix heap overflow in simple_data_pool>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1056>
> > >>
> > > * Make args of redis protocol be StringPiece>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1128>
> > >>
> > > * Support the length of redis args could be zero>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1128>
> > >>
> > > * Optimize code in timer_thread>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1137/files>
> > >>
> > > * Fix a narrowing warning on aarch64>
> > >>
> > >
> https://github.com/apache/incubator-brpc/commit/87f149c464ea0322a5b59d040bb80e7847f365be
> >
> > >>
> > > * Make pthread_atfork not registered in child process>
> > >>
> > >
> https://github.com/apache/incubator-brpc/commit/2f8fc37d52c2a02ee6f348aaa52c7ded4a4844c3
> >
> > >>
> > > * Rename LOG_NONE which conflicts with a name in mysql>
> > >>
> > >
> https://github.com/apache/incubator-brpc/commit/e3840c18cdd9e1ff81f8280b96ac14869007a122
> >
> > >>
> > > * Fix several warnings under MAC>
> > >>
> > >
> https://github.com/apache/incubator-brpc/commit/f8c188a7a5186c2d43a20735ad175a32b39788a3
> >
> > >>
> > > * Ignore ELIMIT for circuit breaker>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1005>
> > >>
> > > * limit minimum value of max_concurrency for auto_cl>
> > >>
> > > https://github.com/apache/incubator-brpc/pull/1003>
> > >>
> > >>
> > >>
> > >>
> > >>
> > > Please vote on releasing this package as:>
> > >>
> > > Apache brpc(incubating) 0.9.8-rc01>
> > >>
> > >>
> > >>
> > > This vote will be open until “Monday July 20 2020 00:00:00 GMT+0800
> (CST)" and>
> > >>
> > > passes if a majority of at least three +1 Apache Incubator IPMC votes
> are>
> > >>
> > > cast.>
> > >>
> > >>
> > >>
> > > [ ] +1 Release this package>
> > >>
> > > [ ] 0  I don't feel strongly about it, but don't object>
> > >>
> > > [ ] -1 Do not release this package because...>
> > >>
> > >>
> > >>
> > > Anyone can participate in testing and voting, not just committers,
> please>
> > >>
> > > feel free to try out the release candidate and provide your votes.>
> > >>
> > >>
> > >>
> > > A checklist for reference:>
> > >>
> > >