Re: The role of a mentor

[Ted Dunning]

I try to be more aware early on and then ease up later after things start
moving smoothly.

I still watch a lot, however.



On Wed, Apr 11, 2018 at 9:47 PM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Thu, Apr 12, 2018 at 6:07 AM, Hen  wrote:
> > ...If you
> > think of someone you view as a mentor, they didn't spend all their time
> > looking over your shoulder. Instead you met with them from time to time
> and
> > discussed a topic that you were looking to find clarity on...
>
> That's how I see my role as a mentor - I try to become aware of where
> help is needed, but generally don't follow everything.
>
> For this I like the [mentors] subject line tag that some podlings use
> to raise the mentors attention on their dev list.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: The role of a mentor

[Bertrand Delacretaz]

On Thu, Apr 12, 2018 at 6:07 AM, Hen  wrote:
> ...If you
> think of someone you view as a mentor, they didn't spend all their time
> looking over your shoulder. Instead you met with them from time to time and
> discussed a topic that you were looking to find clarity on...

That's how I see my role as a mentor - I try to become aware of where
help is needed, but generally don't follow everything.

For this I like the [mentors] subject line tag that some podlings use
to raise the mentors attention on their dev list.

-Bertrand

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

Re: The role of a mentor

[Hen]

I liked Julian's description too.

Yours worries me though - specifically the "but in fact they are reading
every thread, watching every process being developed, thinking through
every decision. Very occasionally (in an ideal world) they are saying
nothing".

My first concern is because that's not in the meaning of mentor. If you
think of someone you view as a mentor, they didn't spend all their time
looking over your shoulder. Instead you met with them from time to time and
discussed a topic that you were looking to find clarity on; and your mentor
successfully helped you find clarity on that. Your description sounds more
like a coach, be it sports coach or another type. Always watching, ideally
doesn't have to nudge, but does when needed. Or Roz from Monster's Inc
"Always Watching". I know there's no reason why the definition of
Incubator Mentor has to equal other concepts of the word, but it helps.

The second concern is on available time. If we assume that all of us are
maxed out in our available time to volunteer for an activity, mentoring a
podling means giving up a substantial existing volunteer activity. In
essence to mentor a podling you have to stop tracking the communication on
another project, which means stopping contributing to another project.
That's a heavy hit and while having coaches (my word) for every podling
would be awesome, I don't see that we have that number of volunteer with
idle cycles waiting to do something.

Which takes us full circle - if what we want are coaches, absent (burnt
out?) mentors are no surprise at all.

Hen

On Tue, Apr 10, 2018 at 9:35 AM,  wrote:

