Re: PPMC voting new committers

[Jean-Baptiste Onofré]

Hi

It sounds good to me. It's a good idea.

Regards
JB

On Nov 3, 2017, 18:34, at 18:34, Craig Russell  wrote:
>I'd like to see a change in incubator policy w.r.t. voting new
>committers.
>
>While there are no Foundation policies on how to vote new committers,
>we do have best practices documented in
>http://community.apache.org/newcommitter.html that explicitly calls for
>consensus approval of at least three positive votes and no vetoes.
>
>Applying this to the incubator, it makes sense to me to change the
>incubator policy to require a vote (no lazy consensus) and at least
>three PPMC votes in favor. I'd also add a requirement for at least one
>Mentor vote in favor.
>
>After graduation, communities might feel that they know better and can
>adopt bylaws that are different from the community best practices. But
>while in incubation I think that we should enforce best practice.
>
>Craig
>
>Craig L Russell
>c...@apache.org
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org

[DISCUSS] Accept ServiceComb into Apache Incubator

[Willem Jiang]

Hi Folks,

I would like to open a DISCUSS thread on the topic of accepting the
ServiceComb Project into the Incubator.

ServiceComb is a microservice framework that provides a set of tools and
components to make development and deployment of cloud applications easier.

The draft proposal can be found in the wiki at the following URL:
https://wiki.apache.org/incubator/ServiceCombProposal

At this stage we could very much appreciate the discussion and
feedback for entering
Apache Incubation. The text for the draft proposal is found below.

= ServiceComb Proposal =

== Abstract ==

ServiceComb is a microservice framework that provides a set of tools and
components to make development and deployment of cloud applications easier.
It provides functionalities such as service contract enforcement, service
registration, service discovery, load balance, service reliability (latency
and fault tolerance, flow control and graceful degradation, handler chain
tracing), eventual data consistency and so forth.

== Proposal ==

The goal of this proposal is to bring the existing ServiceComb codebase and
existing developers into the Apache Software Foundation (ASF) in order to
build a vibrant, diverse and self-governed open source community around the
technology.
So far the major contributors to the project have been affiliated with
Huawei and Huawei is planning to continue market and sell the Cloud Service
Engine leveraging the ServiceComb framework.
ServiceComb is currently a registered trademark owned by Huawei, and Huawei
is happy to donate this trademark to Apache.

Huawei is submitting this proposal to donate the Service source code and
associated artifacts (documentation, web site content, wiki, etc.) to the
Apache Software Foundation Incubator under the Apache License, Version 2.0
and is asking Incubator PMC to establish an open source community. These
artifacts are currently available on GitHub at
https://github.com/ServiceComb/ and include:
 * Java Chassis: a multi-protocol (RPC & Restful) microservice framework
which adopts contract-first design
 * Service Center: a service registry that enforces service contract upon
service registration and discovery
 * Saga: a distributed coordinator to achieve eventual data consistency
based on the paper "Sagas" by Hector Garcia-Molina and Kenneth Salem
 * ServiceComb.github.io:  the website repo of ServiceComb.
 * The other projects will be moved to another place if ServiceComb is
accepted by Apache as an incubator project.

== Background ==

Microservices is a variant of the service-oriented architecture (SOA)
architectural style that structures an application as a collection of
loosely coupled services. ServiceComb is an open source microservice
framework initiated as part of Huawei CSE projects (Cloud Service Engine)
which was developed in 2015. It is a part of ServiceStage of Huawei Public
Cloud which is one-stop PaaS platform for enterprises and developers.
Besides ServiceStage, it’s  also used in the Huawei Core Network IOT
Platform and Huawei consumer cloud. The number of  companies using
ServiceComb to develop their enterprise applications, they are
chinasofti.com, isoftstone.com, pactera.com,zbj.com,movit-tech.com, and the
number is over 5 and counting.

== Rationale ==

ServiceComb has been developed as a total, open source solution for
developing cloud native applications. So far ServiceComb has existed as a
GitHub project with committers mostly working for Huawei. We feel that
moving it to a neutral organization like Apache, with its strong governance
model, is expected to help get more contributions from various
organizations and developers, who may be concerned by exclusive control of
ServiceComb by Huawei.

== Initial Goals ==

