[ANNOUNCE] Apache Livy 0.4.0-incubating released

[Saisai Shao]

The Apache Livy team is proud to announce Apache Livy version
0.4.0-incubating.

This is the first Livy release after entering the Apache Incubator.

Livy is web service that exposes a REST interface for managing
long running Apache Spark contexts in your cluster. With Livy, new
applications can be built on top of Apache Spark that require fine grained
interaction with many Spark contexts.

For Livy release details and downloads, visit:
http://livy.incubator.apache.org/download/


We would like to thank the contributors that made the release possible.


Regards,
The Livy Team

Re: [RESULT][VOTE] Release Airflow 1.8.2 based on Airflow 1.8.2 RC4

[John D. Ament]

Pierre is not an IPMC member.  Please ask your mentors to vote on the
release.

On Sep 4, 2017 12:31 PM, "Maxime Beauchemin" 
wrote:

> Hi All,
>
> The vote for releasing *Apache Airflow 1.8.2-incubating* is now closed.
>
> With a total of *+3 binding* votes, the vote passes:
> * Justin McLean
> * John D. Ament
> * Pierre Smits
>
> Thank you to all the reviewers for taking the time to validate this release
> and
> provide very good feedback. We will make sure to incorporate all the
> suggested changes in the next release.
>
> Regards!
>
> Maxime Beauchemin
>
> On Wed, Aug 23, 2017 at 12:31 AM, Pierre Smits 
> wrote:
>
> > +1
> >
> > Best regards
> >
> > Pierre
> >
> > On Tue, 22 Aug 2017 at 13:23 John D. Ament 
> wrote:
> >
> > > Hi,
> > >
> > > +1 to release...however, please make sure you are cleaning up your old
> > > releases.  Do not keep old releases on dist.a.o.
> > >
> > > John
> > >
> > > On Wed, Aug 16, 2017 at 6:18 PM Maxime Beauchemin <
> > > maximebeauche...@gmail.com> wrote:
> > >
> > > > Hello Incubator PMC’ers,
> > > >
> > > > The Apache Airflow community has voted and approved the proposal to
> > > release
> > > > Apache Airflow 1.8.2 (incubating) based on 1.8.2 Release Candidate 4.
> > We
> > > > now kindly request the Incubator PMC members to review and vote on
> this
> > > > incubator release.
> > > >
> > > > Airflow is a platform to programmatically author, schedule and
> monitor
> > > > workflows. Use airflow to author workflows as directed acyclic graphs
> > > > (DAGs) of tasks. The airflow scheduler executes your tasks on an
> array
> > of
> > > > workers while following the specified dependencies. Rich command line
> > > > utilities make performing complex surgeries on DAGs a snap. The rich
> > user
> > > > interface makes it easy to visualize pipelines running in production,
> > > > monitor progress, and troubleshoot issues when needed. When workflows
> > are
> > > > defined as code, they become more maintainable, versionable,
> testable,
> > > and
> > > > collaborative.
> > > >
> > > > Artefacts are available at https://dist.apache.org/repos/
> > > > dist/dev/incubator/airflow, public keys are available at
> > > > https://dist.apache.org/repos/dist/release/incubator/airflow.
> > > >
> > > > apache-airflow-1.8.2+incubating-source.tar.gz
> > > > <
> > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> > 8.2rc4/apache-airflow-1.8.2+incubating-source.tar.gz
> > > > >
> > > > is
> > > > a source release that comes with INSTALL instructions. Along with it,
> > for
> > > > convenience, find the binary Python "sdist" as apache-airflow-1.8.2+
> > > > incubating-bin.tar.gz
> > > > <
> > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> > 8.2rc4/apache-airflow-1.8.2+incubating-bin.tar.gz
> > > > >
> > > >
> > > > Vote thread:
> > > >
> > > >
> > > http://mail-archives.apache.org/mod_mbox/incubator-
> > airflow-dev/201708.mbox/browser
> > > >
> > > > Git tag:
> > > > https://github.com/apache/incubator-airflow/releases/tag/1.8.2rc4
> > > >
> > > > The vote will be open for at least 72 hours or until necessary number
> > of
> > > > votes are reached.
> > > >
> > > > Members please be sure to indicate "(Binding)" with your vote which
> > will
> > > > help in tallying the vote(s).
> > > >
> > > > * Here is my +1 (non-binding) *
> > > >
> > > > Cheers,
> > > >
> > > > Maxime Beauchemin
> > > >
> > >
> > --
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
>