> +1000
>
> I've not been very active in the incubator for some time. I've
> participated in these "role of the mentor" conversations many times over
> the years. I wish I'd been able to make my contribution as clear and
> accurate as Julian's contribution below... (applause)
>
> A good mentor *looks* like they are doing nothing, but in fact they are
> reading every thread, watching every process being developed, thinking
> through every decision. Very occasionally (in an ideal world) they are
> saying nothing.
>
> When they do choose to speak it's because something is happening that is
> in conflict with "the Apache Way". The goal is not to teach the community
> specific and rigid processes, the goal is to teach the community how to use
> the Apache Way to create communities that create software. The precise
> processes will evolve over time in a way that suits the project community.
>
> In most cases, as the podling community matures the mentor will start to
> learn improvements to their own processes. This has certainly been true in
> every single project I've mentored over the years and why I occasionally
> come back and mentor a new project. It's a learning experience, it is NOT a
> teaching experience.
>
> Ross
>
> -Original Message-
> From: Jim Jagielski 
> Sent: Tuesday, April 10, 2018 7:32 AM
> To: general 
> Subject: Re: The role of a mentor
>
> +1
>
> > On Apr 9, 2018, at 12:45 PM, Julian Hyde  wrote:
> >
> > Has anyone here taught someone how to fish? (Or how to make cookies,
> > or ski?)
> >
> > Mostly you just stand off, watching what they do. If you see them
> > about to screw up in a big way, step in. Occasionally, offer them
> > hints for how they might do what they’re doing a little bit better.
> > (Not too often, because they’ll start to resent the advice.)
> >
> > It’s a time-intensive process, and most of the time the person being
> taught thinks you’re doing nothing.
> >
> > Sometimes they ask for help, and very occasionally they ask for guidance
> (but only if you have not given them more unsolicited advice than they
> think they need, see above).
> >
> > Julian
> >
> >
> >> On Apr 9, 2018, at 5:52 AM, Liang Chen  > wrote:
> >>
> >> Hi
> >>
> >> +1, agree with JB points.
> >> Mentor mostly just focus on ASF policy and rules, then is ok.
> >> "Teach him how to fish", it is more important, so it would be better
> >> if mentors could provide some good example cases(role model) for them
> >> to learn, tell them how to find the solution from ASF website.
> >>
> >> Regards
> >> Liang
> >>
> >> Jean-Baptiste Onofré wrote
> >>> Hi John,
> >>>
> >>> IMHO, a mentor is not necessary involved in the project
> >>> technics/codebase (it's actually a bonus).
> >>>
> >>> As a mentor, I'm focusing:
> >>> 1. Insure of the legal aspect of the project (ICLA/CCLA, SGA, ...)
> >>> 2. Help around infra and release preparation according to Apache
> >>> rules 3. Help to promote the project and build communities around 4.
> >>> See if there's potential interaction with other podlings and
> >>> existing TLPs 5. Help to go to graduation (following the graduation
> >>> checklist) 6. (optional) Help on the contribution (codebase,
> >>> website, ...)
> >>>
> >>> My 

Re: [VOTE] Retire the HTrace Podling

[???? Sheng Wu]

Hi Lewis,
Feel sorry about HTRACE community has decided to retire. 


Already involved in discussion in dev@


My +1 no binding


Sheng Wu


 
---Original---
From: "lewis john mcgibbney"
Date: Thu, Apr 12, 2018 07:40 AM
To: "general";
Cc: "dev";
Subject: [VOTE] Retire the HTrace Podling


Hi Folks,
Please excuse the error on my part, which essentially missed this important
stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
However, we are here now. The VOTE will be open for a minimum of 72 hours.
The previous community VOTE [0] took place on the HTrace dev@ list with a
lot of participation. I closed this off today with the RESULT [1].
I would like to explicitly note that a subsequent parallel thread was
initiated [2] which essentially suggested HTrace staying alive as a
Subproject. Unfortunately this thread petered out... my inclination is that
this outcome is that for HTrace to become a Subproject, essentially work
would need to be done by some people... which brings us back to the initial
reason for drafting the retirement email thread in the first place e.g.
no-one has the time to work on HTrace any more.
Please DISCUSS or VOTE as below

[ ] +1 retire the HTrace podling
[ ] -1 NOT NOT retire the HTrace podling (please provide justification)

Thanks,
Lewis
P.S. Here is my +1


[0] VOTE: https://s.apache.org/2sGB
[1] RESULT: https://s.apache.org/e22i
[2] https://s.apache.org/MlLn

-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc

[VOTE] Retire the HTrace Podling

[lewis john mcgibbney]

Hi Folks,
Please excuse the error on my part, which essentially missed this important
stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
However, we are here now. The VOTE will be open for a minimum of 72 hours.
The previous community VOTE [0] took place on the HTrace dev@ list with a
lot of participation. I closed this off today with the RESULT [1].
I would like to explicitly note that a subsequent parallel thread was
initiated [2] which essentially suggested HTrace staying alive as a
Subproject. Unfortunately this thread petered out... my inclination is that
this outcome is that for HTrace to become a Subproject, essentially work
would need to be done by some people... which brings us back to the initial
reason for drafting the retirement email thread in the first place e.g.
no-one has the time to work on HTrace any more.
Please DISCUSS or VOTE as below

[ ] +1 retire the HTrace podling
[ ] -1 NOT NOT retire the HTrace podling (please provide justification)

Thanks,
Lewis
P.S. Here is my +1


[0] VOTE: https://s.apache.org/2sGB
[1] RESULT: https://s.apache.org/e22i
[2] https://s.apache.org/MlLn

-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc

Re: svn commit: r1828932 - in /incubator/public/trunk/content: podlings.xml projects/htrace.xml

[lewis john mcgibbney]

Bugger.
I missed that line and this is the first time I've initiated the process.
Sorry about that folks and thank you John for the correction.
I'll kick that thread off now...
Damn.

On Wed, Apr 11, 2018 at 4:28 PM, John D. Ament 
wrote:

> Lewis,
>
> In order to retire a podling, a vote must occur on general@incubator.
> https://incubator.apache.org/guides/retirement.html
>
> John
>
> On Wed, Apr 11, 2018 at 4:20 PM  wrote:
>
>> Author: lewismc
>> Date: Wed Apr 11 20:20:39 2018
>> New Revision: 1828932
>>
>> URL: http://svn.apache.org/viewvc?rev=1828932=rev
>> Log:
>> Retire HTrace podling
>>
>> Modified:
>> incubator/public/trunk/content/podlings.xml
>> incubator/public/trunk/content/projects/htrace.xml
>>
>> Modified: incubator/public/trunk/content/podlings.xml
>> URL: http://svn.apache.org/viewvc/incubator/public/trunk/
>> content/podlings.xml?rev=1828932=1828931=1828932=diff
>> 
>> ==
>> --- incubator/public/trunk/content/podlings.xml [utf-8] (original)
>> +++ incubator/public/trunk/content/podlings.xml [utf-8] Wed Apr 11
>> 20:20:39 2018
>> @@ -1124,9 +1124,9 @@ and a set of useful extensions for this
>> Daniel Dai
>>  
>>  
>> -> sponsor="Incubator" startdate="2014-11-11">
>> +> sponsor="Incubator" startdate="2014-11-11" enddate="2018-04-11">
>>  HTrace is a tracing framework intended for use with
>> distributed systems written in java.
>> -
>> +HTrace made several releases however energy
>> gradually evaporated and a community retirement VOTE was held with the
>> RESULT that HTrace be retired.
>>  Roman Shaposhnik
>>  
>>  Jake Farrell
>>
>> Modified: incubator/public/trunk/content/projects/htrace.xml
>> URL: http://svn.apache.org/viewvc/incubator/public/trunk/
>> content/projects/htrace.xml?rev=1828932=1828931=1828932=diff
>> 
>> ==
>> --- incubator/public/trunk/content/projects/htrace.xml [utf-8] (original)
>> +++ incubator/public/trunk/content/projects/htrace.xml [utf-8] Wed Apr
>> 11 20:20:39 2018
>> @@ -14,10 +14,12 @@
>>  
>>Description
>>HTrace is a tracing framework intended for use with distributed
>> systems written in java.
>> +  The HTrace podling retired on
>> 2018-04-11
>>  
>>  
>>News
>>
>> +2018-04-11 The HTrace podling retired on 2018-04-11
>>  2016-10-05 PPMC: Mike Drob
>>  2016-03-08 GSoC Mentor: Colin McCabe
>>  2016-03-04 Apache HTrace 4.1.0 release
>>
>>
>>
>> -
>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: cvs-h...@incubator.apache.org
>>
>>


-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc

Re: svn commit: r1828932 - in /incubator/public/trunk/content: podlings.xml projects/htrace.xml

[John D. Ament]

Lewis,

In order to retire a podling, a vote must occur on general@incubator.
https://incubator.apache.org/guides/retirement.html

John

On Wed, Apr 11, 2018 at 4:20 PM  wrote:

> Author: lewismc
> Date: Wed Apr 11 20:20:39 2018
> New Revision: 1828932
>
> URL: http://svn.apache.org/viewvc?rev=1828932=rev
> Log:
> Retire HTrace podling
>
> Modified:
> incubator/public/trunk/content/podlings.xml
> incubator/public/trunk/content/projects/htrace.xml
>
> Modified: incubator/public/trunk/content/podlings.xml
> URL:
> http://svn.apache.org/viewvc/incubator/public/trunk/content/podlings.xml?rev=1828932=1828931=1828932=diff
>
> ==
> --- incubator/public/trunk/content/podlings.xml [utf-8] (original)
> +++ incubator/public/trunk/content/podlings.xml [utf-8] Wed Apr 11
> 20:20:39 2018
> @@ -1124,9 +1124,9 @@ and a set of useful extensions for this
> Daniel Dai
>  
>  
> - sponsor="Incubator" startdate="2014-11-11">
> + sponsor="Incubator" startdate="2014-11-11" enddate="2018-04-11">
>  HTrace is a tracing framework intended for use with
> distributed systems written in java.
> -
> +HTrace made several releases however energy gradually
> evaporated and a community retirement VOTE was held with the RESULT that
> HTrace be retired.
>  Roman Shaposhnik
>  
>  Jake Farrell
>
> Modified: incubator/public/trunk/content/projects/htrace.xml
> URL:
> http://svn.apache.org/viewvc/incubator/public/trunk/content/projects/htrace.xml?rev=1828932=1828931=1828932=diff
>
> ==
> --- incubator/public/trunk/content/projects/htrace.xml [utf-8] (original)
> +++ incubator/public/trunk/content/projects/htrace.xml [utf-8] Wed Apr 11
> 20:20:39 2018
> @@ -14,10 +14,12 @@
>  
>Description
>HTrace is a tracing framework intended for use with distributed
> systems written in java.
> +  The HTrace podling retired on
> 2018-04-11
>  
>  
>News
>
> +2018-04-11 The HTrace podling retired on 2018-04-11
>  2016-10-05 PPMC: Mike Drob
>  2016-03-08 GSoC Mentor: Colin McCabe
>  2016-03-04 Apache HTrace 4.1.0 release
>
>
>
> -
> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> For additional commands, e-mail: cvs-h...@incubator.apache.org
>
>

Re: Challenges using Gitbox

[Daniel Gruno]

On 04/11/2018 09:58 PM, Ted Dunning wrote:




3. The mailing list is a bit dated.



Totally true.  Pony helps a bit: https://lists.apache.org/

But not all that much.

Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.

SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.



I think this is a matter of newness and prominence, not as much whether 
the pony is good or bad. I can easily google stuff on there if I search 
for "site:lists.apache.org fosdem 2018" and read up on fosdem topics 
(Google knows how to crawl it)...but there are some 20 million emails to 
index on a relatively new sub domain, and that's probably gonna take a 
while. It will very likely change and be easier in the future, but I've 
no idea how fast that'll happen.


Anyway, as we always say, patches welcome :). If people have improvement 
suggestions, we'll gladly accept them at the pony mail project. There 
are several major overhauls on the drawing board, but with many users 
and very few contributors, this moves along quite slowly.


