Re: [VOTE] Release Apache ServiceComb Saga (incubating) version 0.1.0

[Roman Shaposhnik]

On Mon, Mar 19, 2018 at 9:41 PM, Mohammad Asif Siddiqui
 wrote:
> Hello All,
>
> This is a call for vote to release Apache ServiceComb Saga (Incubating) 
> version 0.1.0
>
> Apache ServiceComb (Incubating) Community has voted and approved the release.
>
> Vote Thread : 
> https://lists.apache.org/thread.html/46b2a639306ed5260f1aec5a3749eeb9112cc666069842e8aad1862d@%3Cdev.servicecomb.apache.org%3E
>
> Result Thread : 
> https://lists.apache.org/thread.html/1b60c2a2542b9a3358e16b8960c4f925fc7b3c25bc382771b97c5567@%3Cdev.servicecomb.apache.org%3E
>
> Release Notes : 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12342353
>
> Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/incubator-servicecomb-saga/0.1.0/
>
> Staging Repo : 
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1166
>
> Release Tag : 
> https://github.com/apache/incubator-servicecomb-saga/releases/tag/0.1.0
>
> Release CommitID : 708eec092988dfd4a5960ca5f232fb7421d5fbdd
>
> Keys to verify the Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 20th March, 2018) and will remain open for 
> next 72 hours, We request all IPMC members to give their vote.
>
> [ ] +1 Release this package as 0.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because

+1 (binding)

* checked hashes
* checked signatures
* compared tag to the tarball
* checked NOTICE, LICENSE and DISCLAIMER
* RAT plugin enabled

Thanks,
Roman.

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

Re: [VOTE]: Apache HAWQ 2.3.0.0-incubating Release

[Roman Shaposhnik]

+1 (binding)

* checked sigs and checksums
* checked licenses
* checked for archive matching git tag

Thanks,
Roman.


On Mon, Mar 12, 2018 at 12:21 PM, Konstantin Boudnik  wrote:
> +1 [biding]
>
> - signature check [ok]
> - checksum check [ok]
> - licenses check (RAT) [ok]
>
> I haven't tried to build it because of the complexity of the build
> process and multiplicity of the environment configurations. To lower
> the entry barrier, I would recommend the community to think how to
> wrap these steps into the build system. You can go as far as to
> provide an "official" toolchain for the project. In Bigtop, we even
> provide official Docker containers were people can start working with
> the project in under 2 minutes and without any need for additional
> error prone configuration steps.
> --
>   With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Tue, Mar 6, 2018 at 6:56 PM, Yi JIN  wrote:
>> Hi IPMC members,
>>
>> The PPMC vote for the Apache HAWQ 2.3.0.0-incubating release has passed.
>> So I request IPMC now to vote on this release candidate. Thank you!
>>
>> The release page is here:
>> https://cwiki.apache.org/confluence/display/HAWQ/Apache+HAWQ+2.3.0.0-incubating+Release
>>
>> The PPMC vote thread is located here:
>> https://lists.apache.org/thread.html/fa5b41cd7461bd729146e10d8f7a54156c818f93e5a1160c42e76c79@%3Cdev.hawq.apache.org%3E
>>
>> The artifacts can be downloaded here:
>> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.3.0.0-incubating.RC2/
>> The artifacts have been signed with Key : CE60F90D1333092A
>>
>> All JIRAs completed for this release are tagged with 'FixVersion
>> =2.3.0.0-incubating'
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340262&styleName=Html&projectId=12318826
>>
>> Please vote accordingly:
>> [ ] +1, accept as the official Apache HAWQ 2.3.0.0-incubating release
>> [ ] -1, do not accept as the official Apache HAWQ 2.3.0.0-incubating release
>> because...
>>
>> The vote will run for at least 72 hours.
>>
>> Best regards,
>> Yi Jin (yjin)
>
> -
> 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: Write access to incubator wiki

[Roman Shaposhnik]

Done!

On Tue, Mar 6, 2018 at 3:58 PM, Mark Thomas  wrote:
> Hi,
>
> Please grant 'markt' write access to the incubator wiki.
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [DISCUSS] Dr. Elephant Incubator Proposal

[Roman Shaposhnik]

On Tue, Mar 6, 2018 at 3:17 PM, Mike Drob  wrote:
> Why does Dr. Elephant make sense as a separate project instead of
> contributing to Hadoop directly?
>
> What is the relationship between Dr. Elephant and the (now seemingly
> defunct) Hadoop Vaidya?

A different way to ask the same question would be: how closely is it tied
to YARN as a scheduler? Does it support other schedulers (as in running
Spark on Mesos for example)?

Thanks,
Roman.

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

Re: [VOTE] Apache DataFu podling graduation

[Roman Shaposhnik]

On Wed, Feb 14, 2018 at 9:36 AM, Matthew Hayes  wrote:
> Hi all,
>
> I would like to open a vote for Apache DataFu's graduation from incubator.  
> The
> DataFu community previously voted on this back in July, 2017 and the vote
>  passed
> .
> Following this there was a discussion
> 
> on
> this list about graduation.  There were several pieces of feedback.  To
> summarize, there were:
>
> * Comments about the number of committers vs. proposed PMC size (here
> 
>  and here
> 
> )
> * Comments about the process for removing committers (here
> 
>  and here
> 
> )
> * Comments about the website, sha-512 extension, etc. (here
> 
> ).  DATAFU-131  was filed
> to address these.
>
> All of that feedback should now be addressed (see the bottom of this email
> for a more detailed summary than what follows).  The list of proposed PMC
> members has been updated in the graduation resolution to include 11
> individuals, which includes 10 of the current 14 committers.  The remaining
> committers declined to remain committers and join the PMC and upon
> graduation these individuals will no longer be committers.  However given
> their past contributions they would be welcomed back if they wished to
> become committers again in the future and contribute.  Following these
> updates another community vote was held in February 2018 to reaffirm
> graduation and this vote passed as well
> 
> .
>
> Given this, I would like to open a vote for Apache DataFu's graduation from
> incubator and becoming a top-level project.  The proposed graduation
> resolution can be found at https://cwiki.apache.org/confluence/display/
> DATAFU/Graduation+Resolution as well as at the bottom of this email.
>
> The vote will be open for 72 hours.
>
> [ ] +1 graduate DataFu to a TLP
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

+1 (binding)

Thanks,
Roman.

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

Re: [VOTE] Apache DataFu 1.3.3 release RC1

[Roman Shaposhnik]

+1 (binding)

- checked sigs
- LICENSES/NOTICE/DISCLAIMER look good
- Headers look good
- checked for the release tag in Git
- offending (cat X) material got removed, but otherwise git tag
matches release tarball

Thanks,
Roman.

P.S. Weirdly gradle.properties is set to non-release on tag -- you may
want to look
into that for future releases


On Thu, Jan 25, 2018 at 10:59 AM, Jakob Homan  wrote:
> +1 (binding)
> - Sigs/asc look good
> - NOTICE/LICENSE/DISCLAIMER look good
> - Licenses look good
> - Tests succeed
> - Gradle binaries not included
>
> Good work.
> -Jakob
>
> On 24 January 2018 at 13:01, Justin Mclean  wrote:
>> Hi,
>>
>>> Hi, it's been almost 72 hours since the vote was opened.  How many votes do
>>> we need for this to pass?  Can other folks take a look if necessary?
>>
>> I suggest asking your mentor who are IPMC member to vote.
>>
>> Thanks,
>> Justin
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: Apache Policy Quiz

[Roman Shaposhnik]

On Wed, Jan 24, 2018 at 10:27 PM, Nick Kew  wrote:
> On Wed, 2018-01-24 at 23:03 -0600, Greg Stein wrote:
>> Every single question that I answered gave me a "not quite right". Even
>> when it asked if an Apache product can be distributed under Cat-X and I
>> said "No", it said "not quite right".
>
> A veritable triumph.  It has demonstrated that Apache policy
> is to confuse an issue just enough to cause the scholars
> to debate at length how many angels can dance on the pinhead
> of a release.
>
> I'll get me coat.

BEST! COMMENT! EVER!

Thanks,
Roman.

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

Re: Apache Policy Quiz

[Roman Shaposhnik]

On Wed, Jan 24, 2018 at 9:55 PM, Justin Mclean  wrote:
> Hi,
>
>> I got inconsistent results from the same answer out of the same choices on 
>> the same question. It was not clear to me that many of the questions are 
>> “check all that apply”.
>
> I will add that to make it clearer.
>
>> Some of the questions are poorly worded, e.g. something like “can Apache 
>> rely on cat X  software”:
>
> I used that wording as it is used in the legal resolved page. [1] “depend” or 
> “rely on a dependancy” may be better words to use.
>
>> For many of the questions I thought there was a mismatch between my 
>> understanding of Apache policy and any of the possible answers presented, 
>> and I ended up feeling vaguely insulted.
>
> Sorry that was certainly not my intention.

I was holding off on this -- but now I just can't resit. So here it goes:

Surely we are not talking about some kind of an official ASF exam test
here, right?

This is more of a fun quiz that makes people think about certain things which
means that anything goes -- trick questions, silly questions, whatever (not that
I'm making a judgement call on what Justin has there -- just pointing
this out in
general).

In that sense, how could anyone has a "...I ended up feeling vaguely insulted"
is a tad beyond my understanding.

So I guess my only bit of feedback would be this: use this opportunity to make
the test go: "ah well, here's the thing..." when somebody ends up with one
of those "not quite" answers.

Just my 2c.

Thanks,
Roman.

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

Re: [VOTE] Retire Wave

[Roman Shaposhnik]

On Mon, Jan 8, 2018 at 10:56 AM, John D. Ament  wrote:
> All,
>
> This is a call to vote for the retirement of the Wave podling.
>
> The podling has positively voted to retire [1].  I now call upon the IPMC
> to confirm this retirement.
>
> [ ] +1 to retire
> [ ] +/- 0 to retire
> [ ] -1 don't retire because...

+1 (binding)

Thanks,
Roman.

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

Re: [VOTE] Accept ServiceComb into the Apache Incubator

[Roman Shaposhnik]

ga
>>> * github.com/pelletier/go-toml
>>> * github.com/siddontang/go
>>> * github.com/siddontang/ledisdb
>>> * github.com/siddontang/rdb
>>> * github.com/ugorji/go
>>> * github.com/urfave/cli
>>> * github.com/xiang90/probing
>>> * github.com/bgentry/speakeasy
>>> * github.com/ghodss/yaml
>>>
>>> BSD 3-Clause
>>> * github.com/beego/x2j
>>> * github.com/belogik/goes
>>> * github.com/cloudflare/golz4
>>> * github.com/edsrzf/mmap-go
>>> * github.com/golang/snappy
>>> * github.com/spf13/pflag
>>> * github.com/widuu/gojson
>>> * golang.org/x/crypto
>>> * golang.org/x/net
>>> * golang.org/x/text
>>> * golang.org/x/time
>>> * gopkg.in/cheggaaa/pb.v1
>>>
>>> BSD 2-Clause
>>> * github.com/gorilla/websocket
>>> * github.com/syndtr/goleveldb
>>>
>>> Apache-2.0
>>> * github.com/bradfitz/gomemcache
>>> * google.golang.org/genproto
>>> * github.com/astaxie/beego
>>> * gopkg.in/yaml.v2
>>> * github.com/cockroachdb/cmux
>>> * github.com/casbin/casbin
>>> * github.com/coreos/etcd
>>> * github.com/coreos/go-semver
>>> * github.com/coreos/go-systemd
>>> * github.com/jonboulle/clockwork
>>> * github.com/prometheus/client_golang
>>> * github.com/prometheus/client_model
>>> * github.com/prometheus/common
>>> * github.com/prometheus/procfs
>>> * github.com/hsluoyz/casbin
>>> * github.com/coreos/pkg
>>> * github.com/garyburd/redigo
>>> * github.com/spf13/cobra
>>> * github.com/google/btree
>>> * github.com/matttproud/golang_protobuf_extensions
>>>
>>> Copyright (c) 2013, The GoGo Authors.
>>> * github.com/gogo/protobuf
>>>
>>> Copyright 2010 The Go Authors.
>>> * github.com/golang/protobuf
>>>
>>> Service-Center Frontend depends on
>>> Open-Source Projects(Organized by License)
>>> MIT:
>>> * angular
>>> * angular-animate
>>> * angular-aria
>>> * angular-material-data-table
>>> * angular-material
>>> * angular-messages
>>> * angular-mocks
>>> * angular-resource
>>> * angular-route
>>> * angular-sanitize
>>> * angular-swagger-ui
>>> * angular-translate-loader-static-files
>>> * angular-translate
>>> * angular-ui-bootstrap
>>> * angular-ui-router
>>> * bootstrap-less-only
>>> * bootstrap-sass-official
>>> * chart.js
>>> * Components-font-awesome
>>> * mmumshad/angular-yamljs
>>> * jeremyfa/yaml.js
>>>
>>> Apache-2.0:
>>> * Json-formatter
>>>
>>> BSD
>>> * Angular-charts.js
>>> * JS Foundation
>>> * jQuery
>>>
>>> == Required Resources ==
>>> === Mailing Lists ===
>>> * priv...@servicecomb.incubator.apache.org (moderated subscriptions)
>>> * comm...@servicecomb.incubator.apache.org
>>> * d...@servicecomb.incubator.apache.org
>>> * iss...@servicecomb.incubator.apache.org
>>>
>>> === Source Control ===
>>> *
>>> https://git-wip-us.apache.org/repos/asf/incubator-servicecomb-java-chassis.git
>>> *
>>> https://git-wip-us.apache.org/repos/asf/incubator-servicecomb-service-center.git
>>> * https://git-wip-us.apache.org/repos/asf/incubator-servicecomb-saga.git
>>> * https://git-wip-us.apache.org/repos/asf/incubator-servicecomb-website.git
>>>
>>> === Issue Tracking ===
>>> JIRA Project ServiceComb
>>>
>>> === Initial Committers ===
>>> * Ning Jiang
>>> * Qi Zhang
>>> * Xiang Yin
>>> * JiMin Wu
>>> * Bao Liu
>>> * Mohammad Asif Siddiqui
>>> * Sukesh A C
>>> * Yihua Cui
>>> * Roman Shaposhnik
>>> * Jean-Baptiste Onofre
>>> * Timothy Chen
>>>
>>> === Additional Interested Contributors ===
>>> * Jian Zhang cos...@gmail.com
>>> * Bing Wang wangbb0...@gmail.com
>>> * Ven Jiang venji...@gmail.com
>>> * GeekTJS josephy...@gmail.com
>>> * Li Zhou eacdy0...@126.com
>>> * Haiwei Zhang haiwei...@foxmail.com
>>> * Yetiea yet...@gmail.com
>>>
>>> === Affiliations ===
>>> * Huawei: Ning Jiang, Qi Zhang, Xiang Yin, JiMin Wu, Bao Liu, Sukesh A C,
>>> Mohammad Asif Siddiqui, Yihua Cui
>>> * Stealth: Roman Shaposhnik
>>> * Talend: Jean-Baptiste Onofré
>>> * Hyperpilot: Timothy Chen
>>>
>>> === Sponsors ===
>>> Champion
>>> * Roman Shaposhnik[r...@apache.org]
>>> Nominated Mentors
>>> * Roman Shaposhnik[r...@apache.org]
>>> * Jean-Baptiste Onofre [jbono...@apache.org]
>>> * Timothy Chen[tnac...@apache.org]
>>>
>>> === Sponsoring Entity ===
>>> * We are requesting the Incubator to sponsor this project.
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
>>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [VOTE] Accept ServiceComb into the Apache Incubator

[Roman Shaposhnik]