[RESULT][VOTE] Release Airflow 1.8.2 based on Airflow 1.8.2 RC4

[Maxime Beauchemin]

Hi All,

The vote for releasing *Apache Airflow 1.8.2-incubating* is now closed.

With a total of *+3 binding* votes, the vote passes:
* Justin McLean
* John D. Ament
* Pierre Smits

Thank you to all the reviewers for taking the time to validate this release
and
provide very good feedback. We will make sure to incorporate all the
suggested changes in the next release.

Regards!

Maxime Beauchemin

On Wed, Aug 23, 2017 at 12:31 AM, Pierre Smits 
wrote:

> +1
>
> Best regards
>
> Pierre
>
> On Tue, 22 Aug 2017 at 13:23 John D. Ament  wrote:
>
> > Hi,
> >
> > +1 to release...however, please make sure you are cleaning up your old
> > releases.  Do not keep old releases on dist.a.o.
> >
> > John
> >
> > On Wed, Aug 16, 2017 at 6:18 PM Maxime Beauchemin <
> > maximebeauche...@gmail.com> wrote:
> >
> > > Hello Incubator PMC’ers,
> > >
> > > The Apache Airflow community has voted and approved the proposal to
> > release
> > > Apache Airflow 1.8.2 (incubating) based on 1.8.2 Release Candidate 4.
> We
> > > now kindly request the Incubator PMC members to review and vote on this
> > > incubator release.
> > >
> > > Airflow is a platform to programmatically author, schedule and monitor
> > > workflows. Use airflow to author workflows as directed acyclic graphs
> > > (DAGs) of tasks. The airflow scheduler executes your tasks on an array
> of
> > > workers while following the specified dependencies. Rich command line
> > > utilities make performing complex surgeries on DAGs a snap. The rich
> user
> > > interface makes it easy to visualize pipelines running in production,
> > > monitor progress, and troubleshoot issues when needed. When workflows
> are
> > > defined as code, they become more maintainable, versionable, testable,
> > and
> > > collaborative.
> > >
> > > Artefacts are available at https://dist.apache.org/repos/
> > > dist/dev/incubator/airflow, public keys are available at
> > > https://dist.apache.org/repos/dist/release/incubator/airflow.
> > >
> > > apache-airflow-1.8.2+incubating-source.tar.gz
> > > <
> > >
> > https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> 8.2rc4/apache-airflow-1.8.2+incubating-source.tar.gz
> > > >
> > > is
> > > a source release that comes with INSTALL instructions. Along with it,
> for
> > > convenience, find the binary Python "sdist" as apache-airflow-1.8.2+
> > > incubating-bin.tar.gz
> > > <
> > >
> > https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> 8.2rc4/apache-airflow-1.8.2+incubating-bin.tar.gz
> > > >
> > >
> > > Vote thread:
> > >
> > >
> > http://mail-archives.apache.org/mod_mbox/incubator-
> airflow-dev/201708.mbox/browser
> > >
> > > Git tag:
> > > https://github.com/apache/incubator-airflow/releases/tag/1.8.2rc4
> > >
> > > The vote will be open for at least 72 hours or until necessary number
> of
> > > votes are reached.
> > >
> > > Members please be sure to indicate "(Binding)" with your vote which
> will
> > > help in tallying the vote(s).
> > >
> > > * Here is my +1 (non-binding) *
> > >
> > > Cheers,
> > >
> > > Maxime Beauchemin
> > >
> >
> --
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Jim Apple]

>  I'll be honest, I have no idea why they
> think they have to do it, but they do it.

I suspect it is because projects are motivated to graduate and believe
that one or more people on the IPMC with -1 their graduation if they
do not complete the model and put a check mark in every box.

