Re: [MENTORS] Mentor guidance document

[Justin Mclean]

Hi,

> Sorry for my top post, but I have some observations about your “guide”.
> (1) It is more a mentoring FAQ than a guide.

Yep agree, and happy to change the name. I was hoping in time it could be 
fleshed out with more general guidance, but that’s probably a long way off.

> (2) You are listing symptoms / policy violations.

What I’m trying to do is to map why we do things in a certain way back to ASF 
values. I think part of the bigger issue here is that it hard to map abstract 
values to concrete actions in a given situation if you don’t have a lot of 
experience. This applies to committers, PPMC members and mentors. 
Meta-cognition is generally the term used, being able to take previous learned 
knowledge and apply it in new contexts.

For people who know the values well it’s becomes unconscious knowledge and that 
make it a) hard to pass on and b) they may be a little confused why it’s not 
obvious to everyone. Experts often make poor teachers because of this.

In general for any given knowledge/skills area a lot of people are shallow 
learners, they learn what they need, just before they need it, and don’t really 
want or need to go too deep. This is a common attribute of adult learners. 
(There are of course exceptions.) Things (which research has show) that can be 
done to best improve that include having the material in multiple formats, 
regular feedback and staggered repetition. You’ll note that the Incubator does 
provide an environment for that to happen and we generally do 2 of those 3 
things well, that not to say improvements can’t be made. I also suggest you 
have a look at Sharan's thesis for some other insights, the incubator actually 
does a far better job than some people may think.

> (3) It would be better to discuss what community problem is causing the 
> particular issue instead of putting the blame on poor mentoring.

I not so sure this is an universal issue with a single cause, the majority of 
podlings have no or few issues and progress well, a few don’t and there’s 
different factors involved in each case. One factor is certainly how far their 
development process is away from the ASF norm. Another may be company or 
cultural values shared by a majority of people on the project. However I do 
think that mentor education is one part of the solution.

> I’m overstating a little but I think this FAQ should tie back to solution 
> using the Apache Way of Governance.
> 
> (A) Consensus Decision Making on a public dev@/general@ Mailing List.
> (B) Community Growth is Recognizing all people providing value to the project 
> as being committed to the project. Trust these people.
> (C) Release Open Source Software following Apache Release and Distribution 
> Policies.
> (D) Brand compliance.

Well those are all well known and easy to follow… yet we have podlings that 
don’t follow these. Perhaps part of that is see above comment regards expert 
knowledge. :-)

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

Re: [MENTORS] Mentor guidance document

[Justin Mclean]

Hi,

> Specific feedback: I don't think the "Values" lists are needed. I would
> prefer these incorporated into the prose in the "Reasoning" section.

The reason it’s there is to map to the values. I think you don’t see the need 
for it because you have a good understanding of those, but I’m not sure that 
applies to everyone, in particular if you think of this document being for 
committers and PPMC members as well.

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 Superset (incubating) 0.34.0 [RC1]

[Justin Mclean]

Hi,

> Oh here's something. Somewhere inside the source release I have a version
> string that says "0.34.0rc1" and that now I'm realizing should really say
> "0.34.0" as it becomes an official release. Now changing that string will
> make for a different SHA.

That's a bit awkward. It would be best to call a vote again if it needs to be 
changed, given the changes shod be minor it shod be easy to review.

Other IPMC members might have another view. Anyone?

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 Superset (incubating) 0.34.0 [RC1]

[Justin Mclean]

Hi,

> since these issues seems non-blocking (given your +1) the fixes won't make 
> 0.34.0 which
> looks like it is good to go.

That’s fine.

> I couldn't get a clear read on the monokai theme's license either, I'll see
> with Erik who introduced these line whether we can just remove the lines.

If licensing is unknown or not easily tacked down then it may be best to remove 
it.

> Oh, mentors, quick question about the [RESULT] post, do I account for both
> threads (dev@+general@) in it, or just the general@ one?

Just the IPMC votes.

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 Superset (incubating) 0.34.0 [RC1]

[Maxime Beauchemin]

Oh here's something. Somewhere inside the source release I have a version
string that says "0.34.0rc1" and that now I'm realizing should really say
"0.34.0" as it becomes an official release. Now changing that string will
make for a different SHA.

How should I go about this?

On Wed, Aug 21, 2019 at 9:54 PM Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:

> Thanks Justin, I just addressed 1,2 and 3 here
> https://github.com/apache/incubator-superset/pull/8087, but since these
> issues seems non-blocking (given your +1) the fixes won't make 0.34.0 which
> looks like it is good to go.
>
> I couldn't get a clear read on the monokai theme's license either, I'll
> see with Erik who introduced these line whether we can just remove the
> lines.
>
> Oh, mentors, quick question about the [RESULT] post, do I account for both
> threads (dev@+general@) in it, or just the general@ one?
>
> Max
>
> On Tue, Aug 20, 2019 at 8:05 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> +1 (binding)
>>
>> I checked:
>> - incubating in name
>> - signatures and hashes fine
>> - DISCLAIMER exists, although you may want to use the DISCLAIMER_WIP [8]
>> - LICENSE is probably missing a few things (se below)
>> - NOTICE is fine
>> - No unexpected binary files
>> - I didn’t check compiling from source
>>
>> LiCENSE is missing:
>> - This BSD licensed file [1] The file also has an incorrectly has an ASF
>> header on it.
>> - This file in not mentioned [2] and I think is licensed like so [3] If
>> so that may be problematic [4]. However I seem to recall this was discussed
>> before so there may of been some conclusion about it? I also note that
>> .*geojson are explicitly listed in your rat excludes so I assume there a
>> reason for that. (Comments in the rat exclusion file could help here).
>> - This file [5] looks to contain the Monokai theme from [6] I’m unsure
>> how this is licensed. The pro version seems to require a commercial
>> license. It might of come from here [7]? which is MIT licensed.
>>
>> Thanks,
>> Justin
>>
>> 1. ./superset/extract_table_names.py
>> 2 ./assets/src/visualizations/CountryMap/countries/india.geojson
>> 3. ./licenses/LICENSE-diva-gis.txt
>> 4. https://apache.org/legal/resolved.html#cc-by
>> 5. superset/assets/src/components/FilterableTable/FilterableTable.jsx
>> 6. https://www.monokai.nl
>> 7 https://packagecontrol.io/packages/Monokai%20JSON%2B
>> 8 https://incubator.apache.org/policy/incubation.html#disclaimers
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [OFFER] Offer to Mentor one or two podlings

[Javi Roman]

Many thanks Julian,

By the way, any help with the last binding IPMC vote for the new
Myriad release it would be appreciated.
--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info
Apache Id: javiroman

On Wed, Aug 21, 2019 at 3:32 PM Julian Feinauer
 wrote:
>
> Hi Javi,
> hi John,
>
> I will have a look and register to the mailing lists.
> I was also pointet to Milagro, so I'll also check that out : )
>
> Julian
>
> Am 20.08.19, 20:11 schrieb "Javi Roman" :
>
> At Apache Myriad we need some help, our more active mentor is really
> busy right now.
>
> Myriad => Hadoop YARN (Big Data) and the awesome Mesos, what else! ;-)
> --
> Javi Roman
>
> Twitter: @javiromanrh
> GitHub: github.com/javiroman
> Linkedin: es.linkedin.com/in/javiroman
> Big Data Blog: dataintensive.info
> Apache Id: javiroman
>
> On Tue, Aug 20, 2019 at 5:42 PM John D. Ament  
> wrote:
> >
> > Julian,
> >
> > Apache Tamaya could use help.  My activity has been reduced pretty 
> heavily as of late.
> >
> > John
> >
> > On 2019/08/13 06:21:54, Julian Feinauer  
> wrote:
> > > Hi,
> > >
> > > this goes to the IPMC as well as to podlings watching this list.
> > > I just recently became IPMC member and am currently pretty active in 
> the IoTDB Project as “informal mentor” (started there before becoming IPMC 
> member) together with 3 other pretty active mentors.
> > > As I received a lot of help from mentors and learned a lot about the 
> Apache Way since I joined incubating projects, I think its time now to give 
> something back. I could join one or two other podlings as Mentor if I am 
> needed.
> > >
> > > I gained a reasonable amount of “podling” experience hands-on during 
> the last 2 years after joining the PLC4X project and moving from release 0.1 
> to TLP and am active in other Podlings.
> > > My main interest is in the IoT, Big Data and analytics area (I’m 
> active in PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the 
> JVM. So this is the area where I could help most, I guess.
> > >
> > > So if someone has an idea where I can help, feel free to contact me!
> > >
> > > Julian
> > >
> >
> > -
> > 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: [MENTORS] Mentor guidance document

[Dave Fisher]

Hi -

Sorry for my top post, but I have some observations about your “guide”.

(1) It is more a mentoring FAQ than a guide.
(2) You are listing symptoms / policy violations.
(3) It would be better to discuss what community problem is causing the 
particular issue instead of putting the blame on poor mentoring.

I’m overstating a little but I think this FAQ should tie back to solution using 
the Apache Way of Governance.

(A) Consensus Decision Making on a public dev@/general@ Mailing List.
(B) Community Growth is Recognizing all people providing value to the project 
as being committed to the project. Trust these people.
(C) Release Open Source Software following Apache Release and Distribution 
Policies.
(D) Brand compliance.

If a project does those things then things are good.

Regards,
Dave

Sent from my iPhone

> On Aug 20, 2019, at 9:41 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Sone thoughts inline.
> 
>> Documentation does not solve the problem.
> 
> I agree it doesn’t solve the whole problem. But it may give time poor mentors 
> more time to do other things if they can easily reference collective 
> knowledge on these issues.
> 
>> If someone doesn't already "get" this stuff then they should not be 
>> mentoring.
> 
> We have had on occasion people who are mentoring who may not get this stuff 
> but were passionate supports of their projects, should we exclude them? Some 
> of this is down to inexperience, and mentoring is one of the good ways to  
> improve this knowledge and become a better mentor. Even if you have gone 
> though incubation and mentored a project before you may of not come across 
> the same situation and it’s not always obvious how to apply the values, 
> especially in case where there’s conflict between those values (or ASF 
> policies).
> 
>> Having a document does not replace for selecting good mentors who have the 
>> time to do the job right.
> 
> 1-2 years (or more in some cases) a long commitment and life sometime  
> changes things, replacement mentors can’t in all cases be found, so even if 
> the initial condition is true, it may not be a year into teh project.
> 
> I had thought of making up a mentor capability / score card to help podlings 
> elect mentors if they don’t already have one. But haven't suggested it 
> previously as it would probably be unpopular and could be used unproductively.
> 
>> It's a good effort in the broader context, but doesn't solve the problem I 
>> see in the IPMC (insufficient high quality mentoring coupled with too much 
>> application of rules in the process). 
> 
> Is that because you think don’t we have enough high quality mentors? Or the 
> ones we do have are spread a little too thin? Or that we have these people 
> but they are not mentoring projects?
> 
>> How would I solve the problem? If I were championing another project into 
>> the ASF I would carefully select mentors, just as I have in the past.
> 
> Being here along time and your previous / current positions would make it 
> easy for to be able to get the best mentors we have that are a good fit for 
> the project. I’m not sure that all new incubating projects are able to do 
> that.
> 
>> I don't mean to say the effort you are putting in is wasted effort. Clarity 
>> in what is expected can help the podlings, 
> 
> Do any other mentors want to contribute to this or think it’s an idea worth 
> perusing? If not I’ll drop it and focus on something else.
> 
>> I don't see how this can really help those people I would already trust to 
>> be good mentors i.e. People who have a vested interest in the success of the 
>> project and already know how to apply the Apache Way to new communities so 
>> that they might flourish in their own way.
> 
> I not sure we actually have enough mentors with those abilities and knowledge 
> for all of the 50 odd podlings we have or a pool of idle mentors than new 
> projects can select from.
> 
> 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

[RESULT][VOTE] Release Apache Superset (incubating) 0.34.0 [RC1]

[Maxime Beauchemin]

Dear community,

I'm happy to announce that the vote passes with 9 * +1 votes (7 binding, 2
non-binding)