ServiceComb.github.io
>
> === Source and Intellectual Property Submission Plan ===
> As soon as ServiceComb is approved to join Apache Incubator, the source
> code will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License, version
> 2.0. We know of no legal encumberments that would inhibit the transfer of
> source code to the ASF.
>
> === External Dependencies ===
>
> 1. ServiceComb java-chassis depends on some Apache projects:
>  * Commons Lang
>  * Commons Codec
>  * httpClient
>  * CXF
>  * Tomcat
>  * Maven
>
> and other open source projects (organized by license)
>
> ALv2:
>  * Netty
>  * Spring
>  * Spring-Boot
>  * Zipkin
>  * brave
>  * protostuff
>  * Jackson
>  * Swagger
>  * vertx
>  * Netflix ribbon
>  * Netflix hystrix
>  * rxjava
>  * Google guava
>  * Google guice
>  * Aspectj
>  * Okhttp
>  * hibernate-validator
>
> MPL:
>  * Javassist
>  * MIT
>  * Mockito
>  * SLF4J
>  * Bridge-method-annotation
>  * EPL 1.0
>  * JUnit
>  * Logback
>
> 2.ServiceComb Saga depends on some Apache projects:
>  * Commons IO
>  * Commons lang
>  * Maven
>
> And other open source projects (organized by license)
> ALv2:
>  * servicecomb-java-chassis
>  * awaitility
>  * kamon
>  * disruptor
>  * rest-assured
>  * wiremock
>  * Aspectj
>
> MPL:
>  * Javassist
>
> MIT:
>  * Mockito
>  * SLF4J
>  * Bridge-method-annotation
>
> EPL 1.0:
>  * JUnit
>  * Logback
>
> As all dependencies are managed using Apache Maven, none of the external
> libraries need to be packaged in a source distribution.
>
> 3.ServiceComb Service-Center depends on
> Open-Source Projects(Organized by License)
> MIT
>  * github.com/Knetic/govaluate
>  * github.com/beorn7/perks
>  * github.com/boltdb/bolt
>  * github.com/couchbase/go-couchbase
>  * github.com/couchbase/gomemcached
>  * github.com/cupcake/rdb
>  * github.com/dustin/go-humanize
>  * github.com/karlseguin/ccache
>  * github.com/kr/pty
>  * github.com/lib/pq
>  * github.com/mattn/go-runewidth
>  * github.com/olekukonko/tablewriter
>  * github.com/onsi/ginkgo
>  * github.com/onsi/gomega
>  * github.com/pelletier/go-toml
>  * github.com/siddontang/go
>  * github.com/siddontang/ledisdb
>  * github.com/siddontang/rdb
>  * github.com/ugorji/go
>  * github.com/urfave/cli
>  * github.com/xiang90/probing
>  * github.com/bgentry/speakeasy
>  * github.com/ghodss/yaml
>
> BSD 3-Clause
>  * github.com/beego/x2j
>  * github.com/belogik/goes
>  * github.com/cloudflare/golz4
>  * github.com/edsrzf/mmap-go
>  * github.com/golang/snappy
>  * github.com/spf13/pflag
>  * github.com/widuu/gojson
>  * golang.org/x/crypto
>  * golang.org/x/net
>  * golang.org/x/text
>  * golang.org/x/time
>  * gopkg.in/cheggaaa/pb.v1
>
> BSD 2-Clause
>  * github.com/gorilla/websocket
>  * github.com/syndtr/goleveldb
>
> Apache-2.0
>  * github.com/bradfitz/gomemcache
>  * google.golang.org/genproto
>  * github.com/astaxie/beego
>  * gopkg.in/yaml.v2
>  * github.com/cockroachdb/cmux
>  * github.com/casbin/casbin
>  * github.com/coreos/etcd
>  * github.com/coreos/go-semver
>  * github.com/coreos/go-systemd
>  * github.com/jonboulle/clockwork
>  * github.com/prometheus/client_golang
>  * github.com/prometheus/client_model
>  * github.com/prometheus/common
>  * github.com/prometheus/procfs
>  * github.com/hsluoyz/casbin
>  * github.com/coreos/pkg
>  * github.com/garyburd/redigo
>  * github.com/spf13/cobra
>  * github.com/google/btree
>  * github.com/matttproud/golang_protobuf_extensions
>
> Copyright (c) 2013, The GoGo Authors.
>  * github.com/gogo/protobuf
>
> Copyright 2010 The Go Authors.
>  * github.com/golang/protobuf
>
> Service-Center Frontend depends on
> Open-Source Projects(Organized by License)
> MIT:
>  * angular
>  * angular-animate
>  * angular-aria
>  * angular-material-data-table
>  * angular-material
>  * angular-messages
>  * angular-mocks
>  * angular-resource
>  * angular-route
>  * angular-sanitize
>  * angular-swagger-ui
>  * angular-translate-loader-static-files
>  * angular-translate
>  * angular-ui-bootstrap
>  * angular-ui-router
>  * bootstrap-less-only
>  * bootstrap-sass-official
>  * chart.js
>  * Components-font-awesome
>  * mmumshad/angular-yamljs
>  * jeremyfa/yaml.js
>
> Apache-2.0:
>  * Json-formatter
>
> BSD
>  * Angular-charts.js
>  * JS Foundation
>  * jQuery
>
> == Required Resources ==
> === Mailing Lists ===
>  * priv...@servicecomb.incubator.apache.org (moderated sub

Re: PPMC voting new committers

[Roman Shaposhnik]

I'm of two minds on this: on one hand, in the beginning of the
incubation process something
like this certainly makes sense. Yet, towards the graduation we should
really encourage
the PPMC to behave more like a TLP PMC.  As such they should have an
option NOT to
follow these somewhat arbitrary rules but instead come up with the
rules of their own
(within the foundation policy and doctrine of course).

Not sure how to reconcile these two aspects.

Thanks,
Roman.

On Fri, Nov 3, 2017 at 10:34 AM, 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
>

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

Re: [VOTE] Accept PageSpeed into the Apache Incubator

[Roman Shaposhnik]

On Wed, Sep 27, 2017 at 12:04 PM, Otto van der Schaaf
 wrote:
> Hi All,
>
> I would like to start a VOTE to bring the PageSpeed project in as an Apache
> incubator
> podling.
>
> The ASF voting rules are described:
>
> 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 PageSpeed into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept PageSpeed into the Apache Incubator because ...

+1 (binding)

Thanks,
Roman.

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

Re: Proper way to retire podlings/madlib.yml

[Roman Shaposhnik]

Ping! I would really like someone to please explain to me the role
these files play.

Thanks,
Roman.

On Tue, Aug 22, 2017 at 8:46 PM, Roman Shaposhnik  wrote:
> On Tue, Aug 22, 2017 at 8:35 PM, John D. Ament  wrote:
>> On Tue, Aug 22, 2017 at 4:13 PM Roman Shaposhnik  wrote:
>>
>>> Hi!
>>>
>>> first of all, I wanted to let y'all know that the MADlib trademark
>>> transferred has finally happened and thus PODLINGNAMESEARCH-125
>>> is now successfully resolved. Thanks to all who helped in the process!
>>>
>>> This, in turn, made me go back to Incubator website to clean up
>>> a few things for MADlib. I think we're good, but I've noticed this:
>>>./content/podlings/madlib.yml
>>> which I don't quite know how to "retire". Do I just remove it?
>>>
>>
>> You shouldn't need to do anything with this file.
>
> That's good to hear. Still, please elaborate what are the expectation
> for these files. Who/when creates them? Who/when deletes or
> moves  them?
>
> Thanks,
> Roman.

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

Re: Proper way to retire podlings/madlib.yml

[Roman Shaposhnik]

On Tue, Aug 22, 2017 at 8:35 PM, John D. Ament  wrote:
> On Tue, Aug 22, 2017 at 4:13 PM Roman Shaposhnik  wrote:
>
>> Hi!
>>
>> first of all, I wanted to let y'all know that the MADlib trademark
>> transferred has finally happened and thus PODLINGNAMESEARCH-125
>> is now successfully resolved. Thanks to all who helped in the process!
>>
>> This, in turn, made me go back to Incubator website to clean up
>> a few things for MADlib. I think we're good, but I've noticed this:
>>./content/podlings/madlib.yml
>> which I don't quite know how to "retire". Do I just remove it?
>>
>
> You shouldn't need to do anything with this file.

That's good to hear. Still, please elaborate what are the expectation
for these files. Who/when creates them? Who/when deletes or
moves  them?

Thanks,
Roman.

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

Proper way to retire podlings/madlib.yml

[Roman Shaposhnik]

Hi!

first of all, I wanted to let y'all know that the MADlib trademark
transferred has finally happened and thus PODLINGNAMESEARCH-125
is now successfully resolved. Thanks to all who helped in the process!

This, in turn, made me go back to Incubator website to clean up
a few things for MADlib. I think we're good, but I've noticed this:
   ./content/podlings/madlib.yml
which I don't quite know how to "retire". Do I just remove it?

Thanks,
Roman.

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

Re: Urgent: Regarding Java package name change to org.apache.*

[Roman Shaposhnik]

On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament  wrote:
> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
> wrote:
>
>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:
>> > Hi all,
>> >
>> > In regards to the recently incubated project - Gobblin, we were wondering
>> > about the policy around renaming Java package names to org.apache.* Is
>> it a
>> > mandatory requirement or good to have?
>> >
>> > The reason to ask this is that while we see many projects have migrated
>> to
>> > use org.apache.* package name for their Java source files, the Kafka
>> > project uses kafka.* for Scala sources and org.apache.kafka.* for Java
>> > sources.
>> >
>> > Please let us know as soon as possible, because we are in process of
>> > renaming the  packages but if not mandatory we would want to keep
>> gobblin.*
>> > package name and avoid the cost of downstream migrations and backwards
>> > incompatibility.
>>
>> You don't have to do it right away, but it is a requirement unless you
>> have a really,
>> really, really good reason of why you can't do that.
>>
>>
> I'm not aware of any requirement around Java package naming.  IN fact, last
> time it came up it was clear that its a best practice only, and doesn't
> have any actual naming requirements.

I'm not a policy wonk, but for every single podling I've witnessed this
has been a very strong bias to be in o.a namespace.

Speaking as an IPMC member I would like to see new projects migrate
into o.a namespace unless there's a really good reason not to.

Or to put it another way, if you want to avoid threads like this one:
   http://markmail.org/message/2bsrtgckuuihhnv4
during your graduation VOTE -- it is better to think about rename now.

Thanks,
Roman.

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

Re: Urgent: Regarding Java package name change to org.apache.*

[Roman Shaposhnik]

On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:
> Hi all,
>
> In regards to the recently incubated project - Gobblin, we were wondering
> about the policy around renaming Java package names to org.apache.* Is it a
> mandatory requirement or good to have?
>
> The reason to ask this is that while we see many projects have migrated to
> use org.apache.* package name for their Java source files, the Kafka
> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
> sources.
>
> Please let us know as soon as possible, because we are in process of
> renaming the  packages but if not mandatory we would want to keep gobblin.*
> package name and avoid the cost of downstream migrations and backwards
> incompatibility.

You don't have to do it right away, but it is a requirement unless you
have a really,
really, really good reason of why you can't do that.

Or to put it a different way: during your eventual graduation this
question will be
asked and you better have a really, really good explanation if you're
still using
something other than o.a.

Thanks,
Roman.

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

Re: Hawq trademarks?

[Roman Shaposhnik]

This one is on my plate -- but the entire plate is on hold while I'm
on vacation.

I don't think I can assign podling name search JIRA to myself, but if anybody
here can -- feel free to do that since that's the honest thruth ATM.

Thanks,
Roman.

On Fri, Jul 14, 2017 at 12:31 AM, Ted Dunning  wrote:
> I meant this for incubator, but I think I should have meant it for the
> podling list.
>
> Pushing general@ to bcc and adding the podling list.
>
>
> On Thu, Jul 13, 2017 at 1:49 PM, John D. Ament 
> wrote:
>
>> Ted,
>>
>> Was this for the hawq list or the incubator list?  It appears that there is
>> an open PNS https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-83
>>
>> John
>>
>> On Thu, Jul 13, 2017 at 4:46 PM Ted Dunning  wrote:
>>
>> > We had a recent problem with Madlib graduating due to lack of progress on
>> > trademark assignment.
>> >
>> > I suspect that Hawq will find itself in the same situation as it gets
>> > closer to graduation.
>> >
>> > What is the situation with the Hawq trademark? Has the transfer process
>> > been started?
>> >
>> > http://www.trademarkia.com/hawq-86117685.html
>> >
>>

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

I'll have very sporadic email connectivity for the next 3 weeks

[Roman Shaposhnik]

Hi!

just a quick note that I'll have very sporadic email connectivity
for the next 3 weeks. This pretty much means that all the email
to the lists will go unnoticed until end of July. If there's something
urgent you can try emailing me directly, but no guarantees.

See y'all back in Aug!

Thanks,
Roman.

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

Re: [VOTE]: Apache HAWQ 2.2.0.0-incubating Release

[Roman Shaposhnik]

On Sat, Jul 1, 2017 at 6:37 PM, Ruilong Huo  wrote:
> Hi IPMC member,
>
>
> The PPMC vote for the Apache HAWQ 2.2.0.0-incubating release has passed. We 
> kindly request that the IPMC now vote on the release.
>
>
> The PPMC vote thread is located here:
> https://lists.apache.org/thread.html/ee0b81127e75eb2562e91b0a44d56b24165c6284a7a46dc03eeb7d6d@%3Cdev.hawq.apache.org%3E
>
>
> The artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.2.0.0-incubating.RC3/
>
>
> The artifacts have been signed with Key : 1B8B6872
>
>
> All JIRAs completed for this release are tagged with 'FixVersion = 
> 2.2.0.0-incubating'. You can view them here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318826&version=12339641
>
>
> Please vote accordingly:
> [ ] +1, accept as the official Apache HAWQ 2.2.0.0-incubating release
> [ ] -1, do not accept as the official Apache HAWQ 2.2.0.0-incubating release 
> because...

I'm +1 on the release with one caveat: it seems that pxf RPMs don't
deliver LICENSE/NOTICE/DISCLAIMER.
inside of the RPMs. Normally that would be enough for me to cast a -1,
but it seems that the JARs inside
of the RPMs (and these RPMs deliver JARs only) actually bundle the
required files.

My take it is that we shouldn't hold a release for that -- but I'll
let the rest of IPMC chime in.

The rest looks really good:
   * checked sigs and hashes
   * compared source tarball to the git tag
   * checked for license headers in the source
   * installed the RPMs

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 11:51 PM, Bertrand Delacretaz
 wrote:
> On Fri, Jun 9, 2017 at 7:15 AM, Greg Stein  wrote:
>>... Do no evil...
>
> Of course. As long as everybody agrees on the definition of "evil" ;-)
>
> Hence my proposal to briefly document best practices about how to
> collect user data in a non-evil way.
>
> Maybe adding a few notes to
> https://issues.apache.org/jira/browse/IGNITE-5413 about what infra has
> been doing to fix the current issue is sufficient, so that we can
> point to that later if similar cases arise.

There's also this:
https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14513325&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14513325

which I find very intriguing.

But I've got to say -- we need INFRA (Greg?) to tell us what they are
and what they are NOT
willing to do to enable something like that.

If the default is not much -- I think we have no choice but to say
that since ASF can't
provide the infrastructure to reliable and securely collect user data
project that publish
convenience binaries off of Apache Infra shouldn't do that.

Which basically gets me to the list I was proposing we clean up and
add to the policy:

So far it seems that there's an agreement on that having this type of
capability...
   1 ... in the source code disabled by default -- totally OK
   2 ... in the source code enabled by default -- questionable, but OK
   3 ... in the binary hosted by ASF disabled by default -- OK
   4 ... in the binary hosted by ASF enabled by default -- NOT OK

Thanks,
Roman.

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

Re: [RESULT][VOTE] Graduate Apache MADlib podling

[Roman Shaposhnik]

On Sat, Jun 10, 2017 at 11:59 AM, John D. Ament  wrote:
> Please don't forget to get this resolution up on the board's agenda.

Thanks for the reminder. This is for me to do over the weekend.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 10:15 PM, Greg Stein  wrote:
> I recall a company that started to list out each of things NOT to do. Item
> after item after item, to develop a policy. After a few dozen such, one guy
> piped up, "this is ridiculous" ... It just isn't tractable. So he suggested
> a simple replacement:
>
> Do no evil.

Should we add that to our release policy? Will VP Legal go along with that?

Seriously, on one hand I see folks saying here that clarfiying what is and isn't
acceptable is useful. On the other hand, I see your reaction that can only
be described as "duh! what policy -- its just common sense".

I actually do not think it is common sense anymore -- I do think it needs to be
documented.

However, this won't be the first time when what I feel passionate about is
ignored by the "official ASF" -- not a biggie -- you guys are the bosses. I just
need to learn to care less.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 12:43 AM, Bertrand Delacretaz
 wrote:
> On Wed, Jun 7, 2017 at 5:32 PM, Sean Busbey  wrote:
>> ...Who owns release policy? I presume it's VP Legal, which would suggest 
>> legal-discuss...
>
> I don't think our release policy is relevant here.

Actually, that's what I'm trying to figure out. My initial thought around why
release policy was relevant here was that THE ONLY reason we reacted
the way we did is because there was a piece of software associated with
ASF in two ways:
   1. branding
   2. distribution off of ASF infrastructure

It sounds like you're saying that #1 is actually more important that #2. I may
buy that, but let me ask you a hypothetical first. Suppose releases of Ingite
were only done as source tarballs. Suppose also that the company called
GridGain built it and made the binary available off of their website with
the binary (and associated branding) saying Apache Ignite.

Would we still have a problem if that binary did what Ignite's binary did?

> The issue is a project releasing software that a) collects user data
> without an explicit opt-in, and b) apparently does that in an insecure
> way.

I'm not concerned about b -- so lets cut it out of the discussion.

> a) is a privacy violation - we have
> https://www.apache.org/foundation/policies/privacy.html for that, I
> suggest that we simply expand it with a "collecting user data"
> section. As Shane mentions
> https://wiki.openoffice.org/wiki/Update_Service is related.

Well, but what does that policy apply to? A source release? A binary
release? A binary release off of ASF infrastructure?

Please be specific.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Wed, Jun 7, 2017 at 1:26 PM, Shane Curcuru  wrote:
> Roman Shaposhnik wrote on 6/7/17 4:20 PM:
>> On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas  wrote:
>>> On 07/06/17 17:53, Roman Shaposhnik wrote:
>>>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
>>>>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  
>>>>> wrote:
>>>>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
>>>>>> wrote:
>>>>>>> While these are all great discussion points, I don't believe they're
>>>>>>> relevant to incubator only and probably should have remained on the
>>>>>>> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator 
>>>>>>> probably
>>>>>>> doesn't have an opinion about this, but it's good to know that the 
>>>>>>> policy
>>>>>>> may change (and I do personally have an opinion on said types of 
>>>>>>> software).
>>>>>>
>>>>>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>>>>>> with how long
>>>>>> ago Ignite graduated and everything to do with the following two points:
>>>>>>1. It can be very useful to the future podlings
>>>>>>2. I honestly don't know any other forum where I can meaningfully
>>>>>> discuss changes to release policy
>>>>>>
>>>>>> I'll take advice on #2, of course.
>>>>>
>>>>>
>>>>> Who owns release policy? I presume it's VP Legal, which would suggest 
>>>>> legal-discuss.
>>>>
>>>> I would really be surprised if VP Legal actually *owned* it. This
>>>> feels someplace between
>>>> INFRA, ComDev and Legal, but it still doesn't answer the question
>>>> who's a single throat
>>>> to choke.
>>>
>>> Consider yourself surprised then. V.P. Legal owns the release policy.
>>
>> Is legal-discuss then the appropriate forum to actually build the consensus?
>> I surely hope V.P. Legal won't play a BDFL with our release policy, will he?
>
> Huh?

Because last time BDFL tendencies flared up around ASF Legal it was
painful all around.

>  Only the board and specifically authorized officers can set policy
> like the release policy that all PMCs MUST follow.  So yes, VP Legal is
> the final determiner of release policy updates, not anyone else.
>
> legal-discuss@ is the best place to bring any specific requests from
> project(s) to change the actual policy itself.  But first it would be
> useful to get some rough consensus on some of those specific requests
> here from the IPMC or from ComDev.

That was my very question: what is the right forum. You could've just answered
that. So it is IPMC, ComDev, both?