Our initial goals are to bring ServiceComb into the ASF, transition
internal engineering processes into the open, and foster a collaborative
development model according to the "Apache Way." Huawei and the current
contributors to ServiceComb plan to develop new functionality in an open,
community-driven way. To get there, the existing internal build, test and
release processes will be refactored to support open development.

 1. More specifically, our initial plan of moving ServiceComb to ASF is
focused on:
 2. open up the governance model in order to simplify and streamline
contributions from the community
 3. move the existing codebase to Apache
 4. integrate with the Apache development process
 5. ensure all dependencies are compliant with Apache License version 2.0
 6. incremental development and releases per Apache guideline

== Current Status ==

=== Meritocracy ===

We intend to substantially expand the initial developer and user community
by running the project in line with the "Apache Way". Users and new
contributors will be treated with respect and welcomed. By participating in
the community and providing quality patches/support that move the project
forward, they will earn merit. They will also  be encouraged to provide

Re: [RESULT] [VOTE] Accept Crail into the Apache Incubator

[Jitendra Pandey]

+1

On 11/1/17, 7:40 AM, "Craig Russell"  wrote:

Subject line change to close the vote.

> On Nov 1, 2017, at 6:42 AM, Luciano Resende  wrote:
> 
> On Thu, Oct 26, 2017 at 8:31 AM, Luciano Resende 
> wrote:
> 
>> Now that the discussion thread on the Crail proposal has ended, please
>> vote on accepting Crail into into the Apache Incubator.
>> 
>> The ASF voting rules are described at:
>>   http://www.apache.org/foundation/voting.html
>> 
>> A vote for accepting a new Apache Incubator podling is a majority vote
>> for which only Incubator PMC member votes are binding.
>> 
>> Votes from other people are also welcome as an indication of peoples
>> enthusiasm (or lack thereof).
>> 
>> Please do not use this VOTE thread for discussions.
>> If needed, start a new thread instead.
>> 
>> This vote will run for at least 72 hours. Please VOTE as follows
>> [] +1 Accept Crail into the Apache Incubator
>> [] +0 Abstain.
>> [] -1 Do not accept Crail into the Apache Incubator because ...
>> 
>> The proposal below is also on the wiki:
>> https://wiki.apache.org/incubator/CrailProposal
>> 
>> ===
>> 
>> Abstract
>> 
>> Crail is a storage platform for sharing performance critical data in
>> distributed data processing jobs at very high speed. Crail is built
>> entirely upon principles of user-level I/O and specifically targets data
>> center deployments with fast network and storage hardware (e.g., 100Gbps
>> RDMA, plenty of DRAM, NVMe flash, etc.) as well as new modes of operation
>> such resource disaggregation or serverless computing. Crail is written in
>> Java and integrates seamlessly with the Apache data processing ecosystem.
>> It can be used as a backbone to accelerate high-level data operations 
such
>> as shuffle or broadcast, or as a cache to store hot data that is queried
>> repeatedly, or as a storage platform for sharing inter-job data in 
complex
>> multi-job pipelines, etc.
>> 
>> Proposal
>> 
>> Crail enables Apache data processing frameworks to run efficiently in 
next
>> generation data centers using fast storage and network hardware in
>> combination with resource (e.g., DRAM, Flash) disaggregation.
>> 
>> Background
>> 
>> Crail started as a research project at the IBM Zurich Research Laboratory
>> around 2014 aiming to integrate high-speed I/O hardware effectively into
>> large scale data processing systems.
>> 
>> Rational
>> 
>> During the last decade, I/O hardware has undergone rapid performance
>> improvements, typically in the order of magnitudes. Modern day networking
>> and storage hardware can deliver 100+ Gbps (10+ GBps) bandwidth with a 
few
>> microseconds of access latencies. However, despite such progress in raw 
I/O
>> performance, effectively leveraging modern hardware in data processing
>> frameworks remains challenging. In most of the cases, upgrading to 
high-end
>> networking or storage hardware has very little effect on the performance 
of
>> analytics workloads. The problem comes from heavily layered software
>> imposing overheads such as deep call stacks, unnecessary data copies,
>> thread contention, etc. These problems have already been addressed at the
>> operating system level with new I/O APIs such as RDMA verbs, NVMe, etc.,
>> allowing applications to bypass software layers during I/O operations.
>> Distributed data processing frameworks on the other hand, are typically
>> implemented on legacy I/O interfaces such as such as sockets or block
>> storage. These interfaces have been shown to be insufficient to deliver 
the
>> full hardware performance. Yet, to the best of our knowledge, there are 
no
>> active and systematic efforts to integrate these new user level I/O APIs
>> into Apache software frameworks. This problem affects all end-users and
>> organizations that use Apache software. We expect them to see
>> unsatisfactory small performance gains when upgrading their networking 
and
>> storage hardware.
>> 
>> Crail solves this problem by providing an efficient storage platform 
built
>> upon user-level I/O, thus, bypassing layers such as JVM and OS during I/O
>> operations. Moreover, Crail directly leverages the specific hardware
>> features of RDMA and NVMe to provide a better integration with high-level
>> data operations in Apache compute frameworks. As a consequence, Crail
>> enables users to run larger, more complex queries against ever increasing
>> amounts of data at a speed largely determined by the deployed hardware.
>> Crail is generic solution that integrates well with the Apache ecosystem
>> including frameworks like Spark, Hadoop, 

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