With regards,
Daniel.

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

Re: Challenges using Gitbox

[Ted Dunning]

On Wed, Apr 11, 2018 at 11:11 AM, Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:

> Hi general@incubator!
>
> This is an email discussing the challenges we are facing while using Github
> / Gitbox for our ASF project and wanted to start a thread to discuss
> solutions and ways we can mitigate.
>
> We're very grateful for Gitbox, but here are the challenges we're facing
> with it:
>
> 1. Our PMs are not committers, so they can't do simple things as labeling
> issues, closing issues and assigning issues to people. We need either for
> them to have write access to Github, or for them to get some sort of
> special committer status so they can get write access. Is voting PMs as
> committers the solution here?
>

Why not make them committers?

Seriously. It sounds like the project needs and wants them to do stuff that
requires committer-fu. What possible reason is there not to give it to them?


> 2. From what I gather using Github issues as a replacement for Jira is ok
> as long as we set Github notifications to be sent to the mailing list. The
> problem is that this makes our mailing list unusable for other purposes
> than getting spammed out of our minds with Github notifications. I think
> the solution would be to standardize on 2 mailing lists:
> `github-notifications@{project}.apache.org` and the good old `dev@`.
> Though
> for early adopters `dev@` is probably busted as people have filters set up
> against it already. So is the solution to create another list and get
> everyone to sign up for it?
>

Can't you tone down the notifications to dev@ and arrange for all
notifications to be sent to notifications@?

I am asking because I don't know if it is possible.


> 3. The mailing list is a bit dated.


Totally true.  Pony helps a bit: https://lists.apache.org/

But not all that much.

Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.

SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.



