Re: [VOTE] Apache MXNet (incubating) 1.1.0 release RC0

[Justin Mclean]

Hi,

Sorry but -1 binding for me due to LICENSE issues but happy to discuss and 
change my vote depending on what other IPMC members think.

Putting “wherever applicable” is probably not enough to compile with the terms 
of 3rd party licenses or ASF policy. Most licenses say the full text of the 
license needs to be included in order to comply with the terms of the license 
and that normally includes a copyright line. Usually files have the license 
text as the header so this is probably OK from a licensing point of view but I 
can see a number of cases here where they don’t. There are also several types 
of BSD license included not just the 2 clause BSD license listed in license.

I checked:
- incubating in name
- signatures and hashes good
- DISCLAIMER exists
- LICENSE has issues
- NOTICE has wrong year
- source files are missing license headers
- no unexpected binary files
- can compile from source

For license all the 3rd party pieces need to be listed in LICENSE. [1] There is 
also software under other licenses i.e. (zlib) that are are not mentioned in 
license.

I’m still confused how some files are licensed as they are missing headers 
(about 600 files) and this make the release hard to review. i.e. How do you 
tell if someone forget to put an ASF header on a file or is it a 3rd party file 
and if so how is it licensed?

Also two minor things I noticed with the vote thread:
a) several people said they tested the release from what was on GitHub, the one 
in dist.apache.org would be the one tested.
b) Votes are pen for a minimum pf 72 hours not exactly 72 hours.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
2. https://github.com/apache/mynewt-core/blob/master/LICENSE




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

[RESULTS] [VOTE] Release Apache Livy 0.5.0-incubating (RC2)

[Alex Bozarth]

This vote has passed with three +1 binding votes and no -1s or 0s.

+1 (binding):
Justin Mclean
Luciano Resende
Jean-Baptiste Onofré (carried over from the Livy dev vote)

Thank you to those that voted, I will follow up with the release and
announcement at the start of next week.

   
 Alex Bozarth   
   
 Software Engineer  
   
 Spark Technology Center
   

   

 

 

 
 E-mail: ajboz...@us.ibm.com
 
 GitHub: github.com/ajbozarth   
 
   505 Howard 
Street 
 San Francisco, CA 
94105 
   United 
States 

 








From:   "Alex Bozarth" 
To: general@incubator.apache.org
Cc: d...@livy.incubator.apache.org
Date:   01/29/2018 08:56 PM
Subject:[VOTE] Release Apache Livy 0.5.0-incubating (RC2)





The Apache Livy community has voted on and approved a proposal to release
Apache Livy 0.5.0-incubating (RC2). We would like to request that the
Incubator PMC members review and vote on this incubator release candidate.

Apache Livy (incubating) 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.


The livy dev voting thread can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_dev-40livy.incubator.apache.org_msg00297.html=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88=A4Zj9gq_lY03yGNaX1_vdv2qhHnUGV4L977gCZNZ9SI=


And the results here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_dev-40livy.incubator.apache.org_msg00308.html=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88=bkZOidHCkYJLm_b8zKiBTgmrMwPVokBfx1RwY81U4po=


Git tag: v0.5.0-incubating-rc2
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dlivy_tree_v0.5.0-2Dincubating-2Drc2=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88=O_kxYpiepl0wVaKyaz8eCsYl-MH4tUR33TVpv3FPjuY=


All distribution packages, including signatures, digests, etc. can be found
at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_incubator_livy_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88=p94R0sDvo-3IQsQ7K6hCpkyQw-7I-jDjFkBnnzT2O7o=


Staging artifacts can be found at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__repository.apache.org_content_repositories_orgapachelivy-2D1005_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo=KMyzqbWH-_wvXigmaGS87yHcYzpZNbJiY8bTu_mzt88=io8fHD48IMg_fp25H7oJMG29WbUK012gQ-U9F5oB-bQ=



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 Livy 0.5.0-incubating

 [ ] -1 Do not release this package because ...


Thank you on behalf of the Apache Livy community,

 Alex Bozarth

 Software Engineer

 Spark Technology Center





 E-mail: ajboz...@us.ibm.com

 GitHub: github.com/ajbozarth

   505
Howard Street
 San Francisco,
CA 94105

United States

Re: [VOTE] Apache MXNet (incubating) 1.1.0 release RC0

[Haibin Lin]

Hello all,

Just a gentle reminder that voting is in progress. Please help verify if
the release candidate meets the standard and vote accordingly. Thanks!

Best,
Haibin