Seriously WHERE do I have to move this thread to?

> Note that ComDev is a PMC itself, and has no authority to set *policy*
> for other PMCs.  But they do provide a lot of good docs and best
> practices, and dev@community is becoming quite a good cross-project
> discussion area, so it's a good place to get other feedback on a proposal.

Sure. We all know that.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas  wrote:
> On 07/06/17 17:53, Roman Shaposhnik wrote:
>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
>>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
>>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
>>>> wrote:
>>>>> While these are all great discussion points, I don't believe they're
>>>>> relevant to incubator only and probably should have remained on the
>>>>> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator 
>>>>> probably
>>>>> doesn't have an opinion about this, but it's good to know that the policy
>>>>> may change (and I do personally have an opinion on said types of 
>>>>> software).
>>>>
>>>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>>>> with how long
>>>> ago Ignite graduated and everything to do with the following two points:
>>>>1. It can be very useful to the future podlings
>>>>2. I honestly don't know any other forum where I can meaningfully
>>>> discuss changes to release policy
>>>>
>>>> I'll take advice on #2, of course.
>>>
>>>
>>> Who owns release policy? I presume it's VP Legal, which would suggest 
>>> legal-discuss.
>>
>> I would really be surprised if VP Legal actually *owned* it. This
>> feels someplace between
>> INFRA, ComDev and Legal, but it still doesn't answer the question
>> who's a single throat
>> to choke.
>
> Consider yourself surprised then. V.P. Legal owns the release policy.

Is legal-discuss then the appropriate forum to actually build the consensus?
I surely hope V.P. Legal won't play a BDFL with our release policy, will he?

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  wrote:
>> > While these are all great discussion points, I don't believe they're
>> > relevant to incubator only and probably should have remained on the
>> > legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
>> > doesn't have an opinion about this, but it's good to know that the policy
>> > may change (and I do personally have an opinion on said types of software).
>>
>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>> with how long
>> ago Ignite graduated and everything to do with the following two points:
>>1. It can be very useful to the future podlings
>>2. I honestly don't know any other forum where I can meaningfully
>> discuss changes to release policy
>>
>> I'll take advice on #2, of course.
>
>
> Who owns release policy? I presume it's VP Legal, which would suggest 
> legal-discuss.

I would really be surprised if VP Legal actually *owned* it. This
feels someplace between
INFRA, ComDev and Legal, but it still doesn't answer the question
who's a single throat
to choke.

Thanks,
Roman.

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

Re: [VOTE] Graduate Apache Mynewt podling

[Roman Shaposhnik]

On Tue, Jun 6, 2017 at 10:52 AM, aditi hilbert  wrote:
> Hello IPMC,
>
> We have had the discussion thread for the graduation of Apache Mynewt podling
> to TLP open for >72 hours. All the issues raised there have been addressed.
> I propose that we graduate Apache Mynewt from the incubator.
> The full text of the proposal is below. The [DISCUSS] thread is:
> https://lists.apache.org/thread.html/8d8b40b5de2cff4fca1b300870bcf1f5b5ac92b2e4b2a8ddf2db3e17@%3Cgeneral.incubator.apache.org%3E
>
> Please vote on the resolution:
>
> [ ] +1 Graduate Apache Mynewt from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Mynewt from the Incubator (please provide
> the reason)

+1 (binding)

Thanks,
Roman.

> This VOTE will be opened for the next 72 hours.
>
> Thanks to all Mentors and Apache Mynewt Project members for their
> support and contributions.
>
> Thanks,
> Aditi
>
> ---
>
> Resolution:
>
> Establish the Apache Mynewt Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of software related to
> an embedded OS optimized for networking and built for remote management
> of constrained devices that are incapable of running either Linux or Android.
>
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Mynewt Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Mynewt Project be and hereby is
> responsible for the creation and maintenance of software
> related to an embedded OS optimized for networking and built
> for remote management of constrained devices that are incapable of
> running either Linux or Android.
>
> RESOLVED, that the office of "Vice President, Apache Mynewt" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Mynewt Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Mynewt Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Mynewt Project:
> *Justin Mclean” 
> P. Taylor Goetz” ,
> Greg Stein ,
> Jim Jagielski ,
> Sterling Hughes ,
> Marko Kiiskila ,
> will sanfilippo ,
> Christopher Collins ,
> Vipul Rahane ,
> Fabio Utzig ,
> Andrzej Kaczmarek ,
> Michał Narajowski ,
> Szymon Janc ,
> Łukasz Rymanowski ,
> Neel Natu ,
> Peter Snyder ,
> Paul Dietrich  Julian Ingram ,
> Kevin Townsend ,
> Aditi Hilbert 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Justin Mclean
> be appointed to the office of Vice President, Apache Mynewt, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Mynewt PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Mynewt Project; and be it further
>
> RESOLVED, that the Apache Mynewt Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Mynewt podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Mynewt podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
> -
> 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: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  wrote:
> While these are all great discussion points, I don't believe they're
> relevant to incubator only and probably should have remained on the
> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> doesn't have an opinion about this, but it's good to know that the policy
> may change (and I do personally have an opinion on said types of software).

The reason I'm bringing it on the IPMC mailing list has nothing to do
with how long
ago Ignite graduated and everything to do with the following two points:
   1. It can be very useful to the future podlings
   2. I honestly don't know any other forum where I can meaningfully
discuss changes to release policy

I'll take advice on #2, of course.

Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
> Thanks for the explanation, Roman. I had no idea that policies for hosted 
> binaries
> were stricter than for source code (other than the obvious effect on 
> licensing when you bundle in dependencies).

Btw, this one is serious enough that I'd like us to update our release
policy based on the
learnings here.

So far it seems that there's an agreement on that having this type of
capability...
   1 ... in the source code disabled by default -- totally OK
   2 ... in the source code enabled by default -- questionable, but OK
   3 ... in the binary hosted by ASF disabled by default -- OK
   4 ... in the binary hosted by ASF enabled by default -- NOT OK

#4 can get nuanced if we want to invest in ASF managed infrastructure that is
responsible for update tracking and user data collection. With my ASF hat on,
I'd say that INFRA should probably stay away from user data
collection/retention.

That still leaves a possibility of a a ping/pong API that only
consumes a name of ASF
project and its version and returns a JSON object of some kind as per
PMC choice.


Thanks,
Roman.

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  wrote:
> If the binaries are built from the released source code I don’t think we 
> should restrict what the binaries do.

Well, but that's not how we treat licensing for example. For example
-- there's plenty of ASF project that
allow GPL licensed extension to be pulled into the build. That
mechanics is part of the source code. However,
as per our policy, we will not allow this kind of a convenience binary
(containing GPL bits) to be hosted by
ASF infrastructure.

Now, there's nothing wrong with those kinds of binaries -- and 3d
parties host them all the time -- its just that
WE at ASF decided that it wouldn't be aligned with what we do.

What I'm concerned about is that a combination of binaries hosted by
ASF and a lack of opt-in AND an unsecure
nature of the communication AND unclear data handling policies can
potential make ASF liable if this kind of
data ends up containing sensitive information and gets exploited.

IANAL, but I could see EU being especially strict here.

> The question is whether the community is aware of what the code is doing, and 
> considers it to be in the best interests of the project.
>
> The answer seems to be yes, and yes. I saw that the issue was discussed on 
> dev@ignite[1], and had a corresponding JIRA case[2],

As for the discussion on JIRA, I expected the podling to listen to the
advice given by one of the mentors:
   
https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
but apparently that never happened.

Thanks,
Roman.

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

ASF hosted binaries collecting user data without an explicit opt-in

[Roman Shaposhnik]

Hi!

after seeing this thread on legal-discuss:

https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E

I'd like to ask a policy related question.

What we currently have is a whole bunch of binaries hosted
by ASF: https://ignite.apache.org/download.cgi#binaries that
collect user data and ship it away to a host currently not
associated with ASF (nor does it seem to be associated with
Ignite's PMC). The host name is ignite.run (and, as a side note,
as it turns out the connection to that host in Ignite releases prior
to 1.9 is unsecure:
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
)

Is this something ASF should be concerned with from a standpoint
of the policy that we have for binary convenience artifacts that are
hosted on our end?

Would it make it different if ignite.run and the data collected
by it was managed by an Ignite PMC as opposed to an unidentified
3d party?

Thanks,
Roman.

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

Re: [RESULT][VOTE] Graduate Apache MADlib podling

[Roman Shaposhnik]

Super awesome news! Major milestone for the MADlib community!

With my mentor hat on, I'll start driving the rest of the graduation
process soon:
http://incubator.apache.org/guides/graduation.html#process

Stay tuned!

Thanks,
Roman.

On Tue, May 30, 2017 at 7:39 PM, FENG, Xixuan (Aaron)
 wrote:
> With 5 +1 binding votes, 2 +1 non-bidning votes and 0 votes
> of any other kind this vote PASSES. Thanks to everyone who
> voted. The voting tally can be seen below:
>
> +1 binding:
> John D. Ament
> Jim Jagielski
>     P. Taylor Goetz
> Roman Shaposhnik
> Konstantin Boudnik
>
> +1 non-binding:
> Pierre Smits
> Gregory Chase
>
> Thanks!
>
> --
> FENG, Xixuan (Aaron)
>
> Recruit Institute of Technology
> http://www.recruit.ai/
>
> Recruit Holdings
> http://www.recruit-rgf.com/
>
> Tel. +81-70-1402-6921 <+81%2070-1402-6921>
> http://www.recruit.ai/aaron-feng
>
>
> On Wed, May 31, 2017 at 10:14 AM, Gregory Chase  wrote:
>
>> +1 (loiterer)
>>
>> On Tue, May 30, 2017 at 6:09 PM, Konstantin Boudnik 
>> wrote:
>>
>> > +1 [binding]
>> >
>> > On Sat, May 27, 2017 at 04:56PM, FENG, Xixuan (Aaron) wrote:
>> > > Greetings IPMC!
>> > >
>> > > The discussion seems to have died down, so I'm calling the
>> > > vote:  I propose that we graduate Apache MADlib from the Incubator.
>> > > The full text of the proposal is below.  The discuss thread can be
>> found
>> > > here:
>> > > https://lists.apache.org/thread.html/535f9871636f6e10c13e47
>> f1ec6e41
>> > > 5eca7f666e1580d8b762d8a42d@%3Cgeneral.incubator.apache.org%3E
>> > >
>> > > Please vote on the resolution:
>> > >
>> > > [ ] +1 Graduate Apache MADlib from the Incubator.
>> > > [ ] +0 No opinion
>> > > [ ] -1 Don't graduate Apache MADlib from the Incubator (please provide
>> > > the reason)
>> > >
>> > > This VOTE will be opened for the next 72 hours.
>> > >
>> > > Thanks to all Mentors and Apache MADlib Project members for their
>> > > support and contributions.
>> > >
>> > > Thanks,
>> > > Aaron.
>> > >
>> > > Resolution:
>> > >
>> > > Establish the Apache MADlib Project
>> > >
>> > > WHEREAS, the Board of Directors deems it to be in the best
>> > > interests of the Foundation and consistent with the
>> > > Foundation's purpose to establish a Project Management
>> > > Committee charged with the creation and maintenance of
>> > > open-source software, for distribution at no charge to the
>> > > public, related to a scalable, Big Data, SQL-driven machine
>> > > learning framework for Data Scientists.
>> > >
>> > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>> > > Committee (PMC), to be known as the "Apache MADlib Project",
>> > > be and hereby is established pursuant to Bylaws of the
>> > > Foundation; and be it further
>> > >
>> > > RESOLVED, that the Apache MADlib Project be and hereby is
>> > > responsible for the creation and maintenance of software
>> > > related to a scalable, Big Data, SQL-driven machine
>> > > learning framework for Data Scientists.
>> > >
>> > > RESOLVED, that the office of "Vice President, Apache MADlib" be
>> > > and hereby is created, the person holding such office to
>> > > serve at the direction of the Board of Directors as the chair
>> > > of the Apache MADlib Project, and to have primary responsibility
>> > > for management of the projects within the scope of
>> > > responsibility of the Apache MADlib Project; and be it further
>> > >
>> > > RESOLVED, that the persons listed immediately below be and
>> > > hereby are appointed to serve as the initial members of the
>> > > Apache MADlib Project:
>> > >
>> > > Sarah Aerni 
>> > > Greg Chase 
>> > > Aaron Feng 
>> > > Rahul Iyer 
>> > > Jim Jagielski 
>> > > Nandish Jayaram 
>> > > Anirudh Kondaveeti 
>> > > Orhan Kışlal 
>> > > Frank McQuillan 
>> > > Srivatsan R 
>> > > Rashmi Raghu 
>> > > Roman Shaposhnik 
>> > > Atri Sharma 
>> > >
>> > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Aaron 

Re: [VOTE] Graduate Apache MADlib podling

[Roman Shaposhnik]

On Sat, May 27, 2017 at 12:56 AM, FENG, Xixuan (Aaron)
 wrote:
> Greetings IPMC!
>
> The discussion seems to have died down, so I'm calling the
> vote:  I propose that we graduate Apache MADlib from the Incubator.
> The full text of the proposal is below.  The discuss thread can be found
> here:
> https://lists.apache.org/thread.html/535f9871636f6e10c13e47f1ec6e41
> 5eca7f666e1580d8b762d8a42d@%3Cgeneral.incubator.apache.org%3E
>
> Please vote on the resolution:
>
> [ ] +1 Graduate Apache MADlib from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache MADlib from the Incubator (please provide
> the reason)

+1 (binding)

Thanks,
Roman.

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

Re: Good examples of licensing in ASF produced web apps?

[Roman Shaposhnik]

On Fri, May 26, 2017 at 4:37 PM, John D. Ament  wrote:
> I'll point out that Ranger graduated the incubator with a less than stellar
> release history.  [1] is a good example of such problems
>
> Oozie predates me.
>
> But to answer the original question, no, the requirements shouldn't be any
> less stringent on WAR files vs other packages, its a closed package that is
> hard to look at and needs to indicate everything within it.  While both of
> these projects were incubating, they are no longer incubating and you
> should follow up with them directly if you want them to fix their licensing.

I do -- but that gets me back to my original question -- what example
can I give them?

Seriously -- at this point -- I'm about to go to Maven central and
search for org.apache.*
artifacts with war as packaging and see what comes up in terms of
recent releases.

However, if somebody can spare me this agony -- I'd appreciate it ;-)

Thanks,
Roman.

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

Re: Good examples of licensing in ASF produced web apps?

[Roman Shaposhnik]

On Fri, May 26, 2017 at 2:52 PM, Tom Barber  wrote:
> I don't have any examples, but I don't know of any webapps that don't
> bundle dependencies otherwise users are forced to install all the
> dependencies by hand into tomcat/common or something. Whether they
> dependencies are ASF compatible or not I don't know, but from the peanut
> gallery that sounds completely normal.

Well my podling doesn't -- they manipulate TC classpath to find extra
dependencies.

But that's actually not important -- you're right bundling
dependencies is OK, but
doing that makes it even more important to do proper LICENSE and NOTICE.

The examples I see in Ooize and Ranger are pretty shockingly not doing any of
that.

Thanks,
Roman.

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

Good examples of licensing in ASF produced web apps?

[Roman Shaposhnik]

Hi!

I advising a podling on producing a binary release that
includes a Java web app (think war file). I wanted to give
them a taste of what TLPs do so I went to the ones that
I knew were generating war files: Oozie and Ranger.
You know the stuff I'm familiar with in Hadoop ecosystem.

What he discovered may shock you! No, but seriously.

Here's what these projects publish on Maven central:

https://search.maven.org/remotecontent?filepath=org/apache/oozie/oozie-webapp/4.3.0/oozie-webapp-4.3.0.war
https://search.maven.org/remotecontent?filepath=org/apache/ranger/security-admin-web/0.7.0/security-admin-web-0.7.0.war

Each of these WAR files:
   1. bundles all sorts of dependancies -- not just the bits coming
from the project itself

2. Neither provides a meanigful LICENSE nor NOTICE files.
The ones under ./WEB-INF/classes/META-INF are stock ones
and really don't address the binary dependencies bundling

Have we somehow relaxed the requirements for binary artifacts?
I hope not -- and if not -- what are the good examples of web app
projects doing it right?

Thanks,
Roman.

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

Re: [DISCUSS] Apache MADlib podling graduation

[Roman Shaposhnik]

On Wed, May 24, 2017 at 5:13 AM, Jim Jagielski  wrote:
> +1
> (if you would like another PMC member to join to help w/
> the transition and post-graduation community hurdles, I volunteer).

Would love to have you on board Jim!

Thanks,
Roman.

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

Re: [DISCUSS] Apache MADlib podling graduation

[Roman Shaposhnik]

On Tue, May 23, 2017 at 3:19 AM, John D. Ament  wrote:
> What does the (*) on Recruit Holdings mean?

Affiliation of the proposed Chair.

Thanks,
Roman.

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

Re: [DISCUSS] Apache MADlib podling graduation

[Roman Shaposhnik]

On Tue, May 23, 2017 at 3:27 AM, sebb  wrote:
> On 23 May 2017 at 07:24, Roman Shaposhnik  wrote:
>> Hi!
>>
>> with my mentor hat on, I wanted to kick off this discussion
>> thread on the basis of a general consensus in the MADlib
>> community that it is time for the project to consider a TLP
>> status: http://markmail.org/thread/mgjzwjjriqjrfsix
>>
>> Apache MADlib entered incubation on Sept. 15, 2015.  Since
>> that time we have made 5 releases, added 3 committers and
>> are actively pursuing other committers.  We have extensive
>> user documentation, an up-to-date wiki and an informative
>> web page.  We are a very helpful and engaged community,
>> ready to answer all questions and feedback via the dev and
>> user mailing lists.  We have learned much about the Apache Way
>> as a result of being an incubating project, and have incorporated
>> the guidance that we have been given by our mentors and others.
>> As part of that learning process we've learned a great deal about
>> ASF's approach to IP and have resolved MADlib licensing concerns
>> stemming from its BSD licensed past LEGAL-293.  While we plan
>> to continue to develop as a community, we do not feel that remaining
>> as an incubating project is a prerequisite for this development.
>>
>
> The website looks very nice.
>
> However there are some problems with the download page.
>
> The links all appear to point to
>
> https://dist.apache.org/repos/dist/release/incubator/madlib/
>
> This is not allowed; download links for current releases must point to
> the ASF mirror system.
>
> The dist release directory has not been tidied up; only the latest
> release(s) should be present on the mirror system.
> It's unfair on the 3rd party mirrors to expect them to carry old releases.
>
> There is no information on the download page how to check sigs or
> hashes, and no link to the KEYS file.
> KEYS, sigs and hashes should be linked from the following tree
> https://www.apache.org/dist/incubator/madlib/