*+1 votes*
* Justin Mclean (binding)
* Jim Jagielski (binding)
* Julian Feinauer (binding)
* Alan Gates (binding)
* Abhishek Sharma (binding)
* Jakob Homan (binding)
* Furkan Kamaci (binding)
* Jeff Feng (non-binding)
* Bolke de Bruin (non-binding)

*0 votes*
* None

*-1 votes*
* None

Vote thread can be found here
,
and the list members can be found here
.

Look forward to an [ANNOUNCE] thread for the 0.34.0 release in the next few
days.

Cheers!

Max


On Wed, Aug 21, 2019 at 9:54 PM Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:

> Thanks Justin, I just addressed 1,2 and 3 here
> https://github.com/apache/incubator-superset/pull/8087, but since these
> issues seems non-blocking (given your +1) the fixes won't make 0.34.0 which
> looks like it is good to go.
>
> I couldn't get a clear read on the monokai theme's license either, I'll
> see with Erik who introduced these line whether we can just remove the
> lines.
>
> Oh, mentors, quick question about the [RESULT] post, do I account for both
> threads (dev@+general@) in it, or just the general@ one?
>
> Max
>
> On Tue, Aug 20, 2019 at 8:05 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> +1 (binding)
>>
>> I checked:
>> - incubating in name
>> - signatures and hashes fine
>> - DISCLAIMER exists, although you may want to use the DISCLAIMER_WIP [8]
>> - LICENSE is probably missing a few things (se below)
>> - NOTICE is fine
>> - No unexpected binary files
>> - I didn’t check compiling from source
>>
>> LiCENSE is missing:
>> - This BSD licensed file [1] The file also has an incorrectly has an ASF
>> header on it.
>> - This file in not mentioned [2] and I think is licensed like so [3] If
>> so that may be problematic [4]. However I seem to recall this was discussed
>> before so there may of been some conclusion about it? I also note that
>> .*geojson are explicitly listed in your rat excludes so I assume there a
>> reason for that. (Comments in the rat exclusion file could help here).
>> - This file [5] looks to contain the Monokai theme from [6] I’m unsure
>> how this is licensed. The pro version seems to require a commercial
>> license. It might of come from here [7]? which is MIT licensed.
>>
>> Thanks,
>> Justin
>>
>> 1. ./superset/extract_table_names.py
>> 2 ./assets/src/visualizations/CountryMap/countries/india.geojson
>> 3. ./licenses/LICENSE-diva-gis.txt
>> 4. https://apache.org/legal/resolved.html#cc-by
>> 5. superset/assets/src/components/FilterableTable/FilterableTable.jsx
>> 6. https://www.monokai.nl
>> 7 https://packagecontrol.io/packages/Monokai%20JSON%2B
>> 8 https://incubator.apache.org/policy/incubation.html#disclaimers
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [VOTE] Release Apache Superset (incubating) 0.34.0 [RC1]

[Maxime Beauchemin]

Thanks Justin, I just addressed 1,2 and 3 here
https://github.com/apache/incubator-superset/pull/8087, but since these
issues seems non-blocking (given your +1) the fixes won't make 0.34.0 which
looks like it is good to go.

I couldn't get a clear read on the monokai theme's license either, I'll see
with Erik who introduced these line whether we can just remove the lines.

Oh, mentors, quick question about the [RESULT] post, do I account for both
threads (dev@+general@) in it, or just the general@ one?

Max

On Tue, Aug 20, 2019 at 8:05 PM Justin Mclean 
wrote:

> Hi,
>
> +1 (binding)
>
> I checked:
> - incubating in name
> - signatures and hashes fine
> - DISCLAIMER exists, although you may want to use the DISCLAIMER_WIP [8]
> - LICENSE is probably missing a few things (se below)
> - NOTICE is fine
> - No unexpected binary files
> - I didn’t check compiling from source
>
> LiCENSE is missing:
> - This BSD licensed file [1] The file also has an incorrectly has an ASF
> header on it.
> - This file in not mentioned [2] and I think is licensed like so [3] If so
> that may be problematic [4]. However I seem to recall this was discussed
> before so there may of been some conclusion about it? I also note that
> .*geojson are explicitly listed in your rat excludes so I assume there a
> reason for that. (Comments in the rat exclusion file could help here).
> - This file [5] looks to contain the Monokai theme from [6] I’m unsure how
> this is licensed. The pro version seems to require a commercial license. It
> might of come from here [7]? which is MIT licensed.
>
> Thanks,
> Justin
>
> 1. ./superset/extract_table_names.py
> 2 ./assets/src/visualizations/CountryMap/countries/india.geojson
> 3. ./licenses/LICENSE-diva-gis.txt
> 4. https://apache.org/legal/resolved.html#cc-by
> 5. superset/assets/src/components/FilterableTable/FilterableTable.jsx
> 6. https://www.monokai.nl
> 7 https://packagecontrol.io/packages/Monokai%20JSON%2B
> 8 https://incubator.apache.org/policy/incubation.html#disclaimers
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release 1.1.0-incubating-RC2

[Kenneth Knowles]

I will retract my -1. I need not speak for the others in this thread.

If the other IPMC member found and looked at RC2 then by all means proceed.
I had guessed that confirming this fact was equivalent to a replacement
vote. If not, great!

Kenn

On Wed, Aug 21, 2019 at 8:31 PM leerho  wrote:

> RE: VERIFY VOTE
>
> Folks,
>
> My apologies, there was an error in the Vote Letter whereby the top of the
> letter clearly requests a vote on RC2, but down below, the link to the
> Release Candidate and the GitHub Tag were actually pointing to RC1.
> Everything else appears to be correct.
>
> Please verify that it was RC2 that you examined and voted on.
>
> Thank you!
>
> Lee.
>
>
>
> On Wed, Aug 21, 2019 at 8:09 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > > &^%$%^&  You are right.  That is a terrible copy/paste error on my
> part.
> > > However, the top of the vote letter clearly calls out RC2.  Are you
> > > changing your vote to -1?  If so I will correct the vote letter and we
> > will
> > > have to start over.
> >
> > I think it’s clear enough that it was RC2 that was being released and
> that
> > what I looked at. Perhaps just confirm that any other IPMC votes were
> also
> > on RC2?
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Release 1.1.0-incubating-RC2

[leerho]

RE: VERIFY VOTE

Folks,

My apologies, there was an error in the Vote Letter whereby the top of the
letter clearly requests a vote on RC2, but down below, the link to the
Release Candidate and the GitHub Tag were actually pointing to RC1.
Everything else appears to be correct.

Please verify that it was RC2 that you examined and voted on.

Thank you!

Lee.



On Wed, Aug 21, 2019 at 8:09 PM Justin Mclean 
wrote:

> Hi,
>
> > &^%$%^&  You are right.  That is a terrible copy/paste error on my part.
> > However, the top of the vote letter clearly calls out RC2.  Are you
> > changing your vote to -1?  If so I will correct the vote letter and we
> will
> > have to start over.
>
> I think it’s clear enough that it was RC2 that was being released and that
> what I looked at. Perhaps just confirm that any other IPMC votes were also
> on RC2?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release 1.1.0-incubating-RC2

[Justin Mclean]

Hi,

> &^%$%^&  You are right.  That is a terrible copy/paste error on my part.
> However, the top of the vote letter clearly calls out RC2.  Are you
> changing your vote to -1?  If so I will correct the vote letter and we will
> have to start over.

I think it’s clear enough that it was RC2 that was being released and that what 
I looked at. Perhaps just confirm that any other IPMC votes were also on RC2?

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

Re: [VOTE] Release 1.1.0-incubating-RC2

[leerho]

&^%$%^&  You are right.  That is a terrible copy/paste error on my part.
However, the top of the vote letter clearly calls out RC2.  Are you
changing your vote to -1?  If so I will correct the vote letter and we will
have to start over.



On Wed, Aug 21, 2019 at 7:08 PM Kenneth Knowles  wrote:

> -1 because I did in fact download RC1. I had not noticed, but your call for
> this vote on general@ links to RC1 artifacts. So the archive of this
> thread
> will be confusing if some votes were cast after verifying RC1 while others
> are corrected.
>
> Kenn
>
> On Wed, Aug 21, 2019 at 5:20 PM leerho  wrote:
>
> > Just a guess, did you happen to download RC1 by mistake?
> >
> > Lee.
> >
> > On Wed, Aug 21, 2019 at 5:09 PM leerho  wrote:
> >
> > > Kenn,
> > >
> > > I am puzzled by
> > >
> > > I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is
> looking
> > >> for a .git directory.
> > >
> > >
> > > The git-commit-id plugin is in a separate "nexus-jars" profile which
> must
> > > be called from the command line.
> > > it is specifically placed in the separate profile so that it will not
> be
> > > called from the main Maven build lifecycle.
> > >
> > > If you are running just "mvn test" or even "mvn install" that plugin
> > > should not be called.
> > >
> > > I don't have that problem.
> > >
> > > Lee.
> > >
> > >
> > >
> > > On Wed, Aug 21, 2019 at 11:57 AM Kenneth Knowles 
> > wrote:
> > >
> > >> +1
> > >>
> > >> Triple-checked: LICENSE, DISCLAIMER, license headers, mvn test
> > >>
> > >> I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is
> > looking
> > >> for a .git directory.
> > >>
> > >> On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean <
> jus...@classsoftware.com
> > >
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > +1 (binding)
> > >> >
> > >> > I checked:
> > >> > - incubating in name
> > >> > - signatures and hashes fine
> > >> > - DISCLAIMER exists and uses the WIP text. you also might want to
> fill
> > >> in
> > >> > #Podling-Name#
> > >> > - LICENSE is OK. Do you know what is missing?
> > >> > - NOTICE is fine
> > >> > - NO binary files in release
> > >> > - All source files have ASF header
> > >> > - Can compile from source
> > >> >
> > >> > There’s some very minor issues:
> > >> > - I assume that some of the files may have an incorrect header?
> > >> > [1][2][3][4][6][7][8]. 3rd party headers should probably not be
> > replaced
> > >> > with ASF ones [9] unless they have been extensively modified. This
> > shod
> > >> be
> > >> > mentioned in the DISCLAIMER.
> > >> > - In LICENSE there is probably no need to mention the java files
> that
> > >> use
> > >> > the Gettysburg address.
> > >> > - "lee...@users.noreply.github.com” is probably not the best email
> to
> > >> > sign the release with, please use an apache one in future.
> > >> > - It’s nicer if the source unzips into a directory
> > >> >
> > >> > Thanks,
> > >> > Justin
> > >> >
> > >> > 1.
> src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
> > >> > 2. src/main/java/org/apache/datasketches/memory/XxHash64.java
> > >> > 3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
> > >> > 4.
> > src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
> > >> > 5. src/main/java/org/apache/datasketches/memory/Utf8.java
> > >> > 6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
> > >> > 7
> > src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
> > >> > 8 src/main/java/org/apache/datasketches/memory/XxHash64.java
> > >> > 9 https://www.apache.org/legal/src-headers.html#3party
> > >> >
> -
> > >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> > For additional commands, e-mail: general-h...@incubator.apache.org
> > >> >
> > >> >
> > >>
> > >
> >
>

Re: [VOTE] Release Apache ShardingSphere (Incubating) 4.0.0-RC2

[Gosling Von]

+1 (binding), forward my vote from PPMC.

Best Regards,
Von Gosling