On Wed, Jan 31, 2018 at 1:48 PM, Haibin Lin 
wrote:

> Hello all,
>
> This is a call for a releasing Apache MXNet (incubating) 1.1.0, release
> candidate 0.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
> https://lists.apache.org/thread.html/4b9310aaa1e5c378aa91c274acf412
> eb5b495a10fe7dad0fab653436@%3Cdev.mxnet.apache.org%3E
>
> Result thread:
> https://lists.apache.org/thread.html/9048b226cd7f86f1fec84ac251934c
> 7877c9442e5f053f5f2ccd8c52@%3Cdev.mxnet.apache.org%3E
>
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.1.0.rc0/
>
> The tag to be voted upon is 1.1.0.rc0:
> https://github.com/apache/incubator-mxnet/releases/tag/1.1.0.rc0
>
> The release hash is 8b3c9ebb7bb4a9e8ee88e7222a718f7fa1c9a6be:
> https://github.com/apache/incubator-mxnet/commit/
> 8b3c9ebb7bb4a9e8ee88e7222a718f7fa1c9a6be
>
> Release artifacts are signed with the following key:
> 7302 629A 6791 AC2C 3593  B9A0 015E D8A2 9C81 5704
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> For information about the contents of this release, see:
> https://cwiki.apache.org/confluence/display/MXNET/
> Apache+MXNet+%28incubating%29+1.1.0+Release+Notes
>
> The vote will end at 2 pm on Sunday (Feb 3rd).
>
> [ ] +1 Release this package as 1.1.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Best,
> Haibin
>

Re: [DISCUSSION] Apache DataFu podling graduation

[Matthew Hayes]

Hi John,

Regarding the events you listed:

- Podling discusses graduation.


 Done.  See here

.

- Podling drafts a charter (whimsy more or less generates this for you
> these days)


The charter is in the graduation resolution right?  DataFu's graduation
resolution is here
.

- Podling calls for a vote & at the same time podling notifies IPMC about
> that vote


Vote started yesterday.  See here

.

- Podling members start a discussion on general@incu about the graduation.


Done, as this is the current discussion thread about graduation.  I opened
the discussion before voting because DataFu had already voted once before

the
most recent vote and there was feedback in the discussion that followed. I
wanted to collect all feedback from the general list before starting
another vote so those issues could be addressed first.  Hopefully this was
okay.

- Calls for a vote (usually, the discussions go 72 hrs - 1 week, depending
> on how lively they are)


Waiting for current vote.

I see a few disconnects between your status page and whimsy roster.  Can
> you double check that everything lines up?  If people are not going to be
> included in the new TLP, I would recommend removing them from whimsy; this
> will save some work.  Any reason you are losing members when graduating?


I've updated the Whimsy roster to match the proposed PMC members in the
graduation proposal.  Most people are continuing on to PMC.  We are only
losing a few, for different reasons.

I see a few disconnects between your status page and whimsy roster.  Can
> you double check that everything lines up?


Can you specify what disconnects you see?  Under Mentors on the roster page
 I see Jakob is not listed
but he is listed on the status page
.  The Licensing section
on the roster page lists that there have been no software grant and IP
clearance and no releases, which isn't true.  How does the roster get
updated?  Otherwise I'm not sure what disconnects there are.

-Matt

On Thu, Feb 1, 2018 at 7:12 PM, John D. Ament  wrote:

> On Thu, Feb 1, 2018 at 6:23 PM Matthew Hayes <
> matthew.terence.ha...@gmail.com> wrote:
>
> > Given that it has been a few days and I've only seen positive feedback so
> > far, I have opened a new vote for graduation in the datafu dev
> >  list.
> I
> > will open a new vote here when this vote passes.
> >
> >
> Matt,
>
> The typical order of events is:
>
> - Podling discusses graduation.
> - Podling drafts a charter (whimsy more or less generates this for you
> these days)
> - Podling calls for a vote & at the same time podling notifies IPMC about
> that vote
> - Podling members start a discussion on general@incu about the graduation.
> - Calls for a vote (usually, the discussions go 72 hrs - 1 week, depending
> on how lively they are)
>
> I see a few disconnects between your status page and whimsy roster.  Can
> you double check that everything lines up?  If people are not going to be
> included in the new TLP, I would recommend removing them from whimsy; this
> will save some work.  Any reason you are losing members when graduating?
>
> The IPMC (specifically, the graduating podlings) have received consistent
> feedback from the board regarding ASF members being present on newly formed
> TLPs.  I believe you will not have that issue with both Roman & Jarek on
> the proposed PMC.
>
> John
>
>
> > -Matt
> >
> > On Mon, Jan 29, 2018 at 3:57 PM, Jakob Homan  wrote:
> >
> > > +1
> > >
> > > On 29 January 2018 at 15:49, Matthew Hayes  wrote:
> > > > Hi,
> > > >
> > > > I would like to reopen the discussion regarding Apache DataFu's
> > > graduation
> > > > from incubator.  In the community vote
> > > >  > > dev/201708.mbox/%3CCAA4Vo8CNf0sVw0veP2GdV9VN%
> > > 3DaP5-Q8kstgY%2B0xM48kNuJMFWw%40mail.gmail.com%3E>
> > > >  there was consensus to graduate to TLP status.  Here is my email
> that
> > > > kicked off the previous discussion:
> > > >
> > > > https://mail-archives.apache.org/mod_mbox/incubator-
> > > general/201710.mbox/%3CCAA4Vo8DuQH2KkQ82bOm4Aj8GyoH
> > > s8hoauywco2mutibwgwx...@mail.gmail.com%3E
> > > >
> > > > There were several pieces of feedback from that discussion that
> should
> > > all
> > > > be addressed as of now.
> > > >
> > > > * 