Great feedback. Filed https://issues.apache.org/jira/browse/MADLIB-1108 and
will provide a fix ASAP.

> IMO this needs to be fixed before graduation.
> Also the project docs may need updating to ensure RMs remove old
> releases after a new one has bee published.

Yup. That too.

Thanks,
Roman.

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

[DISCUSS] Apache MADlib podling graduation

[Roman Shaposhnik]

Hi!

with my mentor hat on, I wanted to kick off this discussion
thread on the basis of a general consensus in the MADlib
community that it is time for the project to consider a TLP
status: http://markmail.org/thread/mgjzwjjriqjrfsix

Apache MADlib entered incubation on Sept. 15, 2015.  Since
that time we have made 5 releases, added 3 committers and
are actively pursuing other committers.  We have extensive
user documentation, an up-to-date wiki and an informative
web page.  We are a very helpful and engaged community,
ready to answer all questions and feedback via the dev and
user mailing lists.  We have learned much about the Apache Way
as a result of being an incubating project, and have incorporated
the guidance that we have been given by our mentors and others.
As part of that learning process we've learned a great deal about
ASF's approach to IP and have resolved MADlib licensing concerns
stemming from its BSD licensed past LEGAL-293.  While we plan
to continue to develop as a community, we do not feel that remaining
as an incubating project is a prerequisite for this development.

To inform the discussion, some project information is listed below:

Project status:
http://incubator.apache.org/projects/madlib.html

Project website:
http://madlib.incubator.apache.org/

User documentation:
http://madlib.incubator.apache.org/docs/latest/index.html

Wiki:
https://cwiki.apache.org/confluence/display/MADLIB

Github mirror:
https://github.com/apache/incubator-madlib

JIRA:
https://issues.apache.org/jira/browse/MADLIB/

Maturity assessment:
https://cwiki.apache.org/confluence/display/MADLIB/ASF+Maturity+Evaluation

DRAFT of the board resolution can be found at the bottom of this email.

Proposed PMC size: 12 members

Total number of committers: 12 members

PMC affiliation ( * indicated chair):

Pivotal:
  - Greg Chase
  - Rahul Iyer
  - Nandish Jayaram
  - Orhan Kışlal
  - Anirudh Kondaveeti
  - Frank McQuillan
  - Rashmi Raghu
  - Roman Shaposhnik

Salesforce:
  - Sarah Aerni
  - Srivatsan R

Recruit Holdings:
  - (*) Aaron Feng

Microsoft:
  - Atri Sharma

Here are some project statistics for the period between when Apache
MADlib entered incubation on Sept. 15, 2015 and the present:

over 200 commits on master
120 closed PR’s on GitHub
16 unique contributors on master

186 issues created
126 issues resolved

dev list averaged ~81 msgs/month over last 12 months
user list averaged ~22 msgs/month over last 12 months

Resolution:

Establish the Apache MADlib Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software, for distribution at no charge to the
public, related to a scalable, Big Data, SQL-driven machine
learning framework for Data Scientists.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache MADlib Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache MADlib Project be and hereby is
responsible for the creation and maintenance of software
related to a scalable, Big Data, SQL-driven machine
learning framework for Data Scientists.

RESOLVED, that the office of "Vice President, Apache MADlib" be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache MADlib Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache MADlib Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache MADlib Project:

Sarah Aerni 
Greg Chase 
Aaron Feng 
Rahul Iyer 
Nandish Jayaram 
Anirudh Kondaveeti 
Orhan Kışlal 
Frank McQuillan 
Srivatsan R 
Rashmi Raghu 
Roman Shaposhnik 
Atri Sharma 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Aaron Feng
be appointed to the office of Vice President, Apache MADlib, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further

RESOLVED, that the initial Apache MADlib PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache MADlib Project; and be it further

RESOLVED, that the Apache MADlib Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator MADlib podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator MADlib podling encumbered upon the Apache Incubator
Project are hereafter discharged.

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Roman Shaposhnik]

On Mon, May 22, 2017 at 1:04 PM, Craig Russell  wrote:
> Hi Niclas,
>
>> On May 22, 2017, at 12:05 AM, Niclas Hedhman  wrote:
>>
>> Originally, the IP Clearance was intended for "block contributions" larger
>> than suitable for a Jira patch file, and from people outside the community.
>> For example, it could be code that was made at SourceForge and IP Clearance
>> was to make sure that the the OK/interest of the authors was recorded (via
>> ICLAs, IIRC).
>>
>> In this case, it seems that the author is on the PM, have an ICLA on file,
>> the work is part of the same commit tree, so I see no reason for the ASF to
>> doubt that he had the permission from the company to commit/push.
>
> My understanding is that the code under review here was developed outside 
> Apache and is larger than suitable for a JIRA patch.
>
> So it is precisely the situation for which IP Clearance is intended.

That's 100% correct!

Thanks,
Roman.

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

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Roman Shaposhnik]

On Sun, May 21, 2017 at 2:02 PM, John D. Ament  wrote:
> On Sun, May 21, 2017 at 4:54 PM Craig Russell  wrote:
>
>> Hi John,
>>
>> I don't know all of the details of the code, but this is in regard to
>> GridGain's grant via SGA of a persistent store system which is a
>> substantial body of code not developed at Apache. So IMHO it is appropriate
>> for the code grant to be reviewed.
>>
>>
> Errr... wait a tick.  We've been told a few times that IP Clearance and SGA
> are binary.  You do one or the other, not both.  Specifically SGA is to
> allow the modification of license (from X to Apache-V2.0) whereas IP
> Clearance is verifying that all existing Apache-v2.0 donation is in fact
> properly licensed (e.g. no hidden LGPL or other inappropriate licenses).
> There's even a line in the SGA that puts the ownness on this to the donator.
>
> If GridGain has submitted an SGA then that SGA is what is used.  Have they
> actually submitted an SGA as well?

FWIW: last week I recommended them to do that. Not sure if it was submitted.
That's why I'm so puzzled to see this request here (on top of Ignite being TLP
and not longer having much to do with IPMC).

Thanks,
Roman.

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

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Roman Shaposhnik]

Why is this request showing up on IPMC mailing list?

Thanks,
Roman.

On Sat, May 20, 2017 at 8:42 PM, Denis Magda  wrote:
> Apache Ignite is receiving code for distributed Persistent Store.
>
> See: 
> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
>
> Please vote to approve the donation.
>
> This is a lazy consensus majority vote, open for at least 72 hours.
>
> Regards,
> Denis
>
>
>
> -
> 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

Need a 3d IPMC vote for Apache MADlib (incubating)

[Roman Shaposhnik]

Hi!

any chance somebody from the IPMC can take a look
at the Apache MADlib (incubating) MADlib v1.11-rc3
vote?

Its been going on for quite some time and all we're
missing is a 3d binding vote.

Thanks,
Roman.

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

Re: [VOTE] MADlib v1.11-rc3

[Roman Shaposhnik]

On Wed, May 10, 2017 at 12:44 AM, Rashmi Raghu  wrote:
> Hello Incubator PMC,
>
> The Apache MADlib (incubating) community has voted on and approved the
> proposal to release MADlib v1.11-rc3.
>
> The voting result is available at:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201705.mbox/%3CCAMtNjo%3Dwq0qQmJRTqAnef%2BtuTawXm508pQmLAcvWho0fOfkEmQ%40mail.gmail.com%3E
>
> This will be the 5th release for Apache MADlib (incubating).
>
> The main goals of this release are:
> * new module (PageRank for graph analytics with grouping support included)
> * improvements to existing modules (add grouping support to Single Source
> Shortest Path, reduce memory footprint of DT and RF, include NULL features
> in training DT, add support for array and svec output for Pivot module,
> utility to unnest 2-D arrays into rows of 1-D arrays)
> * platform updates (GPDB 5)
> * updates for Apache Top Level Project readiness and build process on
> Apache infrastructure
> * bug fixes
> * doc improvements
>
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.11
>
> To run check RAT, please do:
>
> $mvn verify
>
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
>
> We're voting upon the source and convenience binaries below:
>
> Source Repository (tag):  rc/1.11-rc3
> https://github.com/apache/incubator-madlib/tree/rc/1.11-rc3
>
> Source Files and convenience Binaries:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.11-incubating-rc3/
>
> Commit:
> https://github.com/apache/incubator-madlib/commit/8e2778a3921aa99f009962756881ce4bea5eee16
>
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
>
> For your convenience, the recent ASF licensing guidance to the MADlib
> community is summarized here:
> https://cwiki.apache.org/confluence/display/MADLIB/ASF+Licensing+Guidance
>
> Please vote:
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)

+1 (binding)

* checked signatures and hashes
* check the KEYS file
* compared content of the archive to tag and git sha
* checked license headers
* checked the binary artifacts for correct licensing statements
* installed binary artifacts

Thanks,
Roman.

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

Re: Podling release vote terminology

[Roman Shaposhnik]

On Tue, May 9, 2017 at 11:00 AM, Craig Russell  wrote:
> I've seen a few (recent) incubator votes that imply that there are two 
> separate, distinct votes:
> one in the podling and one in the incubator general. And lots of questions 
> about binding votes
> and carried-over votes and whose votes are counted.
>
> I'd like to suggest:
>
> There is one vote for a podling release candidate. The first phase of the 
> vote takes place on the podling dev list.
> Anyone can vote. An affirmative vote by three PPMC members (including 
> mentors) is sufficient to start the second
> phase, which takes place on the incubator general list. An individual's vote 
> can be changed any time during either
> phase until the final vote is tallied.
>
> All votes are counted. Only IPMC member votes are binding. The final tally 
> counts affirmative, neutral, and
> negative votes from both phases combined and affirmative, neutral and 
> negative binding votes from both phases
> combined.

I think this talk about distinct phases is confusing, but otherwise I
really like where this is going.

To me -- there are no two distinct phases -- there's just opening up
of an initial vote.

Or to put it another way, I'd like to optimize for a happy path. Which
is: vote goes on
on dev@ and receives 3+ binding votes from IPMC members. At that point I'd like
the vote to be DONE.

Is there a way for us to optimize for that? From where I sit one way to optimize
is simply frontload the process and ALWAYS CC: IPMC on the community votes.

> This terminology answers questions about:
>
> Whether PPMC votes are binding. They are not.
> Whether IPMC member votes on the first phase of voting carry over to the 
> second phase. They do.
> Whether public votes in either phase count. They do.
> Whether public votes in either phase are binding. They are not.
>
> If we agree on the terminology, I'll see what documents need to be updated.

Terminology makes sense.

Thanks,
Roman.

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

Re: Incubator Governance Change

[Roman Shaposhnik]

On Tue, Apr 25, 2017 at 8:47 PM, P. Taylor Goetz  wrote:
>
>> On Apr 25, 2017, at 9:06 PM, Roman Shaposhnik  wrote:
>>
>> I honestly think its time for us to consider being more board like
>> around here at
>> IPMC. May be not exactly as strict as the board, but moving in that 
>> direction.
>>
>> After all, being a podling means being TLP-on-training-wheels. That's the 
>> whole
>> idea. If your PMC shrinks -- you have to know what it means. Same here. If 
>> your
>> mentors are not active -- you've got to raise hell around here on general@
>> before its too late.
>
> I mostly agree, but would hesitate with the idea that a podling be 
> responsible for
> raising a red flag when mentors are inactive. If the IPMC isn’t doing it’s 
> job,
> that’s on us, not the projects we incubate.

I am not saying IPMC is off the hook here, but rather I'm trying to instill
a sense of self-reliance in a future TLP.

While PPMC is mostly an artificial construct from the ASF's point of view,
the idea there is to teach podling how the TLP PMC should behave. One
of the traits of this behaviour is to recognize problems within the community
and try to resolve them instead of semi-passively waiting for either board
or IPMC to intervene.

Again, I'm not advocating for shifting the responsibility as much as
I'm advocating
for shift in perspective. I would still expect the IPMC members to be watchful,
but I would also expect them to use every opportunity like that as a teaching
moment. E.g. "oh, so we've noticed you're struggling with mentors being MIA,
we're sorry about that, but have you considered escalating to IPMC and perhaps
soliciting additional mentors?" instead of "oh, so we've noticed
you're struggling
with mentors being MIA, let us fix this for you" (I'm obviously
exaggerating, but you
catch my drift).

Thanks,
Roman.

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

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sun, Apr 23, 2017 at 4:50 AM, Greg Stein  wrote:
> On Sat, Apr 22, 2017 at 7:46 PM, Roman Shaposhnik 
> wrote:
>>...
>
>> I'm starting to wonder whether the real solution here should be along the
>> lines
>> of what a board would do to a TLP if its active PMC shrinks to less
>> than 3 people.
>>
>
> Oh, that's easy, and has been done quite a few times. The Board moves them
> to the Attic. ... The Board will give the PMC several chances, and this can
> drag out for a year, but at the end of the day, the Board says "enough" and
> forces the issue. Done. Attic'd.

That's what I was implying.

> Now, I'm not sure if you were trying to draw an analogy between Board/PMC
> and IPMC/PPMC. From a legal/oversight perspective, these are very
> different. I don't think the IPMC should be so drastic. But the Board must,
> and will.

I honestly think its time for us to consider being more board like
around here at
IPMC. May be not exactly as strict as the board, but moving in that direction.

After all, being a podling means being TLP-on-training-wheels. That's the whole
idea. If your PMC shrinks -- you have to know what it means. Same here. If your
mentors are not active -- you've got to raise hell around here on general@
before its too late.

Thanks,
Roman.

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

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 7:24 PM, Niclas Hedhman  wrote:
> On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik 
> wrote:
>
>>
>> I'm starting to wonder whether the real solution here should be along the
>> lines
>> of what a board would do to a TLP if its active PMC shrinks to less
>> than 3 people.
>
>
> That will inevitable lead to definition of "what is active" and the whole
> "pity me/them for not having time" discussion that always arises when
> Mentor responsibilities are brought up.

True. But this is exactly what happens to a TLP, isn't it?

It is true that this will re-define mentorship expectations, but I think it
we may benefit from this re-definition in the long run. As it stands, being
a mentor today is way less commital than being a PMC member and
I don't think this is right.

I also suspect that re-defining commitment this way would serve
as a forcing function for potential podlings that don't get enough
engaged mentors up-front to fail fast (they won't be able to enter
Incubator) instead of getting stuck in limbo.