> On Aug 20, 2019, at 6:16 PM, Zhang Yonglun  wrote:
> 
> Hello all,
> 
> This is a call for vote to release Apache ShardingSphere (Incubating)
> version 4.0.0-RC2.
> 
> The Apache ShardingSphere community has voted on and approved a proposal to
> release Apache ShardingSphere (Incubating) version 4.0.0-RC2.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> ShardingSphere is an open-source ecosystem consisted of a set of
> distributed database middleware solutions, including 2 independent
> products, Sharding-JDBC & Sharding-Proxy.
> 
> Sharding-JDBC is an enhanced JDBC driver that provides in-process
> transparent distributed database by connecting to multiple database back
> ends. It supports many ORM frameworks and database connection pools and
> supports many back end databases that have JDBC interfaces: MySQL, Oracle,
> SQLServer and PostgreSQL.
> 
> Sharding-Proxy is a database proxy that runs in a separate process and
> appears as a database server to multiple back end databases. It supports
> multiple client front ends such as MySQL Command Client, MySQL Workbench,
> Navicat etc. Current support is for MySQL and PostgreSQL.
> 
> ShardingSphere community vote and result thread:
> https://lists.apache.org/thread.html/4b29490f433dd26cc85d0e00340def3bd0f7b64e4bd2f3512e568bcd@%3Cdev.shardingsphere.apache.org%3E
> 
> Release notes:
> https://github.com/apache/incubator-shardingsphere/blob/dev/RELEASE-NOTES.md
> 
> The release candidates:
> https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/4.0.0-RC2/
> 
> Maven 2 staging repository:
> https://repository.apache.org/content/repositories/staging/org/apache/shardingsphere/
> 
> Git tag for the release:
> https://github.com/apache/incubator-shardingsphere/tree/4.0.0-RC2
> 
> Release Commit ID:
> https://github.com/apache/incubator-shardingsphere/commit/85f2ff877a7aaf122998964a0d03f7c9b2830e36
> 
> Keys to verify the Release Candidate:
> https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/KEYS
> GPG username: zhangyonglun
> 
> Look at here for how to verify this release candidate:
> https://shardingsphere.apache.org/community/en/contribute/release/
> 
> 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
> 
> Checklist for reference:
> 
> [ ] Download links are valid.
> 
> [ ] Checksums and PGP signatures are valid.
> 
> [ ] DISCLAIMER is included.
> 
> [ ] Source code artifacts have correct names matching the current release.
> 
> [ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.
> 
> [ ] All files have license headers if necessary.
> 
> [ ] No compiled archives bundled in source archive.
> 
> -- 
> Zhang Yonglun
> Apache ShardingSphere


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

Re: [VOTE] Release 1.1.0-incubating-RC2

[Kenneth Knowles]

-1 because I did in fact download RC1. I had not noticed, but your call for
this vote on general@ links to RC1 artifacts. So the archive of this thread
will be confusing if some votes were cast after verifying RC1 while others
are corrected.

Kenn

On Wed, Aug 21, 2019 at 5:20 PM leerho  wrote:

> Just a guess, did you happen to download RC1 by mistake?
>
> Lee.
>
> On Wed, Aug 21, 2019 at 5:09 PM leerho  wrote:
>
> > Kenn,
> >
> > I am puzzled by
> >
> > I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
> >> for a .git directory.
> >
> >
> > The git-commit-id plugin is in a separate "nexus-jars" profile which must
> > be called from the command line.
> > it is specifically placed in the separate profile so that it will not be
> > called from the main Maven build lifecycle.
> >
> > If you are running just "mvn test" or even "mvn install" that plugin
> > should not be called.
> >
> > I don't have that problem.
> >
> > Lee.
> >
> >
> >
> > On Wed, Aug 21, 2019 at 11:57 AM Kenneth Knowles 
> wrote:
> >
> >> +1
> >>
> >> Triple-checked: LICENSE, DISCLAIMER, license headers, mvn test
> >>
> >> I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is
> looking
> >> for a .git directory.
> >>
> >> On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean  >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > +1 (binding)
> >> >
> >> > I checked:
> >> > - incubating in name
> >> > - signatures and hashes fine
> >> > - DISCLAIMER exists and uses the WIP text. you also might want to fill
> >> in
> >> > #Podling-Name#
> >> > - LICENSE is OK. Do you know what is missing?
> >> > - NOTICE is fine
> >> > - NO binary files in release
> >> > - All source files have ASF header
> >> > - Can compile from source
> >> >
> >> > There’s some very minor issues:
> >> > - I assume that some of the files may have an incorrect header?
> >> > [1][2][3][4][6][7][8]. 3rd party headers should probably not be
> replaced
> >> > with ASF ones [9] unless they have been extensively modified. This
> shod
> >> be
> >> > mentioned in the DISCLAIMER.
> >> > - In LICENSE there is probably no need to mention the java files that
> >> use
> >> > the Gettysburg address.
> >> > - "lee...@users.noreply.github.com” is probably not the best email to
> >> > sign the release with, please use an apache one in future.
> >> > - It’s nicer if the source unzips into a directory
> >> >
> >> > Thanks,
> >> > Justin
> >> >
> >> > 1. src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
> >> > 2. src/main/java/org/apache/datasketches/memory/XxHash64.java
> >> > 3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
> >> > 4.
> src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
> >> > 5. src/main/java/org/apache/datasketches/memory/Utf8.java
> >> > 6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
> >> > 7
> src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
> >> > 8 src/main/java/org/apache/datasketches/memory/XxHash64.java
> >> > 9 https://www.apache.org/legal/src-headers.html#3party
> >> > -
> >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> > For additional commands, e-mail: general-h...@incubator.apache.org
> >> >
> >> >
> >>
> >
>

[RESULT] was [VOTE] Release Apache Flagon UserALE.js (Incubating) v2.0.2

[Joshua Poore]

All,

The VOTE to Release Apache Flagon UserALE.js (Incubating) v2.0.2 has concluded. 
Thanks to all who voted.

This VOTE has passed successfully within the Apache Flagon community and the 
Incubator Project community. 

The VOTE tally is as follows:

[+1] 8  
Joshua Poore
Rob Foley (`Confused`)
Laura Mariano
Furkan Kamaci*
Arthi Vezhavendan
Tim Allison*
Dave Meikle*
Justin McLean*

[0] 0

[-1]

*Binding IPMC VOTE

The Apache Flagon community will progress to remaining release processes.


Thanks,

Joshua Poore (FLAGON PPMC)


> On Aug 20, 2019, at 12:40 AM, Dave Fisher  wrote:
> 
> You have enough IPMC votes from your mentors.
> 
> I think you are good.
> 
> Sent from my iPhone
> 
>> On Aug 19, 2019, at 7:36 PM, Joshua Poore  wrote:
>> 
>> Hi Folks—
>> 
>> Just a reminder to VOTE on Apache Flagon UserALE.js (Incubating) v2.0.2. 
>> 
>> We’ve passed the VOTE on dev@, still looking for a few binding VOTE on 
>> general to release this security patch. 
>> 
>> Many thanks!
>> 
>> Josh
>> 
>>> On Aug 17, 2019, at 6:16 PM, Justin Mclean  wrote:
>>> 
>>> Hi,
>>> 
>>> +1(binding)
>>> 
>>> I checked the new binaries and they container the DISCLAIMER and signatures 
>>> and hashes match. It would off been easier to review if this was another RC 
>>> as then an easy comparison could be made with the previous files.
>>> 
>>> 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
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: [VOTE] Release 1.1.0-incubating-RC2

[Justin Mclean]

Hi,

> Of all of these, perhaps #4, #6, #7 (perhaps #5) could have the source
> license header at the top.  Even so, that would be incredibly conservative
> and generous.

IMO Unless changes are significant I’d leave the original header in there. Up 
to the PPMC what they think the definition of significant is, you might want to 
discuss that, but typically teh bar is high. For instance changing code form 
one language to another is usually not considered enough to change the header.

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

Re: [VOTE] Release 1.1.0-incubating-RC2

[leerho]

Just a guess, did you happen to download RC1 by mistake?

Lee.

On Wed, Aug 21, 2019 at 5:09 PM leerho  wrote:

> Kenn,
>
> I am puzzled by
>
> I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
>> for a .git directory.
>
>
> The git-commit-id plugin is in a separate "nexus-jars" profile which must
> be called from the command line.
> it is specifically placed in the separate profile so that it will not be
> called from the main Maven build lifecycle.
>
> If you are running just "mvn test" or even "mvn install" that plugin
> should not be called.
>
> I don't have that problem.
>
> Lee.
>
>
>
> On Wed, Aug 21, 2019 at 11:57 AM Kenneth Knowles  wrote:
>
>> +1
>>
>> Triple-checked: LICENSE, DISCLAIMER, license headers, mvn test
>>
>> I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
>> for a .git directory.
>>
>> On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean 
>> wrote:
>>
>> > Hi,
>> >
>> > +1 (binding)
>> >
>> > I checked:
>> > - incubating in name
>> > - signatures and hashes fine
>> > - DISCLAIMER exists and uses the WIP text. you also might want to fill
>> in
>> > #Podling-Name#
>> > - LICENSE is OK. Do you know what is missing?
>> > - NOTICE is fine
>> > - NO binary files in release
>> > - All source files have ASF header
>> > - Can compile from source
>> >
>> > There’s some very minor issues:
>> > - I assume that some of the files may have an incorrect header?
>> > [1][2][3][4][6][7][8]. 3rd party headers should probably not be replaced
>> > with ASF ones [9] unless they have been extensively modified. This shod
>> be
>> > mentioned in the DISCLAIMER.
>> > - In LICENSE there is probably no need to mention the java files that
>> use
>> > the Gettysburg address.
>> > - "lee...@users.noreply.github.com” is probably not the best email to
>> > sign the release with, please use an apache one in future.
>> > - It’s nicer if the source unzips into a directory
>> >
>> > Thanks,
>> > Justin
>> >
>> > 1. src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
>> > 2. src/main/java/org/apache/datasketches/memory/XxHash64.java
>> > 3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
>> > 4. src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
>> > 5. src/main/java/org/apache/datasketches/memory/Utf8.java
>> > 6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
>> > 7 src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
>> > 8 src/main/java/org/apache/datasketches/memory/XxHash64.java
>> > 9 https://www.apache.org/legal/src-headers.html#3party
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>> >
>>
>

Re: [VOTE] Release 1.1.0-incubating-RC2

[leerho]

Kenn,

I am puzzled by

I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
> for a .git directory.


The git-commit-id plugin is in a separate "nexus-jars" profile which must
be called from the command line.
it is specifically placed in the separate profile so that it will not be
called from the main Maven build lifecycle.

If you are running just "mvn test" or even "mvn install" that plugin should
not be called.

I don't have that problem.

Lee.



On Wed, Aug 21, 2019 at 11:57 AM Kenneth Knowles  wrote:

> +1
>
> Triple-checked: LICENSE, DISCLAIMER, license headers, mvn test
>
> I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
> for a .git directory.
>
> On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > +1 (binding)
> >
> > I checked:
> > - incubating in name
> > - signatures and hashes fine
> > - DISCLAIMER exists and uses the WIP text. you also might want to fill in
> > #Podling-Name#
> > - LICENSE is OK. Do you know what is missing?
> > - NOTICE is fine
> > - NO binary files in release
> > - All source files have ASF header
> > - Can compile from source
> >
> > There’s some very minor issues:
> > - I assume that some of the files may have an incorrect header?
> > [1][2][3][4][6][7][8]. 3rd party headers should probably not be replaced
> > with ASF ones [9] unless they have been extensively modified. This shod
> be
> > mentioned in the DISCLAIMER.
> > - In LICENSE there is probably no need to mention the java files that use
> > the Gettysburg address.
> > - "lee...@users.noreply.github.com” is probably not the best email to
> > sign the release with, please use an apache one in future.
> > - It’s nicer if the source unzips into a directory
> >
> > Thanks,
> > Justin
> >
> > 1. src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
> > 2. src/main/java/org/apache/datasketches/memory/XxHash64.java
> > 3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
> > 4. src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
> > 5. src/main/java/org/apache/datasketches/memory/Utf8.java
> > 6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
> > 7 src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
> > 8 src/main/java/org/apache/datasketches/memory/XxHash64.java
> > 9 https://www.apache.org/legal/src-headers.html#3party
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Release 1.1.0-incubating-RC2

[leerho]

Justin,
Thank you for your detailed response!  This is very helpful.

I will address each one of your license issues:

1. src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
There is only one method (6 lines long) in this entire file that was
"adapted" from the the original source file and is properly attributed  in
the Javadoc for the method and referenced in the LICENSE file.   Even this
method is modified quite a bit from the original.  Putting their license
header at the top of the file would be disregarding our original code in
the rest of the file.
My recommendation is to leave it as it is.  But if you have a suggestion as
to how this should be handled better, please let me know.

2. src/main/java/org/apache/datasketches/memory/XxHash64.java
About half of the original was copied (in form) and extensively modified.
Considerable functionality was removed and replaced with completely new
functionality.  The source is attributed at the top of the file and in the
LICENSE file.  Because of the extensive modifications, and the presence of
our original code, putting their license header at the top of the file
would be disregarding our original code in the rest of the file.  My
recommendation is to leave it as it is.  But please advise.

3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
Only one method in this file (~15 lines) is adapted from the original
source and every one of the lines had to be modified to suit our
environment.
The source is attributed at the top of the file and in the LICENSE file.
Because of the extensive modifications, and the presence of our original
code, putting their license header at the top of the file would be
disregarding our original code in the rest of the file.  My recommendation
is to leave it as it is.  But please advise.

4. src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
This file contains one method (~7 lines), which is heavily adapted from the
original source, and about 1000 static data values that are used in a
bit-for-bit compatibility test to make sure our implementation of this hash
function produces the exact same hashes bit-for-bit!  Even so, this file is
not an exact copy of the original.   The source is attributed at the top of
the file and in the LICENSE file. Perhaps it could be argued that because
the majority of this file contains a copy of their test data, Their
copyright header should be used.  Even that would disregard the
modifications we did make.  My recommendation is to leave it as it is.  But
please advise.

5. src/main/java/org/apache/datasketches/memory/Utf8.java
This file adapts portions of the original with extensive modifications.
Method names are changed, looping methods are different, etc.  Some of the
same code comments are copied over, but additional code comments were
added.  Again, bit-for-bit compatibility is critical.  The source is
attributed at the top of the file and in the LICENSE file.  My
recommendation is to leave it as it is.  But please advise.

6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
This file adapts portions of the original with modifications. Some of the
same code comments are copied over, but additional code comments were
added.  It could be argued that the original license header could be placed
at the top.  The source is attributed at the top of the file and in the
LICENSE file.  My recommendation is to leave it as it is.  But please
advise.


7 src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
This is a vastly stripped down version of the original.   It could be
argued that the original license header could be placed at the top.  The
source is attributed at the top of the file and in the LICENSE file.  My
recommendation is to leave it as it is.  But please advise.

8 src/main/java/org/apache/datasketches/memory/XxHash64.java  Duplicate of
#2.

Of all of these, perhaps #4, #6, #7 (perhaps #5) could have the source
license header at the top.  Even so, that would be incredibly conservative
and generous.

Lee.



On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean 
wrote:

> Hi,
>
> +1 (binding)
>
> I checked:
> - incubating in name
> - signatures and hashes fine
> - DISCLAIMER exists and uses the WIP text. you also might want to fill in
> #Podling-Name#
> - LICENSE is OK. Do you know what is missing?
> - NOTICE is fine
> - NO binary files in release
> - All source files have ASF header
> - Can compile from source
>
> There’s some very minor issues:
> - I assume that some of the files may have an incorrect header?
> [1][2][3][4][6][7][8]. 3rd party headers should probably not be replaced
> with ASF ones [9] unless they have been extensively modified. This shod be
> mentioned in the DISCLAIMER.
> - In LICENSE there is probably no need to mention the java files that use
> the Gettysburg address.
> - "lee...@users.noreply.github.com” is probably not the best email to
> sign the release with, please use an apache one in future.
> - It’s nice

Re: [MENTORS] Mentor guidance document

[Kenneth Knowles]

+1 I like this document.

I expect the way one reaches a point where they don't need the proposed
document is by doing a lot of mentoring. So you can't wait until they've
already done a lot of mentoring before you start them mentoring :-). It is
true that the starter examples are the ones that many people have
encountered and dealt with.