I suspect they believe this because they see other discussions or
votes on this mailing list end up with -1 votes (or "fix it for your
next release" statements) that they believe go beyond the official
policy requirements of the issue at question.

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

Re: How to handle exclusions in a software grant?

[Chris Mattmann]

Thanks John, I would clarify this on the contributing organization side, and 
pass
that along to the mentors. Thanks.




On 9/4/17, 8:13 AM, "John D. Ament"  wrote:

Agreed that the grant in question is missing a proper Exhibit A.  But
perhaps their intention with Exhibit A was to list what was excluded,
rather than what was included?

Considering that the committers in question had CLAs on file, I would be
surprised if 3rd Party Code were brought in.

John

On Mon, Sep 4, 2017 at 11:06 AM Chris Mattmann  wrote:

> Hi Bertrand,
>
> I believe they were supposed to provide a list to go along with that zip
> file.
>
> Can you double check?
>
> Cheers,
> Chris
>
>
>
>
> On 9/4/17, 3:30 AM, "Bertrand Delacretaz"  wrote:
>
> Hi,
>
> I'm mentoring a podling where a large initial code donation just
> happened.
>
> The corresponding software grant points to a large zip file indicating
> that the donation consists of that file's contents, "excluding any
> third-party and separately licensed material" that it contains.
>
> My understanding is that this puts the burden on the ASF to review
> each and every file found in there, and decide whether we can safely
> include it in an ASF release or if it's third-party and separately
> licensed.
>
> Do people agree with that interpretation?
>
> Have people seen similar cases before, and if yes how were they
> handled?
>
> -Bertrand
>
> -
> 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: How to handle exclusions in a software grant?

[John D. Ament]

Agreed that the grant in question is missing a proper Exhibit A.  But
perhaps their intention with Exhibit A was to list what was excluded,
rather than what was included?

Considering that the committers in question had CLAs on file, I would be
surprised if 3rd Party Code were brought in.

John

On Mon, Sep 4, 2017 at 11:06 AM Chris Mattmann  wrote:

> Hi Bertrand,
>
> I believe they were supposed to provide a list to go along with that zip
> file.
>
> Can you double check?
>
> Cheers,
> Chris
>
>
>
>
> On 9/4/17, 3:30 AM, "Bertrand Delacretaz"  wrote:
>
> Hi,
>
> I'm mentoring a podling where a large initial code donation just
> happened.
>
> The corresponding software grant points to a large zip file indicating
> that the donation consists of that file's contents, "excluding any
> third-party and separately licensed material" that it contains.
>
> My understanding is that this puts the burden on the ASF to review
> each and every file found in there, and decide whether we can safely
> include it in an ASF release or if it's third-party and separately
> licensed.
>
> Do people agree with that interpretation?
>
> Have people seen similar cases before, and if yes how were they
> handled?
>
> -Bertrand
>
> -
> 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: How to handle exclusions in a software grant?

[Chris Mattmann]

Hi Bertrand,

I believe they were supposed to provide a list to go along with that zip file. 

Can you double check?

Cheers,
Chris




On 9/4/17, 3:30 AM, "Bertrand Delacretaz"  wrote:

Hi,

I'm mentoring a podling where a large initial code donation just happened.

The corresponding software grant points to a large zip file indicating
that the donation consists of that file's contents, "excluding any
third-party and separately licensed material" that it contains.

My understanding is that this puts the burden on the ASF to review
each and every file found in there, and decide whether we can safely
include it in an ASF release or if it's third-party and separately
licensed.

Do people agree with that interpretation?

Have people seen similar cases before, and if yes how were they handled?

-Bertrand

-
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: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[John D. Ament]

Hi Bertrand,

On Mon, Sep 4, 2017 at 4:54 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi John,
>
> On Fri, Aug 25, 2017 at 9:11 PM, John D. Ament 
> wrote:
> > ...Its unfair for us to put some stake in the ground expecting podlings
> to
> > match up 100% on the questions.  Many of the questions are subjective -
> is
> > the code easy to discover? respond to bug reports in a timely manner?...
>
> Ok, I think I understand your reluctance now: you don't want us to set
> a gate for graduating podlings that many TLPs might not pass.
>
>
I'm not sure how you got that from a comment about the subjective nature of
something of the questions, but sure, that's definitely one problem.  I'll
also take this time to note that it is not easy to discovery the source
code for the com dev website, nor the actual contents of the APMM webpage.


> I agree with that, and although I'm a strong supporter of the Maturity
> Model (having initiated it that's understandable ;-) I'm totally ok
> with podlings graduating without fullfilling all of its requirements.
>
> In my view the model is:
>
> 1) A good tool to help discover areas that podlings might have neglected.
>

Yes.


>
> 2) A good tool to help podlings look at where they stand, and what
> they might still need to improve after graduation.
>

Yes, and in a way to reflect upon their current state and see if it's going
well or not.


>
> 3) A good tool to express our ideal way of doing things, in a concise
> way, and evolve that definition over time.
>