> I have been Mentor on 8 podlings;
>   * I was inactive on 1 of those (can't recall the reason)
>   * On 2 projects one other mentor was active.
>   * Remaining 5 projects, none of the other mentors did anything
> substantial, most nothing at all.
>
> Am I unlucky, scare others to inactivity, or is this what I think; people
> don't take the responsibility particularly seriously. "Oh cool project, I
> would like to be associated with that."
>
> Pat's suggestion is understandable, but not really viable.
>
> I would like to make a counter-suggestion, and I am sure IPMC won't like
> it, since it is filled with inactive, but sensitive, mentors;
>
>* If the release is left dangling (not enough votes) for IPMC approval
> beyond 72 hours,
>  1. The release may be placed in the dist snapshot areas, so active
> community members have some stable milestone to work with,
>  2. An Incubator page (for instance the /projects page) is updated with
> a "Attempted Release - failed not enough votes" with dates and votes
> received. This will accumulate the data points for IF there is a real
> problem in the Incubator and we can gather the stats if we have
> irresponsible mentors or not. It also gives the podling a vent for the
> frustration.

This is exactly the kind of stats gathering I was referring to. At the
same time,
I think the line in the sand is pretty clear -- it only is stats
gathering. I don't
think releasing something out of ASF that hasn't had at least 3 binding votes
would be advisable.

Thanks,
Roman.

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

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 5:14 PM, John D. Ament  wrote:
> On Sat, Apr 22, 2017 at 8:10 PM Ted Dunning  wrote:
>
>> Another solution is to do back door politicking where you contact IPMC
>> members individually and ask them to take a look. Start with members who
>> have voted on Mahout releases in the past and be specific about what you
>> would like them do and provide links to artifacts and discussions to make
>> the job easy.
>>
>> That has usually been my best way to succeed on that.
>>
>>
> 9 times out of 10, I ignore those emails.  If its someone I don't know,
> I'll send them over to http://incubator.apache.org/whoweare.html .  I'm not
> sure who created that page but I like it.
>
> We rely first and foremost of podling mentors to review releases.  Its much
> easier to review a release if the mentors have reviewed and given it a once
> over.  We're all volunteers here.  To me its also a good sign of mentor
> engagement seeing the mentors review the releases.

And that's exactly why my constant advice to all the podlings is to get at least
3 mentors so that at least in theory those are the ones from IPMC who would
care.

Interestingly enough, it hasn't really worked 100% but it is definitely better
than hoping for random IPMC votes.

I'm starting to wonder whether the real solution here should be along the lines
of what a board would do to a TLP if its active PMC shrinks to less
than 3 people.

This actually reminds me that I need to write my positioning statement since
this is definitely one of the issues I'd like to keep exploring more and more
instead of waiting for emails like the one that started this thread to kick us
in the collective IPMC butt.

Thanks,
Roman.

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

Re: Incubator Governance Change

[Roman Shaposhnik]

On Sat, Apr 22, 2017 at 10:02 AM, Julian Hyde  wrote:
> I agree that lack of IPMC votes is a problem. I don’t think that lowering the 
> bar to making a release is the solution.

+1 to that.

> I wish that each IPMC member would personally commit to voting on two release
> candidates per year. There are so many members of the IPMC that this would
> easily cover all of the votes that come up.

It would be interesting to start gathering the stats as we used to see
a few trends
and also consider how can we reverse them. For instance, I'd like to see the
percentage of votes that comes from mentors, etc.

Thanks,
Roman.

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

Re: [VOTE]: Apache HAWQ 2.2.0.0-incubating Release

[Roman Shaposhnik]

On Thu, Apr 20, 2017 at 7:05 AM, Ruilong Huo  wrote:
> Thanks Roman for the verification! We will fix the issue and keep updated
> in the community.

Thanks for your understanding! Lets take it back to dev@hawq where I can
help you guys with the required changes.

Thanks,
Roman.

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

Re: Coming to ApacheCON? Showcase your project at a Podling Shark Tank!

[Roman Shaposhnik]

On Wed, Apr 19, 2017 at 8:30 AM, Will Stevens  wrote:
> I am assuming this is only for Apache projects that are in the incubator
> phase?
>
> You don't want pitches for non-apache projects right?

I can totally see a project that is seeking to joing the incubator pitching.

What do you have in mind?

Thanks,
Roman.

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

Re: Coming to ApacheCON? Showcase your project at a Podling Shark Tank!

[Roman Shaposhnik]

On Tue, Apr 18, 2017 at 10:53 PM, Jean-Baptiste Onofré  
wrote:
> Hi Roman,
>
> do you think it would make sense to introduce nearly graduated podling,
> explaining the project and the journey in the incubator ? I'm thinking about
> Apache CarbonData for example.
>
> Thoughts ?

If we have slots available -- I'd say absolutely! Can I keep your offer in mind
and see how many podling will we have?

Thanks,
Roman.

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

Re: [VOTE]: Apache HAWQ 2.2.0.0-incubating Release

[Roman Shaposhnik]

On Thu, Apr 13, 2017 at 6:30 AM, Ruilong Huo  wrote:
> Hi All,
>
> The PPMC vote for the Apache HAWQ 2.2.0.0-incubating release has passed. We
> kindly request that the IPMC now vote on the release.
>
> The PPMC vote thread is located here:
> https://lists.apache.org/thread.html/a7c780cf5655679fa5c0cbe5a8d24777cd0439601266260859f935ef@%3Cdev.hawq.apache.org%3E
>
> The artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.2.0.0-incubating.RC2/
>
> The artifacts have been signed with Key: 1B8B6872.
>
> All JIRAs completed for this release are tagged with 'FixVersion =
> 2.2.0.0-incubating'. You can view them here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318826&version=12339641
>
> Please vote accordingly:
> [ ] +1, accept as the official Apache HAWQ 2.2.0.0-incubating release
> [ ] -1, do not accept as the official Apache HAWQ 2.2.0.0-incubating
> release because...
> The vote will run for at least 72 hours.

I do apologize for a delay -- I should've provided this feedback last feedback
last week, but it seems I'll be voting:

-1 (binding)

on the binary portion of this releases. Here's why:
1. The deal breaker issue is a total lack of clear IP attribution in
 binary artifacts. There's no proper LICENSE, NOTICE and
 DISCLAIMER file in neither the x86 binary package of HAWQ
 nor in the JAVA packages of companion components. This
 need to be fixed as per:
 http://www.apache.org/dev/licensing-howto.html#binary
 http://incubator.apache.org/guides/release-java.html#notes
 Note that you HAVE to account to all the dependencies you're
 bundling in a binary release which means your LICENSE and
 NOTICE files will likely get bigger. For Java side of HAWQ
 Apache Geode offers a good place to look for how to deal with
 those files in a binary distribution.

 2. This is one is less of a deal deal breaker for the first release, but
 will be so for subsequent ones: you really shouldn't be shipping
 apache-tomcat package. For one, you already have a dependency
 on bigtop-tomcat in hawq-ranger-plugin which means shipping
 apache-tomcat is wasteful, could conflicting with distribution RPM
 names and frankly looks a bit sloppy coming from the same project.

 3. This is even less of a dealbreaker than #2, but it may help you
 simplify solving for #1: I don't think you need to ship all those
 extra dependencies in hawq-ranger-plugin -- a much better option
 is getting them from a classpath just like other Java packages of
 HAWQ do.

Thanks,
Roman.

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

Coming to ApacheCON? Showcase your project at a Podling Shark Tank!

[Roman Shaposhnik]

Hi!

if you are (or anybody you know who's passionate about your project is)
going to travel to Miami for ApacheCON we've got an awesome
opportunity for you to showcase your project. Even if you don't have
talks scheduled in the regular program, consider doing a lighting talk
at Podling Shark Tank:
 https://wiki.apache.org/apachecon/ACNA17PodlingSharkTank

You've got nothing to lose (in fact, the opposite: you're likely to get
a prize!) and you will get a chance to receive feedback that might
actually help you grow your community and ultimately graduate to the
TLP status. Given our awesome panel of judges:
 * Sally Khudairi
 * Jim Jagielski
 * Justin Mclean
We guarantee this to be a fun and useful event for your community!

Please sign up on the wiki ASAP. The time is running out!

Thanks,
Roman.

P.S. If you have *any* questions whatsoever, but especially if you have
questions on logistics please email me directly.

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

Re: [PROPOSAL] Superset Proposal for Apache Incubator

[Roman Shaposhnik]

On Fri, Apr 14, 2017 at 5:45 PM, Julian Hyde  wrote:
> My mentoring cycles are all spoken for, but Superset is a great project and I 
> look forward to it becoming part of Apache. Good luck, and I look forward to 
> voting on your release candidates!

Ditto for me, unfortunately -- but I very much share Julian's sentiment!

Thanks,
Roman.

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

Re: Slack support?

[Roman Shaposhnik]

On Wed, Mar 29, 2017 at 10:32 AM, Ted Dunning  wrote:
> Reference to the twitter account situation just recently. We luckily still
> had access (I was the contact), but the risk was obvious. The admin email
> is not private@i.a.o to remediate that.

You meant now (as in "is now...") right?

Thanks,
Roman.

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

Re: [RESULT] [VOTE] Apache Fineract podling graduation

[Roman Shaposhnik]

Congrats and best of luck!

Thanks,
Roman.

On Mon, Mar 27, 2017 at 3:33 AM, Myrle Krantz  wrote:
> Hello Incubator,
>
> The vote to graduate Apache Fineract from the incubator passes with 8
> binding votes,  2 non-binding votes, and no down-votes
>
> +1 binding: John D. Ament, Daniel Gruno, Bertrand Delacretaz, Roman
> Shaposhnik, Niclas Hedhman, Jim Jagielski, Justin Mclean, Tom Barber
> +1 non-binding: Pierre Smits, Markus Geiß
>
> (+1 binding votes not carried over from the pre-proposal-correction
> vote thread: Jean-Baptiste Onofré, Ross Gardler)
>
> We at Apache Fineract deeply appreciate the expressions of good will
> that came together with your votes.
>
> Thank you,
> Myrle
>
>
> On Wed, Mar 22, 2017 at 3:11 PM, Myrle Krantz  wrote:
>> Greetings Incubator,
>>
>> I propose that we graduate Apache Fineract from the Incubator.  The
>> full text of the proposal is below.
>>
>> This is a restarted VOTE thread to correct an error in the resolution
>> from the original thread. Here's the previous VOTE thread:
>>
>> [https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]
>>
>> And here's the DISCUSS thread:
>>
>> [https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]
>>
>>
>> Thank you,
>> Myrle Krantz
>>
>>
>> Resolution:
>>
>> Establish the Apache Fineract Project
>>
>> WHEREAS, the Board of Directors deems it to be in the best
>> interests of the Foundation and consistent with the
>> Foundation's purpose to establish a Project Management
>> Committee charged with the creation and maintenance of
>> open-source software, for distribution at no charge to the
>> public, related to a core banking platform that provides a reliable,
>> robust, and affordable solution for entrepreneurs, financial
>> institutions, and service providers to offer financial
>> services to the world's underbanked and unbanked.
>>
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>> Committee (PMC), to be known as the "Apache Fineract Project",
>> be and hereby is established pursuant to Bylaws of the
>> Foundation; and be it further
>>
>> RESOLVED, that the Apache Fineract Project be and hereby is
>> responsible for the creation and maintenance of software
>> related to a core banking platform that provides a reliable,
>> robust, and affordable solution for entrepreneurs, financial
>> institutions, and service providers to offer financial
>> services to the world's underbanked and unbanked.
>>
>> RESOLVED, that the office of "Vice President, Apache Fineract" be
>> and hereby is created, the person holding such office to
>> serve at the direction of the Board of Directors as the chair
>> of the Apache Fineract Project, and to have primary responsibility
>> for management of the projects within the scope of
>> responsibility of the Apache Fineract Project; and be it further
>>
>> RESOLVED, that the persons listed immediately below be and
>> hereby are appointed to serve as the initial members of the
>> Apache Fineract Project:
>>
>> * Vishwas Babu AJ 
>> * Edward Cable 
>> * Markus Geiss 
>> * Sander van der Heijden 
>> * Ishan Khanna 
>> * Myrle Krantz 
>> * Terence Monteiro 
>> * Adi Nayaran Raju 
>> * Gaurav Saini 
>> * Nazeer Hussain Shaik 
>> * Jim Jagielski 
>> * Michael Vorburger 
>>
>>
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
>> be appointed to the office of Vice President, Apache Fineract, to
>> serve in accordance with and subject to the direction of the
>> Board of Directors and the Bylaws of the Foundation until
>> death, resignation, retirement, removal or disqualification,
>> or until a successor is appointed; and be it further
>>
>> RESOLVED, that the initial Apache Fineract PMC be and hereby is
>> tasked with the creation of a set of bylaws intended to
>> encourage open development and increased participation in the
>> Apache Fineract Project; and be it further
>>
>> RESOLVED, that the Apache Fineract Project be and hereby
>> is tasked with the migration and rationalization of the Apache
>> Incubator Fineract podling; and be it further
>>
>> RESOLVED, that all responsibilities pertaining to the Apache
>> Incubator Fineract podling encumbered upon the Apache Incubator
>> Project are hereafter discharged.

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

Re: [VOTE] Apache Fineract podling graduation (restarted with corrected proposal)

[Roman Shaposhnik]

+1 (binding)

Thanks,
Roman.

P.S. This is a repeat of a previous vote.

On Wed, Mar 22, 2017 at 7:11 AM, Myrle Krantz  wrote:
> Greetings Incubator,
>
> I propose that we graduate Apache Fineract from the Incubator.  The
> full text of the proposal is below.
>
> This is a restarted VOTE thread to correct an error in the resolution
> from the original thread. Here's the previous VOTE thread:
>
> [https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]
>
> And here's the DISCUSS thread:
>
> [https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]
>
>
> Thank you,
> Myrle Krantz
>
>
> Resolution:
>
> Establish the Apache Fineract Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Fineract Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is
> responsible for the creation and maintenance of software
> related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> RESOLVED, that the office of "Vice President, Apache Fineract" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Fineract Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Fineract Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Fineract Project:
>
> * Vishwas Babu AJ 
> * Edward Cable 
> * Markus Geiss 
> * Sander van der Heijden 
> * Ishan Khanna 
> * Myrle Krantz 
> * Terence Monteiro 
> * Adi Nayaran Raju 
> * Gaurav Saini 
> * Nazeer Hussain Shaik 
> * Jim Jagielski 
> * Michael Vorburger 
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
> be appointed to the office of Vice President, Apache Fineract, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Fineract PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Fineract Project; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Fineract podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Fineract podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [VOTE] Apache Fineract podling graduation

[Roman Shaposhnik]

+1 (binding)

Best of luck!

Thanks,
Roman.

On Mon, Mar 20, 2017 at 1:38 AM, Myrle Krantz  wrote:
> The discussion seems to have died down, so I'm calling the vote:  I propose
> that we graduate Apache Fineract from the Incubator.  The full text of the
> proposal is below.  The discuss thread can be found here:
>
>
> [
> https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E
> ]
>
> Thank you,
> Myrle
>
>
>
> Resolution:
>
> Establish the Apache Fineract Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a data management platform that provides
> real-time, consistent access to data-intensive applications
> throughout widely distributed cloud architectures.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Fineract Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is
> responsible for the creation and maintenance of software
> related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> RESOLVED, that the office of "Vice President, Apache Fineract" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Fineract Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Fineract Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Fineract Project:
>
> * Vishwas Babu AJ 
> * Edward Cable 
> * Markus Geiss 
> * Sander van der Heijden 
> * Ishan Khanna 
> * Myrle Krantz 
> * Terence Monteiro 
> * Adi Nayaran Raju 
> * Gaurav Saini 
> * Nazeer Hussain Shaik 
> * Jim Jagielski 
> * Michael Vorburger 
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
> be appointed to the office of Vice President, Apache Fineract, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Fineract PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Fineract Project; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Fineract podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Fineract podling encumbered upon the Apache Incubator
> Project are hereafter discharged.

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

Re: [VOTE] MADlib v1.10-rc2

[Roman Shaposhnik]

CCing dev@madlib

On Thu, Mar 9, 2017 at 9:26 AM, Frank McQuillan  wrote:
> @john
> Pivotal Network
> https://network.pivotal.io/
> is a commercial download site maintained by Pivotal.  MADlib binaries are
> also hosted there after Apache releases are completed
> e.g.,
> https://network.pivotal.io/products/pivotal-gpdb#/releases/4540/file_groups/491

I reviewed the link that John mentioned and I must say I agree with him.
That link just doesn't belong to a Download page of an ASF project.

It would be fine on a "powered by" kind of a page or on the wiki, but not
on a main download page.

Thanks,
Roman.

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

Re: [VOTE] MADlib v1.10-rc2

[Roman Shaposhnik]

On Tue, Mar 7, 2017 at 10:56 AM, Frank McQuillan  wrote:
> Hello Incubator PMC,
>
> The Apache MADlib (incubating) community has voted on and approved the
> proposal to release MADlib v1.10-rc2.
>
> The voting result is available at:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201703.mbox/%3CCAKBQfzQ_BeetybM9cOkXd%2BAvGDQY_BM3KMs3d28sH8tPFzDU8Q%40mail.gmail.com%3E
>
> This will be the 4th release for Apache MADlib (incubating).
>
> The main goals of this release are:
> * new modules (single source shortest path for graph analytics, encode
> categorical variables, K-nearest neighbors)
> * improvements to existing modules (add grouping support to elastic
> net and PCA, add cross validation to elastic net, array input for
> K-means, verbose output option for DT and RF, limit itemset size in
> association rules, various madpack installer improvements)
> * platform updates (PostgreSQL 9.6)
> * bug fixes
> * doc improvements
>
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.10
>
> To run check RAT, please do:
>
> $mvn verify
>
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
>
> We're voting upon the source (tag):  rc/1.10.0-rc2
> https://github.com/apache/incubator-madlib/tree/rc/1.10.0-rc2
>
> Source Files:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.10.0-incubating-rc2/
>
> Commit to be voted upon:
> https://github.com/apache/incubator-madlib/commit/a3863b6c2407eb28ba007f6288d167bf88674e6d
>
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
>
> For your convenience, the recent ASF licensing guidance to the MADlib
> community is summarized here:
> https://cwiki.apache.org/confluence/display/MADLIB/ASF+Licensing+Guidance
>
> Please vote:
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)

+1 (binding)

* checked KEYS
* checked hashes and signatures
* compared the content of the archive to the Git hash and tag
* checked LICENSE, NOTICE and DISCLAIMER
* checked the RAT exclusion list in pom.xml
* checked the license headers for files added to the project since
entering incubation

Thanks,
Roman.

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

Re: [VOTE] Apache DataFu 1.3.2 release RC0

[Roman Shaposhnik]

On Thu, Mar 2, 2017 at 12:31 PM, Matthew Hayes  wrote:
> The Apache DataFu community has voted on and approved the release of Apache
> DataFu 1.3.2 (incubating):
>
> http://mail-archives.apache.org/mod_mbox/incubator-datafu-dev/201703.mbox/browser
>
> Results:
> 3 binding +1 votes
> No 0 votes
> No -1 votes
>
> I'd like to call a vote in general to approve the release.
>
> The source release candidate RC0 can be downloaded here:
>
> https://dist.apache.org/repos/dist/dev/incubator/datafu/apache-datafu
> -incubating-1.3.2-rc0/
>
> The artifacts (i.e. JARs) built from 1.3.2 RC0 can be found here:
>
> https://repository.apache.org/content/repositories/orgapachedatafu-1004/
>
> These have been signed with PGP key 7BA4C7DF, corresponding to
> mha...@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&search=0x7BA4C7DF
> *
>
> The key is also listed here:
>
> https://people.apache.org/keys/group/datafu.asc
>
> The release candidate has been tagged in git with release-1.3.2-rc0, which
> has been signed with the same key.  I've also created a branch 1.3.2.
>
> For reference, here is a list of all closed JIRAs tagged with 1.3.2:
>
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20DATAFU%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%201.3.2%
> 20ORDER%20BY%20updated%20DESC%2C%20created%20DESC%2C%
> 20status%20DESC%2C%20priority%20DESC
>
> For a summary of the changes in this release, see:
>
> https://github.com/apache/incubator-datafu/blob/1.3.2/changes.md
>
> Note that starting with this release, LICENSE, NOTICE, and DISCLAIMER files
> are included in the META-INF of the JARs.  These differ from the source
> release versions as they reflect what is bundled in the JARs.
>
> Please download the release candidate, check the hashes, check the
> signatures, test it, and vote.  The vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

+1 (binding)

* Checked Maven artifacts (jars) to have the right LICENSE, NOTICE and
DISCLAIMER
* Checked source tarball for LICENSE, NOTICE and DISCLAIMER
* Checked the keyfile
* Checked the hashes and signatures
* Compared content of the tarball to the tag
* Run RAT check
* Built the project

Thanks,
Roman.

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

Re: [VOTE] Release Apache HAWQ 2.1.0.0-incubating (RC4)

[Roman Shaposhnik]