Personally, I think I'm at the point where I "get" many of the problem
statements. I can explain the reasoning well for some, less well for
others. I still often need help with approaches to improving things. So,
personally, I'll benefit from it.

 Specific feedback: I don't think the "Values" lists are needed. I would
prefer these incorporated into the prose in the "Reasoning" section.

Kenn



On Wed, Aug 21, 2019 at 12:08 AM Julian Hyde  wrote:

> +1 This guidance document is worth pursuing. There is plenty of criticism
> of mentors on this list, it helps to have some guidelines. Thanks Justin.
>
> > On Aug 20, 2019, at 9:41 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > Sone thoughts inline.
> >
> >> Documentation does not solve the problem.
> >
> > I agree it doesn’t solve the whole problem. But it may give time poor
> mentors more time to do other things if they can easily reference
> collective knowledge on these issues.
> >
> >> If someone doesn't already "get" this stuff then they should not be
> mentoring.
> >
> > We have had on occasion people who are mentoring who may not get this
> stuff but were passionate supports of their projects, should we exclude
> them? Some of this is down to inexperience, and mentoring is one of the
> good ways to  improve this knowledge and become a better mentor. Even if
> you have gone though incubation and mentored a project before you may of
> not come across the same situation and it’s not always obvious how to apply
> the values, especially in case where there’s conflict between those values
> (or ASF policies).
> >
> >> Having a document does not replace for selecting good mentors who have
> the time to do the job right.
> >
> > 1-2 years (or more in some cases) a long commitment and life sometime
> changes things, replacement mentors can’t in all cases be found, so even if
> the initial condition is true, it may not be a year into teh project.
> >
> > I had thought of making up a mentor capability / score card to help
> podlings elect mentors if they don’t already have one. But haven't
> suggested it previously as it would probably be unpopular and could be used
> unproductively.
> >
> >> It's a good effort in the broader context, but doesn't solve the
> problem I see in the IPMC (insufficient high quality mentoring coupled with
> too much application of rules in the process).
> >
> > Is that because you think don’t we have enough high quality mentors? Or
> the ones we do have are spread a little too thin? Or that we have these
> people but they are not mentoring projects?
> >
> >> How would I solve the problem? If I were championing another project
> into the ASF I would carefully select mentors, just as I have in the past.
> >
> > Being here along time and your previous / current positions would make
> it easy for to be able to get the best mentors we have that are a good fit
> for the project. I’m not sure that all new incubating projects are able to
> do that.
> >
> >> I don't mean to say the effort you are putting in is wasted effort.
> Clarity in what is expected can help the podlings,
> >
> > Do any other mentors want to contribute to this or think it’s an idea
> worth perusing? If not I’ll drop it and focus on something else.
> >
> >> I don't see how this can really help those people I would already trust
> to be good mentors i.e. People who have a vested interest in the success of
> the project and already know how to apply the Apache Way to new communities
> so that they might flourish in their own way.
> >
> > I not sure we actually have enough mentors with those abilities and
> knowledge for all of the 50 odd podlings we have or a pool of idle mentors
> than new projects can select from.
> >
> > Thanks,.
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Justin Mclean]

Hi,

Yep I agreed, it seems several IPMC members are are not in favours of this 
change, so it stays.

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

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

[John D. Ament]

Hi all,

Its been over a week since this thread was last active.  I know its created
some confusion within the IPMC now about the membership rules.  Unless we
can conclude this thread with a vote to change the process, I think we have
to assume the old process remains in place.

John

On Tue, Aug 13, 2019 at 2:57 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi,
>
> I fully agree with Julian here. But we should beware not to start a witch
> hunt about 'bad mentors' but develop an environment where one can step back
> as mentor if priorities change or for other reasons are no longer able to
> mentor. Everybody is a volunteer here so we should thank everybody for
> their effort and not be 'mad' if they 'do not enough'.
>
> But on the other hand this should encourage mentors who can for whatever
> reason not support their podlings enough to speak freely or look for others
> to fill in their spots.
>
> JulianF
>
>
>  Ursprüngliche Nachricht 
> Betreff: Re: [DISCUSS] Drop requirement that ASF members can join IPMC by
> just asking
> Von: Julian Hyde
> An: general@incubator.apache.org
> Cc:
>
> I agree with a lot of Dave Fisher's points.
>
> Some mentors will fail. Let's not waste effort trying to 'vet' them
> beforehand; it's time-consuming and counter-productive. Let's instead
> make it easier to detect when mentors fail (I think the "Have your
> mentors been helpful?" question on podling reports helps with that,
> but we need to do more), and let's try to increase the supply of
> potential good mentors. That way, we'll end up with good mentors, and
> we'll bring active new members into the Foundation.
>
> Julian
>
> On Tue, Aug 13, 2019 at 10:40 AM Hao Chen  wrote:
> >
> > I founded some apache project and graduated to TLP, and also keep
> > contributing to some other apache projects but almost in code, wonder to
> > know how to volunteer as IPMC to help some incubator projects graduate in
> > Apache way.
> >
> > Hao Chen
> >
> > On Tue, Aug 13, 2019 at 7:43 AM Dave Fisher 
> wrote:
> >
> > >
> > >
> > > Sent from my iPhone
> > >
> > > > On Aug 13, 2019, at 2:39 AM, Justin Mclean  >
> > > wrote:
> > > >
> > > > HI,
> > > >
> > > > I think there's a couple of misconceptions in this thread. First off
> > > currently you can join the IPMC two ways by being an ASF member and
> asking
> > > to join, the other by being voted in. On average the people being
> voted in
> > > tend to not go missing, review releases and sign off board reports more
> > > frequently.
> > > >
> > > > This has come up on list the list before and some (ex)board members
> have
> > > suggested that the IPMC shouldn’t;t allow people to be added this way.
> > > >
> > > > The suggestion here isn’t to be exclusionary, in fact we now allow
> > > people who have experience in incubator to ask if they can join, as it
> > > often hard for the IPMC to recognise merit, but they still need to be
> voted
> > > in. [1] When a project graduates I go though the PMC list and see if
> there
> > > are any likely IPMC candidates and contact them to see if they are
> > > interested, you’ll notice that more people have been voted in in recent
> > > times. In another thread I’ve gone one step further and suggested that
> > > mentors look out for people on their projects list who are release
> managers
> > > and vote on releases and suggest they be voted in as IPMC members. [2]
> > > (Option D). I agree the bar should be low.
> > > >
> > > > I do find it strange that we would allow people from a privileged
> group
> > > to auto join, when they possibly may not have shown merit and/or have
> not
> > > being involved in the incubator or an incubating project before.
> Obviously
> > > this doesn’t apply to all ASF members that ask join the incubator, but
> I
> > > can point to examples where this has given rise to serious issues.
> We’ve
> > > even had the occasional mentor who has never sent an email to their
> > > podlings list, never voted on a release and never signed off a board
> report.
> > >
> > > This is a different problem. I’ve seen nonmember mentors who were
> voted in
> > > who never really do anything. Let’s face it life intrudes in one way or
> > > another. One hopes that such mentors will resign, but they usually fade
> > > away.
> > >
> > > Let’s focus on service to podlings and try to replace mentors who for
> > > whatever reason cannot help.
> > >
> > > Following through with your proposal creates an IPMC that is not fully
> > > trusting the Membership. The membership of The ASF is the Foundation.
> These
> > > people have attained merit.
> > >
> > > >
> > > > I don’t mind if their's not consensus on this and letting this stay.
> > > There may be better ways to make sure mentors who sign up do their job
> and
> > > make mentors are more engaged. Please post your suggestions to this
> list
> > > for discussion.
> > >
> > > I reject the use of the verb “make” for this problem. We should “help”
> > > mentors and podling c

Re: [VOTE] Release 1.1.0-incubating-RC2

[Kenneth Knowles]

+1

Triple-checked: LICENSE, DISCLAIMER, license headers, mvn test

I did have to run `mvn -Dmaven.gitcommitid.skip test` since it is looking
for a .git directory.

On Tue, Aug 20, 2019 at 9:04 PM Justin Mclean 
wrote:

> Hi,
>
> +1 (binding)
>
> I checked:
> - incubating in name
> - signatures and hashes fine
> - DISCLAIMER exists and uses the WIP text. you also might want to fill in
> #Podling-Name#
> - LICENSE is OK. Do you know what is missing?
> - NOTICE is fine
> - NO binary files in release
> - All source files have ASF header
> - Can compile from source
>
> There’s some very minor issues:
> - I assume that some of the files may have an incorrect header?
> [1][2][3][4][6][7][8]. 3rd party headers should probably not be replaced
> with ASF ones [9] unless they have been extensively modified. This shod be
> mentioned in the DISCLAIMER.
> - In LICENSE there is probably no need to mention the java files that use
> the Gettysburg address.
> - "lee...@users.noreply.github.com” is probably not the best email to
> sign the release with, please use an apache one in future.
> - It’s nicer if the source unzips into a directory
>
> Thanks,
> Justin
>
> 1. src/main/java/org/apache/datasketches/memory/AccessByteBuffer.java
> 2. src/main/java/org/apache/datasketches/memory/XxHash64.java
> 3. src/test/java/org/apache/datasketches/memory/XxHash64Test.java
> 4. src/test/java/org/apache/datasketches/memory/XxHash64LoopingTest.java
> 5. src/main/java/org/apache/datasketches/memory/Utf8.java
> 6. src/test/java/org/apache/datasketches/memory/Utf8Test.java
> 7 src/test/java/org/apache/datasketches/memory/IsValidUtf8TestUtil.java
> 8 src/main/java/org/apache/datasketches/memory/XxHash64.java
> 9 https://www.apache.org/legal/src-headers.html#3party
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Matt Sicker]

I would think that if the person who submits the PR has the rights to
make that contribution, then their ICLA should cover that. See
https://www.apache.org/licenses/contributor-agreements.html for more
info.