[Luciano Resende]

Thanks Ryan, Let me look into this right away.

On Fri, Nov 3, 2017 at 10:26 AM, Ryan Blue 
wrote:

> -1 (binding)
>
> There are a few things that could be improved, but my -1 is because the
> release tarball doesn’t match the release tag (inclusion of
> .example-image), some files are missing the license header, and there is no
> mention in the license file of mesos-protobuf that’s included in the
> tarball.
>
> rb
>
>
> Here are my other notes:
>
> The .sha file has a sha512 checksum, which should be in a .sha512 file.
> Also (but minor), both .md5 and .sha files have a full path instead of a
> relative path:
> /Users/lresende/opensource/jupyter/incubator-toree-
> apache/dist/toree-src/toree-0.2.0-incubating-src.tar.gz
>
> I had to import the key using gpg --recv-keys EFB55DF1. Is there a KEYS
> file published for Toree?
>
> The tarball currently unpacks into the current directory, which is unusual
> for source tarballs.
>
> RAT checks fail for some files. Here’s the summary:
>
>  !? .jvmopts
>  !? .example-image
>  !? sparkr-interpreter/src/main/resources/README.md
>  !? index.ipynb
>  !? README.md
>  !? RELEASE_NOTES.md
>  !? etc/pip_install/MANIFEST.in
>  !? etc/.src-release-ignore
>
> We should have license headers in the .md files, and the release process
> should ideally use git archive to avoid picking up files from the local
> working directory that aren’t part of the tagged release.
>
> This also distributes a few Jars:
>
> Archives:
>  + scala-interpreter/src/test/resources/TestJar2.jar
>  + scala-interpreter/src/test/resources/ScalaTestJar.jar
>  + scala-interpreter/src/test/resources/TestJar.jar
>  + kernel/lib/mesos-0.18.1-shaded-protobuf.jar
>
> I think the test Jars are fine, but LICENSE and NOTICE don’t mention
> distributing mesos-protobuf.
> ​
>
> On Wed, Nov 1, 2017 at 6:37 AM, Atri Sharma  wrote:
>
> > +1
> > -- Checked Headers
> > -- Checked License
> > -- Checked DISCLAIMER and Incubator policies
> >
> > On Thu, Oct 26, 2017 at 9:37 PM, Luciano Resende 
> > wrote:
> > > Please vote to approve the release of Apache Toree 0.2.0-incubating
> > (RC1).
> > >
> > > The PPM vote thread:
> > > https://www.mail-archive.com/dev@toree.incubator.apache.
> > org/msg01527.html
> > >
> > > And the result:
> > > https://www.mail-archive.com/dev@toree.incubator.apache.
> > org/msg01539.html
> > >
> > > Tag: v0.2.0-incubating-rc1 (01cd97e9bad04878a8014016c154a50e2a00f21d)
> > >
> > > https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc1
> > >
> > > All distribution packages, including signatures, digests, etc. can be
> > found
> > > at:
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.
> > 0-incubating-rc1/
> > >
> > > Staging artifacts can be found at:
> > >
> > > https://repository.apache.org/content/repositories/orgapachetoree-1007
> > >
> > > 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/
> >
> >
> >
> > --
> > Regards,
> >
> > Atri
> > l'apprenant
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>



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

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