Re: [VOTE] Accept Coral into the Apache Incubator

[Mark Struberg]

+1 binding

LieGrue,
strub

> Am 01.02.2018 um 15:07 schrieb Byung-Gon Chun :
> 
> Hi all,
> 
> I would like to start a VOTE to propose the Coral project as a podling into
> the Apache Incubator.
> 
> The ASF voting rules are described at https://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.
> 
> This vote will run for at least 72 hours. Please VOTE as follows.
> [] +1 Accept Coral into the Apache Incubator
> [] +0 Abstain
> [] -1 Do not accept Coral into the Apache Incubator because ...
> 
> The proposal is listed below, but you can also access it on the wiki:
> https://wiki.apache.org/incubator/CoralProposal
> 
> = CoralProposal =
> 
> == Abstract ==
> Coral is a data processing system for flexible employment with
> different execution scenarios for various deployment characteristics
> on clusters.
> 
> == Proposal ==
> Today, there is a wide variety of data processing systems with
> different designs for better performance and datacenter efficiency.
> They include processing data on specific resource environments and
> running jobs with specific attributes. Although each system
> successfully solves the problems it targets, most systems are designed
> in the way that runtime behaviors are built tightly inside the system
> core to hide the complexity of distributed computing. This makes it
> hard for a single system to support different deployment
> characteristics with different runtime behaviors without substantial
> effort.
> 
> Coral is a data processing system that aims to flexibly control the
> runtime behaviors of a job to adapt to varying deployment
> characteristics. Moreover, it provides a means of extending the
> system’s capabilities and incorporating the extensions to the flexible
> job execution.
> 
> In order to be able to easily modify runtime behaviors to adapt to
> varying deployment characteristics, Coral exposes runtime behaviors to
> be flexibly configured and modified at both compile-time and runtime
> through a set of high-level graph pass interfaces.
> 
> We hope to contribute to the big data processing community by enabling
> more flexibility and extensibility in job executions. Furthermore, we
> can benefit more together as a community when we work together as a
> community to mature the system with more use cases and understanding
> of diverse deployment characteristics. The Apache Software Foundation
> is the perfect place to achieve these aspirations.
> 
> == Background ==
> Many data processing systems have distinctive runtime behaviors
> optimized and configured for specific deployment characteristics like
> different resource environments and for handling special job
> attributes.
> 
> For example, much research have been conducted to overcome the
> challenge of running data processing jobs on cheap, unreliable
> transient resources. Likewise, techniques for disaggregating different
> types of resources, like memory, CPU and GPU, are being actively
> developed to use datacenter resources more efficiently. Many
> researchers are also working to run data processing jobs in even more
> diverse environments, such as across distant datacenters. Similarly,
> for special job attributes, many works take different approaches, such
> as runtime optimization, to solve problems like data skew, and to
> optimize systems for data processing jobs with small-scale input data.
> 
> Although each of the systems performs well with the jobs and in the
> environments they target, they perform poorly with unconsidered cases,
> and do not consider supporting multiple deployment characteristics on
> a single system in their designs.
> 
> For an application writer to optimize an application to perform well
> on a certain system engraved with its underlying behaviors, it
> requires a deep understanding of the system itself, which is an
> overhead that often requires a lot of time and effort. Moreover, for a
> developer to modify such system behaviors, it requires modifications
> of the system core, which requires an even deeper understanding of the
> system itself.
> 
> With this background, Coral is designed to represent all of its jobs
> as an Intermediate Representation (IR) DAG. In the Coral compiler,
> user applications from various programming models (ex. Apache Beam)
> are submitted, transformed to an IR DAG, and optimized/customized for
> the deployment characteristics. In the IR DAG optimization phase, the
> DAG is modified through a series of compiler “passes” which reshape or
> annotate the DAG with an expression of the underlying runtime
> behaviors. The IR DAG is then submitted as an execution plan for the
> Coral runtime. The runtime includes the unmodified parts of data
> processing in the backbone which is transparently integrated with
> configurable components exposed for further extension.
> 
> == Rationale ==
> Coral’s vision lies in 