On Wed, 21 Aug 2019 at 11:49, Roy Lenferink  wrote:
>
> > Given it was already had a ASF license header and from a ASF project why
> was IP clearance even needed? I assume the person involved has signed a
> ICLA?
>
> The individual contributors all submitted an ICLA and a CCLA for the
> company is already present. We were following IP clearance
> because the written software was developed outside of the ASF version
> control system (company internal VCS). After that, we squashed everything
> into a single commit and submitted it as a PR to Celix.
>
> Would IP clearance be necessary in this case (duplication of an already
> existing component)? Would IP clearance be necessary for new components
> which already have ASF headers in place?



-- 
Matt Sicker 

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

Re: [OFFER] Offer to Mentor one or two podlings

[Brian Spector]

Hi Julian, we’d be delighted if you could come on board as a mentor.

Thanks for considering it.

Best regards,
Brian

Brian Spector
Chief Product and Strategy Officer
T: +44 1394825764
1 Primrose Street
London, UK EC2A 2EX
https://qredo.com
Qredo Ltd is a limited company registered in England and Wales (registered 
number 7834052). This e-mail and any attachments are confidential, and are 
intended only for the named addressee(s). If you are not the intended recipient 
you may not copy, disclose to anyone else or otherwise use the content of this 
e-mail or any attachment thereto and should notify the sender immediately and 
delete them from your system.

From: Julian Feinauer 
Sent: Wednesday, August 21, 2019 3:32 pm b0ard
To: general@incubator.apache.org
Subject: Re: [OFFER] Offer to Mentor one or two podlings

Hi Javi,
hi John,

I will have a look and register to the mailing lists.
I was also pointet to Milagro, so I'll also check that out : )

Julian

Am 20.08.19, 20:11 schrieb "Javi Roman" :

At Apache Myriad we need some help, our more active mentor is really
busy right now.

Myriad => Hadoop YARN (Big Data) and the awesome Mesos, what else! ;-)
--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info
Apache Id: javiroman