On Tue, Feb 21, 2017 at 5:54 PM, Ed Espino  wrote:
> Hello Incubator PMC (IPMC),
>
> The Apache HAWQ community has voted on and approved a proposal to
> release Apache HAWQ 2.1.0.0-incubating (source only release).
>
> We kindly request that the IPMC members review and vote on this
> incubator release.
>
> The PPMC VOTE thread is here:
> https://lists.apache.org/thread.html/b641ddf4519feba01d3d4c55180be842a27e75bdaef640175b623e12@%3Cdev.hawq.apache.org%3E
>
> The PPMC VOTE RESULT is here:
> https://lists.apache.org/thread.html/9d3025c12dc032437d1317d662f0e4434754c00258ca1abdd5c0ab9f@%3Cdev.hawq.apache.org%3E
>
> All JIRAs completed for this release are tagged with:
>   fixVersion = 2.1.0.0-incubating
>
> A complete JIRA list can be reviewed here:
> *
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318826&version=12339640
>
> The tag to be voted on: 2.1.0.0-incubating-rc4
> (f5033eaa3c7c1d9f85bbcc56e9d921d96337831a), located here:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-hawq.git;a=commit;h=12c7df017551f1c3b0deb38c7243db3e018ef62c
>
> Git release branch:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-hawq.git;a=shortlog;h=refs/heads/2.1.0.0-incubating
>
> Source release package:
> *
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz
>
> Source release verification:
> * PGP Signature:
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.asc
> * SHA256/MD5 Hash:
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.sha256
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.md5
>
> Keys to verify the signature of the release artifact are available at:
> * https://dist.apache.org/repos/dist/dev/incubator/hawq/KEYS
>
> The artifact(s) has been signed with Key ID: 57325522 ("esp...@apache.org")
>
> Build instructions are included in the project's wiki:
> https://cwiki.apache.org/confluence/display/HAWQ/Build+and+Install
>
> When voting, please list the actions taken to verify the release. To
> facilitate Apache license review and conformance, an Apache Release
> Audit Tool (RAT) pom.xml file is included in the source root
> directory.
>
> The vote will be open for at least 72 hours.
>
> Please vote:
> [ ] +1 Approve the release
> [ ] +0 no opinion
> [ ] -1 Don't approve the release (please provide specific comments)

+1 (binding)

  * checked hashes and signatures
  * checked the signing key
  * compared the tarball content to the tag
  * compared RAT exclusions in pom.xml to the previous approved release
  * ran RAT with the provide exclusion list (from pom.xml) and without
  * checked the content of
pxf/pxf-json/src/test/resources/tweets.tar.gz and filed  HAWQ-1351

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Tue, Feb 21, 2017 at 12:15 PM, John D. Ament  wrote:
> On Tue, Feb 21, 2017 at 2:52 PM Roman Shaposhnik 
> wrote:
>
>> On Tue, Feb 21, 2017 at 10:25 AM, Marvin Humphrey
>>  wrote:
>> > On Tue, Feb 21, 2017 at 6:31 AM, John D. Ament 
>> wrote:
>> >
>> >> So are we saying that the code modifications are sub-licensed? Or
>> >> re-licensed?
>> >
>> > Think of each file as the result of layering changesets on top of each
>> > other.  Each changeset has its own copyright holder and each copyright
>> > holder grants a license.
>> >
>> > When all changesets have the same license, then the end product has
>> > uniform licensing, even though many entities hold continue to hold
>> > copyright.
>> >
>> > However, it is also possible that changesets may be granted under
>> > different licenses -- in which case, the end product has heterogeneous
>> > licensing.  It may not be possible to slice up the file into code blocks
>> > which are under one license exclusively. Instead, if you want clean
>> > divisions by license you have to go back to the changesets.
>> >
>> > For BSD-2-clause files which came in with MADlib but were not relicensed
>> > (because not all authors participated in the SGA), we are saying that
>> > changesets submitted after arrival at the ASF shall be under Apache-2.0.
>>
>> I think we all agree on what's going on and I believe (although correct
>> me if I'm putting words in your mouth John) that we all feel the current
>> situation with MADlib is NOT against any policy of ASF.
>>
>>
> Not 100%.  We are saying that code modifications should have been under
> apache license, but they were still under BSD as of the release from last
> year.  Its nothing that I believe would have put the foundation in any
> negative situation.

The ARE under Apache License -- we are all in agreement there. We simply
lack tools to make this very fine grain statement.

Does it make it clearer? Are we in agreement now?

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Tue, Feb 21, 2017 at 10:25 AM, Marvin Humphrey
 wrote:
> On Tue, Feb 21, 2017 at 6:31 AM, John D. Ament  wrote:
>
>> So are we saying that the code modifications are sub-licensed? Or
>> re-licensed?
>
> Think of each file as the result of layering changesets on top of each
> other.  Each changeset has its own copyright holder and each copyright
> holder grants a license.
>
> When all changesets have the same license, then the end product has
> uniform licensing, even though many entities hold continue to hold
> copyright.
>
> However, it is also possible that changesets may be granted under
> different licenses -- in which case, the end product has heterogeneous
> licensing.  It may not be possible to slice up the file into code blocks
> which are under one license exclusively. Instead, if you want clean
> divisions by license you have to go back to the changesets.
>
> For BSD-2-clause files which came in with MADlib but were not relicensed
> (because not all authors participated in the SGA), we are saying that
> changesets submitted after arrival at the ASF shall be under Apache-2.0.

I think we all agree on what's going on and I believe (although correct
me if I'm putting words in your mouth John) that we all feel the current
situation with MADlib is NOT against any policy of ASF.

The real question is how do we communicate it to a downstream consumer.

There are two tools we have: a LICENSE file at the root of the project tree
and individual license headers in each of the files. Neither of these tools
are precise enough to address the subtlety that changesets may be granted
under different licenses. IOW, there's no perfect solution here and we have
to unblock the podling by making a decision that will be *less* than precise.

I really hope we can all agree on that.

Initially, I was very happy with the solution endorsed by Marvin and VP of Legal
https://s.apache.org/EOT5
In fact I thought that in conjunction with the statement in LICENSE file
it would be OK to modify the files and still NOT add ALv2 header (only
brand new files created throughout the ASF lifetime of the project will
get the proper AL header).

It seems that this assumption is now being challenged and as such we
NO LONGER have a path forward for the podling.

John, am I capturing your concerns correctly?

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Mon, Feb 20, 2017 at 3:30 AM, John D. Ament  wrote:
> On Sun, Feb 19, 2017 at 11:09 PM Roman Shaposhnik 
> wrote:
>
>> On Sun, Feb 19, 2017 at 8:01 PM, Niclas Hedhman  wrote:
>> > I haven't followed this issue, but if we take BSD licensed source and
>> > modifies it (enough to claim copyright on the modifications) we
>> re-license
>> > to ALv2, but leaves the original BSD headers (if any) in the source.
>> >
>> > CatA licenses are CatA because they allow modifications on source and
>> > re-license...
>>
>> Correct. Which seems to make Roy's proposal a superset of what you're
>> talking
>> about. Now, while we can debate whether we can accomplish something similar
>> to what he was suggesting by some other means -- I'd rather vote for
>> simplicity
>> and go ahead with this:
>>
>> https://issues.apache.org/jira/browse/LEGAL-293?focusedCommentId=15873943&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15873943
>>
>> At this point -- I just need to see if there's anybody who's strongly
>> opposed this
>> approach.
>>
>
> Doing what you've outlined was my original request, so I have no qualms.
> It had seemed to me that the preference was to not relicense.  But I am
> glad we are relicensing.

No we are not. See Mike's reply above.

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Sun, Feb 19, 2017 at 8:01 PM, Niclas Hedhman  wrote:
> I haven't followed this issue, but if we take BSD licensed source and
> modifies it (enough to claim copyright on the modifications) we re-license
> to ALv2, but leaves the original BSD headers (if any) in the source.
>
> CatA licenses are CatA because they allow modifications on source and
> re-license...

Correct. Which seems to make Roy's proposal a superset of what you're talking
about. Now, while we can debate whether we can accomplish something similar
to what he was suggesting by some other means -- I'd rather vote for simplicity
and go ahead with this:
 
https://issues.apache.org/jira/browse/LEGAL-293?focusedCommentId=15873943&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15873943

At this point -- I just need to see if there's anybody who's strongly
opposed this
approach.

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Sun, Feb 19, 2017 at 12:12 PM, John D. Ament  wrote:
> On Sun, Feb 19, 2017 at 3:08 PM Roman Shaposhnik 
> wrote:
>
>> On Sun, Feb 19, 2017 at 5:43 AM, John D. Ament 
>> wrote:
>> > I'm personally still concerned about MADLib's licensing status.
>> > Specifically speaking, where I feel more info is needed around
>> > modifications to the BSD licensed code.  None of that was in the legal
>> > resolution.
>>
>> Can you please suggest how can this be resolved? I've stated my opinion,
>> others stated theirs -- but how do we arrive at a either a consensus or
>> a resolution? What's a mechanism here?
>>
>
> Was there a clear statement on the code modifications?  Last I saw, there
> was an agreement for the imported code, but I thought I saw something
> saying the modifications were apache licensed, which is confusing in the
> current state.
>
> Either way, lets move this to legal discuss.

I filed https://issues.apache.org/jira/browse/LEGAL-293 and provided links
to the previous conversations around this subject. If there's a need to re-open
that discussion I'd rather do it on the JIRA.

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

On Sun, Feb 19, 2017 at 5:43 AM, John D. Ament  wrote:
> I'm personally still concerned about MADLib's licensing status.
> Specifically speaking, where I feel more info is needed around
> modifications to the BSD licensed code.  None of that was in the legal
> resolution.

Can you please suggest how can this be resolved? I've stated my opinion,
others stated theirs -- but how do we arrive at a either a consensus or
a resolution? What's a mechanism here?

Thanks,
Roman.

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

Re: Podling Graduation Rally

[Roman Shaposhnik]

Sorry for jumping at this rather tale -- being overwhelmed with
work and personal stuff :-(

As usual, John, I applaud your focus! A quick comment bellow.

On Mon, Feb 13, 2017 at 4:28 AM, John D. Ament  wrote:
> All,
>
> As mentioned in this month's report, there are 63 active podlings.  While
> I've been chasing retiring podlings, I think it would be good for the
> community as a whole to look closely as podlings and see what we can do to
> graduate podlings that seem to be doing well.
>
> Take a look at the last two reports:
>
> https://wiki.apache.org/incubator/February2017
> https://wiki.apache.org/incubator/January2017
>
> Last month, I listed 4 podlings that appear to have completed all
> graduation requirements, but remain in the incubator (Airflow, BatchEE,
> Freemarker, Metron).  I didn't include that in February, but if I had to
> list the names, it would be: CarbonData, Edgent, Fineract, Guacamole,
> PredictionIO, SystemML, Tamaya, Unomi (but that's entirely my POV/opinion
> unless others want to chime in).
>
> So I'm curious, what can others do to help these 12 podlings get past the
> finish line?

Out of the podlings I mentor I agree that Fineract is pretty close. But
I also would like to suggest that MADlib and DataFu. The logic being
those 3 are at pretty much the same level of maturity/community
development (although they are different in the community's size).

Could you, folks, please take a look at past reports for these 3 and
let me know your opinion? Btw, both MADlib and DataFu are working
on the one more release right now.

Thanks,
Roman.

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

Re: [DISCUSS] new incubator project Apache IOT

[Roman Shaposhnik]

On Mon, Jan 30, 2017 at 6:35 PM, Edward Capriolo  wrote:
> I know IOT is a super hot buzz word but here me out. This is not one of
> those attempts to brand a some random piece of software as IOT :)

Yeah, right ;-)

> When working with hardware there are a few common protocols. SPI, I2C, and
> GPIO. That are supported by a majority of the electronics
> http://www.mouser.com/ProductDetail/Maxim-Integrated/MAX31725MTA+/?qs=g0UVtq9Ld0OAg4p2QdgbSw%3D%3D&gclid=CPz0uPCr69ECFdaFswodwrEDtQ
>
> It is very difficult, if not impossible, to find quality implementations of
> the software side of these protocols that have Apache licences.

Funny you should mention this: Apache Mynewt (incubating) is basically
rolling with exact same thesis but around BLE. My last conversation with
Sterling (CCed) also pointed at the fact that they were thinking of doing
the same with USB implementation.

What I love about Mynewt is that they are very heavily invested in small,
reusable and robust implementations (think libraries) of these protocols.
It seems that it is pretty close to what you have in mind.

> If you are working with a something like the Rasp PI your go-to library is
> GPL
> http://pi4j.com/license.html.
>
> My proposal would be the Apache IOT project (could get a better name like
> IOT WIRE). We would provide the software to speak I2C, GPIO, Modbus.
> Support could be either c, java, or both.

It actually makes tons of sense to me, but let me ask you this: what footprint
are you trying to target and what implementation? Are you thinking embedded
(which I guess will mean C) or something else (which could be anything including
Python, etc.)?

Are you thinking devices or clients?

Thanks,
Roman.

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

Re: Incubator wiki write access for "espino"

[Roman Shaposhnik]

Done!

Thanks,
Roman.

On Wed, Jan 18, 2017 at 12:44 PM, Ed Espino  wrote:
> Hello, can you grant "karma" to the Apache ID "espino" to edit the
> incubator wiki for the podling report?
>
> Regards,
> -=e
>
> --
> *Ed Espino*
> *esp...@apache.org *

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

Re: Still need sign off from HAWQ, MADLib

[Roman Shaposhnik]

 (non-PMC)
>
> Date of last release:
>
>   2016-06-26
>
> Signed-off-by:
>
>   [X](freemarker) Jacopo Cappellato
>   [X](freemarker) Jean-Frederic Clere
>   [X](freemarker) David E. Jones
>   [X](freemarker) Ralph Goers
>   [X](freemarker) Sergio Fernández
>
> Shepherd/Mentor notes:
>
>
>
> 
> Gossip
>
> Gossip is an implementation of the Gossip Protocol.
>
> Gossip has been incubating since 2016-04-28.
>
> Three most important issues to address in the move towards graduation:
>
>   1. Create some tutorial videos and blog posts to educate people on Gossip
>  Project
>   2. Focus on some critical technical improvements multi-node testing and
>  accrual failure detection that will be critical for adoption into other
>  projects
>
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
>
>   No.
>
> How has the community developed since the last report?
>
>   - One contributor has been voted as a committer. There are 13 watches 24
> stars on github.
>   - Sean Busbey has stepped down as a mentor. Sean's early help was critical
> to this hatchling. Thank you, Sean.
>   - Drew Farris has taken a role as a mentor.
>
> How has the project developed since the last report?
>
>   Some technical features were frozen out until we completed our first
>   release. Effort was spent on doing the first release (getting access, key
>   signing, correctly enabling RAT maven plugin etc). This was mostly
> one-time
>   effort.
>
> Date of last release:
>
>   We are currently voting on our first release.
>
> When were the last committers or PPMC members elected?
>
>   Chandresh Pancholi as added as a committer on 11/29/16
>
> Signed-off-by:
>
>   [x](gossip) P. Taylor Goetz
>   [x](gossip) Josh Elser
>   [x](gossip) Drew Farris
>
> Shepherd/Mentor notes:
>
>   Josh Elser:
>
> First release should be landing within 72*2 hrs. Hopefully this will
> spawn a good cadence and attract more people to the, relatively quiet,
> podling.
>
> 
>
> HAWQ
>
> Apache HAWQ is a Hadoop native SQL query engine that combines the key
> technological advantages of MPP database with the scalability and
> convenience
> of Hadoop. HAWQ reads data from and writes data to HDFS natively.  HAWQ
> delivers industry-leading performance and linear scalability. It provides
> users the tools to confidently and successfully interact with petabyte range
> data sets. HAWQ provides users with a complete, standards compliant SQL
> interface.
>
> HAWQ has been incubating since 2015-09-04.
>
> Three most important issues to address in the move towards graduation:
>
>   1. Expand the community, by adding new contributors and focusing on making
>  sure that there's a much more robust level of conversations and
>  discussions happening around roadmaps and feature development on the
>  public dev mailing list
>   2. Infrastructure migration: create Jenkins projects that build HAWQ
>  binary, source tarballs, and run feature tests including at least
>  installcheck-good tests for each commit (HAWQ-127).
>
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
> of?
>
>   Everything seems to be smooth, nothing urgent at this time.
>
> How has the community developed since the last report?
>
>   1. The community becomes more open for discussion around the roadmap,
>  various features that committers are working on, infrastructure
>  enhancements for the project.
>   2. Two talks:
>  * The SQL-on-Hadoop engine that replaces traditional data warehouses:
>HAWQ, China Open Source Conference Oct, 2016, Lei Chang
>  * Apache HAWQ on cloud: the easiest way to cloud from traditional data
>warehouses, Big Data Technology Conferences, Dec, 2016, Lei Chang
>   3. Ed volunteered as an RM for the upcoming 2.1.0.0 release
>   4. Interesting discussions and work around Docker for HAWQ. HAWQ has an
>  account on docker hub: https://hub.docker.com/u/hawq/
>
> How has the project developed since the last report?
>
>   1. Apache HAWQ 2.0.0.0 released.
>   2. HAWQ 2.1.0.0 release proposed:
>
> https://cwiki.apache.org/confluence/display/HAWQ/HAWQ+Release+2.1.0.0-incubating+Release
>  * Critical HAWQ Register bug fixes
>  * Move HAWQ Ambari plugin to Apache HAWQ:   HAWQ-1013 RESOLVED
>  * Introduction of the PXF ORC support
>  * Many bug fixes
>
> Date of last release:
>
>   Oct 8, 2016
>
> When were the last committers or PMC members elected?
>
>   Two committers added: Hong Wu and Paul Guo
>
&

Re: [DISCUSS] publishing docker image for podling

[Roman Shaposhnik]

On Thu, Jan 5, 2017 at 1:32 AM, Greg Stein  wrote:
> Taking off my Infrastructure hat from within that issue, and speaking to
> this from a Foundation policy standpoint ... I think this is probably okay,
> if the docker image is named (say) u/apache/incubator-singa. We allow
> incubator projects in our github namespace as
> github.com/apache/incubator-singa.