> 4. Github ecosystem services (build systems, code quality services, code
> coverage services, version manager, ...) are hard and sometimes impossible
> to setup (without admin Github privileges), forcing us to open INFRA Jira
> tickets for this. I understand the limitations here, and a lot of it is on
> the Github side, but would like to think of ways to mitigate this, perhaps
> by using specified "main-forks" where committers have more control? Just a
> list of "Apache Approved Github-services" would help.
>

Ask infra. My experience is that this stabilizes pretty quickly with
limited requests after a break-in period.

That means that the current infra-centric arrangement is painful a bit at
first, but it declines in prominence pretty quickly.



> The ASF is all about helping growing communities, and making committers as
> productive as can be should be a top priority. Joining the ASF shouldn't
> make governance harder.
>

Well actually ASF is, in many ways, all about certain downstream
consumers of software and, in particular, about certain governance
guarantees. The support of communities is a derived goal because the
downstream is best served by having robust communities.

As such, joining ASF is *absolutely* going to make some aspects of
governance considerably harder.

That said, the tooling shouldn't be vastly harder.

I hear other software foundations are less opinionated in terms of tooling,
> is that something the ASF should consider? What are the constraints?


The core constraints are (roughly, probably not quite complete):

1) downstream consumers of source code releases have comfort around
dependency risks and licensing

2) Apache has "good enough" provenance on essentially every line of code.

3) Apache is open and historically transparent with respect to decision
making. Open across time zones and presence.

4) Failures or adverse takeovers of non-Apache entities will not compromise
the mission of Apache

5) Apache doesn't run with professional fundraisers out beating the bushes
(this isn't really an axiom as much as a consequence)

6) Contributors, committers and members are all individuals and participate
as such. This is in contrast to foundations where corporations are members.
It also relates to the fact that Apache is a charity rather than a trade
organization.

Item (1) is where the licensing limitations and signing and release
policies come from.

Item (2) was one of the major sticking points with github because it was
hard to understand how much confidence we could have about who checked in
code.

Item (3) is where the mailing list rules and voting practices come from.

Item (4) is where the reticence about using external services for mailing
lists and ticketing comes from.

Item (5) limits the bandwidth and special purpose tooling that any single
project can expect to have created and maintained.

Item (6) is why a company has trouble getting 

Re: Challenges using Gitbox

[Dave Fisher]

Hi -


> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin  
> wrote:
> 
> Hi general@incubator!
> 
> This is an email discussing the challenges we are facing while using Github
> / Gitbox for our ASF project and wanted to start a thread to discuss
> solutions and ways we can mitigate.
> 
> We're very grateful for Gitbox, but here are the challenges we're facing
> with it:
> 
> 1. Our PMs are not committers, so they can't do simple things as labeling
> issues, closing issues and assigning issues to people. We need either for
> them to have write access to Github, or for them to get some sort of
> special committer status so they can get write access. Is voting PMs as
> committers the solution here?

Yes - make people committers to have access. People will do the correct thing 
and work in their area. If someone doesn’t then it is an SCM and the changes 
can be reverted.

> 
> 2. From what I gather using Github issues as a replacement for Jira is ok
> as long as we set Github notifications to be sent to the mailing list. The
> problem is that this makes our mailing list unusable for other purposes
> than getting spammed out of our minds with Github notifications. I think
> the solution would be to standardize on 2 mailing lists:
> `github-notifications@{project}.apache.org` and the good old `dev@`. Though
> for early adopters `dev@` is probably busted as people have filters set up
> against it already. So is the solution to create another list and get
> everyone to sign up for it?

Projects typically have a commits@ or issues@ ML and you can redirect there. 
Your PPMC members should follow that list.

The dev@ list is critical for recording decisions.

> 
> 3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt
> to be polite. Maintainers have to sort through spam (AI had solved this a
> decade ago!), it's hard to know how many people and who are signed up, no
> weekly or daily digest-type features, SEO is bad and the list aren't very
> searchable. Something like Google Groups would be a huge step forward here.

Have a look at lists.apache.org  which is a 
searchable archive of every Apache Mailing list.

The lists are permanent records of the ASF and the Foundation has to maintain 
these. Relying on third parties is not within policy.

> 
> 4. Github ecosystem services (build systems, code quality services, code
> coverage services, version manager, ...) are hard and sometimes impossible
> to setup (without admin Github privileges), forcing us to open INFRA Kira
> tickets for this. I understand the limitations here, and a lot of it is on
> the Github side, but would like to think of ways to mitigate this, perhaps
> by using specified "main-forks" where committers have more control? Just a
> list of "Apache Approved Github-services" would help.

You should have a discussion with Infra about what privileges you are missing 
and if it is possible for these to be enabled through GitBox. Perhaps the 
distinction could be made between Committer and PPMC member within the LDAP, 
but I really don’t know.

> 
> The ASF is all about helping growing communities, and making committers as
> productive as can be should be a top priority. Joining the ASF shouldn't
> make governance harder.

At a minimum the ASF requires that the Apache License is used and that 
everything is compliant. This can be difficult. We also have minimal rules for 
how Releases are done to our shared and consistent Infrastructure. Once 
released the software is held by the Foundation for the public good in 
perpetuity.

> 
> I hear other software foundations are less opinionated in terms of tooling,
> is that something the ASF should consider? What are the constraints?

The code must be able to be part of the ASF maintained infrastructure. Many 
years and much discussion was done in order to accept GitHub.

Infrastructure supports over 250 projects and podlings, consistency is 
required. Anything non-standard must be supported by the project. Infra has a 
quota of one VM per project.

Regards,
Dave


> 
> Cheers!
> 
> Max