Its also of use to look at an incoming podling and ask "are these things
you're interested in achieving?"


>
> Based on this I will continue to push for podlings to come to
> graduation with a self-assessment based on that model.
>
> OTOH I'm fine with us clarifying that it's not a requirement.
>
>
The website already lists it as a recommendation only, not a requirement
https://incubator.apache.org/guides/graduation.html#other_issues (I'm
waiting on the build to fix the link).


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

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Bertrand Delacretaz]

On Mon, Sep 4, 2017 at 4:34 PM, Jim Apple  wrote:
> ...I think the current Model has a number of vague statements that are
> unlikely to be interpreted consistently without clarification. For
> instance "The project is open and honest about the quality of its
> code."..

That's a good example where a yes or no answer does not make much
sense. What's useful is a response like "we include a list of know
issues with each release" or "experimental or unstable modules are
clearly labeled as such" that demonstrate that the project takes
quality seriously and does not try to hide problems from their users.

I think such items help projects take a look at their overall
well-being, and at the same time they make it impossible to base
graduation on a given score based on that model - because there are no
black and white answers for those items.

So IMO we're doing the right thing in recommending that projects do a
self-assessment based on that model before graduation, yet not
requiring specific results for graduation.

-Bertrand

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

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[John D. Ament]

On Mon, Sep 4, 2017 at 7:26 AM Shane Curcuru  wrote:

> Bertrand Delacretaz wrote on 9/4/17 4:54 AM:
> > Hi John,
> >
> > On Fri, Aug 25, 2017 at 9:11 PM, John D. Ament 
> wrote:
> >> ...Its unfair for us to put some stake in the ground expecting podlings
> to
> >> match up 100% on the questions.  Many of the questions are subjective -
> is
> >> the code easy to discover? respond to bug reports in a timely manner?...
> >
> > Ok, I think I understand your reluctance now: you don't want us to set
> > a gate for graduating podlings that many TLPs might not pass.
> >
> > I agree with that, and although I'm a strong supporter of the Maturity
> > Model (having initiated it that's understandable ;-) I'm totally ok
> > with podlings graduating without fullfilling all of its requirements.
> >
> > In my view the model is:
> >
> > 1) A good tool to help discover areas that podlings might have neglected.
> >
> > 2) A good tool to help podlings look at where they stand, and what
> > they might still need to improve after graduation.
> >
> > 3) A good tool to express our ideal way of doing things, in a concise
> > way, and evolve that definition over time.
> >
> > Based on this I will continue to push for podlings to come to
> > graduation with a self-assessment based on that model.
> >
> > OTOH I'm fine with us clarifying that it's not a requirement.
>
> Proposal: It should be a *requirement* for the podling to self-document
> their maturity model answers in the [DISCUSS] thread before IPMC
> graduation vote.  The requirement is having done it, not passing it.
>
>
To be clear - it is not a requirement today for podlings to complete the
Apache Project Maturity Model.  I'll be honest, I have no idea why they
think they have to do it, but they do it.  I don't want to stop them from
doing it, but I want to stop them from incorrectly stating they pass
everything.  I also want to clarify that the answers should not be "Yes" or
"No" but an "OK" and explaining their response, or perhaps an "N/A" and
explain why that line doesn't apply to them yet (the most common issue is
related to something Dave's brought up recently where projects are answer
the security reporting questions).


> It's *very* helpful to have podlings consider their growth using some
> form of structured and consistent criteria, so IPMC (and board) can
> consider how different podlings see themselves compared to past podling
> history.
>
> It doesn't mean every podling has to say "Yes 100%" to every question,
> just that they've considered each point and can describe their situation
> there if not.  I'd expect plenty of podlings would have some missing or
> "we're not completely here" on some points, but still be healthy and
> well-self-governing communities ready to graduate.
>
>
> --
>
> - Shane
>   https://www.apache.org/foundation/marks/resources
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Jim Apple]

> It's *very* helpful to have podlings consider their growth using some
> form of structured and consistent criteria, so IPMC (and board) can
> consider how different podlings see themselves compared to past podling
> history.

I think the current Model has a number of vague statements that are
unlikely to be interpreted consistently without clarification. For
instance "The project is open and honest about the quality of its
code."

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

Re: [VOTE] Graduate Apache RocketMQ from podling to TLP

[William Guo]

+1(non-binding) cool.