[Dave Fisher]

-0

I started a review and noticed that the RELEASE_NOTES.md is for 0.1.0 and the 
copyright year in NOTICE should be updated.

I’ll stop for now.

Regards,
Dave

> On Nov 3, 2017, at 10:26 AM, Ryan Blue  wrote:
> 
> -1 (binding)
> 
> There are a few things that could be improved, but my -1 is because the
> release tarball doesn’t match the release tag (inclusion of
> .example-image), some files are missing the license header, and there is no
> mention in the license file of mesos-protobuf that’s included in the
> tarball.
> 
> rb
> 
> 
> Here are my other notes:
> 
> The .sha file has a sha512 checksum, which should be in a .sha512 file.
> Also (but minor), both .md5 and .sha files have a full path instead of a
> relative path:
> /Users/lresende/opensource/jupyter/incubator-toree-apache/dist/toree-src/toree-0.2.0-incubating-src.tar.gz
> 
> I had to import the key using gpg --recv-keys EFB55DF1. Is there a KEYS
> file published for Toree?
> 
> The tarball currently unpacks into the current directory, which is unusual
> for source tarballs.
> 
> RAT checks fail for some files. Here’s the summary:
> 
> !? .jvmopts
> !? .example-image
> !? sparkr-interpreter/src/main/resources/README.md
> !? index.ipynb
> !? README.md
> !? RELEASE_NOTES.md
> !? etc/pip_install/MANIFEST.in
> !? etc/.src-release-ignore
> 
> We should have license headers in the .md files, and the release process
> should ideally use git archive to avoid picking up files from the local
> working directory that aren’t part of the tagged release.
> 
> This also distributes a few Jars:
> 
> Archives:
> + scala-interpreter/src/test/resources/TestJar2.jar
> + scala-interpreter/src/test/resources/ScalaTestJar.jar
> + scala-interpreter/src/test/resources/TestJar.jar
> + kernel/lib/mesos-0.18.1-shaded-protobuf.jar
> 
> I think the test Jars are fine, but LICENSE and NOTICE don’t mention
> distributing mesos-protobuf.
> ​
> 
> On Wed, Nov 1, 2017 at 6:37 AM, Atri Sharma  wrote:
> 
>> +1
>> -- Checked Headers
>> -- Checked License
>> -- Checked DISCLAIMER and Incubator policies
>> 
>> On Thu, Oct 26, 2017 at 9:37 PM, Luciano Resende 
>> wrote:
>>> Please vote to approve the release of Apache Toree 0.2.0-incubating
>> (RC1).
>>> 
>>> The PPM vote thread:
>>> https://www.mail-archive.com/dev@toree.incubator.apache.
>> org/msg01527.html
>>> 
>>> And the result:
>>> https://www.mail-archive.com/dev@toree.incubator.apache.
>> org/msg01539.html
>>> 
>>> Tag: v0.2.0-incubating-rc1 (01cd97e9bad04878a8014016c154a50e2a00f21d)
>>> 
>>> https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc1
>>> 
>>> All distribution packages, including signatures, digests, etc. can be
>> found
>>> at:
>>> 
>>> https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.
>> 0-incubating-rc1/
>>> 
>>> Staging artifacts can be found at:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachetoree-1007
>>> 
>>> 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/
>> 
>> 
>> 
>> --
>> Regards,
>> 
>> Atri
>> l'apprenant
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
> 
> 
> --
> Ryan Blue
> Software Engineer
> Netflix



signature.asc
Description: Message signed with OpenPGP

PPMC voting new committers

[Craig Russell]

I'd like to see a change in incubator policy w.r.t. voting new committers.

While there are no Foundation policies on how to vote new committers, we do 
have best practices documented in http://community.apache.org/newcommitter.html 
that explicitly calls for consensus approval of at least three positive votes 
and no vetoes.

Applying this to the incubator, it makes sense to me to change the incubator 
policy to require a vote (no lazy consensus) and at least three PPMC votes in 
favor. I'd also add a requirement for at least one Mentor vote in favor.

After graduation, communities might feel that they know better and can adopt 
bylaws that are different from the community best practices. But while in 
incubation I think that we should enforce best practice.

Craig

Craig L Russell
c...@apache.org


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

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

[Ryan Blue]