On Tue, Aug 20, 2019 at 5:42 PM John D. Ament  wrote:
>
> Julian,
>
> Apache Tamaya could use help.  My activity has been reduced pretty 
heavily as of late.
>
> John
>
> On 2019/08/13 06:21:54, Julian Feinauer  
wrote:
> > Hi,
> >
> > this goes to the IPMC as well as to podlings watching this list.
> > I just recently became IPMC member and am currently pretty active in 
the IoTDB Project as “informal mentor” (started there before becoming IPMC 
member) together with 3 other pretty active mentors.
> > As I received a lot of help from mentors and learned a lot about the 
Apache Way since I joined incubating projects, I think its time now to give 
something back. I could join one or two other podlings as Mentor if I am needed.
> >
> > I gained a reasonable amount of “podling” experience hands-on during 
the last 2 years after joining the PLC4X project and moving from release 0.1 to 
TLP and am active in other Podlings.
> > My main interest is in the IoT, Big Data and analytics area (I’m active 
in PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the JVM. So 
this is the area where I could help most, I guess.
> >
> > So if someone has an idea where I can help, feel free to contact me!
> >
> > Julian
> >
>
> -
> 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



B�CB��[��X��ܚX�KK[XZ[��[�\�[
 ][��X��ܚX�P[��X�]܋�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[��[�\�[ 
Z[[��X�]܋�\X�K�ܙ�B

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Roy Lenferink]

> Given it was already had a ASF license header and from a ASF project why
was IP clearance even needed? I assume the person involved has signed a
ICLA?

The individual contributors all submitted an ICLA and a CCLA for the
company is already present. We were following IP clearance
because the written software was developed outside of the ASF version
control system (company internal VCS). After that, we squashed everything
into a single commit and submitted it as a PR to Celix.

Would IP clearance be necessary in this case (duplication of an already
existing component)? Would IP clearance be necessary for new components
which already have ASF headers in place?

[jira] [Created] (INCUBATOR-243) Are both cvs@ and commits@ mailing lists needed?

[Sebb (Jira)]

Sebb created INCUBATOR-243:
--

 Summary: Are both cvs@ and commits@ mailing lists needed?
 Key: INCUBATOR-243
 URL: https://issues.apache.org/jira/browse/INCUBATOR-243
 Project: Incubator
  Issue Type: Task
Reporter: Sebb


Incubator currently has both cvs@ and commits@ mailing lists.

That seems unnecessary.
Given that CVS has not been used for a long while, maybe that list should be 
shut down and any emails redirected to commits@.

Please raise an INFRA JIRA if so.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Roy Lenferink]

> Thales has been sending SGAs for all their Celix PRs lately.

Thales indeed sent 3 SGAs already. 1 definitely required: a complete new
component (HTTP admin).
This websocket pubsub admin and a tcp pubsub admin. All those were
approached the same.

--
Roy

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Matt Sicker]

Thales has been sending SGAs for all their Celix PRs lately.

On Wed, 21 Aug 2019 at 05:35, Justin Mclean  wrote:
>
> Hi,
>
> > The donation was developed by duplicating an existing Celix component
> > (pubsub_admin_zmq)[1] to a new component (pubsub_admin_websocket)[2].
> > Then the contents of the files has been changed to use websockets instead
> > of ZeroMQ. All this time the ASF header was kept in place.
>
>
> Given it was already had a ASF license header and from a ASF project why was 
> IP clearance even needed? I assume the person involved has signed a ICLA?
>
> Thanks,
> Justin
>
> 1. https://github.com/apache/celix/blob/master/NOTICE
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>


-- 
Matt Sicker 

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

Re: [VOTE] Release Apache Milagro (incubating) Crypto Libraries v1.0.0

[Julian Feinauer]

Hi all,

+1 (binding)

I checked
- Download links are valid
- Checksums and PGP signatures are valid for C 
- Checksums and PGP signatures are valid for JS
-  DISCLAIMER, LICENCE & NOTICE files are included
- Artefacts have incubating in name
- No compiled binaries are included
- C Libraries build correctly and all tests pass (make)on macOS Mojave 10.14.4
- JS Libraries build correctly and all tests pass (npm install and npm test) on 
macOS Mojave 10.14.4

Minor issues found:
- Your KEY File is in an unusual location and has an unusual name. Its more 
convenient (IMHO) to have in in the root folder of the project and named KEYS
- DISCLAIMER is formatted not optimally and hard to read (for C and JS)
- I found no RELEASE NOTES for C and JS

The release overall looks pretty good for me and the documentation is done 
really well!

Julian

Am 21.08.19, 16:10 schrieb "John McCane-Whitney" :

Hi,

This is a call to vote to release the Apache Milagro (incubating) Crypto 
Libraries v1.0.0.

The Apache Milagro (incubating) community has voted to approve this release 
with 5 x +1 votes.  The vote thread can be found here:


https://lists.apache.org/thread.html/7d788b5f3b293bb5545612d9f8af59a005f6407d57d826a1d2a2a563@%3Cdev.milagro.apache.org%3E

(Note that my original [VOTE] email doesn't render for some reason, but its 
contents can be seen further down in the thread)

And a summary of the result:


https://lists.apache.org/thread.html/6b320894a91d5ac298f71b1fab168127de6e75ba4763ab0b1b896a0f@%3Cdev.milagro.apache.org%3E

This release includes both C and JavaScript libraries tagged as v1.0.0 in 
the following repositories:

Crypto C Library:
https://github.com/apache/incubator-milagro-crypto-c/tags

milagro-crypto-c is a modern cryptographic C library that focuses on 
Elliptic Curve Cryptography but has support for legacy systems that require 
RSA. There is support for three different security levels; 128, 192 and 256 
bit. It has been written only in C and has no external dependencies other than 
an entropy source. Measures have been taken in the code base to prevent side 
channel attacks.  Pairing based cryptography (PBC) is a maturing field that has 
recently gained widespread acceptance. The library supports schemes that make 
use of PBC such as BLS for short signatures and MPIN for multi-factor 
authentication (MFA).

Crypto JavaScript Library:
https://github.com/apache/incubator-milagro-crypto-js/tags

milagro-crypto-js is the JavaScript equivalent of milagro-crypto-c. It has 
all the same functionality, API and even the intermediate calculated values in 
the functions are the same. This library allows you to run MFA using MPIN in 
the browser which, to the best of our knowledge, is the only such 
implementation of MFA in this context.

Both libraries have been under active development for many years and the 
APIs haven't changed in several months. There are extensive tests using third 
party test vectors and the tooling required to deploy this software into a 
modern software project. We believe that the code base has reached the point 
that we can perform general availability (GA) releases.

The compressed archives from these release along with a SHA512 checksum, 
PGP signature and PGP key file are being staged here:

https://dist.apache.org/repos/dist/dev/incubator/milagro

Specifically, for the C library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/team.keys

And for the JavaScript library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/team.keys

Please note that the project's website (https://milagro.apache.org) has 
been updated to include the standard Apache incubator disclaimer

[VOTE] Release Apache Milagro (incubating) Crypto Libraries v1.0.0

[John McCane-Whitney]

Hi,

This is a call to vote to release the Apache Milagro (incubating) Crypto 
Libraries v1.0.0.

The Apache Milagro (incubating) community has voted to approve this release 
with 5 x +1 votes.  The vote thread can be found here:

https://lists.apache.org/thread.html/7d788b5f3b293bb5545612d9f8af59a005f6407d57d826a1d2a2a563@%3Cdev.milagro.apache.org%3E

(Note that my original [VOTE] email doesn't render for some reason, but its 
contents can be seen further down in the thread)

And a summary of the result:

https://lists.apache.org/thread.html/6b320894a91d5ac298f71b1fab168127de6e75ba4763ab0b1b896a0f@%3Cdev.milagro.apache.org%3E

This release includes both C and JavaScript libraries tagged as v1.0.0 in the 
following repositories:

Crypto C Library:
https://github.com/apache/incubator-milagro-crypto-c/tags

milagro-crypto-c is a modern cryptographic C library that focuses on Elliptic 
Curve Cryptography but has support for legacy systems that require RSA. There 
is support for three different security levels; 128, 192 and 256 bit. It has 
been written only in C and has no external dependencies other than an entropy 
source. Measures have been taken in the code base to prevent side channel 
attacks.  Pairing based cryptography (PBC) is a maturing field that has 
recently gained widespread acceptance. The library supports schemes that make 
use of PBC such as BLS for short signatures and MPIN for multi-factor 
authentication (MFA).

Crypto JavaScript Library:
https://github.com/apache/incubator-milagro-crypto-js/tags

milagro-crypto-js is the JavaScript equivalent of milagro-crypto-c. It has all 
the same functionality, API and even the intermediate calculated values in the 
functions are the same. This library allows you to run MFA using MPIN in the 
browser which, to the best of our knowledge, is the only such implementation of 
MFA in this context.

Both libraries have been under active development for many years and the APIs 
haven't changed in several months. There are extensive tests using third party 
test vectors and the tooling required to deploy this software into a modern 
software project. We believe that the code base has reached the point that we 
can perform general availability (GA) releases.

The compressed archives from these release along with a SHA512 checksum, PGP 
signature and PGP key file are being staged here:

https://dist.apache.org/repos/dist/dev/incubator/milagro

Specifically, for the C library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/apache-milagro-crypto-c-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-c-1.0.0-incubating/team.keys

And for the JavaScript library:

Source code archive: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz
SHA512 checksum: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.sha512
PGP Signature: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/apache-milagro-crypto-js-1.0.0-incubating-src.tar.gz.asc
Keys: 
https://dist.apache.org/repos/dist/dev/incubator/milagro/apache-milagro-crypto-js-1.0.0-incubating/team.keys

Please note that the project's website (https://milagro.apache.org) has been 
updated to include the standard Apache incubator disclaimer and documentation 
for the above two libraries.  Please note that download links for the above two 
release have not been included, but will be as soon as the release's approval 
has been completed and the archives are available for public download.

We now kindly request that the Incubator PMC members review and vote on this 
incubator release as follows:

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

Checklist for reference:

[ ] Download links are valid
[ ] Checksums and PGP signatures are valid
[ ] DISCLAIMER, LICENCE & NOTICE files are included
[ ] Source code archives have correct names matching the current release.
[ ] All source code files have licence headers
[ ] No compiled binaries are included
[ ] Libraries build correctly and all tests pass (as per the instructions in 
their respective readme files) on either Windows, Mac or Linux.

The vote will be open for a minimum of 72 hours.  3 x +1 votes are required to 
approve this release.

Many thanks,

John

John McCane-Whitney
Director of Product at Qredo Ltd
T: +44 7966 490687
1 Primrose Str

Re: [OFFER] Offer to Mentor one or two podlings

[Julian Feinauer]

Hi Javi,
hi John,

I will have a look and register to the mailing lists.
I was also pointet to Milagro, so I'll also check that out : )

Julian

Am 20.08.19, 20:11 schrieb "Javi Roman" :

At Apache Myriad we need some help, our more active mentor is really
busy right now.

Myriad => Hadoop YARN (Big Data) and the awesome Mesos, what else! ;-)
--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info
Apache Id: javiroman

On Tue, Aug 20, 2019 at 5:42 PM John D. Ament  wrote:
>
> Julian,
>
> Apache Tamaya could use help.  My activity has been reduced pretty 
heavily as of late.
>
> John
>
> On 2019/08/13 06:21:54, Julian Feinauer  
wrote:
> > Hi,
> >
> > this goes to the IPMC as well as to podlings watching this list.
> > I just recently became IPMC member and am currently pretty active in 
the IoTDB Project as “informal mentor” (started there before becoming IPMC 
member) together with 3 other pretty active mentors.
> > As I received a lot of help from mentors and learned a lot about the 
Apache Way since I joined incubating projects, I think its time now to give 
something back. I could join one or two other podlings as Mentor if I am needed.
> >
> > I gained a reasonable amount of “podling” experience hands-on during 
the last 2 years after joining the PLC4X project and moving from release 0.1 to 
TLP and am active in other Podlings.
> > My main interest is in the IoT, Big Data and analytics area (I’m active 
in PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the JVM. So 
this is the area where I could help most, I guess.
> >
> > So if someone has an idea where I can help, feel free to contact me!
> >
> > Julian
> >
>
> -
> 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 ShardingSphere (Incubating) 4.0.0-RC2

[William Guo]

+1

I checked:
- Can compile from source
- DISCLAIMER, LICENSE,  NOTICE exists
- incubating in name
- signatures and hashes correct
- ASF headers fine


Thanks,
William


On Wed, Aug 21, 2019 at 4:49 PM Willem Jiang  wrote:

> +1 (binding)
>
> I checked:
>
> The artifacts has incubating in the name.
> There is no binary in the release kit.
> signature and hash is OK
> DISCLAIMER file exists
> LICENSE and NOTICE looks good to me.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Wed, Aug 21, 2019 at 1:15 PM Zhang Yonglun 
> wrote:
> >
> >  I have put the wrong link of Maven 2 staging repository, now it's
> updated
> > to:
> >
> > Maven 2 staging repository:
> >
> https://repository.apache.org/content/repositories/orgapacheshardingsphere-1022/org/apache/shardingsphere/
> >
> >
> > Zhang Yonglun  于2019年8月20日周二 下午6:16写道：
> >
> > > Hello all,
> > >
> > > This is a call for vote to release Apache ShardingSphere (Incubating)
> > > version 4.0.0-RC2.
> > >
> > > The Apache ShardingSphere community has voted on and approved a
> proposal
> > > to release Apache ShardingSphere (Incubating) version 4.0.0-RC2.
> > >
> > > We now kindly request the Incubator PMC members review and vote on this
> > > incubator release.
> > >
> > > ShardingSphere is an open-source ecosystem consisted of a set of
> > > distributed database middleware solutions, including 2 independent
> > > products, Sharding-JDBC & Sharding-Proxy.
> > >
> > > Sharding-JDBC is an enhanced JDBC driver that provides in-process
> > > transparent distributed database by connecting to multiple database
> back
> > > ends. It supports many ORM frameworks and database connection pools and
> > > supports many back end databases that have JDBC interfaces: MySQL,
> Oracle,
> > > SQLServer and PostgreSQL.
> > >
> > > Sharding-Proxy is a database proxy that runs in a separate process and
> > > appears as a database server to multiple back end databases. It
> supports
> > > multiple client front ends such as MySQL Command Client, MySQL
> Workbench,
> > > Navicat etc. Current support is for MySQL and PostgreSQL.
> > >
> > > ShardingSphere community vote and result thread:
> > >
> > >
> https://lists.apache.org/thread.html/4b29490f433dd26cc85d0e00340def3bd0f7b64e4bd2f3512e568bcd@%3Cdev.shardingsphere.apache.org%3E
> > >
> > > Release notes:
> > >
> > >
> https://github.com/apache/incubator-shardingsphere/blob/dev/RELEASE-NOTES.md
> > >
> > > The release candidates:
> > >
> https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/4.0.0-RC2/
> > >
> > > Maven 2 staging repository:
> > >
> > >
> https://repository.apache.org/content/repositories/staging/org/apache/shardingsphere/
> > >
> > > Git tag for the release:
> > > https://github.com/apache/incubator-shardingsphere/tree/4.0.0-RC2
> > >
> > > Release Commit ID:
> > >
> > >
> https://github.com/apache/incubator-shardingsphere/commit/85f2ff877a7aaf122998964a0d03f7c9b2830e36
> > >
> > > Keys to verify the Release Candidate:
> > > https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/KEYS
> > > GPG username: zhangyonglun
> > >
> > > Look at here for how to verify this release candidate:
> > > https://shardingsphere.apache.org/community/en/contribute/release/
> > >
> > > 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
> > >
> > > Checklist for reference:
> > >
> > > [ ] Download links are valid.
> > >
> > > [ ] Checksums and PGP signatures are valid.
> > >
> > > [ ] DISCLAIMER is included.
> > >
> > > [ ] Source code artifacts have correct names matching the current
> release.
> > >
> > > [ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.
> > >
> > > [ ] All files have license headers if necessary.
> > >
> > > [ ] No compiled archives bundled in source archive.
> > >
> > > --
> > > Zhang Yonglun
> > > Apache ShardingSphere
> > >
> >
> >
> > --
> > Zhang Yonglun
> > Apache ShardingSphere
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Justin Mclean]

Hi,

> The donation was developed by duplicating an existing Celix component
> (pubsub_admin_zmq)[1] to a new component (pubsub_admin_websocket)[2].
> Then the contents of the files has been changed to use websockets instead
> of ZeroMQ. All this time the ASF header was kept in place.


Given it was already had a ASF license header and from a ASF project why was IP 
clearance even needed? I assume the person involved has signed a ICLA?

Thanks,
Justin

1. https://github.com/apache/celix/blob/master/NOTICE
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [IP CLEARANCE] Apache Celix - Websocket pubsub admin

[Roy Lenferink]

 The donation was developed by duplicating an existing Celix component
(pubsub_admin_zmq)[1] to a new component (pubsub_admin_websocket)[2].
Then the contents of the files has been changed to use websockets instead
of ZeroMQ. All this time the ASF header was kept in place.

[1]
https://github.com/apache/celix/tree/develop/bundles/pubsub/pubsub_admin_zmq/src
[2]
https://github.com/dhbfischer/celix/tree/feature/websocket_pubsub_admin/bundles/pubsub/pubsub_admin_websocket/src

Op wo 21 aug. 2019 om 08:57 schreef Justin Mclean :

> Hi,
>
> > For Celix is it okay to continue if we update the NOTICE file and add the
> > following statement?:
> >
> > This product includes software developed at
> > Thales Nederland B.V. (https://www.thalesgroup.com/nl).
>
> That sounds fine to me, but it depends on the original headers of on those
> files or if the original source had it own NOTICE file, with a PR like this
> missing that information I cannot really answer that question.
>
> 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 ShardingSphere (Incubating) 4.0.0-RC2

[Furkan KAMACI]

Hi,

+1 from me.

 I checked:

- Incubating in name
- DISCLAIMER exists
- LICENSE and NOTICE are fine
- No unexpected binary files
- Signatures are OK
- Code compiles

Kind Regards,
Furkan KAMACI

On Wed, Aug 21, 2019 at 11:49 AM Willem Jiang 
wrote:

> +1 (binding)
>
> I checked:
>
> The artifacts has incubating in the name.
> There is no binary in the release kit.
> signature and hash is OK
> DISCLAIMER file exists
> LICENSE and NOTICE looks good to me.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Wed, Aug 21, 2019 at 1:15 PM Zhang Yonglun 
> wrote:
> >
> >  I have put the wrong link of Maven 2 staging repository, now it's
> updated
> > to:
> >
> > Maven 2 staging repository:
> >
> https://repository.apache.org/content/repositories/orgapacheshardingsphere-1022/org/apache/shardingsphere/
> >
> >
> > Zhang Yonglun  于2019年8月20日周二 下午6:16写道：
> >
> > > Hello all,
> > >
> > > This is a call for vote to release Apache ShardingSphere (Incubating)
> > > version 4.0.0-RC2.
> > >
> > > The Apache ShardingSphere community has voted on and approved a
> proposal
> > > to release Apache ShardingSphere (Incubating) version 4.0.0-RC2.
> > >
> > > We now kindly request the Incubator PMC members review and vote on this
> > > incubator release.
> > >
> > > ShardingSphere is an open-source ecosystem consisted of a set of
> > > distributed database middleware solutions, including 2 independent
> > > products, Sharding-JDBC & Sharding-Proxy.
> > >
> > > Sharding-JDBC is an enhanced JDBC driver that provides in-process
> > > transparent distributed database by connecting to multiple database
> back
> > > ends. It supports many ORM frameworks and database connection pools and
> > > supports many back end databases that have JDBC interfaces: MySQL,
> Oracle,
> > > SQLServer and PostgreSQL.
> > >
> > > Sharding-Proxy is a database proxy that runs in a separate process and
> > > appears as a database server to multiple back end databases. It
> supports
> > > multiple client front ends such as MySQL Command Client, MySQL
> Workbench,
> > > Navicat etc. Current support is for MySQL and PostgreSQL.
> > >
> > > ShardingSphere community vote and result thread:
> > >
> > >
> https://lists.apache.org/thread.html/4b29490f433dd26cc85d0e00340def3bd0f7b64e4bd2f3512e568bcd@%3Cdev.shardingsphere.apache.org%3E
> > >
> > > Release notes:
> > >
> > >
> https://github.com/apache/incubator-shardingsphere/blob/dev/RELEASE-NOTES.md
> > >
> > > The release candidates:
> > >
> https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/4.0.0-RC2/
> > >
> > > Maven 2 staging repository:
> > >
> > >
> https://repository.apache.org/content/repositories/staging/org/apache/shardingsphere/
> > >
> > > Git tag for the release:
> > > https://github.com/apache/incubator-shardingsphere/tree/4.0.0-RC2
> > >
> > > Release Commit ID:
> > >
> > >
> https://github.com/apache/incubator-shardingsphere/commit/85f2ff877a7aaf122998964a0d03f7c9b2830e36
> > >
> > > Keys to verify the Release Candidate:
> > > https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/KEYS
> > > GPG username: zhangyonglun
> > >
> > > Look at here for how to verify this release candidate:
> > > https://shardingsphere.apache.org/community/en/contribute/release/
> > >
> > > 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
> > >
> > > Checklist for reference:
> > >
> > > [ ] Download links are valid.
> > >
> > > [ ] Checksums and PGP signatures are valid.
> > >
> > > [ ] DISCLAIMER is included.
> > >
> > > [ ] Source code artifacts have correct names matching the current
> release.
> > >
> > > [ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.
> > >
> > > [ ] All files have license headers if necessary.
> > >
> > > [ ] No compiled archives bundled in source archive.
> > >
> > > --
> > > Zhang Yonglun
> > > Apache ShardingSphere
> > >
> >
> >
> > --
> > Zhang Yonglun
> > Apache ShardingSphere
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache ShardingSphere (Incubating) 4.0.0-RC2

[Willem Jiang]

+1 (binding)

I checked:

The artifacts has incubating in the name.
There is no binary in the release kit.
signature and hash is OK
DISCLAIMER file exists
LICENSE and NOTICE looks good to me.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Wed, Aug 21, 2019 at 1:15 PM Zhang Yonglun  wrote:
>
>  I have put the wrong link of Maven 2 staging repository, now it's updated
> to:
>
> Maven 2 staging repository:
> https://repository.apache.org/content/repositories/orgapacheshardingsphere-1022/org/apache/shardingsphere/
>
>
> Zhang Yonglun  于2019年8月20日周二 下午6:16写道：
>
> > Hello all,
> >
> > This is a call for vote to release Apache ShardingSphere (Incubating)
> > version 4.0.0-RC2.
> >
> > The Apache ShardingSphere community has voted on and approved a proposal
> > to release Apache ShardingSphere (Incubating) version 4.0.0-RC2.
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > ShardingSphere is an open-source ecosystem consisted of a set of
> > distributed database middleware solutions, including 2 independent
> > products, Sharding-JDBC & Sharding-Proxy.
> >
> > Sharding-JDBC is an enhanced JDBC driver that provides in-process
> > transparent distributed database by connecting to multiple database back
> > ends. It supports many ORM frameworks and database connection pools and
> > supports many back end databases that have JDBC interfaces: MySQL, Oracle,
> > SQLServer and PostgreSQL.
> >
> > Sharding-Proxy is a database proxy that runs in a separate process and
> > appears as a database server to multiple back end databases. It supports
> > multiple client front ends such as MySQL Command Client, MySQL Workbench,
> > Navicat etc. Current support is for MySQL and PostgreSQL.
> >
> > ShardingSphere community vote and result thread:
> >
> > https://lists.apache.org/thread.html/4b29490f433dd26cc85d0e00340def3bd0f7b64e4bd2f3512e568bcd@%3Cdev.shardingsphere.apache.org%3E
> >
> > Release notes:
> >
> > https://github.com/apache/incubator-shardingsphere/blob/dev/RELEASE-NOTES.md
> >
> > The release candidates:
> > https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/4.0.0-RC2/
> >
> > Maven 2 staging repository:
> >
> > https://repository.apache.org/content/repositories/staging/org/apache/shardingsphere/
> >
> > Git tag for the release:
> > https://github.com/apache/incubator-shardingsphere/tree/4.0.0-RC2
> >
> > Release Commit ID:
> >
> > https://github.com/apache/incubator-shardingsphere/commit/85f2ff877a7aaf122998964a0d03f7c9b2830e36
> >
> > Keys to verify the Release Candidate:
> > https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/KEYS
> > GPG username: zhangyonglun
> >
> > Look at here for how to verify this release candidate:
> > https://shardingsphere.apache.org/community/en/contribute/release/
> >
> > 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
> >
> > Checklist for reference:
> >
> > [ ] Download links are valid.
> >
> > [ ] Checksums and PGP signatures are valid.
> >
> > [ ] DISCLAIMER is included.
> >
> > [ ] Source code artifacts have correct names matching the current release.
> >
> > [ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.
> >
> > [ ] All files have license headers if necessary.
> >
> > [ ] No compiled archives bundled in source archive.
> >
> > --
> > Zhang Yonglun
> > Apache ShardingSphere
> >
>
>
> --
> Zhang Yonglun
> Apache ShardingSphere

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

Re: [MENTORS] Mentor guidance document

[Julian Hyde]

+1 This guidance document is worth pursuing. There is plenty of criticism of 
mentors on this list, it helps to have some guidelines. Thanks Justin.

> On Aug 20, 2019, at 9:41 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Sone thoughts inline.
> 
>> Documentation does not solve the problem.
> 
> I agree it doesn’t solve the whole problem. But it may give time poor mentors 
> more time to do other things if they can easily reference collective 
> knowledge on these issues.
> 
>> If someone doesn't already "get" this stuff then they should not be 
>> mentoring.
> 
> We have had on occasion people who are mentoring who may not get this stuff 
> but were passionate supports of their projects, should we exclude them? Some 
> of this is down to inexperience, and mentoring is one of the good ways to  
> improve this knowledge and become a better mentor. Even if you have gone 
> though incubation and mentored a project before you may of not come across 
> the same situation and it’s not always obvious how to apply the values, 
> especially in case where there’s conflict between those values (or ASF 
> policies).
> 
>> Having a document does not replace for selecting good mentors who have the 
>> time to do the job right.
> 
> 1-2 years (or more in some cases) a long commitment and life sometime  
> changes things, replacement mentors can’t in all cases be found, so even if 
> the initial condition is true, it may not be a year into teh project.
> 
> I had thought of making up a mentor capability / score card to help podlings 
> elect mentors if they don’t already have one. But haven't suggested it 
> previously as it would probably be unpopular and could be used unproductively.
> 
>> It's a good effort in the broader context, but doesn't solve the problem I 
>> see in the IPMC (insufficient high quality mentoring coupled with too much 
>> application of rules in the process). 
> 
> Is that because you think don’t we have enough high quality mentors? Or the 
> ones we do have are spread a little too thin? Or that we have these people 
> but they are not mentoring projects?
> 
>> How would I solve the problem? If I were championing another project into 
>> the ASF I would carefully select mentors, just as I have in the past.
> 
> Being here along time and your previous / current positions would make it 
> easy for to be able to get the best mentors we have that are a good fit for 
> the project. I’m not sure that all new incubating projects are able to do 
> that.
> 
>> I don't mean to say the effort you are putting in is wasted effort. Clarity 
>> in what is expected can help the podlings, 
> 
> Do any other mentors want to contribute to this or think it’s an idea worth 
> perusing? If not I’ll drop it and focus on something else.
> 
>> I don't see how this can really help those people I would already trust to 
>> be good mentors i.e. People who have a vested interest in the success of the 
>> project and already know how to apply the Apache Way to new communities so 
>> that they might flourish in their own way.
> 
> I not sure we actually have enough mentors with those abilities and knowledge 
> for all of the 50 odd podlings we have or a pool of idle mentors than new 
> projects can select from.
> 
> 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