From: dongeforever 
Sent: Monday, September 4, 2017 7:39:53 PM
To: general
Subject: Re: [VOTE] Graduate Apache RocketMQ from podling to TLP

+1

Nice to see the RocketMQ becomes TLP.

2017-09-03 12:38 GMT+08:00 Justin Mclean :

> HI,
>
> +1 (binding). Well done!
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Apache RocketMQ from podling to TLP

[dongeforever]

+1

Nice to see the RocketMQ becomes TLP.

2017-09-03 12:38 GMT+08:00 Justin Mclean :

> HI,
>
> +1 (binding). Well done!
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Shane Curcuru]

Bertrand Delacretaz wrote on 9/4/17 4:54 AM:
> Hi John,
> 
> On Fri, Aug 25, 2017 at 9:11 PM, John D. Ament  wrote:
>> ...Its unfair for us to put some stake in the ground expecting podlings to
>> match up 100% on the questions.  Many of the questions are subjective - is
>> the code easy to discover? respond to bug reports in a timely manner?...
> 
> Ok, I think I understand your reluctance now: you don't want us to set
> a gate for graduating podlings that many TLPs might not pass.
> 
> I agree with that, and although I'm a strong supporter of the Maturity
> Model (having initiated it that's understandable ;-) I'm totally ok
> with podlings graduating without fullfilling all of its requirements.
> 
> In my view the model is:
> 
> 1) A good tool to help discover areas that podlings might have neglected.
> 
> 2) A good tool to help podlings look at where they stand, and what
> they might still need to improve after graduation.
> 
> 3) A good tool to express our ideal way of doing things, in a concise
> way, and evolve that definition over time.
> 
> Based on this I will continue to push for podlings to come to
> graduation with a self-assessment based on that model.
> 
> OTOH I'm fine with us clarifying that it's not a requirement.

Proposal: It should be a *requirement* for the podling to self-document
their maturity model answers in the [DISCUSS] thread before IPMC
graduation vote.  The requirement is having done it, not passing it.

It's *very* helpful to have podlings consider their growth using some
form of structured and consistent criteria, so IPMC (and board) can
consider how different podlings see themselves compared to past podling
history.

It doesn't mean every podling has to say "Yes 100%" to every question,
just that they've considered each point and can describe their situation
there if not.  I'd expect plenty of podlings would have some missing or
"we're not completely here" on some points, but still be healthy and
well-self-governing communities ready to graduate.


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

How to handle exclusions in a software grant?

[Bertrand Delacretaz]

Hi,

I'm mentoring a podling where a large initial code donation just happened.

The corresponding software grant points to a large zip file indicating
that the donation consists of that file's contents, "excluding any
third-party and separately licensed material" that it contains.

My understanding is that this puts the burden on the ASF to review
each and every file found in there, and decide whether we can safely
include it in an ASF release or if it's third-party and separately
licensed.

Do people agree with that interpretation?

Have people seen similar cases before, and if yes how were they handled?

-Bertrand

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

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Bertrand Delacretaz]

Hi John,

On Fri, Aug 25, 2017 at 9:11 PM, John D. Ament  wrote:
> ...Its unfair for us to put some stake in the ground expecting podlings to
> match up 100% on the questions.  Many of the questions are subjective - is
> the code easy to discover? respond to bug reports in a timely manner?...

Ok, I think I understand your reluctance now: you don't want us to set
a gate for graduating podlings that many TLPs might not pass.

I agree with that, and although I'm a strong supporter of the Maturity
Model (having initiated it that's understandable ;-) I'm totally ok
with podlings graduating without fullfilling all of its requirements.

In my view the model is:

1) A good tool to help discover areas that podlings might have neglected.

2) A good tool to help podlings look at where they stand, and what
they might still need to improve after graduation.

3) A good tool to express our ideal way of doing things, in a concise
way, and evolve that definition over time.

Based on this I will continue to push for podlings to come to
graduation with a self-assessment based on that model.

OTOH I'm fine with us clarifying that it's not a requirement.

-Bertrand

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

Re: Digests in releases

[Bertrand Delacretaz]

On Thu, Aug 31, 2017 at 3:15 PM, Henk P. Penning  wrote:
>   -- SHA-1 : not as bad as MD5, but no longer considered secure
>  by some ; https://en.wikipedia.org/wiki/SHA-1 ; skip
>   -- SHA-256 : fine
>   -- SHA-512 : fine
>
>   So, I would suggest we pick SHA-256...

+1

-Bertrand

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