This is orthogonal to the podling discussion, but have we settled the issue
of any Docker container being full of not only GPLed binaries, but also,
interesting potential trademark implications along the lines of:
https://mjg59.dreamwidth.org/36312.html

The reason I'm raising this is because we're now talking about an official
ASF account on DockerHub which means ramifications are Foundation-level
(not PMC level).

Apologies if it was settled and I missed it.

> But then we also get into an area of "what happens around graduation?" ...
> do we then offer both u/incubator-singa *and* u/singa ? ... If that's
> acceptable, then this may be a simple decision. But for downstream
> stability/continuity reasons would a podling want to *start* at
> docker/u/singa ? ... and that is where I ask if the IPMC is willing to give
> up the incubator- signal within our namespace on docker.
>
> And yes, I recognize the similarity to the concurrent discussion about
> Maven Central artifacts. There are costs/benefits around continuity and
> impacts on downstream users.

I just want to point out that just like with Maven -- you can achieve -incubator
tagging with versions/tags of Docker containers which will solve the naming
issue.

Thanks,
Roman.

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

Re: [DISCUSS] Significance of Artifact Names

[Roman Shaposhnik]

Huge +1 to what Cédric has said.

Thanks,
Roman.

On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
 wrote:
> Cross-posting since I missed this topic in the first place. My apologies
> for the duplicate:
>
> I would argue that one of the Foundation mottos is "community first". In
> that sense, enforcing a policy like that is not thinking about users. It's
> adding a burden they don't care about. I am strongly against anything that
> enforces technical requirements where there shouldn't be. Enforcing Maven
> coordinates, or enforcing a _version string_ is going too far into the
> technical details. There's branding and there's technical. Maven already
> makes the mistake of mixing how you build the project and how you consume
> it, which is the root of a lot of pain. Let's not make the error again at
> the policy level, it's a total non sense.
>
> The Foundation can host a variety of different projects, from new ones
> written in C to "old" ones written in Java, and all the different things we
> can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
> you consume a project, by Maven coordinates or version string is an
> implementation detail. Branding the project is not. In other words, as long
> as your package name, maven artifacts, Docker images, ... do not infringe
> copyright, it's a no brainer. However, the project page *must* state about
> incubating status and *explain* what it means. A *lot* of people don't care
> what *incubating* means in the Foundation sense (and even worse, podling
> can have very negative image). It would have been terrible for Groovy to
> change the way people consume the artifacts, making them think of low
> quality software, because they don't understand what "incubating" mean. To
> me it sounds even worse than "alpha". Since "incubating" is meant towards
> *incubating project in the sense of the Apache community*, it should *only*
> appear where it makes sense: DISCLAIMER, web site, ... That is to say
> everywhere you can give an explanation about its meaning. It should also
> appear in the source package name, because that is what we legally care
> about. But the version *string*, inside the package, is purely, again,
> internal details, just like package name, Maven coordinates, NPM
> coordinates, ... Why would you force me to use a version pattern if what I
> want is the revision hash as the version number? The policy should NOT
> impact how we design software or how we want the design to be. There are
> potential technical issues with putting such a label in a version string
> (OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
> name the Java ecosystem), so to me enforcing the policy here is just an
> error.
>
> As for Groovy and the Codehaus package and Maven coordinates, we plan to
> change this in a major, breaking, 3.0 release, not before. Because it would
> be a breaking change, and some dependency management engines, typically,
> are very poor when it comes to dependency substitution, which would add too
> much burden for people to upgrade. We had an agreement with Ben from
> Codehaus to use the name when we joined the ASF.
>
>
>
> 2017-01-04 6:24 GMT+01:00 Alex Harui :
>
>> Sorry for top-posting.
>>
>> It's always been interesting to me that the ASF says that it only releases
>> source code, but still has policy about the contents of convenience
>> binaries such as [6].  So, I suppose the ASF could dictate naming of
>> binary packages.
>>
>> I know very little about Maven, but in my mind, the -incubating suffix is
>> supposed to help warn the customer or cover the ASFs butt or both.  I
>> don't know if anybody actually points to a source artifact from Maven, but
>> if the downstream user is being careful enough to work from sources, it
>> makes sense to me to put in an additional warning by adding the
>> -incubating suffix to the source package. It says that these source
>> packages are not like other ASF source packages without having to open the
>> package.
>>
>> But for a binary artifact, given that the ASF already thinks it isn't
>> audit-able and thus not an official release, does the customer care that
>> the artifact may not be ASF-grade (especially if the artifacts were
>> already considered open before entering Apache)?  Do they really need
>> early warning?  Would it really affect the ASF if something bad was later
>> found in a binary artifact?
>>
>> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
>> suffix the source artifact with -incubating but not for the binary
>> artifacts.  But if it is hard, could the next version of Maven do it?
>>
>> Also, if someone is concerned enough about the licensing of the artifacts
>> they depend on to go digging through all of the poms of their binary
>> dependencies, wouldn't they check the  section of each POM?
>> According to [7] there is a comments section there.  Could incubating
>> podlings be required to make it clear in the  section that th

Re: [VOTE] Graduate Apache Ranger Project from the Incubator

[Roman Shaposhnik]

On Tue, Jan 3, 2017 at 4:21 PM, Ramesh Mani  wrote:
> Dear Incubator members,
>
> Apache Ranger Project community has successfully released 0.6.2 version and 
> with it there had been a lot of discussion within Apache Ranger community to 
> consider graduation to TLP. Apache Ranger entered into incubation on 24th 
> July 2014 and from this welcoming community had done a tremendous job in 
> resolving various technical hurdles like refactoring the project core model 
> to  be service based, adding more Apache Hadoop components like Apache YARN, 
> Apache Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger 
> Authorizing  model for security and making it into a core product in the 
> Apache Hadoop security space. PPMC has exhibited a clear understanding of 
> this growing apache community by electing  4 individuals as committers  and  
> inculding 22 individuals as contributors to the Apache Ranger project. PPMC 
> also has done 8 successful releases under the guidance of mentors 
> demonstrating their mastery over AFS’s IP policies.
>
> An voting was conducted within Apache Ranger Community to graduate Apache 
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or 
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>
> Apache Ranger Project has shown a great perspective to become a true TLP. 
> Following summary on the project reflects its accomplishment.
>
> Please vote on the Project resolution that is found in bottom to graduate 
> Apache Ranger Project from Incubator to Top Level Project.
>
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
> reason)

+1 (binding)

Thanks,
Roman.

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

Re: [DISCUSS] Replacing Incubator Release Management guide

[Roman Shaposhnik]

On Thu, Dec 29, 2016 at 6:40 PM, John D. Ament  wrote:
> On Thu, Dec 29, 2016 at 9:31 PM Roman Shaposhnik 
> wrote:
>
>> On Thu, Dec 29, 2016 at 6:17 PM, John D. Ament 
>> wrote:
>> > This is what I'm trying to say with these sentences:
>> >
>> > Those reviewing the releases will provide the release managers
>> > with information about what is wrong with the
>> release.
>> > Release managers should consider issues reported as blocking, unless told
>> > otherwise
>> > by those reporting the issue.
>> >
>> > I'd rather not use the term "pass" and I'd prefer if it were understood
>> by
>> > podlings that the default should be to try to fix the release, unless its
>> > explicitly called out.
>>
>> I understand, but the structure of the sentence makes it difficult to
>> appreciate
>> that mentors/IPMC folks are gatekeepers on what may and may not pass in
>> the incubating release. It is also somewhat confusing on the role of the
>> RM.
>>
>> So how about something like:
>>
>> It is well understood that one of the goals of incubation is to help a
>> podling understand how to build
>> ASF compliant releases. This is why its mandatory to have at least 3
>> +1 votes from IPMC members
>> review the releases (this may or may not include your mentors) for
>> accuracy in compliance with the
>> ASF and Incubator policies. The podling community, of course, needs to
>> be fully engaged in review
>> process as well. Anybody reviewing  the releases will provide the
>> release manager and IPMC members
>> with information about what is wrong  with the release. The severity
>> of the issues and whether they are
>> blocking or not is up to the discussion  but the ultimate guidance on
>> where podling releases may get
>> additional flexibility belongs to the mentors and IPMC members.
>>
>
> Ok, fair enough.  Hence why I always ask for people to give me their takes
> :-)
>
> I rephrased a couple of areas of what you wrote, what do you think?
>
> It is well understood that one of the goals of incubation is to help a
> podling understand how to
> build http://www.apache.org/dev/#releases";>ASF compliant
> releases. This is why its
> mandatory to have at least 3 +1 votes from
>  href="&root-path;/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">IPMC
> members
> review the releases (this should include your  href="&root-path;/incubation/Roles_and_Responsibilities.html#Mentor">mentors
> but is not mandatory)
> for accuracy in compliance with the ASF and  href="&root-path;/incubation/Incubation_Policy.html#Releases">Incubator
> policies.
> The podling community, of course, needs to be fully engaged in review
> process as well. Anybody reviewing
> the releases will provide the release manager and IPMC members with
> information about what is wrong
> with the release. The severity of the issues and whether they are blocking
> or not may be discussed
> but the ultimate guidance on where podling releases may get additional
> flexibility belongs to the mentors and IPMC members.
>
> One of the key things this draws to now is that we want to encourage
> mentors to review podling releases.

+1

Thanks,
Roman.

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

Re: Page for gathering CFP submissions

[Roman Shaposhnik]

On Thu, Dec 29, 2016 at 6:26 PM, John D. Ament  wrote:
> On Thu, Dec 29, 2016 at 9:14 PM Roman Shaposhnik 
> wrote:
>
>> On Thu, Dec 29, 2016 at 6:08 PM, John D. Ament 
>> wrote:
>> > That doesn't work well from a permission standpoint.
>>
>> Can you elaborate?
>>
>
> There's a permission that allows a user to attach a file and a permission
> that would allow you to be the only one to modify your own attachment.  I'd
> rather not change the latter permission on the incubator JIRA, but I guess
> if we wanted to we could request a new JIRA project just to capture this.

I still don't understand -- the only issue here is to be able to essentially
"append" new submissions. Just for kicks I tried doing it with the JIRA
you created using a brand new account (created 2 minutes ago). It worked
like a charm:
   https://issues.apache.org/jira/browse/INCUBATOR-141

Thanks,
Roman.

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

[jira] [Updated] (INCUBATOR-141) Test

[Roman Shaposhnik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Shaposhnik updated INCUBATOR-141:
---
Attachment: test.txt

This is a test attachment from a brand new account.

> Test
> 
>
> Key: INCUBATOR-141
> URL: https://issues.apache.org/jira/browse/INCUBATOR-141
> Project: Incubator
>  Issue Type: Task
>  Components: LogoSubmission
>Reporter: John D. Ament
> Attachments: test.txt, thunder-christmas.jpg
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [DISCUSS] Replacing Incubator Release Management guide

[Roman Shaposhnik]

On Thu, Dec 29, 2016 at 6:17 PM, John D. Ament  wrote:
> This is what I'm trying to say with these sentences:
>
> Those reviewing the releases will provide the release managers
> with information about what is wrong with the release.
> Release managers should consider issues reported as blocking, unless told
> otherwise
> by those reporting the issue.
>
> I'd rather not use the term "pass" and I'd prefer if it were understood by
> podlings that the default should be to try to fix the release, unless its
> explicitly called out.

I understand, but the structure of the sentence makes it difficult to appreciate
that mentors/IPMC folks are gatekeepers on what may and may not pass in
the incubating release. It is also somewhat confusing on the role of the RM.

So how about something like:

It is well understood that one of the goals of incubation is to help a
podling understand how to build
ASF compliant releases. This is why its mandatory to have at least 3
+1 votes from IPMC members
review the releases (this may or may not include your mentors) for
accuracy in compliance with the
ASF and Incubator policies. The podling community, of course, needs to
be fully engaged in review
process as well. Anybody reviewing  the releases will provide the
release manager and IPMC members
with information about what is wrong  with the release. The severity
of the issues and whether they are
blocking or not is up to the discussion  but the ultimate guidance on
where podling releases may get
additional flexibility belongs to the mentors and IPMC members.

Thanks,
Roman.

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

Re: Page for gathering CFP submissions

[Roman Shaposhnik]

On Thu, Dec 29, 2016 at 6:08 PM, John D. Ament  wrote:
> That doesn't work well from a permission standpoint.

Can you elaborate?

> Do you see any harm
> in requesting a ticket per submission, or an author updating the ticket w/
> new attachments?

Its not a huge deal, but it makes it a bit more daunting for somebody who's
new to JIRA. Giving a link to an existing JIRA and saying click Attach
is easier than explaining the JIRA creation process. Also, I seriously knew
ppl. who would obsess about creating a new ticket for an open source project.

It also is a tad more difficult to track and it doesn't allow for
submitters to see
each other's submissions easily (which creates a positive reinforcement effect).

Thanks,
Roman.

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

Re: Page for gathering CFP submissions

[Roman Shaposhnik]

I'm confused. I thought the idea is to have a single JIRA ticket with
all contestants attaching their artwork to it. No?

Thanks,
Roman.

On Thu, Dec 29, 2016 at 5:54 PM, John D. Ament  wrote:
> All,
>
> The IPMC (and Press department) will be announcing soon a CFP for a new
> Incubator logo.  I'd like to solicit some input on a page and set of
> instructions to follow to gather these submissions.  The page I've put
> together is here: http://incubator.staging.apache.org/2017-logo-contest.html
>
> I put together a sample submission here:
> https://issues.apache.org/jira/browse/INCUBATOR-141
>
> Please feel free to review, critique, test it and let me know what should
> change.
>
> John

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

Re: [DISCUSS] Replacing Incubator Release Management guide

[Roman Shaposhnik]

I like it -- nice and simple. +1 to Justin's suggestion. Also,
consider adding a sentence or two
around the fact that podlings *may* get a pass on some of the more
stringent requirements
of a full blown TLP release, but a) it is not guaranteed b) it is up
to mentors/IPMC to define
what is appropriate.

Thanks,
Roman.

On Thu, Dec 29, 2016 at 5:37 PM, Justin Mclean  wrote:
> Hi,
>
> Nice and simple I like it. Perhaps add text or a link that podling releases 
> need to be voted on this list here before being released?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [DISCUSS] Drop the 2013 Alternate Voting Policy

[Roman Shaposhnik]

On Thu, Dec 29, 2016 at 12:53 AM, Bertrand Delacretaz
 wrote:
> On Mon, Dec 26, 2016 at 4:29 PM, John D. Ament  wrote:
>> ...is this a policy we want to keep around?...
>
> I'm fine with removing it - community Darwinism at work ;-)

+1 for the same reason I'm always +1 on removing dead/little used code
-- if after all
you discover that you needed it -- it is one SCM command away.

Thanks,
Roman.

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

Re: [VOTE] Release Apache Fineract 0.5.0 (incubating)

[Roman Shaposhnik]

On Wed, Dec 21, 2016 at 8:52 PM, Nazeer Shaik  wrote:
> Hi Roman, thank you for reviewing the release.
>
> * the format of your hashes is not super convenient for an automatic
> comparison, being compatible with command line tools is probably a
> good idea
> [Nazeer] Can you give some more details please. May be a link to some
> Apache projects will help us to change hash formats :-)

Anything that lends itself to a direct diff/cmp is a good choice. E.g.:
http://www-eu.apache.org/dist/geode/1.0.0-incubating/

>   * I feel that including both LICENSE and LICENSE.md may confuse people
> [Nazeer] Will work on this in next releases

Great! Do you have a JIRA filed for this by any chance?

>   * I am really happy you've integrated rat check into the build, but
> it would be really nice if you could make it available from the top
> level folder
> [Nazeer] rat is configured in such way, it will check all directories and
> files from top level directory. I feel current approach is OK. Please let
> us know otherwise

Well, it took me some time to find out how to run it. This is not a huge
deal, but anything you can do to reduce surprise (like a lot of folks here,
I expect gradle rat to do the right thing when I run it from the top level)
will help you get more folks review your release quicker. IOW, this is not
about some kind of a policy, but rather making your source code base
friendly to reviewers (and users!).

>   * I seems weird that you release war file in a tarball instead of a Maven
> repo
> [Nazeer] Will start a discussion with Fineract community and will take
> their opinion also.

Great!

Thanks,
Roman.

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

[jira] [Commented] (INCUBATOR-139) Test ticket for Apache Incubator Logo Contest submissions