signature.asc
Description: Message signed with OpenPGP

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Steve Lawrence]

On 04/11/2018 02:51 PM, Matt Sicker wrote:
> 
> On Wed, Apr 11, 2018 at 13:49, Steve Lawrence  > wrote:
> 
> The KEYS file was in dist/dev. I've moved it to dist/release, now
> available here:
> 
> https://www.apache.org/dist/incubator/daffodil/KEYS
> 
> 
> Thanks!
> 
> 
> 
> Regarding the BSD-licenses, I don't believe the RAT CLI can detect BSD
> licenses, or at least I haven't figured out how to get it to work if it
> can. I'd love to hear if anyone knows.
> 
> 
> I think we’d need to develop another header matcher instance for it. You can 
> add 
> custom license checks. I also published an sbt plugin that wraps rat into 
> your 
> build, so that might be easier since you could bundle the header matcher 
> itself 
> in your sbt build and add it to the configured licenses.

I didn't see a way to add custom license checks via the CLI, but I may
have missed it. The sbt plugin sounds very interesting--definitely
something that could be useful to Daffodil, especially if it could add
custom license checks. I'll take a look at it.

> 
> 
> Thanks!
> - Steve
> 
> On 04/11/2018 01:32 PM, Matt Sicker wrote:
>  > * Signatures ok
>  > * License, disclaimer, notice ok
>  > * Rat check ok (using sbt-rat locally, though it doesn't seem to detect
>  > some BSD-licensed source files as such)
>  > * Builds/tests ok
>  > * But there's no KEYS file! This should be at
>  > https://www.apache.org/dist/incubator/daffodil/KEYS
>  >
>  > Please add the KEYS file to dist.a.o.
>  >
>  > On 9 April 2018 at 18:24, Steve Lawrence  > wrote:
>  >
>  >> The Apache Daffodil community has voted and approved the proposed
>  >> release of Apache Daffodil (incubating) 2.1.0-rc3.
>  >>
>  >> We now kindly request the Incubator PMC members review and vote on 
> this
>  >> incubator release.
>  >>
>  >> Daffodil is an open source implementation of the DFDL specification 
> that
>  >> uses DFDL schemas to parse fixed format data into an infoset, which is
>  >> most commonly represented as either XML or JSON. This allows the use 
> of
>  >> well-established XML or JSON technologies and libraries to consume,
>  >> inspect, and manipulate fixed format data in existing solutions.
>  >> Daffodil is also capable of the reverse by serializing or "unparsing" 
> an
>  >> XML or JSON infoset back to the original data format.
>  >>
>  >> Vote thread:
>  >> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae06106
>  >> 33e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org
> %3E
>  >>
>  >> Result thread:
>  >> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd1
>  >> 9507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org
> %3E
>  >>
>  >> All distribution packages, including signatures, digests, etc. can be
>  >> found at:
>  >>
>  >> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
>  >>
>  >> Staging artifacts can be found at:
>  >>
>  >> 
> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
>  >>
>  >> This release has been signed with PGP key 033AE661, corresponding to
>  >> slawre...@apache.org , which is included 
> in
> the repository's KEYS file.
>  >> This key can be found on keyservers, such as:
>  >>
>  >> http://pgp.mit.edu/pks/lookup?op=get=0x033AE661
>  >>
>  >> It is also listed here:
>  >>
>  >> https://people.apache.org/keys/committer/slawrence.asc
>  >>
>  >> The release candidate has been tagged in git with v2.1.0-rc3.
>  >>
>  >> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
>  >>
>  >> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=
>  >> project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.
>  >> 1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>  >>
>  >> For a summary of the changes in this release, see:
>  >>
>  >> https://daffodil.apache.org/releases/2.1.0/
>  >>
>  >> Please review and vote. The vote will be open for at least 72 hours.
>  >>
>  >> [ ] +1 approve
>  >> [ ] +0 no opinion
>  >> [ ] -1 disapprove (and reason why)
>  >>
>  >> Thanks,
>  >> - Steve
>  >>
>  >> -
>  >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
>  >> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>  >>
>  >>
>  >
>  

Re: Challenges using Gitbox

[toki]

On 04/11/2018 06:11 PM, Maxime Beauchemin wrote:

> 3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt ...
> searchable. Something like Google Groups would be a huge step forward here.

I'd suggest Groups.IO over Google Groups, if only because one of its
features is: "Integration with other services, including: Github, Google
Hangouts, Dropbox, Instagram, Facebook Pages, and the ability to import
Feeds into your groups."

Downside # 1 is that Apache would have to go with either the Premium or
Enterprise option, at US$110/year or US$2200/year, respectively.
Furthermore, I'm not sure the 1TB storage space would suffice.

Downside # 2 is GDPR. Groups.IO is hoping that it won't apply to them.
I can see the EU commission going after both ASF and Groups.IO, if it
isn't in full compliance with GDPR. OTOH, how compliant with GDPR are
any of the ASF projects?

jonathon

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

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Matt Sicker]

On Wed, Apr 11, 2018 at 13:49, Steve Lawrence  wrote:

> The KEYS file was in dist/dev. I've moved it to dist/release, now
> available here:
>
> https://www.apache.org/dist/incubator/daffodil/KEYS


Thanks!


>
> Regarding the BSD-licenses, I don't believe the RAT CLI can detect BSD
> licenses, or at least I haven't figured out how to get it to work if it
> can. I'd love to hear if anyone knows.