-1 (binding)

There are a few things that could be improved, but my -1 is because the
release tarball doesn’t match the release tag (inclusion of
.example-image), some files are missing the license header, and there is no
mention in the license file of mesos-protobuf that’s included in the
tarball.

rb


Here are my other notes:

The .sha file has a sha512 checksum, which should be in a .sha512 file.
Also (but minor), both .md5 and .sha files have a full path instead of a
relative path:
/Users/lresende/opensource/jupyter/incubator-toree-apache/dist/toree-src/toree-0.2.0-incubating-src.tar.gz

I had to import the key using gpg --recv-keys EFB55DF1. Is there a KEYS
file published for Toree?

The tarball currently unpacks into the current directory, which is unusual
for source tarballs.

RAT checks fail for some files. Here’s the summary:

 !? .jvmopts
 !? .example-image
 !? sparkr-interpreter/src/main/resources/README.md
 !? index.ipynb
 !? README.md
 !? RELEASE_NOTES.md
 !? etc/pip_install/MANIFEST.in
 !? etc/.src-release-ignore

We should have license headers in the .md files, and the release process
should ideally use git archive to avoid picking up files from the local
working directory that aren’t part of the tagged release.

This also distributes a few Jars:

Archives:
 + scala-interpreter/src/test/resources/TestJar2.jar
 + scala-interpreter/src/test/resources/ScalaTestJar.jar
 + scala-interpreter/src/test/resources/TestJar.jar
 + kernel/lib/mesos-0.18.1-shaded-protobuf.jar

I think the test Jars are fine, but LICENSE and NOTICE don’t mention
distributing mesos-protobuf.
​

On Wed, Nov 1, 2017 at 6:37 AM, Atri Sharma  wrote:

> +1
> -- Checked Headers
> -- Checked License
> -- Checked DISCLAIMER and Incubator policies
>
> On Thu, Oct 26, 2017 at 9:37 PM, Luciano Resende 
> wrote:
> > Please vote to approve the release of Apache Toree 0.2.0-incubating
> (RC1).
> >
> > The PPM vote thread:
> > https://www.mail-archive.com/dev@toree.incubator.apache.
> org/msg01527.html
> >
> > And the result:
> > https://www.mail-archive.com/dev@toree.incubator.apache.
> org/msg01539.html
> >
> > Tag: v0.2.0-incubating-rc1 (01cd97e9bad04878a8014016c154a50e2a00f21d)
> >
> > https://github.com/apache/incubator-toree/tree/v0.2.0-incubating-rc1
> >
> > All distribution packages, including signatures, digests, etc. can be
> found
> > at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/toree/0.2.
> 0-incubating-rc1/
> >
> > Staging artifacts can be found at:
> >
> > https://repository.apache.org/content/repositories/orgapachetoree-1007
> >
> > 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/
>
>
>
> --
> Regards,
>
> Atri
> l'apprenant
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Ryan Blue
Software Engineer
Netflix

Re: Update README for retired podlings?

[Shane Curcuru]

Dave Fisher wrote on 11/2/17 11:13 PM:
>> On Nov 2, 2017, at 7:06 PM, John D. Ament  wrote:
>>> On Thu, Nov 2, 2017 at 6:17 PM Dave Fisher  wrote:
> On Nov 2, 2017, at 3:08 PM, sebb  wrote:

> On 2 November 2017 at 21:07, Dave Fisher  wrote:
...snip...
>> I'm not even sure I agree with deleting the websites.  It was a project.
>> Now it's not.  That doesn't mean the information should no longer be
>> available.  But not sure the resources need to be covered.
> 
> Either the IPMC should review the policy or we should ask the board to 
> set/confirm the policy for “retired” podlings.

Podlings in incubation are not Apache projects - by definition.  They
are podlings effectively managed within the incubator.  So it would be
best for the IPMC to come up with a specific policy or plan for this,
vote on it, and then just let the board know "Hey, here's how we're
going to formally handle retiring podling assets".

Personally, I think it depends on how long the podling was around (i.e.
how many likely other people were attempting to use the project) and
what the state of it's IP clearance is.  In particular, if IP clearance
weren't complete, I would vote for deleting the repos, just to ensure
that we're not distributing (even via source control) IP that the ASF
isn't assured of having under our license.

-- 

- 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