[Roman Shaposhnik (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15781763#comment-15781763
 ] 

Roman Shaposhnik commented on INCUBATOR-139:


[~johndament] & [~bdelacretaz] what's the latest on this? I've got a few 
designers itching to submit their entries.

> Test ticket for Apache Incubator Logo Contest submissions
> -
>
> Key: INCUBATOR-139
> URL: https://issues.apache.org/jira/browse/INCUBATOR-139
> Project: Incubator
>  Issue Type: Task
>  Components: site
>Reporter: Bertrand Delacretaz
> Attachments: this-is-not-a-logo.jpg
>
>
> Just checking out if this allows new jira users to upload their logos. If it 
> does we'll update this description with the contest information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [DISCUSS] Drop the 2013 Alternate Voting Policy

[Roman Shaposhnik]

I'd rather not sanctify exceptions with a precise list, but rather stop at:

"During incubation, a podling's release package may not be perfect. It
will be up to mentors and IPMC members
to define the appropriate leeway".

Or something to that extent.

Thanks,
Roman.

On Mon, Dec 26, 2016 at 6:03 PM, John D. Ament  wrote:
> On Mon, Dec 26, 2016 at 12:36 PM Marvin Humphrey 
> wrote:
>
>> On Mon, Dec 26, 2016 at 7:29 AM, John D. Ament 
>> wrote:
>>
>> > This policy as far as I can tell has never been used by any podling.
>>
>> It has been used once (by ODF Toolkit).
>>
>> > I believe the problem it was trying to solve was getting binding votes on
>> > releases which has mostly been fixed (release votes would go on for 20+
>> days
>> > back then).
>>
>> The initiative which culminated in the 2013 Alternate Voting Process had
>> some
>> secondary effects which turned out to be more important than the primary
>> effect.
>>
>> Most crucially, the IPMC achieved a common understanding about when to
>> approve
>> flawed release candidates that were legally OK yet not in compliance with
>> Apache policy.  ("Does it put the Foundation at risk?"  If not, then bias
>> towards approval.)  Between that and the eventual success of a separate
>> initiative to codify and clarify official release policy, two important
>> ends
>> were achieved:
>>
>> *   Arguments over release candidates ended sooner and became less
>> embittered.
>> *   Podlings no longer had to cycle through so many release candidates,
>> reducing burnout for Mentors and allowing us to use the limited IPMC
>> release reviewing capacity more effectively.
>>
>
> So, would it perhaps make sense to include a blurb about what is expected
> of a release and what the goals of incubation should be?  Something like:
>
> During incubation, a podling's release package may not be perfect.  These
> errors may include:
> - Improper NOTICE/LICENSE files
> - Failures building from source
> - Inclusion of binaries in the source release
> - Source release not staged properly.
> - etc... (Justin any notes here?)
>
> These issues vary in severity, and may be pointed out as blocking or not
> blocking the release by the IPMC.  Any blocking issues should cause the
> release to rerolled to fix the issue.  Non-blocking issues should be
> entered into your issue tracker and planned to be fixed for the next
> release.
>
> John
>
>
>
>>
>> The problem of insufficient Mentor participation in release review has not
>> gone away, and we remain heavily dependent on Justin (most often) to
>> provide
>> both review and the additional vote.  If Justin's involvement drops, the
>> Incubator is likely to have problems again.
>>
>> However, to address the remaining systemic flaws it seems wise to channel
>> our energies into policy and documentation streamlining, since that has
>> yielded better results.
>>
>> > So I was wondering, is this a policy we want to keep around?
>>
>> +1 to revert.
>>
>> The language was deliberately crafted as an addendum which would be easy to
>> back out.  Ditching it will have no problematic consequences.
>>
>> Marvin Humphrey
>>
>> -
>> 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: Podling request steps have been updated

[Roman Shaposhnik]

On Tue, Dec 27, 2016 at 8:45 AM, John D. Ament  wrote:
> All,
>
> I just got done editing the podling request page on the public website.
> Its based on areas that have changed recently.
>
> http://www.apache.org/dev/infra-contact#requesting-podling
>
> If everyone could take a look and give feedback and where there needs to be
> more detail, I would appreciate it.

Overall, this looks good. A couple of questions/notes:
   1. I am not sure you need to call #3 explicitly. In setting up of all of my
   podlings I've never had to request it separately.
   2. This check list touches some (ML, SCM) but not all (e.g. JIRA, builds)
   items. If we're striving for the bare minimum I'd say that at least we
   need to include a point on setting up JIRA. If we're covering everything
   builds, wiki and GH also need to be covered.

Thanks,
Roman.

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

Re: [VOTE] Release Apache Fineract 0.5.0 (incubating)

[Roman Shaposhnik]

+1 (binding)

a couple of nits:
  * the format of your hashes is not super convenient for an automatic
comparison, being compatible with command line tools is probably a
good idea
  * I feel that including both LICENSE and LICENSE.md may confuse people
  * I am really happy you've integrated rat check into the build, but
it would be really nice if you could make it available from the top
level folder
  * I seems weird that you release war file in a tarball instead of a Maven repo

Thanks,
Roman.

On Mon, Dec 19, 2016 at 2:52 PM, Justin Mclean  wrote:
> Hi,
>
> +1 binding
>
> I checked:
> - signatures and hashes correct
> - incubating in release names
> - DISCLAIMER exists in source
> - LICENSE and NOTICE good
> - All source files have ASF headers
> - No unexpected binary files
> - Can compile from source
>
> I would remove the list of software included in the binary release from the 
> source release LICENSE file. It’s fine to have two different license files. 
> The LICENSE may also be missing a license for jquery [1]?
>
> The convenience binary file is missing LICENSE, NOTICE and DISCLAIMER in the 
> top level, however the LICENSE and NOTICE file is inside the war and look 
> correct. Can you fix this in the next release please.
>
> Thanks,
> Justin
>
> 1. ./docs/system-architecture/css/toc-0.1.2/example/jquery.js
>
>
> -
> 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: Anyone else want JIRA access to the INCUBATOR project?

[Roman Shaposhnik]

plz add rvs

On Wed, Dec 21, 2016 at 4:25 PM, John D. Ament  wrote:
> All,
>
> I was able to get myself added to the PMC list on INCUBATOR which fixed
> permissions on the JIRA instance.  If anyone else wants access, drop a
> note.  We don't often see tickets created, but may be good to get more
> people helping to field them.
>
> John

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

Re: board comments on incubator

[Roman Shaposhnik]

On Wed, Dec 21, 2016 at 3:44 PM, Ted Dunning  wrote:
> The board is concerned that we have incubating projects that have been
> around for many years.
>
> What is the sense of the incubator about this issue.

Back when I was VP of Incubator I really hoped I could help move a
needle on that.
However, the consensus back then was not in favor of creating any
forcing functions
for graduation. I can dig relevant threads from the archive if needed.

So... unless the IPMC's view has changed -- that's what I'd tell the
board -- IPMC still
thinks it is not a problem (unless podlings exhibit behavior where
board really needs
to get involved).

In a way, it is a very similar to what happens to slow projects and
the Attic -- unless
community itself expresses interest in retiring or the PMC count drops
below 3 -- there's
not really much the board typically does about those.

Thanks,
Roman.

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

Re: [VOTE] Ratis to enter Apache Incubator

[Roman Shaposhnik]

On Fri, Dec 16, 2016 at 3:41 PM, Jitendra Pandey
 wrote:
> Dear All,
>I would like to call a vote for accepting "Ratis" for incubation in the 
> Apache Incubator.
> The full proposal is available below, and is also available at this wiki link.
>https://wiki.apache.org/incubator/RatisProposal
> There are two discussion threads for this proposal, because the project was 
> renamed from Concur to Ratis based on feedback. Please look for both Concur 
> and Ratis in the archives.
>
> Please cast your vote:
>
>   [ ] +1, bring Ratis into Incubator
>   [ ] +0, I don't care either way,
>   [ ] -1, do not bring Ratis into Incubator, because...

+1 (binding) Super excited to see RAFT Java implementation community
development effort!

Thanks,
Roman.

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

Re: [VOTE] Graduate Apache Eagle to top level project

[Roman Shaposhnik]

On Sun, Dec 11, 2016 at 9:22 PM, Edward Zhang  wrote:
> Hi,
>
> After discussion in Apache Eagle community [1][2] and IPMC mail list [3],
> please vote on the resolution proposed by Apache Eagle community below,
> which establishes Apache Eagle as top-level project at the Apache Software
> Foundation.
>
> [ ] +1, Graduate Apache Eagle from the Incubator.
> [ ] +0, Don't care.
> [ ] -1, Don't graduate Apache Eagle from the Incubator because...

+1 (binding) but I also do have a small nit inline:

Thanks,
Roman.

> Resolution:
>
> Establish the Apache Eagle Project
>
>
> WHEREAS, the Board of Directors deems it to be in the best
>
> interests of the Foundation and consistent with the
>
> Foundation's purpose to establish a Project Management
>
> Committee charged with the creation and maintenance of
>
> open-source software, for distribution at no charge to the
>
> public, related to a distributed monitoring solution for identifying
> security and performance issues in real time on big data platforms,
> including Apache Hadoop and Apache Spark etc.

"etc" at the end looks a bit weird to me as part of a more "official"
language of the resolution.


> * Kumar Senthil http://senthilec566.apache.org/>>

This is probably cut-n-paste issue but make sure you submit a clean
version to the board.

Thanks,
Roman.

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

Re: [RESULT] [RESTART] [VOTE] Graduate Apache Beam

[Roman Shaposhnik]

Saw this now. Sorry for the noise. You're all good. Btw, don't forget
to ask one of your mentors to add your resolution to the board agenda
in SVN.

Thanks,
Roman.

On Thu, Dec 8, 2016 at 3:31 PM, Davor Bonaci  wrote:
> This vote has passed unanimously, with 32 affirmative votes, 28 of which
> are confirmed binding:
>
> * Naresh Agarwal
> * John D. Ament
> * Tom Barber
> * Liang Chen
> * Byung-Gon Chun
> * Bertrand Delacretaz
> * Sandeep Deshmukh
> * Ted Dunning
> * Charith Elvitigala
> * Stephan Ewen
> * Sergio Fernández
> * P. Taylor Goetz
> * Von Gosling
> * Julian Hyde
> * Willem Jiang
> * Amol Kekre
> * Daniel Kulp
> * Guillaume Laforge
> * Olivier Lamy
> * Hugo Louro
> * Jacques Nadeau
> * Andreas Neumann
> * Jean-Baptiste Onofré
> * Ashish Paliwal
> * Luciano Resende
> * Neelesh Salian
> * Henry Saputra
> * Roman Shaposhnik
> * Stian Soiland-Reyes
> * James Taylor
> * Thomas Weise
> * Tom White
>
> Thanks everyone!
>
> Davor
>
>
> On Mon, Dec 5, 2016 at 3:30 PM, Davor Bonaci  wrote:
>
>> Hi everyone,
>> Please vote on the draft resolution proposed by the Apache Beam PPMC
>> below, which establishes Apache Beam as a new top-level project at the
>> Apache Software Foundation, as follows:
>>
>> [ ] +1, Graduate Apache Beam from the Incubator.
>> [ ] +0, Don't care.
>> [ ] -1, Don't graduate Apache Beam from the Incubator because...
>>
>> Please note that this is a restarted vote, per John's request, to clarify
>> the alternatives. The old voting thread is archived [1].
>>
>> Before voting, please see the full text of the draft resolution below and
>> the corresponding discussion thread [2], and vote only after you feel ready
>> to do so. The vote will be open for at least 72 hours. This is a procedural
>> vote [3]; it is adopted by a simple majority of qualified votes (with no
>> minimum).
>>
>> If approved by the Apache Incubator, the proposed resolution will be
>> submitted to the Board of Directors for their consideration.
>>
>> Thank you!
>>
>> Davor
>>
>> [1] https://lists.apache.org/thread.html/a8e9cecfe93f0e464cc7c17
>> 74d2761ca14326df1101b7670ca8b1dc3@%3Cgeneral.incubator.apache.org%3E
>> [2] https://lists.apache.org/thread.html/b9c1071b355588468368145
>> 75ada3cdca61c72dc1e672ab994a9c936@%3Cgeneral.incubator.apache.org%3E
>> [3] http://apache.org/foundation/voting.html
>>
>> The full-text of the draft resolution proposed by the Apache Beam PPMC:
>>
>> X. Establish the Apache Beam Project
>>
>>WHEREAS, the Board of Directors deems it to be in the best
>>interests of the Foundation and consistent with the
>>Foundation's purpose to establish a Project Management
>>Committee charged with the creation and maintenance of
>>open-source software, for distribution at no charge to
>>the public, related to a unified programming model for both
>>batch and streaming data processing, enabling efficient
>>execution across diverse distributed execution engines
>>and providing extensibility points for connecting to different
>>technologies and user communities.
>>
>>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>Committee (PMC), to be known as the "Apache Beam Project",
>>be and hereby is established pursuant to Bylaws of the
>>Foundation; and be it further
>>
>>RESOLVED, that the Apache Beam Project be and hereby is
>>responsible for the creation and maintenance of software
>>related to a unified programming model for both batch and
>>streaming data processing, enabling efficient execution across
>>diverse distributed execution engines and providing extensibility
>>points for connecting to different technologies and user
>>communities; and be it further
>>
>>RESOLVED, that the office of "Vice President, Apache Beam" be
>>and hereby is created, the person holding such office to
>>serve at the direction of the Board of Directors as the chair
>>of the Apache Beam Project, and to have primary responsibility
>>for management of the projects within the scope of
>>responsibility of the Apache Beam Project; and be it further
>>
>>RESOLVED, that the persons listed immediately below be and
>>hereby are appointed to serve as the initial members of the
>>Apache Beam Project:
>>

Re: [DISCUSS] Apache Beam podling graduation readiness

[Roman Shaposhnik]

Davor, congrants on the votes passing.

It is customary to conclude the vote (especially a more official one like this)
with a summary email with a subject:
[RESULT][VOTE]...
giving the tally of everyone who voted. Please consider doing that.

Thanks,
Roman.

On Thu, Dec 8, 2016 at 3:34 PM, Davor Bonaci  wrote:
> Since the discussion seems to have concluded and the formal vote has passed
> unanimously [1], I'll submit the draft resolution to the Board for their
> consideration (per graduation guide [2]).
>
> Thanks everyone!
>
> [1]
> https://lists.apache.org/thread.html/71a1c63837a7d1506a10af9c70af1c24db988451ac5b53fa2467b9b8@%3Cgeneral.incubator.apache.org%3E
> [2]
> http://incubator.apache.org/guides/graduation.html#top-level-board-proposal
>
> On Mon, Dec 5, 2016 at 10:13 AM, Davor Bonaci  wrote:
>
>> Since it seems we have a consensus, I'm going to start a formal vote.
>>
>> Please keep the discussion going, and vote only after you feel ready.
>> (Regardless of the outcome, we’d love to hear specific feedback on what can
>> be improved going forward.)
>>
>> On Sun, Dec 4, 2016 at 11:16 PM, Sergio Fernández 
>> wrote:
>>
>>> Out of personal technical interests, I've been following the podling quite
>>> close.
>>> They have made en enormous effort, both on the technical and community
>>> sides.
>>> I strongly believe the project is ready for graduation.
>>>
>>> On Fri, Dec 2, 2016 at 8:36 PM, Davor Bonaci  wrote:
>>>
>>> > Hi everyone,
>>> > Apache Beam entered incubation in early February. Over the past 10
>>> months,
>>> > the podling has made great progress across various areas: refactoring
>>> the
>>> > project to remove any special treatment given to a runner or a vendor,
>>> > building processes that encourage open development, evangelizing the
>>> > project, and growing the community.
>>> >
>>> > Now, with the support of our mentors and overwhelming support from the
>>> > wider Beam community [1], I’d like start a discussion on the progress we
>>> > have made and a possible graduation recommendation as a new top-level
>>> > project.
>>> >
>>> > To prepare for the discussion, we have published our self-assessment [2]
>>> > against the Apache Maturity Model. We tried to include links and
>>> evidence
>>> > whenever applicable. I’ll summarize the commonly asked questions here,
>>> but
>>> > please see the self-assessment for additional information, various
>>> details,
>>> > graphs, evidence, etc.
>>> >
>>> > > Releases?
>>> >
>>> > Three -- all unanimously approved, all driven by different release
>>> > managers, across different organizations. A detailed release guide is
>>> > available on the website.
>>> >
>>> > > Community growth?
>>> >
>>> > There has been a clear growth month-over-month. We have had 1500+ pull
>>> > requests on GitHub and 110+ individual code contributors. In terms of
>>> > mailing list activity, over the past 30 days, we have had 50+ individual
>>> > participants on dev@ and 35+ on user@.
>>> >
>>> > > Organizational influence?
>>> >
>>> > We have worked hard to remove any special treatment given to any
>>> > organization. The bulk of the initial code donation came from Google,
>>> but
>>> > now both the project’s code and branding have a clean separation between
>>> > the project and Google Cloud Dataflow (which has become just one of many
>>> > runners that can be used within Beam).
>>> >
>>> > While it is true that Googlers continue to provide the majority of
>>> commits,
>>> > over the last three months no single organization has had more than
>>> ~50% of
>>> > unique monthly contributors. (Please see the graph in the
>>> self-assessment.)
>>> > Diverse influences are also particularly clear when you look across
>>> modules
>>> > within the project. Beam has about ~22 large modules in the codebase, at
>>> > least 10 modules have been developed with little to no contribution from
>>> > Googlers.
>>> >
>>> > Now, if we were to graduate, the Beam PPMC recommends the following
>>> > information for the Board resolution:
>>> > * Project name: Apache Beam
>>> > * Project description and scope: a unified programming model for
>>> both
>>> > batch and streaming data processing, enabling efficient execution across
>>> > diverse distributed execution engines and providing extensibility points
>>> > for connecting to different technologies and user communities.
>>> > * PMC composition:
>>> >  * Tyler Akidau 
>>> >  * Davor Bonaci 
>>> >  * Robert Bradshaw 
>>> >  * Ben Chambers 
>>> >  * Luke Cwik 
>>> >  * Stephan Ewen 
>>> >  * Dan Halperin 
>>> >  * Kenneth Knowles 
>>> >  * Aljoscha Krettek 
>>> >  * Maximilian Michels 
>>> >  * Jean-Baptiste Onofré 
>>> >  * Frances Perry 
>>> >  * Amit Sela 
>>> >  * Josh Wills 
>>> > (The ratification of the full text of the draft resolution is nearing
>>> > completion.)
>>> >
>>> > While we have made great progress

Re: Incoming Website Changes

[Roman Shaposhnik]

On Wed, Nov 30, 2016 at 6:37 AM, John D. Ament  wrote:
> On Wed, Nov 30, 2016 at 2:38 AM Bertrand Delacretaz 
> wrote:
>
>> On Wed, Nov 30, 2016 at 3:49 AM, John D. Ament 
>> wrote:
>> > .. should we just drop the
>> > current "policy" document and make the guides the policy documents?...
>>
>> Clearly separating policy from everything else sounds good to me, but
>> the policy docs should then be as concise as possible.
>>
>
> I think the problem (my opinion) is that the policy guide is too concise,
> but the guide documents are too wordy.  If we added more text to the policy
> and consolidated there on the processes required then we may end up with
> better documents.
>
>
>>
>> Dunno if that can happen by just remixing the existing content, or if
>> it's better to start a new minimal policy document or section now.
>>
>
> I'm thinking a new document.

+1 to that. I'd be more than happy to help review, but sadly I can't commit
to create this kind of new document.

Thanks,
Roman.

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