I think we’d need to develop another header matcher instance for it. You
can add custom license checks. I also published an sbt plugin that wraps
rat into your build, so that might be easier since you could bundle the
header matcher itself in your sbt build and add it to the configured
licenses.


>
> Thanks!
> - Steve
>
> On 04/11/2018 01:32 PM, Matt Sicker wrote:
> > * Signatures ok
> > * License, disclaimer, notice ok
> > * Rat check ok (using sbt-rat locally, though it doesn't seem to detect
> > some BSD-licensed source files as such)
> > * Builds/tests ok
> > * But there's no KEYS file! This should be at
> > https://www.apache.org/dist/incubator/daffodil/KEYS
> >
> > Please add the KEYS file to dist.a.o.
> >
> > On 9 April 2018 at 18:24, Steve Lawrence  wrote:
> >
> >> The Apache Daffodil community has voted and approved the proposed
> >> release of Apache Daffodil (incubating) 2.1.0-rc3.
> >>
> >> We now kindly request the Incubator PMC members review and vote on this
> >> incubator release.
> >>
> >> Daffodil is an open source implementation of the DFDL specification that
> >> uses DFDL schemas to parse fixed format data into an infoset, which is
> >> most commonly represented as either XML or JSON. This allows the use of
> >> well-established XML or JSON technologies and libraries to consume,
> >> inspect, and manipulate fixed format data in existing solutions.
> >> Daffodil is also capable of the reverse by serializing or "unparsing" an
> >> XML or JSON infoset back to the original data format.
> >>
> >> Vote thread:
> >> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae06106
> >> 33e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
> >>
> >> Result thread:
> >> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd1
> >> 9507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
> >>
> >> All distribution packages, including signatures, digests, etc. can be
> >> found at:
> >>
> >> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
> >>
> >> Staging artifacts can be found at:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
> >>
> >> This release has been signed with PGP key 033AE661, corresponding to
> >> slawre...@apache.org, which is included in the repository's KEYS file.
> >> This key can be found on keyservers, such as:
> >>
> >> http://pgp.mit.edu/pks/lookup?op=get=0x033AE661
> >>
> >> It is also listed here:
> >>
> >> https://people.apache.org/keys/committer/slawrence.asc
> >>
> >> The release candidate has been tagged in git with v2.1.0-rc3.
> >>
> >> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
> >>
> >> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=
> >> project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.
> >> 1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >>
> >> For a summary of the changes in this release, see:
> >>
> >> https://daffodil.apache.org/releases/2.1.0/
> >>
> >> Please review and vote. The vote will be open for at least 72 hours.
> >>
> >> [ ] +1 approve
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Thanks,
> >> - Steve
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
> >
>
> --
Matt Sicker 

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Steve Lawrence]

The KEYS file was in dist/dev. I've moved it to dist/release, now
available here:

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

Regarding the BSD-licenses, I don't believe the RAT CLI can detect BSD
licenses, or at least I haven't figured out how to get it to work if it
can. I'd love to hear if anyone knows.

Thanks!
- Steve

On 04/11/2018 01:32 PM, Matt Sicker wrote:
> * Signatures ok
> * License, disclaimer, notice ok
> * Rat check ok (using sbt-rat locally, though it doesn't seem to detect
> some BSD-licensed source files as such)
> * Builds/tests ok
> * But there's no KEYS file! This should be at
> https://www.apache.org/dist/incubator/daffodil/KEYS
> 
> Please add the KEYS file to dist.a.o.
> 
> On 9 April 2018 at 18:24, Steve Lawrence  wrote:
> 
>> The Apache Daffodil community has voted and approved the proposed
>> release of Apache Daffodil (incubating) 2.1.0-rc3.
>>
>> We now kindly request the Incubator PMC members review and vote on this
>> incubator release.
>>
>> Daffodil is an open source implementation of the DFDL specification that
>> uses DFDL schemas to parse fixed format data into an infoset, which is
>> most commonly represented as either XML or JSON. This allows the use of
>> well-established XML or JSON technologies and libraries to consume,
>> inspect, and manipulate fixed format data in existing solutions.
>> Daffodil is also capable of the reverse by serializing or "unparsing" an
>> XML or JSON infoset back to the original data format.
>>
>> Vote thread:
>> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae06106
>> 33e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
>>
>> Result thread:
>> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd1
>> 9507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
>>
>> All distribution packages, including signatures, digests, etc. can be
>> found at:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
>>
>> Staging artifacts can be found at:
>>
>> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
>>
>> This release has been signed with PGP key 033AE661, corresponding to
>> slawre...@apache.org, which is included in the repository's KEYS file.
>> This key can be found on keyservers, such as:
>>
>> http://pgp.mit.edu/pks/lookup?op=get=0x033AE661
>>
>> It is also listed here:
>>
>> https://people.apache.org/keys/committer/slawrence.asc
>>
>> The release candidate has been tagged in git with v2.1.0-rc3.
>>
>> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
>>
>> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=
>> project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.
>> 1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>
>> For a summary of the changes in this release, see:
>>
>> https://daffodil.apache.org/releases/2.1.0/
>>
>> Please review and vote. The vote will be open for at least 72 hours.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Thanks,
>> - Steve
>>
>> -
>> 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

Challenges using Gitbox

[Maxime Beauchemin]

Hi general@incubator!

This is an email discussing the challenges we are facing while using Github
/ Gitbox for our ASF project and wanted to start a thread to discuss
solutions and ways we can mitigate.

We're very grateful for Gitbox, but here are the challenges we're facing
with it:

1. Our PMs are not committers, so they can't do simple things as labeling
issues, closing issues and assigning issues to people. We need either for
them to have write access to Github, or for them to get some sort of
special committer status so they can get write access. Is voting PMs as
committers the solution here?

2. From what I gather using Github issues as a replacement for Jira is ok
as long as we set Github notifications to be sent to the mailing list. The
problem is that this makes our mailing list unusable for other purposes
than getting spammed out of our minds with Github notifications. I think
the solution would be to standardize on 2 mailing lists:
`github-notifications@{project}.apache.org` and the good old `dev@`. Though
for early adopters `dev@` is probably busted as people have filters set up
against it already. So is the solution to create another list and get
everyone to sign up for it?

3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt
to be polite. Maintainers have to sort through spam (AI had solved this a
decade ago!), it's hard to know how many people and who are signed up, no
weekly or daily digest-type features, SEO is bad and the list aren't very
searchable. Something like Google Groups would be a huge step forward here.

4. Github ecosystem services (build systems, code quality services, code
coverage services, version manager, ...) are hard and sometimes impossible
to setup (without admin Github privileges), forcing us to open INFRA Jira
tickets for this. I understand the limitations here, and a lot of it is on
the Github side, but would like to think of ways to mitigate this, perhaps
by using specified "main-forks" where committers have more control? Just a
list of "Apache Approved Github-services" would help.

The ASF is all about helping growing communities, and making committers as
productive as can be should be a top priority. Joining the ASF shouldn't
make governance harder.

I hear other software foundations are less opinionated in terms of tooling,
is that something the ASF should consider? What are the constraints?

Cheers!

Max

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Matt Sicker]

* Signatures ok
* License, disclaimer, notice ok
* Rat check ok (using sbt-rat locally, though it doesn't seem to detect
some BSD-licensed source files as such)
* Builds/tests ok
* But there's no KEYS file! This should be at
https://www.apache.org/dist/incubator/daffodil/KEYS

Please add the KEYS file to dist.a.o.

On 9 April 2018 at 18:24, Steve Lawrence  wrote:

> The Apache Daffodil community has voted and approved the proposed
> release of Apache Daffodil (incubating) 2.1.0-rc3.
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Daffodil is an open source implementation of the DFDL specification that
> uses DFDL schemas to parse fixed format data into an infoset, which is
> most commonly represented as either XML or JSON. This allows the use of
> well-established XML or JSON technologies and libraries to consume,
> inspect, and manipulate fixed format data in existing solutions.
> Daffodil is also capable of the reverse by serializing or "unparsing" an
> XML or JSON infoset back to the original data format.
>
> Vote thread:
> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae06106
> 33e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
>
> Result thread:
> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd1
> 9507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
>
> All distribution packages, including signatures, digests, etc. can be
> found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
>
> Staging artifacts can be found at:
>
> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
>
> This release has been signed with PGP key 033AE661, corresponding to
> slawre...@apache.org, which is included in the repository's KEYS file.
> This key can be found on keyservers, such as:
>
> http://pgp.mit.edu/pks/lookup?op=get=0x033AE661
>
> It is also listed here:
>
> https://people.apache.org/keys/committer/slawrence.asc
>
> The release candidate has been tagged in git with v2.1.0-rc3.
>
> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
>
> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=
> project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.
> 1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> For a summary of the changes in this release, see:
>
> https://daffodil.apache.org/releases/2.1.0/
>
> Please review and vote. The vote will be open for at least 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Thanks,
> - Steve
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Matt Sicker 

Re: [VOTE] Release of Apache Griffin-0.2.0-incubating [RC3]

[Matt Sicker]

* Signatures ok
* Disclaimer, notice, license ok
  - As an aside, I like the formatting used in the license file.
* Not exactly sure why you distribute the KEYS file with your sources, but
it's not a problem. Keys inside the artifact can't be used to verify the
artifact.
* Rat check ok
* Builds/tests ok

+1

I'll note that I was initially confused by your license file as none of the
projects mentioned in it are bundled in the source distribution, but I see
the service jar does bundle all dependencies where said license file would
be relevant.

On 10 April 2018 at 00:53, William Guo  wrote:

> +1
>
>
> rat passed.
>
> sha1 checked.
>
> all GPL are dual licensed either CDDL or 'Apache License version 2.0'
>
> Checked all suspicious license, looks good.
>
>
>
> Thanks,
> William
>
>
> On Tue, Apr 10, 2018 at 10:14 AM, Lionel Liu  wrote:
>
> > Hi all,
> > The Apache Griffin community has voted on and approved a proposal to
> > release Apache Griffin 0.2.0-rc3.
> > We now kindly request that the Incubator PMC members review and vote
> on
> > this incubator release candidate.
> >
> > Apache Griffin is data quality service for modern data system, it
> > defines a standard process to define, measure data quality for well-known
> > dimensions. With Apache Griffin, users will be able to quickly define
> their
> > data quality requirements and then get the result in near real time in
> > systematical approach.
> >
> >
> > Griffin vote thread
> >
> > https://lists.apache.org/thread.html/c9c9dd2cbea2d479625cd2a2c82345
> > 41022c60f35f423ceb150d7ecb@%3Cdev.griffin.apache.org%3E
> > Griffin vote result thread
> >
> > https://lists.apache.org/thread.html/bc1b2a436119d91c4cf1175a80d6fd
> > 4e4b084749c9e6e259817144be@%3Cdev.griffin.apache.org%3E
> >
> > The source tarball, including signatures, digests, etc. can be found
> > at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/griffin/0.
> 2.0-incubating
> >
> > The tag to be voted upon is 0.2.0-incubating:
> >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.
> > git;a=shortlog;h=refs/tags/griffin-0.2.0-incubating
> >
> > The release hash is :
> >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.
> > git;a=commit;h=70419c4f4ec01dd70815d9480ab596b320fa5e2a
> >
> > The Nexus Staging URL:
> > https://repository.apache.org/content/repositories/
> > orgapachegriffin-1013
> >
> > Release artifacts are signed with the following key:
> > 7F00C3BA90F3ECAEECB843A79BD6EC6C02379561
> >
> > KEYS file available:
> > https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS
> >
> > For information about the contents of this release, see:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/griffin/0.
> > 2.0-incubating/CHANGES.txt
> >
> >
> > Please download the release candidate and evaluate the necessary
> items
> > including checking hashes, signatures, build from source, run and test.
> > Please vote on releasing this package as Apache Griffin
> > 0.2.0-incubating
> > The vote will be open for 72 hours.
> > [ ] +1 Release this package as Apache Griffin 0.2.0-incubating
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because ...
> >
> >
> > Thanks,
> > Lionel
> > on behalf of Apache Griffin PPMC
> >
>