Re: [VOTE] Accept Coral into the Apache Incubator

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-02 7:54 GMT+01:00 Jean-Baptiste Onofré :

> +1 (binding)
>
> Regards
> JB
>
> On 02/01/2018 03:07 PM, Byung-Gon Chun wrote:
> > Hi all,
> >
> > I would like to start a VOTE to propose the Coral project as a podling
> into
> > the Apache Incubator.
> >
> > The ASF voting rules are described at https://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.
> >
> > This vote will run for at least 72 hours. Please VOTE as follows.
> > [] +1 Accept Coral into the Apache Incubator
> > [] +0 Abstain
> > [] -1 Do not accept Coral into the Apache Incubator because ...
> >
> > The proposal is listed below, but you can also access it on the wiki:
> > https://wiki.apache.org/incubator/CoralProposal
> >
> > = CoralProposal =
> >
> > == Abstract ==
> > Coral is a data processing system for flexible employment with
> > different execution scenarios for various deployment characteristics
> > on clusters.
> >
> > == Proposal ==
> > Today, there is a wide variety of data processing systems with
> > different designs for better performance and datacenter efficiency.
> > They include processing data on specific resource environments and
> > running jobs with specific attributes. Although each system
> > successfully solves the problems it targets, most systems are designed
> > in the way that runtime behaviors are built tightly inside the system
> > core to hide the complexity of distributed computing. This makes it
> > hard for a single system to support different deployment
> > characteristics with different runtime behaviors without substantial
> > effort.
> >
> > Coral is a data processing system that aims to flexibly control the
> > runtime behaviors of a job to adapt to varying deployment
> > characteristics. Moreover, it provides a means of extending the
> > system’s capabilities and incorporating the extensions to the flexible
> > job execution.
> >
> > In order to be able to easily modify runtime behaviors to adapt to
> > varying deployment characteristics, Coral exposes runtime behaviors to
> > be flexibly configured and modified at both compile-time and runtime
> > through a set of high-level graph pass interfaces.
> >
> > We hope to contribute to the big data processing community by enabling
> > more flexibility and extensibility in job executions. Furthermore, we
> > can benefit more together as a community when we work together as a
> > community to mature the system with more use cases and understanding
> > of diverse deployment characteristics. The Apache Software Foundation
> > is the perfect place to achieve these aspirations.
> >
> > == Background ==
> > Many data processing systems have distinctive runtime behaviors
> > optimized and configured for specific deployment characteristics like
> > different resource environments and for handling special job
> > attributes.
> >
> > For example, much research have been conducted to overcome the
> > challenge of running data processing jobs on cheap, unreliable
> > transient resources. Likewise, techniques for disaggregating different
> > types of resources, like memory, CPU and GPU, are being actively
> > developed to use datacenter resources more efficiently. Many
> > researchers are also working to run data processing jobs in even more
> > diverse environments, such as across distant datacenters. Similarly,
> > for special job attributes, many works take different approaches, such
> > as runtime optimization, to solve problems like data skew, and to
> > optimize systems for data processing jobs with small-scale input data.
> >
> > Although each of the systems performs well with the jobs and in the
> > environments they target, they perform poorly with unconsidered cases,
> > and do not consider supporting multiple deployment characteristics on
> > a single system in their designs.
> >
> > For an application writer to optimize an application to perform well
> > on a certain system engraved with its underlying behaviors, it
> > requires a deep understanding of the system itself, which is an
> > overhead that often requires a lot of time and effort. Moreover, for a
> > developer to modify such system behaviors, it requires modifications
> > of the system core, which requires an even deeper understanding of the
> > system itself.
> >
> > With this background, Coral is designed to represent all of its jobs
> > as an Intermediate Representation (IR) DAG. In the Coral compiler,
> > user applications from various programming models (ex. Apache Beam)
> > are submitted, transformed