-- 
Matt Sicker 

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Matt Sicker]

* Signatures ok
* License and disclaimer are fine
* Notice included, but the copyright year needs to be updated to 2016-2018
* Rat check ok 
* I got a test failure locally for
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration "should
be able to load Java jars".

On 11 April 2018 at 11:17, Ryan Blue  wrote:

> For the .md5 file, we can simply not publish that file when copying the RC
> files. Please don't let that prevent you from checking this release!
>
> On Wed, Apr 11, 2018 at 8:41 AM, Luciano Resende 
> wrote:
>
> > Here is my binding +1, any volunteers to help review the RC, we need one
> > more IPMC vote.
> >
> > On Sat, Apr 7, 2018 at 6:28 PM, Luciano Resende 
> > wrote:
> >
> > > Please vote to approve the release of Apache Toree 0.2.0-incubating
> > > (RC4).
> > >
> > > The podling dev vote thread:
> > > https://www.mail-archive.com/dev@toree.incubator.apache.
> > org/msg01740.html
> > >
> > > And the result:
> > > https://www.mail-archive.com/dev@toree.incubator.apache.
> > org/msg01748.html
> > >
> > > Tag: v0.2.0-incubating-rc4 (8849271e28a4ea4e77c57ef8fb3da77b73469799)
> > >
> > > https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc4
> > >
> > > All distribution packages, including signatures, digests, etc. can be
> > > found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.0
> > > -incubating-rc4/
> > >
> > > Staging artifacts can be found at:
> > >
> > > https://repository.apache.org/content/repositories/orgapachetoree-1011
> > >
> > > The vote is open for at least 72 hours and passes if a majority of at
> > > least 3 +1 PMC votes are cast.
> > >
> > > [ ] +1 Release this package as Apache Toree 0.2.0-incubating
> > > [ ] -1 Do not release this package because ...
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://twitter.com/lresende1975
> > > http://lresende.blogspot.com/
> > >
> >
> >
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>



-- 
Matt Sicker 

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Ryan Blue]

For the .md5 file, we can simply not publish that file when copying the RC
files. Please don't let that prevent you from checking this release!

On Wed, Apr 11, 2018 at 8:41 AM, Luciano Resende 
wrote:

> Here is my binding +1, any volunteers to help review the RC, we need one
> more IPMC vote.
>
> On Sat, Apr 7, 2018 at 6:28 PM, Luciano Resende 
> wrote:
>
> > Please vote to approve the release of Apache Toree 0.2.0-incubating
> > (RC4).
> >
> > The podling dev vote thread:
> > https://www.mail-archive.com/dev@toree.incubator.apache.
> org/msg01740.html
> >
> > And the result:
> > https://www.mail-archive.com/dev@toree.incubator.apache.
> org/msg01748.html
> >
> > Tag: v0.2.0-incubating-rc4 (8849271e28a4ea4e77c57ef8fb3da77b73469799)
> >
> > https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc4
> >
> > All distribution packages, including signatures, digests, etc. can be
> > found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.0
> > -incubating-rc4/
> >
> > Staging artifacts can be found at:
> >
> > https://repository.apache.org/content/repositories/orgapachetoree-1011
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least 3 +1 PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Toree 0.2.0-incubating
> > [ ] -1 Do not release this package because ...
> >
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>



-- 
Ryan Blue
Software Engineer
Netflix

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Luciano Resende]

Here is my binding +1, any volunteers to help review the RC, we need one
more IPMC vote.

On Sat, Apr 7, 2018 at 6:28 PM, Luciano Resende 
wrote:

> Please vote to approve the release of Apache Toree 0.2.0-incubating
> (RC4).
>
> The podling dev vote thread:
> https://www.mail-archive.com/dev@toree.incubator.apache.org/msg01740.html
>
> And the result:
> https://www.mail-archive.com/dev@toree.incubator.apache.org/msg01748.html
>
> Tag: v0.2.0-incubating-rc4 (8849271e28a4ea4e77c57ef8fb3da77b73469799)
>
> https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc4
>
> All distribution packages, including signatures, digests, etc. can be
> found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.0
> -incubating-rc4/
>
> Staging artifacts can be found at:
>
> https://repository.apache.org/content/repositories/orgapachetoree-1011
>
> The vote is open for at least 72 hours and passes if a majority of at
> least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Toree 0.2.0-incubating
> [ ] -1 Do not release this package because ...
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>



-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/