Re: [PROPOSAL] Optiq

[Julian Hyde]

ting codebase to Apache and
>>> integrate with the Apache development process. Once this is accomplished,
>>> we plan for incremental development and releases that follow the Apache
>>> guidelines.
>>> 
>>> As we move the code into the org.apache namespace, we will restructure
>>> components as necessary to allow clients to use just the components of
>>> Optiq that they need.
>>> 
>>> A version 1.0 release, including pre-built binaries, will foster wider
>>> adoption.
>>> 
>>> == Current Status ==
>>> 
>>> Optiq has had over a dozen minor releases over the last 18 months. Its core
>>> SQL parser and validator, and its planning engine and core rules, are
>>> mature and robust and are the basis for several production systems; but
>>> other components and SPIs are still undergoing rapid evolution.
>>> 
>>> === Meritocracy ===
>>> 
>>> We plan to invest in supporting a meritocracy. We will discuss the
>>> requirements in an open forum. We encourage the companies and projects
>>> using Optiq to discuss their requirements in an open forum and to
>>> participate in development. We will encourage and monitor community
>>> participation so that privileges can be extended to those that contribute.
>>> 
>>> Optiq's pluggable architecture encourages developers to contribute
>>> extensions such as adapters for data sources, new planning rules, and
>>> better statistics and cost-estimation functions. We look forward to
>>> fostering a rich ecosystem of extensions.
>>> 
>>> === Community ===
>>> 
>>> Building a data management system requires a high degree of technical
>>> skill, and correspondingly, the community of developers directly using
>>> Optiq is potentially fairly small, albeit highly technical and engaged. But
>>> we also expect engagement from members of the communities of projects that
>>> use Optiq, such as Drill and Hive. And we intend to structure Optiq so that
>>> it can be used for lighter weight applications, such as providing a SQL and
>>> JDBC interface to a NoSQL system.
>>> 
>>> === Core Developers ===
>>> 
>>> The developers on the initial committers list are all experienced open
>>> source developers, and are actively using Optiq in their projects.
>>> 
>>> * Julian Hyde is lead developer of Mondrian, an open source OLAP engine,
>>> and an Apache Drill committer.
>>> * Chris Wensel is lead developer of Cascading, and of Lingual, the SQL
>>> interface to Cascading built using Optiq.
>>> * Jacques Nadeau is lead developer of Apache Drill, which uses Optiq.
>>> 
>>> In addition, there are several regular contributors whom we hope will
>>> graduate to committers during the incubation process.
>>> 
>>> We realize that additional employer diversity is needed, and we will work
>>> aggressively to recruit developers from additional companies.
>>> 
>>> === Alignment ===
>>> 
>>> Apache, and in particular the ecosystem surrounding Hadoop, contains
>>> several projects for building data management systems that leverage each
>>> other's capabilities. Optiq is a natural fit for that ecosystem, and will
>>> help foster projects meeting new challenges.
>>> 
>>> Optiq is already used by Apache Hive and Apache Drill; Optiq embeds Apache
>>> Spark as an optional engine; we are in discussion with Apache Phoenix about
>>> integrating JDBC and query planning.
>>> 
>>> == Known Risks ==
>>> 
>>> === Orphaned Products ===
>>> 
>>> Optiq is already a key component in three independent projects, each backed
>>> by a different company, so the risk of being orphaned is relatively low. We
>>> plan to mitigate this risk by recruiting additional committers, and
>>> promoting Optiq's adoption as a framework by other projects.
>>> 
>>> === Inexperience with Open Source ===
>>> 
>>> The initial committers are all Apache members, some of whom have several
>>> years in the Apache Hadoop community. The founder of the project, Julian
>>> Hyde, has been a founder and key developer in open source projects for over
>>> ten years.
>>> 
>>> === Homogenous Developers ===
>>> 
>>> The initial committers are employed by a number of companies, including
>>> Concurrent, Hortonworks, MapR Technologies and Salesforce.com. We are
>>> com

Spam

[Julian Hyde]

The dozen or so messages from abiola balogun  on this list in 
the past month have been monosyllabic non sequiturs [1]. I think he/she/it is a 
spam bot and propose that he/she/it be removed from the list.

Julian

[1] https://www.mail-archive.com/general@incubator.apache.org/maillist.html

Re: Spam

[Julian Hyde]

It's laudable that you should give this individual the benefit of the doubt. I 
agree, the motivation is not as simple as malicious spam. But their behavior 
has been disruptive.

Maybe contact them and ask them why they want to be on the list? We don't want 
to ban "people", but the entity behind this email address has done little to 
persuade me that they are a person.

Julian

On Jun 22, 2014, at 2:06 PM, Tim Ellison  wrote:

> Julian,
> 
> There are a few more messages from this sender in the moderator queue
> that I'm looking at, and while I agree they don't add a great deal of
> value, I'm struggling to see the goal if they are (malicious) spam.
> 
> I'm guessing we don't want to ban people for being misguided, or lack of
> insight :)
> 
> Tim
> 
> On 21/06/14 00:37, Julian Hyde wrote:
>> The dozen or so messages from abiola balogun  on this list 
>> in the past month have been monosyllabic non sequiturs [1]. I think 
>> he/she/it is a spam bot and propose that he/she/it be removed from the list.
>> 
>> Julian
>> 
>> [1] https://www.mail-archive.com/general@incubator.apache.org/maillist.html
>> 
> 
> -
> 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

Wiki access

[Julian Hyde]

Could “julianhyde” please be granted write access to the Incubator wiki.

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

Wiki access

[Julian Hyde]

I requested permission to access the incubator wiki last month, and it was 
granted, and I was able to edit https://wiki.apache.org/incubator/July2014. 
However I am now unable to edit https://wiki.apache.org/incubator/August2014. 
It says “immutable page”.

Can I have access to that page, please. My user name is “julianhyde”.

Julian

Re: Wiki access

[Julian Hyde]

I already tried logging out & in, and I also logging in from another browser. 

Can you please check whether “JulianHyde” has access. (Because 
http://moinmo.in/MoinMoinBugs/UserNamesShouldNotBeCaseSensitive.)

Julian

Re: Wiki access

[Julian Hyde]

On Aug 1, 2014, at 3:18 PM, Marvin Humphrey  wrote:

> I've removed "julianhyde" and added "JulianHyde". Please try again.

That did the trick. Thank you.

Julian

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

[VOTE] Release Apache Optiq 0.9.0 (incubating)

[Julian Hyde]

Hi all,

The Optiq community has voted on and approved a proposal to release Apache 
Optiq 0.9.0 (incubating). This would be the first release of the Apache Optiq 
project inside the Incubator.

Pursuant to the Releases section of the Incubation Policy and with the 
endorsement of two of our mentors we would now like to request the permission 
of the Incubator PMC to publish the release. The vote is open for 72 hours, or 
until the necessary number of votes (3 +1) is reached.

[ ] +1 Release this package as Apache Optiq 0.9.0 incubating
[ ] -1 Do not release this package because …

Apache Optiq PPMC


Proposal:
http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201408.mbox/%3CEFDC92D3-2D7A-4D69-96D6-261781F47BA5%40hydromatic.net%3E

Vote result:
5 binding +1 votes
5 non-binding +1 votes
No -1 votes
http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201408.mbox/%3C455640FD-8F46-4C15-A1F0-09D47B944100%40hydromatic.net%3E

Artifacts:
http://people.apache.org/~jhyde/optiq-0.9.0-incubating-rc2/


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

[RESULT] [VOTE] Release Apache Optiq 0.9.0 (incubating)

[Julian Hyde]

This vote passes with 6 +1s and no 0 or -1 votes:
+1 Alan Gates (mentor)
+1 Jan Inversion
+1 John D. Ament
+1 Justin Mclean
+1 Steven Noels (mentor)
+1 Ashutosh Chauhan (champion)

There was some feedback during voting (most of which I agree with). I shall 
open a separate thread to discuss.

Thanks everyone. We’ll roll the release out to the mirrors.

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

Issues raised during Optiq 0.9.0 release vote

[Julian Hyde]

A few issues were raised during the vote for Apache Optiq 0.9.0 (incubating) 
[0]. I started a separate thread to avoid muddying the vote. I address them 
below.

On Aug 23, 2014, at 10:36 AM, jan i  wrote:

> I am a bit concerned about the xml files. suppressions.xml references:
> "-//Puppy Crawl//DTD Suppressions 1.1//EN"
>"http://www.puppycrawl.com/dtds/suppressions_1_1.dtd";>
> 
> and checker.xml does not have any dtd reference. These are just examples,
> it continues. Its not a problem, I would just have expected the project to
> supply their own .dtd files and use them for all xml files.

This DTD is used as a URI that represents the particular version of the XML 
grammar and is not referenced at run time. (As evidenced by the fact that the 
project can be built using “mvn -o”, i.e. offline.) If we copied the DTD it 
would lose its effect of specifying the particular version of the XML grammar. 
Other projects (e.g. Hive) use the same DOCTYPE header for their checkstyle 
suppressions file.

> Sources look ok from a license perspective (it is a bit confusing though
> that src is nearly empty).

Not much in root src because it is the parent module (i.e. serves to combine 
several child modules); most of the code is in child modules, principally core.

$ for i in $(find . -name src); do wc $(find $i -type f) | awk -v i=$i '$4 == 
"total" {print NR, $1, $2, $3, i}'; done
Files   Lines   Words Chars Directory
=  == === = 
   34   6,546  21,753   195,415 ./avatica/src
  964 263,367 927,737 8,710,388 ./core/src
   20   3,077  12,147   127,812 ./mongodb/src
   15   1,979   7,71970,028 ./plus/src
   15   1,480   5,06151,791 ./spark/src
   20   2,514   8,54878,994 ./splunk/src
5 733   2,77035,749 ./src
3 258 948 7,639 ./ubenchmark/src


On Aug 23, 2014, at 3:14 PM, John D. Ament  wrote:

> I'm not sure that I'm comfortable with the fact that all of your source
> code is under net.hydromatic.optiq rather than org.apache.optiq.

There is an issue for this: https://issues.apache.org/jira/browse/OPTIQ-296. 
Code re-org is disruptive, both for this project and for dependent projects, 
and we chose to get a release out first.

> Your
> apache headers also look a bit weird.  Every other apache licensed that
> I've seen looks like [1], rather than your mix of single line and multi
> line headers.  But I think that's just a preference thing.

I think we should comply with the norm. I’ve logged 
https://issues.apache.org/jira/browse/OPTIQ-385.

On Aug 23, 2014, at 6:48 PM, Justin Mclean  wrote:

> You may want to consider changing for the next release:
> - change name format of the released files [1]

We actually tried this release, but backed off when it seemed that we were 
fighting maven.

I’ve logged https://issues.apache.org/jira/browse/OPTIQ-384.

> - place files in correct place [2]

I plan to do this as I roll out the release to mirrors. I didn’t know if it was 
even possible to populate “dist” until you have an approved release.

> - given there' nothing extra in LICENCE then there's probably no need for 
> "Please see LICENSE for additional copyright and licensing information." in 
> the NOTICE
> - NOTICE is missing "The Initial Developer of the Original Code, ..." which I 
> assume is the case as the package names are not apache ones


I’ve logged https://issues.apache.org/jira/browse/OPTIQ-386.

Julian

0. 
http://mail-archives.apache.org/mod_mbox/incubator-general/201408.mbox/%3CCD77DBD8-DBA6-435D-858F-688EF72C8418%40hydromatic.net%3E
1. 
http://incubator.apache.org/guides/releasemanagement.html#best-practice-unique-names
2. https://dist.apache.org/repos/dist/dev/incubator/twill/

Re: [RESULT] [VOTE] Release Apache Optiq 0.9.0 (incubating)

[Julian Hyde]

On Aug 25, 2014, at 11:07 AM, jan i  wrote:

> On 25 August 2014 19:25, Julian Hyde  wrote:
> 
>> +1 Jan Inversion
>> 
> I wonder who that is ?
> 
> Politely said, I am amazed how many ways my name can be spelled.

Sorry; over-enthusiastic spell-checker.

Julian

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

Uploading a release

[Julian Hyde]

The release vote Optiq 0.9.0 passed over a week ago. I have the bits ready and 
staged [1] [2]. Now I have to publish the release.

I’ve read 
http://incubator.apache.org/guides/releasemanagement.html#understanding-upload. 
I now “understand upload” in an abstract sense but am none the wiser.

What should I actually do to publish the release? I suspect that 3 or 4 svn 
commands are sufficient but I can’t guess what they might be.

(My experience being an Apache podling so far… one grueling fight after another 
against the infrastructure. This is just the latest chapter.)

Julian

[1] http://people.apache.org/~jhyde/apache-optiq-0.9.0-incubating-rc1/ 
[2] https://repository.apache.org/content/repositories/orgapacheoptiq-1000

Re: Uploading a release

[Julian Hyde]

On Sep 4, 2014, at 1:31 PM, Hitesh Shah  wrote:

> Publishing the contents at [1] can be done by following the steps detailed 
> out at 
> http://incubator.apache.org/guides/releasemanagement.html#release-distribution.
>  

I read those steps, but was still confused. To this reader, 
https://dist.apache.org/repos/dist/release/incubator/foo is a web URI, not a 
directory. I gather that via subversion it maps to a directory on a server 
somewhere and that using some svn incantations I can make it map to a directory 
on my local machine. But those incantations are not clear unless you are well 
versed in the subversion and Apache’s implementation of it.

Whoever wrote that page committed the first sin of documentation: they wrote 
for themselves, not for their audience.

Julian


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

Re: Uploading a release

[Julian Hyde]

On Sep 4, 2014, at 2:05 PM, David Nalley  wrote:

> Well I think the ASF's implementation of subversion should be pretty
> standard - if for no other reason than Subversion is an Apache
> Project. :)

I meant “implementation" in this sense: 
http://en.wikipedia.org/wiki/Product_software_implementation_method. It would 
have been clearer if I had said “configuration”.

Julian

Re: Uploading a release

[Julian Hyde]

Taylor and Hitesh,

Your instructions worked. It was very straightforward. Thank you.

Julian


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

Podling name change - Optiq becomes Calcite

[Julian Hyde]

We have discovered that we are unlikely to be able to trademark "Apache
Optiq", so we intend to change the name of the project to "Apache Calcite".
The PPMC likes the name, and a trademark search reveals no competing uses
of the name.

What are the next steps? Can someone who has been through the same process
please share their check-list? (I know I will need to log lots of INFRA
requests but it would help to know what these should be -- e.g. should I
ask to rename the lists, two svn repositories, 3 git repos, wiki, web
sites, old releases, jira project etc etc etc or create new ones and
obsolete the old ones?)

Release momentum is one of the good things we have going, so we will make a
release under the new name, which will be apache-calcite-0.9.1-incubating,
in the next few days. We will not have time to re-organize the code into
new package names.

I plan to launch the project under its new name, Apache Calcite, when I
speak at Strata NY on 16th October.

Julian

Re: Podling name change - Optiq becomes Calcite

[Julian Hyde]

On Sep 26, 2014, at 1:29 PM, Hendrik Dev  wrote:

> we just renamed fleece to johnzon so maybe i can help:
> 
> - Check for the new name: http://www.apache.org/foundation/marks/naming.html
> - We voted on the dev list for the new name

Still consensus building but will move to PPMC and dev votes in due course.

> - Open a issue like this one to get approval from @trademark
> (https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-53)
> (You don't need to wait for the approval to go further but if you dont
> get them you maybe have to rename again later)

Good idea. I had already done the searches so I’ve filled out the fields.

https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-56

> - Open INFRA jira ticket to rename the repo, mailinglist, ... like
> https://issues.apache.org/jira/browse/INFRA-8269
> - Rename the incubator files and content (podlings.xml, etc)
> 
> Hope this helps

Yes - exactly what I needed. Thanks.

Julian

[VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

Hi all,

The Calcite community has voted on and approved a proposal to release
Apache Calcite 0.9.1 (incubating).

This will be the second release since the project entered incubation in
May 2014 as Optiq, and the first under the new project name, Calcite.

Pursuant to the Releases section of the Incubation Policy and with
the endorsement of 2 of our mentors we would now like to request
the permission of the Incubator PMC to publish the release. The vote
is open for 72 hours, or until the necessary number of votes (3 +1)
is reached.

[ ] +1 Release this package as Apache Calcite 0.9.1 incubating
[ ] -1 Do not release this package because ...

Apache Calcite PPMC


Proposal:
http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeL%2Bgcf1yamWqRicpUJxU2tkyqGEzojd9nNXKmdEE3QwQQ%40mail.gmail.com%3E

Vote result:
5 binding +1 votes
3 non-binding +1 votes
No -1 votes

Artifacts:
http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/

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

Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

That information is all in the vote proposal: 
http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeL%2Bgcf1yamWqRicpUJxU2tkyqGEzojd9nNXKmdEE3QwQQ%40mail.gmail.com%3E

I’ll repeat it here:

The commit to be voted upon:
http://git-wip-us.apache.org/repos/asf/incubator-optiq/commit/6801257324d7515f91c61877a0edd0863c0433f5

The artifacts to be voted on are located here:
http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1000

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/jhyde.asc

Julian



On Oct 9, 2014, at 1:00 PM, sebb  wrote:

> On 9 October 2014 20:51, Julian Hyde  wrote:
>> Hi all,
>> 
>> The Calcite community has voted on and approved a proposal to release
>> Apache Calcite 0.9.1 (incubating).
>> 
>> This will be the second release since the project entered incubation in
>> May 2014 as Optiq, and the first under the new project name, Calcite.
>> 
>> Pursuant to the Releases section of the Incubation Policy and with
>> the endorsement of 2 of our mentors we would now like to request
>> the permission of the Incubator PMC to publish the release. The vote
>> is open for 72 hours, or until the necessary number of votes (3 +1)
>> is reached.
>> 
>> [ ] +1 Release this package as Apache Calcite 0.9.1 incubating
>> [ ] -1 Do not release this package because ...
>> 
>> Apache Calcite PPMC
>> 
>> 
>> Proposal:
>> http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeL%2Bgcf1yamWqRicpUJxU2tkyqGEzojd9nNXKmdEE3QwQQ%40mail.gmail.com%3E
>> 
>> Vote result:
>> 5 binding +1 votes
>> 3 non-binding +1 votes
>> No -1 votes
>> 
>> Artifacts:
>> http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/
> 
> Where is the KEYS file?
> What is the SVN/GIT tag (with revision/hash)?
> 
> Both of these are needed to check the release.
> Also, the hashes of the release artifacts should be included in the
> vote mail so that the released artifacts can be traced back to the
> vote if necessary.
> 
>> -
>> 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: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

On Oct 9, 2014, at 4:41 PM, sebb  wrote:

> On 9 October 2014 21:14, Julian Hyde  wrote:
>> That information is all in the vote proposal: 
>> http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeL%2Bgcf1yamWqRicpUJxU2tkyqGEzojd9nNXKmdEE3QwQQ%40mail.gmail.com%3E
>> 
>> I’ll repeat it here:
>> 
>> The commit to be voted upon:
>> http://git-wip-us.apache.org/repos/asf/incubator-optiq/commit/6801257324d7515f91c61877a0edd0863c0433f5
>> 
>> The artifacts to be voted on are located here:
>> http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/
> 
> What about the hashes please?

I don’t understand. 
http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/ contains 
two tar balls (.tar.gz and .zip) and each has a corresponding .asc, .md5, .sha1 
file. What other hashes are needed?

If you mean the git commit hash, that is simply the commit id: 
6801257324d7515f91c61877a0edd0863c0433f5.

> 
>> A staged Maven repository is available for review at:
>> https://repository.apache.org/content/repositories/orgapachecalcite-1000
>> 
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/jhyde.asc
> 
> Ideally please show the URL that will be included on the download page, e.g.
> 
> http://www.apache.org/dist/incubator/amber/KEYS
> 
> There was no calcite directory, so I created it.
> 
> It should be sufficient to add the KEYS file to
> 
> https://dist.apache.org/repos/dist/release/incubator/calcite/
> 
> By the magic of svnpubsub it will then appear at
> 
> http://www.apache.org/dist/incubator/calcite/
> 
> Note: I also created
> https://dist.apache.org/repos/dist/dev/incubator/calcite
> which can be used for future release candidates.

Yes, I would have populated those locations but I am still waiting on 
https://issues.apache.org/jira/browse/INFRA-8418.

Julian

Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

OK, let me clarify as sebb has asked so that the vote can proceed.

The git commit to be voted upon:
http://git-wip-us.apache.org/repos/asf/incubator-optiq/commit/6801257324d7515f91c61877a0edd0863c0433f5

Its hash is 6801257324d7515f91c61877a0edd0863c0433f5.

The artifacts to be voted on are located here:
http://people.apache.org/~jhyde/apache-calcite-0.9.1-incubating-rc1/

The hashes of the artifacts are as follows:
src.tar.gz.md5 f7c1a0fa488e061f6812bb0014561738
src.tar.gz.sha1 bf3fc81fb911a33be9e6d9afb0e5d2b34a25fb4c
src.zip.md5 e0326c9463075df3c6f8f9a1324f9512
src.zip.sha1 5943eed6532b3c6edeb208a605a1f5ee6532a0c2

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1000

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/release/incubator/optiq/KEYS

(Note that the directory still bears the old project name, pending
https://issues.apache.org/jira/browse/INFRA-8418.)

Julian

Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

On Oct 11, 2014, at 2:01 PM, Justin Mclean  wrote:

> Hi,
> 
> +0 (binding) Will change to +1 once PPMC vote is clarified.
> 
> I checked:
> - vote may need another +1 (see below)
> - hashes and signatures correct
> - artefacts have incubating in name
> - DISCLAIMER exists
> - LICENSE and NOTICE correct
> - all source files have Apache headers
> - no binary files in source package
> - can compile from source
> - tests pass
> 
> Looking at the vote thread there is:
> +2 binding
> +3 unknown
> +3 non binding 
> 
> So I'm not 100% sure if the release has the 3 required +1 votes from the 
> PPMC. Can you confirm that this is the case. For next release could you 
> summarise the vote result via a [VOTE][RESULT] email.

Here is a link to the [VOTE] [RESULT] email. I sent the email very soon after 
the close of the PPMC vote but I did not include a link in the IPMC vote 
because after 2 hours it had still not appeared on mail-archives.apache.org and 
I ran out of patience.

http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeLhG5Wbc%2BxGjaZouM39_OLEUJF3Jz%3D4fq_bEG0DcsLpuQ%40mail.gmail.com%3E

> Also any reason why the project seem to be hosted outside of Apache? [1]

Is that link in the release, or did you find it via google? I don't think we 
still link to that site from the source code. Correct me if I'm wrong. I 
haven't taken the old site down because the new site still doesn't have 
necessary stuff like javadoc.

> The team page list no members. [2]

We're not trying to keep the old site up to date. The effort to create a new 
site https://issues.apache.org/jira/browse/OPTIQ-355 is blocked because we want 
to transition from CMS to svnpubsub when we rename the site from 
optiq.incubator.apache.org to calcite.incubator.apache.org 
https://issues.apache.org/jira/browse/INFRA-8418.

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

Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

Regarding Apache RAT. I think we have that covered already. RAT is run if you 
specify the apache-release maven profile, and therefore is run automatically 
when we make a release. You can run it standalone using

  mvn -Papache-release verify

As Ted notes, a few exclusions are needed. The top-level pom.xml contains those 
exclusions, and RAT passes.

Julian


On Oct 12, 2014, at 10:39 PM, Ted Dunning  wrote:

> I just looked a bit a this release and I have a few questions.  I am
> uncertain about how these issues should lead to a vote, but would tend
> toward saying that this is OK for a first incubator release on condition
> that these issues should be rectified in subsequent releases.
> 
> I would appreciate guidance from Marvin or other folk experienced in these
> matters about this.
> 
> First, the signing key is present in SVN, but has not been uploaded to the
> standard key-servers, nor has it been signed by anyone.  I don't think that
> this has been made a failing criterion for releases yet, but it does appear
> that Apache is moving towards requiring a web of trust around public keys
> used for signing.  It would be good to rectify this by uploading a signed
> key.
> 
> Then, there is a DEPENDENCIES file which contains licensing information for
> dependencies that are not included in the distribution.  That DEPENDENCIES
> file contains information on many of the dependencies, but not all.  I
> think that this file be deleted or made whole.
> 
> Also, I ran [mvn rat:check] and noted that it failed.  The reason for the
> failure is relatively benign in that the objections are for files such as
> git.properties, some mark-down files and a file containing the textual name
> of a class which do not have a recognizable license.  Adding the following
> to the top-level pom will suppress these messages and allow rat to complete
> successfully:
> 
>
>org.apache.rat
>apache-rat-plugin
>
>
>rat-checks
>validate
>
>check
>
>
>
>
>false
>
>**/*.md
>**/*.json
>**/*.parquet
>**/META-INF/services/java.sql.Driver
>**/git.properties
>**/target/rat.txt
>
>
>
> 
> On a more positive note, I reviewed the NOTICE and LICENSE and they are in
> order for a pure apache source release that embeds no externally licensed
> code.  These would have to be different in a binary release, of course, if
> convenience jars are included, but there is no binary release at this time
> so that is not yet an issue.
> 
> 
> 
> 
> On Sat, Oct 11, 2014 at 7:17 PM, Julian Hyde  wrote:
> 
>> On Oct 11, 2014, at 2:01 PM, Justin Mclean 
>> wrote:
>> 
>>> Hi,
>>> 
>>> +0 (binding) Will change to +1 once PPMC vote is clarified.
>>> 
>>> I checked:
>>> - vote may need another +1 (see below)
>>> - hashes and signatures correct
>>> - artefacts have incubating in name
>>> - DISCLAIMER exists
>>> - LICENSE and NOTICE correct
>>> - all source files have Apache headers
>>> - no binary files in source package
>>> - can compile from source
>>> - tests pass
>>> 
>>> Looking at the vote thread there is:
>>> +2 binding
>>> +3 unknown
>>> +3 non binding
>>> 
>>> So I'm not 100% sure if the release has the 3 required +1 votes from the
>> PPMC. Can you confirm that this is the case. For next release could you
>> summarise the vote result via a [VOTE][RESULT] email.
>> 
>> Here is a link to the [VOTE] [RESULT] email. I sent the email very soon
>> after the close of the PPMC vote but I did not include a link in the IPMC
>> vote because after 2 hours it had still not appeared on
>> mail-archives.apache.org and I ran out of patience.
>> 
>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-optiq-dev/201410.mbox/%3CCAMCtmeLhG5Wbc%2BxGjaZouM39_OLEUJF3Jz%3D4fq_bEG0DcsLpuQ%40mail.gmail.com%3E
>> 
>>> Also any reason why the project seem to be hosted outside of Apache? [1]
>> 
>> Is that link in the release, or did you find it via google? I don't think
>> we still link to that site from the source code. Correct me if I'm wrong. I
>> haven't taken the old site down because the new site still doesn't have
>> necessary stuff like javadoc.
>> 
>&g

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Julian Hyde]

For many projects, especially "library" projects, the "convenient binaries" 
that matter most these days are the jars (source, binary, and javadoc) that are 
deployed to the maven repo. Calcite releases in fact do not currently include a 
binary tar ball, only a source tar ball and maven jars. 

Are these jars subjected to due diligence during the release vote? It seems to 
me that each of those jars is a de facto binary release.

(Not that I think there is too little due diligence! We've been on the 
receiving end of a fair amount recently.)

Julian


On Oct 13, 2014, at 10:02 AM, Bertrand Delacretaz  
wrote:

> On Mon, Oct 13, 2014 at 3:54 PM, Ted Dunning  wrote:
>> On Mon, Oct 13, 2014 at 7:51 AM, Bertrand Delacretaz >> wrote:
>>> make sure
>>> podlings understand the difference between source code releases and
>>> convenience binaries.
>>> 
>> Based on recent discussion, a review of this distinction would be valuable
>> for many at Apache.
> 
> Aren't these pages sufficient for that?
> 
> http://apache.org/dev/release.html (search for "bina")
> http://www.apache.org/dev/licensing-howto.html#binary
> 
> Otherwise I'd suggest adding an "about convenience binaries" section
> at http://apache.org/dev/release.html with a small set of relevant
> questions and answers.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

For the record, I did register my key fingerprint at https://id.apache.org
and my key is present at https://people.apache.org/keys/committer/jhyde.asc.
And it was before the release was made. So, I am surprised that it did not
show up in a search.

Julian


On Oct 13, 2014, at 12:11 PM, Dennis E. Hamilton 
wrote:

I suggest that the release manager and anyone else in the KEYS file should
have added key fingerprints to their Apache profiles at <
https://id.apache.org/>.

This will have their PGP keys refreshed regularly under their Apache ID at
<https://people.apache.org/keys/committer/>.

With regard to an identifiable association of the key, presence in this
manner connects the PGP key to The Apache ID by demonstration of control
over the committer's Apache profile.

One can go farther by adding the user...@apache.org to an User-ID on the
key.
Verifying that one has control over that e-mail address (and all User-IDs)
Is done by registering the public key at the PGP Global Directory service
at
<https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event> and completing the
ceremony specified there.  After the ceremony is completed, you can retrieve
your counter-signed PGP key from that service and synchronize it to a public
PGP key server.  The ASF will pick it up on a future refresh.

Use of the key from the Apache ID list has certain valuable properties.  It
is
not fixed, as in the key files in the project and in distributions.  That
means
any additional (web-of-trust) certifications of the keys association with a
committer are updated automatically.  That includes any revocations.


-- Dennis E. Hamilton
   dennis.hamil...@acm.org+1-206-779-9430
   https://keybase.io/orcmid  PGP F96E 89FF D456 628A
   X.509 certs used and requested for signed e-mail



-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Sunday, October 12, 2014 22:29
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

Hi,

First, the signing key is present in SVN, but has not been uploaded to the
standard key-servers, nor has it been signed by anyone.


I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index

Even if the key is part of a web trust it may not be part of everyone's web
of trust. I'd see that as a hard requirement to meet.

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: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

This vote has been open 8 days, and has two +1 votes. There has been a
lot of discussion, but I don't think any issues have been discovered
which would stop the release. We seem have reached impasse.

I plan to close this vote in 24 hours. If we get one more +1, the vote
will pass. If we don't, I will cancel the vote.

Julian


On Tue, Oct 14, 2014 at 7:57 AM, sebb  wrote:
> On 13 October 2014 17:11, Dennis E. Hamilton  wrote:
>> I suggest that the release manager and anyone else in the KEYS file should
>> have added key fingerprints to their Apache profiles at 
>> <https://id.apache.org/>.
>>
>> This will have their PGP keys refreshed regularly under their Apache ID at
>> <https://people.apache.org/keys/committer/>.
>>
>> With regard to an identifiable association of the key, presence in this
>> manner connects the PGP key to The Apache ID by demonstration of control
>> over the committer's Apache profile.
>
> Similar traceability applies if the user adds their key to the KEYS
> file in SVN at
>
> https://dist.apache.org/repos/dist/release//[path/]KEYS
>
> [This file is required for providing the keys to downloaders]
>
> But no harm in adding the key to LDAP as well.
>
>> One can go farther by adding the user...@apache.org to an User-ID on the key.
>> Verifying that one has control over that e-mail address (and all User-IDs)
>> Is done by registering the public key at the PGP Global Directory service at
>> <https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event> and completing the
>> ceremony specified there.  After the ceremony is completed, you can retrieve
>> your counter-signed PGP key from that service and synchronize it to a public
>> PGP key server.  The ASF will pick it up on a future refresh.
>>
>> Use of the key from the Apache ID list has certain valuable properties.  It 
>> is
>> not fixed, as in the key files in the project and in distributions.  That 
>> means
>> any additional (web-of-trust) certifications of the keys association with a
>> committer are updated automatically.  That includes any revocations.
>>
>
> The keys from the ASF ID list also have disadvantages.
> Keys are used to sign artifacts for projects, and need to remain
> available whilst the artifact remains available.
> That includes archived artifacts.
>
>>
>>  -- Dennis E. Hamilton
>> dennis.hamil...@acm.org+1-206-779-9430
>> https://keybase.io/orcmid  PGP F96E 89FF D456 628A
>> X.509 certs used and requested for signed e-mail
>>
>>
>>
>> -Original Message-
>> From: Justin Mclean [mailto:jus...@classsoftware.com]
>> Sent: Sunday, October 12, 2014 22:29
>> To: general@incubator.apache.org
>> Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)
>>
>> Hi,
>>
>>> First, the signing key is present in SVN, but has not been uploaded to the
>>> standard key-servers, nor has it been signed by anyone.
>>
>> I found it here:
>> https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index
>>
>> Even if the key is part of a web trust it may not be part of everyone's web 
>> of trust. I'd see that as a hard requirement to meet.
>>
>> 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
>

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

[RESULT] [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Julian Hyde]

This vote passes with 3 +1s and no 0 or -1 votes:
+1 Alan Gates (mentor)
+1 Justin Mclean
+1 Steven Noels (mentor)

Thanks everyone. We’ll now roll the release out to the mirrors, as soon as
the necessary sub-tasks of
https://issues.apache.org/jira/browse/INFRA-8413 have
been completed.

Julian

Re: [VOTE] Accept Apex into the Apache Incubator

[Julian Hyde]

+1 (binding)

Julian


> On Aug 13, 2015, at 12:40 PM, Gaurav Gupta  wrote:
> 
> +1 (Non-binding)
> 
> -Gaurav
> 
>> On Aug 13, 2015, at 10:22 AM, Pramod Immaneni  wrote:
>> 
>> +1 (Non-binding)
>> 
>> On Thu, Aug 13, 2015 at 7:48 AM, P. Taylor Goetz  wrote:
>> 
>>> Following the discussion thread [1], I would like to call a VOTE for
>>> Accepting Apex as a new Apache Incubator project.
>>> 
>>> The proposal is available on the wiki [2] and is also attached below.
>>> 
>>> The VOTE will be open for at least 72 hours.
>>> 
>>> [ ] +1 Accept Apex into the Incubator
>>> [ ] ±0 No opinion
>>> [ ] -1 Do not accept Apex into the Incubator because…
>>> 
>>> Thanks,
>>> 
>>> -Taylor
>>> 
>>> [1] http://s.apache.org/apex_discuss
>>> [2] https://wiki.apache.org/incubator/ApexProposal
>>> 
>>> 
>>> == Abstract ==
>>> Apex is an enterprise grade native YARN big data-in-motion platform that
>>> unifies stream processing as well as batch processing. Apex processes big
>>> data in-motion in a highly scalable, highly performant, fault tolerant,
>>> stateful, secure, distributed, and an easily operable way. It provides a
>>> simple API that enables users to write or re-use generic Java code, thereby
>>> lowering the expertise needed to write big data applications.
>>> 
>>> Functional and operational specifications are separated. Apex is designed
>>> in a way to enable users to write their own code (aka user defined
>>> functions) as is and leave all operability to the platform. The API is very
>>> simple and is designed to allow users to drop in their code as is. The
>>> platform mainly deals with operability and treats functional code as a
>>> black box. Operability includes fault tolerance, scalability, security,
>>> ease of use, metrics api, webservices, etc. In other words there is no
>>> separation of UDF (user defined functions), as all functional code is UDF.
>>> This frees users to focus on functional development, and lets platform
>>> provide operability support. The same code runs as is with different
>>> operability attributes. The data-in-motion architecture of Apex unifies
>>> stream as well as batch processing in a single platform. Since Apex is a
>>> native YARN application, it leverages all the components of YARN without
>>> duplication. Apex was developed with YARN in mind and has no overlapping
>>> components/functionality with YARN.
>>> 
>>> The Apex platform is supplemented by project Malhar, which is a library of
>>> operators that implement common business logic functions needed by
>>> customers who want to quickly develop applications. These operators provide
>>> access to HDFS, S3, NFS, FTP, and other file systems;  Kafka, ActiveMQ,
>>> RabbitMQ, JMS, and other message systems; MySql, Cassandra, MongoDB, Redis,
>>> HBase, CouchDB and other databases along with JDBC connectors. The Malhar
>>> library also includes a host of other common business logic patterns that
>>> help users to significantly reduce the time it takes to go into production.
>>> Ease of integration with all other big data technologies is one of the
>>> primary missions of Malhar.
>>> 
>>> == Proposal ==
>>> The goal of this proposal is to establish the core engine of DataTorrent
>>> RTS product as an Apache Software Foundation (ASF) project in order to
>>> build a vibrant, diverse, and self-governed open source community around
>>> the technology. DataTorrent will continue to sell management tools,
>>> application building tools, easy to use big data applications, and custom
>>> high end business logic operators. This proposal covers the Apex source
>>> code (written in Java), Apex documentation and other materials currently
>>> available on https://github.com/DataTorrent/Apex. This proposal also
>>> covers the Malhar source code (written in Java), Malhar documentation, and
>>> other materials currently available on
>>> https://github.com/DataTorrent/Malhar. We have done a trademark check on
>>> the name Apex, and have concluded that the Apex name is likely to be a
>>> suitable project name.
>>> 
>>> == Background ==
>>> DataTorrent RTS is a mature and robust product developed as a native YARN
>>> application. RTS 1.0 was launched in summer of 2014; RTS 2.0 was launched
>>> in Jan 2015. Both were well received by customers. RTS 3.0 was launched at
>>> end of July 2015. RTS is among the first enterprise grade platform that was
>>> developed from the ground up as native YARN application. DataTorrent RTS is
>>> currently maintained by engineers as a closed source project. Even though
>>> the engineers behind RTS are experienced software engineers and are
>>> knowledge leaders in data-in-motion platforms, they have had little
>>> exposure to the open source governance process. Customers are currently
>>> running applications based on DataTorrent RTS in production.
>>> 
>>> == Rationale ==
>>> Big data applications written for non-Hadoop platforms typically require
>>> major rewrites  to get them to work with Hadoop. This rewriting crea

Re: [VOTE] Release apache-calcite-1.4.0-incubating

[Julian Hyde]

Forwarding my vote from the Calcite community vote:

+1 (binding)

Julian


> On Aug 28, 2015, at 7:00 PM, Jacques Nadeau  wrote:
> 
> Thanks for helping clarify Marvin.  I didn't realize that Julian was an
> IPMC.  I was only counting the two mentors that voted in our vote.
> 
> On Fri, Aug 28, 2015 at 2:45 PM, Marvin Humphrey 
> wrote:
> 
>> On Fri, Aug 28, 2015 at 2:32 PM, Jacques Nadeau 
>> wrote:
>> 
>>> Vote result:
>>> 8 binding +1 votes
>>> 1 non-binding +1 votes
>>> No -1 votes
>>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DPUH70eyPY3u25O4ayimwOXfBBxiX2txUEcNbUCYODXg%40mail.gmail.com%3E
>> 
>> To remove the ambiguity: three IPMC members have voted +1: Ashutosh
>> Chauhan, Julian Hyde, and Alan Gates.
>> 
>> 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: [VOTE] Accept HAWQ into the Apache Incubator

[Julian Hyde]

+1

Julian

> On Sep 1, 2015, at 6:45 AM, Luciano Resende  wrote:
> 
> On Mon, Aug 31, 2015 at 11:47 AM, Roman Shaposhnik  wrote:
> 
>> Following the discussion earlier:
>>   http://s.apache.org/Gaf
>> 
>> I would like to call a VOTE for accepting HAWQ
>> as a new incubator project.
>> 
>> The proposal is available at:
>>https://wiki.apache.org/incubator/HAWQProposal
>> and is also included at the bottom of this email.
>> 
>> Vote is open until at least Thu, 3 September 2015, 23:59:00 PST
>> 
>> [ ] +1 accept HAWQ into the Apache Incubator
>> [ ] ±0
>> [ ] -1 because...
>> 
>> Thanks,
>> Roman.
>> 
>> == Abstract ==
>> 
>> HAWQ is an advanced enterprise SQL on Hadoop analytic engine built
>> around a robust and high-performance massively-parallel processing
>> (MPP) SQL framework evolved from Pivotal Greenplum DatabaseⓇ.
>> 
>> HAWQ runs natively on Apache HadoopⓇ clusters by tightly integrating
>> with HDFS and YARN. HAWQ supports multiple Hadoop file formats such as
>> Apache Parquet, native HDFS, and Apache Avro. HAWQ is configured and
>> managed as a Hadoop service in Apache Ambari. HAWQ is 100% ANSI SQL
>> compliant (supporting ANSI SQL-92, SQL-99, and SQL-2003, plus OLAP
>> extensions) and supports open database connectivity (ODBC) and Java
>> database connectivity (JDBC), as well. Most business intelligence,
>> data analysis and data visualization tools work with HAWQ out of the
>> box without the need for specialized drivers.
>> 
>> A unique aspect of HAWQ is its integration of statistical and machine
>> learning capabilities that can be natively invoked from SQL or (in the
>> context of PL/Python, PL/Java or PL/R) in massively parallel modes and
>> applied to large data sets across a Hadoop cluster. These capabilities
>> are provided through MADlib – an existing open source, parallel
>> machine-learning library. Given the close ties between the two
>> development communities, the MADlib community has expressed interest
>> in joining HAWQ on its journey into the ASF Incubator and will be
>> submitting a separate, concurrent proposal.
>> 
>> HAWQ will provide more robust and higher performing options for Hadoop
>> environments that demand best-in-class data analytics for business
>> critical purposes. HAWQ is implemented in C and C++.
>> 
>> HAWQ has a few runtime dependencies licensed under the Cat X list:
>>  * gperf (GPL Version 3)
>>  * libgsasl (LGPL Version 2.1)
>>  * libuuid-2.26 (LGPL Version 2)
>> However, given the runtime (dynamic linking) nature of these
>> dependencies it doesn't represent a problem for HAWQ to be considered
>> an ASF project.
>> 
>> == Proposal ==
>> The goal of this proposal is to bring the core of Pivotal Software,
>> Inc.’s (Pivotal) Pivotal HAWQⓇ codebase into the Apache Software
>> Foundation (ASF) in order to build a vibrant, diverse and
>> self-governed open source community around the technology. Pivotal has
>> agreed to transfer the brand name "HAWQ" to Apache Software Foundation
>> and will stop using HAWQ to refer to this software if the project gets
>> accepted into the ASF Incubator under the name of "Apache HAWQ
>> (incubating)". Pivotal will continue to market and sell an analytic
>> engine product that includes Apache HAWQ (incubating). While HAWQ is
>> our primary choice for a name of the project, in anticipation of any
>> potential issues with PODLINGNAMESEARCH we have come up with two
>> alternative names: (1) Hornet; or (2) Grove.
>> 
>> Pivotal is submitting this proposal to donate the HAWQ source code and
>> associated artifacts (documentation, web site content, wiki, etc.) to
>> the Apache Software Foundation Incubator under the Apache License,
>> Version 2.0 and is asking Incubator PMC to establish an open source
>> community.
>> 
>> == Background ==
>> While the ecosystem of open source SQL-on-Hadoop solutions is fairly
>> developed by now, HAWQ has several unique features that will set it
>> apart from existing ASF and non-ASF projects. HAWQ made its debut in
>> 2013 as a closed source product leveraging a decade's worth of product
>> development effort invested in Greenplum DatabaseⓇ. Since then HAWQ
>> has rapidly gained a solid customer base and became available on
>> non-Pivotal distributions of Hadoop.
>> In 2015 HAWQ still leverages the rock solid foundation of Greenplum
>> Database, while at the same time embracing elasticity and resource
>> management native to Hadoop applications. This allows HAWQ to provide
>> superior SQL on Hadoop performance, scalability and coverage while
>> also providing massively-parallel machine learning capabilities and
>> support for native Hadoop file formats. In addition, HAWQ's advanced
>> features include support for complex joins, rich and compliant SQL
>> dialect and industry-differentiating data federation capabilities.
>> Dynamic pipelining and pluggable query optimizer architecture enable
>> HAWQ to perform queries on Hadoop with the speed and scalability
>> required for enterprise data warehou

Re: [VOTE] Release apache-calcite-1.4.0-incubating

[Julian Hyde]

> On Aug 29, 2015, at 5:07 PM, Justin Mclean  wrote:
> LICENSE has some issues that need to be corrected:
> - missing MIT license for ./site/_sass/_font-awesome.scss
> - missing MIT license for ./site/_sass/_normalize.scs
> - missing MIT license for /site/_sass/_gridism.scss
> - missing MIT license for ./site/js/html5shiv.min.js
> - missing MIT license for ./site/js/respond.min.js
> - missing SIL license for ./site/fonts/fontawesome-webfont.*
> 
> And I assume also missing SASS's MIT license.
> 
> Please read [1] on how to add permissive licenses. Note that the licenses 
> have different copyright owners.

My bad. I failed to update LICENSE when I checked in the web site that was 
generated by jekyll. 

> Also what it the provenance of this file?
> ./example/csv/src/test/resources/bug/archers.json
> 
> It looks like it may be part of a script from The Archers [2], do you have 
> permission from the copyright owners to use this?

My bad also. I confess that I am a fan of the world’s longest running soap 
opera, The Archers. The source was http://www.lowfield.co.uk/archers/ 
. License is not clear, so we will have to 
remove that content.

Both of the above are covered by 
https://issues.apache.org/jira/browse/CALCITE-860 
.

Thanks for your eternal vigilance, Justin.

Julian

Calcite graduation review

[Julian Hyde]

The Calcite project is considering graduation. A discussion on the dev list[1] 
is reaching consensus, and we will shortly start a vote on the dev list. It 
would be helpful if someone from the Incubator PMC could review.

Could a shepherd who is not previously familiar with the project please review 
the project and raise any issues that might prevent graduation?

Julian

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CC2D9AF33-71A0-437A-9398-F86F826431C1%40apache.org%3E
 

Re: Calcite graduation review

[Julian Hyde]

Done[2].

I entered today’s date for tasks that were finished long ago.

Julian

[2] http://incubator.apache.org/projects/calcite.html 
<http://incubator.apache.org/projects/calcite.html>

> On Sep 1, 2015, at 6:13 PM, Jake Farrell  wrote:
> 
> Hey Julian
> Can you please make sure that the projects status page is updated, seeing
> new committers added and releases cut but these have not made it to the
> projects status page. Thanks
> 
> -Jake
> 
> On Tue, Sep 1, 2015 at 8:56 PM, Julian Hyde  wrote:
> 
>> The Calcite project is considering graduation. A discussion on the dev
>> list[1] is reaching consensus, and we will shortly start a vote on the dev
>> list. It would be helpful if someone from the Incubator PMC could review.
>> 
>> Could a shepherd who is not previously familiar with the project please
>> review the project and raise any issues that might prevent graduation?
>> 
>> Julian
>> 
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CC2D9AF33-71A0-437A-9398-F86F826431C1%40apache.org%3E
>> <
>> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3cc2d9af33-71a0-437a-9398-f86f82643...@apache.org%3E
>>> 

Re: [VOTE] Release Apache Kylin-1.0-incubating

[Julian Hyde]

Forwarding my vote from dev@kylin:

+1 (binding)

Julian

> On Sep 2, 2015, at 9:26 PM, Henry Saputra  wrote:
> 
> +1 (binding)
> 
> 
> - Henry
> 
> On Wed, Sep 2, 2015 at 12:44 AM, Luke Han  wrote:
>> Hi all,
>> 
>> The Apache Kylin community has voted on and approved a proposal to release
>> Apache Kylin 1.0 (incubating).
>> 
>> We already have applied some suggestion
>> in last vote attempt, please refer to below vote mail thread for detail.
>> 
>> Proposal:
>> http://s.apache.org/kylin-1.0-rc2-vote
>> 
>> Vote result:
>> http://s.apache.org/kylin-1.0-rc2-result
>> 
>> 8 binding +1 votes
>> 5 non-binding +1 votes
>> No -1 votes
>> 
>> 
>> The commit to be voted upon:
>> https://github.com/apache/incubator-kylin/commit/ef067de4ae43303c015118ad39a9aba7172bc250
>> 
>> Its hash is ef067de4ae43303c015118ad39a9aba7172bc250.
>> 
>> The artifacts to be voted on are located here:
>> https://dist.apache.org/repos/dist/dev/incubator/kylin/apache-kylin-1.0-incubating-rc2
>> 
>> The hashes of the artifacts are as follows:
>> src.tar.gz.md5 0789a032965f1a2686adac738a905378
>> src.tar.gz.sha1 d7cc894cbd3cbc606aabcb0cbf3fb728044e55f1
>> 
>> A staged Maven repository is available for review at:
>> https://repository.apache.org/content/repositories/orgapachekylin-1011/
>> 
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/lukehan.asc
>> 
>> Pursuant to the Releases section of the Incubation Policy and with
>> the endorsement of our mentors we would now like to request
>> the permission of the Incubator PMC to publish the release. The vote
>> is open for 72 hours, or until the necessary number of votes (3 +1)
>> is reached.
>> 
>> [ ] +1 Release this package
>> [ ]  0 I don't feel strongly about it, but I'm okay with the release
>> [ ] -1 Do not release this package because...
>> 
>> +1 from Luke
>> 
>> Luke Han, on behalf of Apache Kylin PPMC
> 
> -
> 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: Incubator PMC/Board report for Sep 2015 ([ppmc])

[Julian Hyde]

FWIW, Exactly the same thing happened to Calcite. Missed July, reported in 
August, was asked to report in September. Rather than quibbling, I filed a 
report. (With luck we’ll be graduated before December.)

> On Sep 2, 2015, at 6:24 PM, Marvin Humphrey  wrote:
> 
> On Wed, Sep 2, 2015 at 5:59 PM, Roman Shaposhnik  wrote:
>> I am a little confused as to why DataFU is on the report schedule
>> when we reported last month.
>> 
>> Can anyone, please let me know?
> 
> Looks like the a glitch in the record keeping. DataFu's last report
> was due in July but was delayed one month (which is fine) and as a
> result they got the "monthly" tag added.  It should have been removed
> after the report was filed in August but that didn't happen.  I've
> updated podlings.xml; the next report will be due in October.
> 
> Cheers,
> 
> 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

Calcite graduation vote

[Julian Hyde]

Pursuant to the graduation policy[1] it is my pleasure to inform the IPMC that 
the Calcite community has completed a discussion on graduation[2] and has 
commenced a vote[3].

Julian

[1] http://incubator.apache.org/guides/graduation.html#tlp-community-vote 


[2] http://s.apache.org/ZPC

[3] http://s.apache.org/rvB

Re: [VOTE] Accept MADlib into the Apache Incubator

[Julian Hyde]

+1 (binding)

Julian


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

[DISCUSS] Graduate Calcite from the Apache Incbuator

[Julian Hyde]

The Calcite community has established consensus and held a
successful vote with 20 +1 votes in favor of proposing
graduation to a top-level project, including 12 votes from
committers and 6 votes from IPMC members.

Here are: the discussion on the dev list [1], vote thread
[2] and result [3]. Also relevant are the incubation status
page [4] and a thread on this list requesting review of
whether Calcite met the criteria to graduate[5].

We propose that Calcite is ready to become a top-level
project. If this discussion reaches consensus we will move
to a formal vote.

Below is our proposed resolution.

Julian Hyde, on behalf of Calcite PPMC

[1] http://s.apache.org/ZPC
[2] http://s.apache.org/rvB
[3] http://s.apache.org/sv
[4] http://incubator.apache.org/projects/calcite.html
[5] http://s.apache.org/itP

- - - snip - - -

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 parsing and planning queries on data in a
wide variety of formats.

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

RESOLVED, that the Apache Calcite Project be and hereby is
responsible for the creation and maintenance of software
related to parsing and planning queries on data in a wide
variety of formats; and be it further

RESOLVED, that the office of "Vice President, Apache
Calcite" 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 Calcite Project, and to have
primary responsibility for management of the projects within
the scope of responsibility of the Apache Calcite 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 Calcite Project:

* Alan Gates 
* Aman Sinha 
* Ashutosh Chauhan 
* James R. Taylor 
* Jacques Nadeau 
* Jesús Camacho Rodríguez 
* Jinfeng Ni 
* John Pullokkaran 
* Julian Hyde 
* Nick Dimiduk 
* Steven Noels 
* Ted Dunning 
* Vladimir Sitnikov 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
appointed to the office of Vice President, Apache Calcite,
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 Apache Calcite Project be and hereby is
tasked with the migration and rationalization of the Apache
Incubator Calcite podling; and be it further

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

- - - end - - -

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

Re: [DISCUSS] Graduate Calcite from the Apache Incbuator

[Julian Hyde]

I’m hearing positive noises, so I will start a formal vote.

Julian

> On Sep 14, 2015, at 3:59 PM, Chris Nauroth  wrote:
> 
> +1 (binding)
> 
> --Chris Nauroth
> 
> 
> 
> 
> On 9/12/15, 3:09 PM, "Julian Hyde"  wrote:
> 
>> The Calcite community has established consensus and held a
>> successful vote with 20 +1 votes in favor of proposing
>> graduation to a top-level project, including 12 votes from
>> committers and 6 votes from IPMC members.
>> 
>> Here are: the discussion on the dev list [1], vote thread
>> [2] and result [3]. Also relevant are the incubation status
>> page [4] and a thread on this list requesting review of
>> whether Calcite met the criteria to graduate[5].
>> 
>> We propose that Calcite is ready to become a top-level
>> project. If this discussion reaches consensus we will move
>> to a formal vote.
>> 
>> Below is our proposed resolution.
>> 
>> Julian Hyde, on behalf of Calcite PPMC
>> 
>> [1] http://s.apache.org/ZPC
>> [2] http://s.apache.org/rvB
>> [3] http://s.apache.org/sv
>> [4] http://incubator.apache.org/projects/calcite.html
>> [5] http://s.apache.org/itP
>> 
>> - - - snip - - -
>> 
>> 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 parsing and planning queries on data in a
>> wide variety of formats.
>> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>> Committee (PMC), to be known as the "Apache Calcite
>> Project", be and hereby is established pursuant to Bylaws of
>> the Foundation; and be it further
>> 
>> RESOLVED, that the Apache Calcite Project be and hereby is
>> responsible for the creation and maintenance of software
>> related to parsing and planning queries on data in a wide
>> variety of formats; and be it further
>> 
>> RESOLVED, that the office of "Vice President, Apache
>> Calcite" 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 Calcite Project, and to have
>> primary responsibility for management of the projects within
>> the scope of responsibility of the Apache Calcite 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 Calcite Project:
>> 
>> * Alan Gates 
>> * Aman Sinha 
>> * Ashutosh Chauhan 
>> * James R. Taylor 
>> * Jacques Nadeau 
>> * Jesús Camacho Rodríguez 
>> * Jinfeng Ni 
>> * John Pullokkaran 
>> * Julian Hyde 
>> * Nick Dimiduk 
>> * Steven Noels 
>> * Ted Dunning 
>> * Vladimir Sitnikov 
>> 
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
>> appointed to the office of Vice President, Apache Calcite,
>> 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 Apache Calcite Project be and hereby is
>> tasked with the migration and rationalization of the Apache
>> Incubator Calcite podling; and be it further
>> 
>> RESOLVED, that all responsibilities pertaining to the Apache
>> Incubator Calcite podling encumbered upon the Apache
>> Incubator Project are hereafter discharged.
>> 
>> - - - end - - -
>> 
>> -
>> 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

[VOTE] Graduate Calcite from the Apache Incubator

[Julian Hyde]

This is a vote for Calcite to become a top-level project.

Since joining the Incubator in May, 2014, the Calcite
community has:
* Produced eight IPMC-approved releases under two release
  managers;
* Added five new committers and one new PPMC member;
* Collaborated successfully with several other Apache
projects (Drill, Hive, Kylin, Phoenix, Samza);
* Grown into an active community (typical monthly activity
  is 100 emails, 30 commits and 20 issues fixed);
* Conducted a successful community vote to graduate with
  20 +1 votes, of which 2 were from our mentors, 12 were
  from committers, and 6 were from IPMC members.

Further information: the discussion on the dev list [1],
vote thread [2] and result [3]. Also relevant are the
incubation status page [4] and a thread on this list
requesting review of whether Calcite met the criteria to
graduate [5].

Below is our proposed resolution for the Board.

Please vote:

[ ] +1 Graduate Apache Calcite as a top-level project
[ ] +0
[ ] -1 Do not graduate Apache Calcite because…

Here is my vote:
+1 (binding)

Voting will last 72 hours, ending at 19:00 Pacific on
September 17th.

Julian Hyde, on behalf of Calcite PPMC

[1] http://s.apache.org/ZPC
[2] http://s.apache.org/rvB
[3] http://s.apache.org/sv
[4] http://incubator.apache.org/projects/calcite.html
[5] http://s.apache.org/itP

- - - snip - - -

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 parsing and planning queries on data in a
wide variety of formats.

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

RESOLVED, that the Apache Calcite Project be and hereby is
responsible for the creation and maintenance of software
related to parsing and planning queries on data in a wide
variety of formats; and be it further

RESOLVED, that the office of "Vice President, Apache
Calcite" 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 Calcite Project, and to have
primary responsibility for management of the projects within
the scope of responsibility of the Apache Calcite 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 Calcite Project:

* Alan Gates 
* Aman Sinha 
* Ashutosh Chauhan 
* James R. Taylor 
* Jacques Nadeau 
* Jesús Camacho Rodríguez 
* Jinfeng Ni 
* John Pullokkaran 
* Julian Hyde 
* Nick Dimiduk 
* Steven Noels 
* Ted Dunning 
* Vladimir Sitnikov 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
appointed to the office of Vice President, Apache Calcite,
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 Apache Calcite Project be and hereby is
tasked with the migration and rationalization of the Apache
Incubator Calcite podling; and be it further

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

- - - end - - -


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

[RESULT] [VOTE] Graduate Calcite from the Apache Incubator

[Julian Hyde]

The vote for Calcite to become a top-level project has passed with 14 binding 
and 8 non-binding +1 votes and no 0 or -1 votes.

We will now prepare a resolution for the next Board meeting.

Thank you for all the kind remarks during the vote and over the last few weeks.

14 binding:
* Alan Gates
* Andrew Purtell
* Chris Nauroth
* Henry Saputra
* Hitesh Shah
* John D. Ament
* Julian Hyde
* Owen O'Malley
* P. Taylor Goetz
* Sean Busbey
* Seetharam Venkatesh
* Stack
* Steven Noels
* Ted Dunning

8 non-binding:
* Amol Kekre
* Balaji Ganesan
* Ian Dunlop
* Jacques Nadeau
* Jiang Xu
* Li Yang
* Luke Han
* Nick Dimiduk

Julian


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

Re: Podling Shark Tank at ApacheCON CORE on Thu 1sth of Oct @13:30

[Julian Hyde]

For what it's worth (since we're in Europe and we believe in
recognizing the progeny of our IP), the US program "Shark Tank" is
derived from a British programme "Dragons' Den", which was derived
from a Japanese show "Money Tigers".

Julian


On Wed, Sep 30, 2015 at 6:12 AM, Roman Shaposhnik  wrote:
> Hi!
>
> if you plan to be at ApacheCON CORE
> for the next two days, make sure to check
> out this year's newest addition to our awesome
> agenda: Podling Shark Tank
> http://s.apache.org/gWO
>
> What is Podling Shark Tank I hear you asking?
> It is as though Lightning Talks and US TV
> show Shark Tank fell in love and had a beautiful
> baby. It is a show filled with deep technical insight,
> off the wall questions and it goes something like this:
> https://www.youtube.com/watch?v=opNiKBP7hQo
>
> Our exclusive cast of sharks is second to none:
>* Greg Chase (starring as Barbara Corcoran)
>* Andrew Bayer (starring as Daymond John)
> and
>* Shane Curcuru (starring as Mark Cuban)
>
> and the podling pitches will include:
>* Corinthia (presented by Roman Shaposhnik)
>* Tamaya (presented by Anatole Tresch)
>* Trafodion (presented by Rohit Jain)
>* Ranger (presented by Owen O'Malley)
>* Brooklyn  (presented by Richard Downer)
>
> Join us to have some good time and win prizes.
>
> And remember: last minute entries are super
> welcome but may not end up on the show. Still
> if you want to pitch -- ping me ASAP.
>
> Thanks,
> Roman.
>
> P.S. If you're pitching -- make sure to watch the clip.
> No, really -- go watch the clip. I'll wait...
>
> Ok, that's how your presentation need to be structured.
> Any other questions?
>
> -
> 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] Mentor neutrality policy

[Julian Hyde]

It seems to me that the negatives of your proposed policy outweigh the 
positives.

Presumably the goal is to prevent mentors from making biased decisions due to 
conflicts of interest. There are other approaches to solving CoI, such as 
declaring conflicts of interest and, Apache’s current approach, to trust 
mentors to “wear multiple hats”.

A more pressing problem, in my opinion, is absentee mentors. Your proposed 
changes would make that problem a good deal worse, by eliminating from the pool 
of possible mentors those people who have the most knowledge about the subject 
area and motivation to help the project succeed.

I suggest that we look at “conflict of interest” as a whole, ascertain whether 
it is a significant problem and if so, consider other solutions to it.

Julian

 
> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> 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] Graduate Kylin from the Apache Incubator

[Julian Hyde]

I am a mentor of Kylin and I believe the project is ready to graduate.
They have created a vibrant, open community and are conducting
business in the Apache Way.

One proviso: Let's complete the name search before starting the IPMC
vote. It would be foolish to let that particular cart get in front of
the horse. I don't think that prevents us from discussing graduation.

Julian


On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha  wrote:
> +1
>
> On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:
>
>>+1
>>
>>On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
>>
>>>I would be happy to see kylin graduate.
>>>On Oct 7, 2015 11:28, "Luke Han"  wrote:
>>>
>>>> The Kylin community and project made significant advances during the
>>>> incubating (from Nov 2014) and
>>>> believes it is ready to graduate as a top-level project.
>>>>
>>>> The Apache Kylin is very active. The PPMC doubled in size (added 6
>>>> committers and 2 mentors) and
>>>>  increased diversity in the past year. Released 3 version in the past 6
>>>> months. There were presentations about Kylin
>>>> at most of the big conferences of the world (including Strata+Hadoop
>>>>World
>>>> London, Hadoop Summit San Jose,
>>>> ApacheCon EU, Big Data Technology China, Database Technology Conference
>>>> China) and some meetups (Bay Area,
>>>> Beijing and one is coming in this weekend in Shanghai), and many talks
>>>> around the world.
>>>> The dev mailing list is growing very month, about 500+ topics per month
>>>> now.
>>>> The community created 1000+ JIRA tickets, many patches from
>>>> contributors/committers have been merged into code base.
>>>>
>>>> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
>>>> below
>>>> references to the graduation preparation artifacts:
>>>> * discussion on dev list [1]
>>>> * vote thread [2]
>>>> * podling name search (still in progress) [3]
>>>> * incubation status [4]
>>>> * proposed resolution below
>>>>
>>>> We believe Apache Kylin is ready to become a top-level project and if
>>>>the
>>>> IPMC agree we will move to a formal vote.
>>>> There are a few more items to be updated on the project status page and
>>>> others during the next couple of days.
>>>>
>>>>
>>>> Many thanks to the mentors and the IPMC for the support,
>>>> Luke Han (on behalf of the Apache Kylin PPMC)
>>>>
>>>> [1] http://s.apache.org/KylinDisGraduate
>>>> [2] http://s.apache.org/KylinGraduateVote
>>>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
>>>> [4] http://incubator.apache.org/projects/kylin.html
>>>>
>>>>
>>>>
>>>> Apache Kylin top-level project resolution:
>>>> ===
>>>>
>>>>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, relative to distributed and scalable OLAP engine
>>>>
>>>>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>>>Committee (PMC), to be known as the "Apache Kylin Project",
>>>>be and hereby is established pursuant to Bylaws of the
>>>>Foundation; and be it further
>>>>
>>>>RESOLVED, that the Apache Kylin Project be and hereby is
>>>>responsible for the creation and maintenance of open-source
>>>>software related to distributed and scalable OLAP engine;
>>>>and be it further
>>>>
>>>>RESOLVED, that the office of "Vice President, Kylin" 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 Kylin Project, and to have primary responsibility for
>>>>management of the projects within the scope of responsibility
>>>>of the Apache Kylin Project; and be it further
>>>>
>>>

Re: [VOTE] Accept Concerted into the Apache Incubator

[Julian Hyde]

e and highly performant reads and
>> > joins. Concerted will be collaborating with many open source projects
>> such
>> > as Apache HAWQ (incubating), Apache Hive, Apache Tajo etc to support
>> their
>> > OLAP workloads hence enabling them to support larger set of usecases
>> with a
>> > better throughput. For eg, a star schema in Hive will benefit from having
>> > dimension tables in Concerted with highly efficient and scalable reads
>> and
>> > joins will be very fast. Similar workload for Tajo.
>> >
>> > Concerted will fit in many other use cases in Apache spectrum as well.
>> For
>> > eg, Concerted can be used with Apache Geode for in memory aggregation
>> > indexing. Concerted can also be used with Apache Flink for streaming real
>> > time data into in memory, perform in memory aggregation and then
>> performing
>> > batch processing for efficiency.
>> >
>> >
>> > == A Excessive Fascination with the Apache Brand ==
>> > We believe that the "Apache Way" governance model will provide additional
>> > help to us in finding contributors and growing the community. The
>> community
>> > and development process will make this project more stable and help
>> > establish ubiquitous APIs. In addition, Concerted is looking to support
>> > multiple Apache projects in their use cases and accelerate their
>> > performance while soliciting their support in development of the project.
>> > We will not be using Apache brand for excessive branding or with any
>> > commercial aspects of Concerted. Apache brand will primarily be used for
>> > community building.
>> >
>> > = Documentation =
>> > Public documents are currently in development and will be published soon.
>> >
>> > = Initial Source =
>> > The initial source is written in C++ and is heavily in development. It
>> will
>> > be restructured and released publicly.
>> > We understand that there might be concerns around github source being
>> > developed by only a single person and development not happening after
>> 2013.
>> > The source on github is only the source initially developed as an
>> > independent project hence the limitation. However, due to reason that
>> > project has been present on github for a while now, it has attracted
>> > attention and people have been using and developing it locally. For eg,
>> > Ingenium Data System took an interest in the project and locally
>> developed
>> > it and used it in an upcoming product they are going to release soon. The
>> > project now wants to accumulate all independent development efforts and
>> > help attract people to grow the community and project. We are currently
>> in
>> > process of updating github repository and making branches for all local
>> > development efforts.
>> >
>> > = Source and Intellectual Property Submission Plan =
>> >
>> > We intend the entire code base to be licensed under the Apache License,
>> > Version 2.0.
>> >
>> > = External Dependencies =
>> > Currently, Concerted only depends on g++ compiler and pthreads. pthreads
>> > will be replaced by Boost in next release.
>> >
>> > = Cryptography =
>> >
>> > N/A
>> >
>> > = Required Resources =
>> > == Mailling List ==
>> >  *priv...@concerted.incubator.apache.org (moderated subscriptions)
>> >  *comm...@concerted.incubator.apache.org
>> >  *d...@concerted.incubator.apache.org
>> >  *iss...@concerted.incubator.apache.org
>> >
>> > == Git Repository ==
>> >
>> > https://git-wip-us.apache.org/repos/asf/incubator-concerted.git
>> >
>> > == Issue Tracking ==
>> > Jira Concerted (CONCERTED)
>> >
>> > == Other Resources ==
>> >  * Continuous Integration
>> >   * Jenkins
>> >  * Wiki
>> >   * cwiki.apache.org/confluence/display/CONCERTED
>> >
>> > = Initial Committers =
>> >  * Roman Shaposhnik 
>> >  * Daniel Dai 
>> >  * Jake Farrell 
>> >  * Lars Hofhansl 
>> >  * Julian Hyde 
>> >  * Chris Nauroth 
>> >  * Pavel Stehule 
>> >  * Amrish 
>> >  * Nupur S 
>> >  * Atri Sharma 
>> >  * Nishith Singhal 
>> >  * Michael Down 
>> >  * Vijayakumar Ramdoss 
>> >  * Wang Albert 
>> >  * Hans-Jurgen Schonig 
>> >  * Kris Popat 
>> >  * Ayrton Gomesz 
>> >
>> > = Affiliations =
>> >  * Roman Shaposhnik (Pivotal)
>> >  * Daniel Dai (HortonWorks)
>> >  * Jake Farrell (Acquia)
>> >  * Lars Hofhansl (Salesforce)
>> >  * Julian Hyde (HortonWorks)
>> >  * Chris Nauroth (HortonWorks)
>> >  * Pavel Stehule (GoodData)
>> >  * Amrish (Ingenium Data Systems)
>> >  * Nupur S (Ingenium Data Systems)
>> >  * Atri Sharma (Barclays)
>> >  * Nishith Singhal (Wipro)
>> >  * Michael Down (Barclays)
>> >  * Vijayakumar Ramdoss (EMC)
>> >  * Wang Albert (Lehigh University)
>> >  * Hans- Jurgen Schonig (CyberTec)
>> >  * Kris Popat (CETIS LLP)
>> >  * Ayrton Gomesz (IQLabs)
>> >
>> > The nominated mentors are employees of HortonWorks, Acquia, and
>> Salesforce.
>> >
>> >  * Daniel Dai (HortonWorks)
>> >  * Jake Farrell (Acquia)
>> >  * Lars Hofhansl (Salesforce)
>> >  * Julian Hyde (HortonWorks)
>> >  * Chris Nauroth (HortonWorks)
>> >
>> > = Sponsors =
>> >
>> > == Champion ==
>> >
>> >  * Roman Shaposhnik (rvs AT apache DOT org)
>> >
>> > == Nominated Mentors ==
>> >
>> >  * Daniel Dai 
>> >  * Jake Farrell 
>> >  * Lars Hofhansl 
>> >  * Julian Hyde 
>> >  * Chris Nauroth 
>> >
>> > == Sponsoring Entity ==
>> > Apache Incubator
>>
>> -
>> 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 Concerted into the Apache Incubator

[Julian Hyde]

Thanks for clarifying.

+1 (binding)

Julian


On Fri, Oct 9, 2015 at 2:09 PM, Atri Sharma  wrote:
> Hi,
>
> Please find answers below:
>
> 1) The main source code on Github wasn't updated for a while. However, the
> original and main core was written in 2013 and has been open source since
> then. As we discussed earlier current code base is only starting point for
> complete development and will be first integrated with silo work done
> independent and then used as starting implementation.
>
> 2) The JNI native API when optimized can provide great performance ( I have
> written an application using it and it is on production systems for many
> years). I think we can still provide a high performance API to the C++ core
> and that is something I am personally working on right now.
> On 10 Oct 2015 02:31, "Julian Hyde"  wrote:
>
>> I have agreed to be a mentor to Concerted and I think it is an
>> interesting idea. I am inclined to vote for it entering the incubator.
>>
>> However since the project has not released any source code yet, there
>> are a couple of questions I'd like to get answered for the record:
>>
>> 1. How many lines of existing code are there? What is their approximate
>> age?
>>
>> 2. Concerted is in C/C++ but you mention interfacing with JVM-based
>> products like Hive. How you would interface with other languages? Is
>> it a goal of the project to create APIs to other languages such as
>> Java? Would access from those languages be as efficient as native
>> access?
>>
>> I apologize that I didn't bring these up in the discussion thread.
>>
>> Julian
>>
>>
>> On Fri, Oct 9, 2015 at 11:53 AM, Ayrton Gomesz 
>> wrote:
>> > +1
>> > @henry.saputra thanks man
>> > On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:
>> >
>> >> +1 (binding)
>> >> Good luck guys!
>> >>
>> >> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
>> >> > Hi all,
>> >> >
>> >> > Following the discussion about Concerted I would like to call a vote
>> for
>> >> > accepting Concerted as a new incubator project.
>> >> >
>> >> > The proposal text is included below, and available on the wiki:
>> >> >
>> >> > https://wiki.apache.org/incubator/ConcertedProposal
>> >> >
>> >> > The vote is open for 72 hours:
>> >> >
>> >> > [ ] +1 accept Concerted in the Incubator
>> >> > [ ] ±0
>> >> > [ ] -1 (please give reason)
>> >> >
>> >> > Regards,
>> >> >
>> >> > Atri
>> >> >
>> >> > = Abstract =
>> >> >
>> >> > Concerted is an in memory write less read more engine aimed to provide
>> >> > extreme read performance with very high degree of concurrency and
>> >> > scalability and focus on minimizing own resource footprint.
>> >> >
>> >> > = Proposal =
>> >> > Concerted is built on the principal that a new type of workload is
>> >> > dominating the scene and is now needed to be supported. These are the
>> >> large
>> >> > data set analytical workloads being analyzed or used on large
>> clusters or
>> >> > high power machines. Large analytical workloads depend on the ability
>> to
>> >> > query large data sets efficiently and in high concurrency while
>> >> maintaining
>> >> > semantics such as immediate consistency. An in memory engine designed
>> to
>> >> > support extreme read queries while providing support for aggregation
>> >> > through various features (such as multidimensional representation of
>> >> > tuples) will accelerate many usecases around large scale analytics.
>> >> >
>> >> > Concerted believes that best understanding of user application lies
>> with
>> >> > user application developer. The need for massive read scaling should
>> be
>> >> on
>> >> > demand and should be flexible to the level that user can decide as to
>> >> which
>> >> > representation and access of data suits his/her current requirements.
>> >> > Hence, Concerted is not built in a traditional client/server model.
>> >> > Concerted provides users with an API which can be used to load, read,
>> >> > update and delete data. User chooses which data structu

Re: Require projects to have solid API docs

[Julian Hyde]

Per [1], "Apache projects should provide sufficient documentation [… so that … 
] users can both make use of our software freely”.

And: "users of Apache software should be able to find our software, learn how 
to use it, and actually apply it to all its common use cases solely by going to 
the Apache project’s own website”.

So: there should be some documentation about how to use the project on the 
project web site. That documentation does not need to be in any particular 
form, such as javadoc.

Julian

[1] https://community.apache.org/projectIndependence.html


> On Oct 11, 2015, at 9:29 AM, Luciano Resende  wrote:
> 
> On Sun, Oct 11, 2015 at 9:15 AM, Ross Gardler 
> wrote:
> 
>> No. That’s not the role of the foundation. However, ensuring people
>> contributing to the docs are recognized like any other contributor is the
>> role of the foundation. Can you help contribute to such docs?
>> 
>> 
>> 
> +1
> 
> -- 
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/


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

Re: Require projects to have solid API docs

[Julian Hyde]

On Sun, Oct 11, 2015 at 1:11 PM, Alan D. Cabrera  wrote:
> Should != Must

Yes, I know. But I didn't want to have everyone leap into yet another
long-winded debate with no one even having mentioned that there is
existing policy on this matter.

Julian

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

Re: Mentor disengagement - a suggestion

[Julian Hyde]

It's not activity on the dev list, or even report signoffs, that
matter most. Podlings, especially new podlings, have lots and lots of
questions, especially about infrastructure. Without at least two
responsive mentors to field those questions you feel like banging your
head on the wall. And you start wondering why you left the comfort and
convenience of github and whether Apache itself is fascinated by its
own brand.

Before you ask, you won't get podlings to send their questions to
another list, because we're all too proud to ask questions which in
retrospect always turn out to be dumb questions.

It's not possible to measure that kind of mentor activity, so I think
people are inclined to measure the "public" forms of activity as proxy
indicators.

Julian


On Tue, Oct 13, 2015 at 4:19 AM, Jim Jagielski  wrote:
> For me, I consider being a mentor as I do being a member of a PMC.
> Occasionally one simply lacks cycles to be actively involved, but
> one is involve enough to see that others *ARE* involved, and so I
> am "unconcerned" about my inactivity during those times.
>
> My understanding is that this is OK and its one of the reasons
> why we *have* multiple mentors.
>
> "Shaming" inactive mentors would be akin to "shaming" PMC members who
> didn't post on the dev@ list this month, or who didn't vote on a release
> or etc...
>
> I am not, of course, referring to mentors who are truly MIA month in and
> month out. But, as someone said, if you remove those from the equation,
> the list of "active" mentors is pretty constant.
>
> So the question is "Is there a difference or problem between a podling
> with 10 mentors, of which 4 are 'active', as compared to a podling with
> 4 mentors, all of which are 'active'"??
>
>> On Oct 13, 2015, at 2:29 AM, Ted Dunning  wrote:
>>
>> On Mon, Oct 12, 2015 at 11:05 PM, Sam Ruby  wrote:
>>
 Sounds like reaching out to the inactive mentors is a great idea and I
 think we have a great example here of how complicated it can be.
>>>
>>> Nope.  I posted that link knowing that my name would be on it, and
>>> advocated that we should be having exactly this discussion.  I should
>>> either become more active on this, or (and probably more likely)
>>> remove myself as a mentor for this podling.
>>
>>
>> And possibly by so doing become a great example to others of us who can't
>> admit to ourselves that we are over-extended.
>
>
> -
> 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] Graduate Apache Kylin from the Apache Incubator

[Julian Hyde]

+1 (binding)

Great job building a vibrant community, and good luck!

Julian

> On Oct 16, 2015, at 1:22 AM, 蒋旭  wrote:
> 
> +1
> Jiang Xu
> -- 原始邮件 --
> 发件人: "Henry Saputra";;
> 发送时间: 2015年10月16日(星期五) 上午9:16
> 收件人: "general@incubator.apache.org"; 
> 
> 主题: Re: [VOTE] Graduate Apache Kylin from the Apache Incubator
> 
> 
> 
> +1 (binding)
> 
> On Thursday, October 15, 2015, Luke Han  wrote:
> 
>> The Apache Kylin community and project made significant advances during the
>> incubating (from Nov 2014) and
>> believes it is ready to graduate as a top-level project.
>> 
>> The Apache Kylin is very active. The PPMC doubled in size (added 6
>> committers and 2 mentors) and
>> increased diversity in the past year. Released 3 version in the past 6
>> months. There were presentations about Apache Kylin
>> at most of the big conferences of the world (including Strata+Hadoop World
>> London, Hadoop Summit San Jose,
>> ApacheCon EU, Big Data Technology China, Database Technology Conference
>> China) and some meetups (Bay Area,
>> Beijing and one is coming in this weekend in Shanghai), and many talks
>> around the world.
>> The dev mailing list is growing very month, about 500+ topics per month
>> now.
>> The community created 1000+ JIRA tickets, many patches from
>> contributors/committers have been merged into code base.
>> 
>> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
>> below
>> references to the graduation preparation artifacts:
>> * discussion on dev list [1]
>> * vote thread [2]
>> * podling name search [3]
>> * incubation status [4]
>> * proposed resolution below
>> 
>> We believe Apache Kylin is ready to become a top-level project and if the
>> IPMC agree we will move to a formal vote.
>> There are a few more items to be updated on the project status page and
>> others during the next couple of days.
>> 
>> 
>> Many thanks to the mentors and the IPMC for the support,
>> Luke Han (on behalf of the Apache Kylin PPMC)
>> 
>> [1] http://s.apache.org/KylinDisGraduate
>> [2] http://s.apache.org/KylinGraduateVote
>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
>> [4] http://incubator.apache.org/projects/kylin.html
>> 
>> 
>> 
>> Apache Kylin top-level project resolution:
>> ===
>> 
>>   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, relative to distributed and scalable OLAP engine
>> 
>>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>   Committee (PMC), to be known as the "Apache Kylin Project",
>>   be and hereby is established pursuant to Bylaws of the
>>   Foundation; and be it further
>> 
>>   RESOLVED, that the Apache Kylin Project be and hereby is
>>   responsible for the creation and maintenance of open-source
>>   software related to distributed and scalable OLAP engine;
>>   and be it further
>> 
>>   RESOLVED, that the office of "Vice President, Kylin" 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 Kylin Project, and to have primary responsibility for
>>   management of the projects within the scope of responsibility
>>   of the Apache Kylin 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 Kylin Project:
>> 
>>* Dayue Gao 
>>* Jason Zhong 
>>* Julian Hyde 
>>* Luke Han 
>>* Henry Saputra 
>>* Hongbin Ma 
>>* Hua Huang 
>>* Owen O'Malley 
>>* P. Taylor Goetz 
>>* Qianhao Zhou 
>>* Shaofeng Shi 
>>* Song Yi 
>>* Ted Dunning 
>>* Xu Jiang 
>>* Yang Li 
>>* Yerui Sun < sunyerui at apache dot org>
>> 
>> 
>>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Luke Han
>>   be appointed to the office of Vice President,Apac

Re: [VOTE] Release Apache Kylin 1.1-incubating (rc1)

[Julian Hyde]

Forwarding my vote from the dev list:

+1 (binding)

> On Oct 19, 2015, at 1:18 AM, 周千昊  wrote:
> 
> +1
> mvn test passed
> 
> hongbin ma 于2015年10月19日周一 上午11:28写道：
> 
>> +1
>> 
>> unit test passed on my CI
>> 
>> On Mon, Oct 19, 2015 at 10:46 AM, Li Yang  wrote:
>> 
>>> +1
>>> 
>>> Checksum is correct.
>>> 
>>> Unit test passed on java version "1.7.0_71", OpenJDK Runtime Environment
>>> (rhel-2.5.3.1.el6-x86_64 u71-b14)
>>> 
>>> 
>>> On Thu, Oct 15, 2015 at 10:00 AM, Luke Han  wrote:
>>> 
 +1
 
 MD5 & SHA1 checksum verified
 License files are all there
 
 Unit Test passed
 
 
 
 Best Regards!
 -
 
 Luke Han
 
 On Thu, Oct 15, 2015 at 9:42 AM, ShaoFeng Shi 
 wrote:
 
> Hi all,
> 
> The Apache Kylin community has voted on and approved a proposal to
 release
> Apache Kylin 1.1-incubating.
> 
> Proposal:http://s.apache.org/Jzu
> 
> Vote result:
> 7 binding +1 votes
> 6 non-binding +1 votes
> No -1 voteshttp://s.apache.org/kylin-1.1-result_rc1
> 
> 
> The commit to be voted
> upon:
> 
 
>>> 
>> https://github.com/apache/incubator-kylin/commit/1955a2f9aea7b7f608f0496c00807715ea4246a5
> 
> Its hash is 1955a2f9aea7b7f608f0496c00807715ea4246a5.
> 
> The artifacts to be voted on are located
> here:
> 
 
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/kylin/apache-kylin-1.1-incubating-rc1/
> 
> The hashes of the artifacts are as follows:
> apache-kylin-1.1-incubating-src.tar.gz.md5
 18dfbb012e1eb807b1a5c1b134a537aa
> apache-kylin-1.1-incubating-src.tar.gz.sha1
> 041ee010c67a0b5611d9dd06f7fd6f37388c5374
> 
> A staged Maven repository is available for review
> at:
 
>> https://repository.apache.org/content/repositories/orgapachekylin-1012/
> 
> Release artifacts are signed with the following
> key:https://people.apache.org/keys/committer/shaofengshi.asc
> 
> Pursuant to the Releases section of the Incubation Policy and with
> the endorsement of our mentors we would now like to request
> the permission of the Incubator PMC to publish the release. The vote
> is open for 72 hours, or until the necessary number of votes (3 +1)
> is reached.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
> 
> 
> Shaofeng Shi, on behalf of Apache Kylin ppmcshaofeng...@apache.org
> 
 
>>> 
>> 
>> 
>> 
>> --
>> Regards,
>> 
>> *Bin Mahone | 马洪宾*
>> Apache Kylin: http://kylin.io
>> Github: https://github.com/binmahone
>> 


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

Re: [DISCUSS] Eagle incubator proposal

[Julian Hyde]

diversify this community further through Apache. We presented Eagle at the
>>>>> hadoop summit in china and garnered interest from different companies who
>>>>> use hadoop extensively.
>>>>> 
>>>>> Inexperience with Open Source
>>>>> The core developers are all active users and followers of open source.
>>>>> They are already committers and contributors to the Eagle Github project.
>>>>> All have been involved with the source code that has been released under 
>>>>> an
>>>>> open source license, and several of them also have experience developing
>>>>> code in an open source environment. Though the core set of Developers do
>>>>> not have Apache Open Source experience, there are plans to onboard
>>>>> individuals with Apache open source experience on to the project. Apache
>>>>> Kylin PMC members are also in the same ebay organization. We work very
>>>>> closely with Apache Ranger committers and are looking forward to find
>>>>> meaningful integrations to improve the security of hadoop platform.
>>>>> 
>>>>> Homogenous Developers
>>>>> The core developers are from eBay. Today the problem of monitoring data
>>>>> activities to find and stop threats is a universal problem faced by all 
>>>>> the
>>>>> businesses. Apache Incubation process encourages an open and diverse
>>>>> meritocratic community. Eagle intends to make every possible effort to
>>>>> build a diverse, vibrant and involved community and has already received
>>>>> substantial interest from various organizations.
>>>>> 
>>>>> Reliance on Salaried Developers
>>>>> eBay invested in Eagle as the monitoring solution for Hadoop clusters and
>>>>> some of its key engineers are working full time on the project. In
>>>>> addition, since there is a growing need for securing sensitive data access
>>>>> we need a data activity monitoring solution for Hadoop, we look forward to
>>>>> other Apache developers and researchers to contribute to the project.
>>>>> Additional contributors, including Apache committers have plans to join
>>>>> this effort shortly. Also key to addressing the risk associated with
>>>>> relying on Salaried developers from a single entity is to increase the
>>>>> diversity of the contributors and actively lobby for Domain experts in the
>>>>> security space to contribute. Eagle intends to do this.
>>>>> 
>>>>> Relationships with Other Apache Products
>>>>> Eagle has a strong relationship and dependency with Apache Hadoop, HBase,
>>>>> Spark, Kafka and Storm. Being part of Apache’s Incubation community, could
>>>>> help with a closer collaboration among these projects and as well as
>>>>> others. An Excessive Fascination with the Apache Brand Eagle is proposing
>>>>> to enter incubation at Apache in order to help efforts to diversify the
>>>>> committer-base, not so much to capitalize on the Apache brand. The Eagle
>>>>> project is in production use already inside eBay, but is not expected to 
>>>>> be
>>>>> an eBay product for external customers. As such, the Eagle project is not
>>>>> seeking to use the Apache brand as a marketing tool.
>>>>> 
>>>>> Documentation
>>>>> Information about Eagle can be found at https://github.com/eBay/Eagle.
>>>>> The following link provide more information about Eagle http://goeagle.io
>>>>> .
>>>>> 
>>>>> Initial Source
>>>>> Eagle has been under development since 2014 by a team of engineers at
>>>>> eBay Inc. It is currently hosted on Github.com under an Apache license 2.0
>>>>> at https://github.com/eBay/Eagle. Once in incubation we will be moving
>>>>> the code base to apache git library.
>>>>> 
>>>>> External Dependencies
>>>>> Eagle has the following external dependencies.
>>>>> Basic
>>>>> •JDK 1.7+
>>>>> •Scala 2.10.4
>>>>> •Apache Maven
>>>>> •JUnit
>>>>> •Log4j
>>>>> •Slf4j
>>>>> •Apache Commons
>>>>> •Apache Commons Math3
>>>>> •Jackson
>>>>> •Siddhi CEP engine
>>>>> 
>>>>> Hadoop
>>>>> •Apache Hadoop
>>>>> •Apache HBase
>>>>> •Apache Hive
>>>>> •Apache Zookeeper
>>>>> •Apache Curator
>>>>> 
>>>>> Apache Spark
>>>>> •Spark Core Library
>>>>> 
>>>>> REST Service
>>>>> •Jersey
>>>>> 
>>>>> Query
>>>>> •Antlr
>>>>> 
>>>>> Stream processing
>>>>> •Apache Storm
>>>>> •Apache Kafka
>>>>> 
>>>>> Web
>>>>> •AngularJS
>>>>> •jQuery
>>>>> •Bootstrap V3
>>>>> •Moment JS
>>>>> •Admin LTE
>>>>> •html5shiv
>>>>> •respond
>>>>> •Fastclick
>>>>> •Date Range Picker
>>>>> •Flot JS
>>>>> 
>>>>> Cryptography
>>>>> Eagle will eventually support encryption on the wire. This is not one of
>>>>> the initial goals, and we do not expect Eagle to be a controlled export
>>>>> item due to the use of encryption. Eagle supports but does not require the
>>>>> Kerberos authentication mechanism to access secured Hadoop services.
>>>>> 
>>>>> Required Resources
>>>>> 
>>>>> Mailing List
>>>>> •eagle-private for private PMC discussions
>>>>> •eagle-dev for developers
>>>>> •eagle-commits for all commits
>>>>> •eagle-users for all eagle users
>>>>> 
>>>>> Subversion Directory
>>>>> •Git is the preferred source control system.
>>>>> 
>>>>> Issue Tracking
>>>>> •JIRA Eagle (Eagle)
>>>>> 
>>>>> Other Resources
>>>>> The existing code already has unit tests so we will make use of existing
>>>>> Apache continuous testing infrastructure. The resulting load should not be
>>>>> very large.
>>>>> 
>>>>> Initial Committers
>>>>> •Seshu Adunuthula 
>>>>> •Arun Manoharan 
>>>>> •Edward Zhang 
>>>>> •Hao Chen 
>>>>> •Chaitali Gupta 
>>>>> •Libin Sun 
>>>>> •Jilin Jiang 
>>>>> •Qingwen Zhao 
>>>>> •Hemanth Dendukuri 
>>>>> •Senthil Kumar 
>>>>> •Tan Chen 
>>>>> 
>>>>> Affiliations
>>>>> The initial committers are employees of eBay Inc.
>>>>> 
>>>>> Sponsors
>>>>> 
>>>>> Champion
>>>>> •Henry Saputra  - Apache IPMC member
>>>>> 
>>>>> Nominated Mentors
>>>>> •Owen O’Malley < omalley at apache dot org > - Apache IPMC member,
>>>>> Hortonworks
>>>>> •Henry Saputra  - Apache IPMC member
>>>>> •Julian Hyde  - Apache IPMC member,
>>>>> Hortonworks
>>>>> 
>>>>> Sponsoring Entity
>>>>> We are requesting the Incubator to sponsor this project.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbono...@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>> 
>>>> -
>>>> 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: [VOTE] Accept Eagle into Apache Incubation

[Julian Hyde]

All have been involved with the source code that has been released under an
>> open source license, and several of them also have experience developing
>> code in an open source environment. Though the core set of Developers do
>> not have Apache Open Source experience, there are plans to onboard
>> individuals with Apache open source experience on to the project. Apache
>> Kylin PMC members are also in the same ebay organization. We work very
>> closely with Apache Ranger committers and are looking forward to find
>> meaningful integrations to improve the security of hadoop platform.
>> 
>> Homogenous Developers
>> The core developers are from eBay. Today the problem of monitoring data
>> activities to find and stop threats is a universal problem faced by all the
>> businesses. Apache Incubation process encourages an open and diverse
>> meritocratic community. Eagle intends to make every possible effort to
>> build a diverse, vibrant and involved community and has already received
>> substantial interest from various organizations.
>> 
>> Reliance on Salaried Developers
>> eBay invested in Eagle as the monitoring solution for Hadoop clusters and
>> some of its key engineers are working full time on the project. In
>> addition, since there is a growing need for securing sensitive data access
>> we need a data activity monitoring solution for Hadoop, we look forward to
>> other Apache developers and researchers to contribute to the project.
>> Additional contributors, including Apache committers have plans to join
>> this effort shortly. Also key to addressing the risk associated with
>> relying on Salaried developers from a single entity is to increase the
>> diversity of the contributors and actively lobby for Domain experts in the
>> security space to contribute. Eagle intends to do this.
>> 
>> Relationships with Other Apache Products
>> Eagle has a strong relationship and dependency with Apache Hadoop, HBase,
>> Spark, Kafka and Storm. Being part of Apache’s Incubation community, could
>> help with a closer collaboration among these projects and as well as
>> others. An Excessive Fascination with the Apache Brand Eagle is proposing
>> to enter incubation at Apache in order to help efforts to diversify the
>> committer-base, not so much to capitalize on the Apache brand. The Eagle
>> project is in production use already inside eBay, but is not expected to be
>> an eBay product for external customers. As such, the Eagle project is not
>> seeking to use the Apache brand as a marketing tool.
>> 
>> Documentation
>> Information about Eagle can be found at https://github.com/eBay/Eagle.
>> The following link provide more information about Eagle http://goeagle.io<
>> http://goeagle.io/>.
>> 
>> Initial Source
>> Eagle has been under development since 2014 by a team of engineers at eBay
>> Inc. It is currently hosted on Github.com under an Apache license 2.0 at
>> https://github.com/eBay/Eagle. Once in incubation we will be moving the
>> code base to apache git library.
>> 
>> External Dependencies
>> Eagle has the following external dependencies.
>> Basic
>> •JDK 1.7+
>> •Scala 2.10.4
>> •Apache Maven
>> •JUnit
>> •Log4j
>> •Slf4j
>> •Apache Commons
>> •Apache Commons Math3
>> •Jackson
>> •Siddhi CEP engine
>> 
>> Hadoop
>> •Apache Hadoop
>> •Apache HBase
>> •Apache Hive
>> •Apache Zookeeper
>> •Apache Curator
>> 
>> Apache Spark
>> •Spark Core Library
>> 
>> REST Service
>> •Jersey
>> 
>> Query
>> •Antlr
>> 
>> Stream processing
>> •Apache Storm
>> •Apache Kafka
>> 
>> Web
>> •AngularJS
>> •jQuery
>> •Bootstrap V3
>> •Moment JS
>> •Admin LTE
>> •html5shiv
>> •respond
>> •Fastclick
>> •Date Range Picker
>> •Flot JS
>> 
>> Cryptography
>> Eagle will eventually support encryption on the wire. This is not one of
>> the initial goals, and we do not expect Eagle to be a controlled export
>> item due to the use of encryption. Eagle supports but does not require the
>> Kerberos authentication mechanism to access secured Hadoop services.
>> 
>> Required Resources
>> 
>> Mailing List
>> •eagle-private for private PMC discussions
>> •eagle-dev for developers
>> •eagle-commits for all commits
>> •eagle-users for all eagle users
>> 
>> Subversion Directory
>> •Git is the preferred source control system.
>> 
>> Issue Tracking
>> •JIRA Eagle (Eagle)
>> 
>> Other Resources
>> The existing code already has unit tests so we will make use of existing
>> Apache continuous testing infrastructure. The resulting load should not be
>> very large.
>> 
>> Initial Committers
>> •Seshu Adunuthula 
>> •Arun Manoharan 
>> •Edward Zhang 
>> •Hao Chen 
>> •Chaitali Gupta 
>> •Libin Sun 
>> •Jilin Jiang 
>> •Qingwen Zhao 
>> •Hemanth Dendukuri 
>> •Senthil Kumar 
>> 
>> 
>> Affiliations
>> The initial committers are employees of eBay Inc.
>> 
>> Sponsors
>> 
>> Champion
>> •Henry Saputra  - Apache IPMC member
>> 
>> Nominated Mentors
>> •Owen O’Malley < omalley at apache dot org > - Apache IPMC member,
>> Hortonworks
>> •Henry Saputra  - Apache IPMC member
>> •Julian Hyde  - Apache IPMC member,
>> Hortonworks
>> •Amareshwari Sriramdasu  - Apache IPMC
>> member
>> •Taylor Goetz  - Apache IPMC member, Hortonworks
>> 
>> Sponsoring Entity
>> We are requesting the Incubator to sponsor this project.
>> 
>> 


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

Re: [VOTE] Accept SystemML into Apache Incubator

[Julian Hyde]

+1 (binding)

> On Oct 28, 2015, at 11:17 AM, Seetharam Venkatesh  
> wrote:
> 
> +1 (binding).
> 
> Thanks!
> 
> On Wed, Oct 28, 2015 at 8:39 AM Till Westmann  wrote:
> 
>> +1
>> 
>> On 27 Oct 2015, at 21:52, Luciano Resende wrote:
>> 
>>> After initial discussion, please vote on the acceptance of SystemML
>>> Project for incubation at the Apache Incubator. The full proposal is
>>> available at the end of this message and on the wiki at :
>>> 
>>> https://wiki.apache.org/incubator/SystemML
>>> 
>>> 
>>> Please cast your votes:
>>> 
>>> [ ] +1, bring SystemML into Incubator
>>> [ ] +0, I don't care either way
>>> [ ] -1, do not bring SystemML into Incubator, because...
>>> 
>>> The vote is open for the next 72 hours and only votes from the
>>> Incubator PMC are binding.
>>> 
>>> 
>>> = SystemML =
>>> 
>>> == Abstract ==
>>> 
>>> SystemML provides declarative large-scale machine learning (ML) that
>>> aims
>>> at flexible specification of ML algorithms and automatic generation of
>>> hybrid runtime plans ranging from single node, in-memory computations,
>>> to
>>> distributed computations on Apache Hadoop MapReduce and  Apache Spark.
>>> ML
>>> algorithms are expressed in an R-like syntax, that includes linear
>>> algebra
>>> primitives, statistical functions, and ML-specific constructs. This
>>> high-level language significantly increases the productivity of data
>>> scientists as it provides (1) full flexibility in expressing custom
>>> analytics, and (2) data independence from the underlying input formats
>>> and
>>> physical data representations. Automatic optimization according to
>>> data
>>> characteristics such as distribution on the disk file system, and
>>> sparsity
>>> as well as processing characteristics in the distributed environment
>>> like
>>> number of nodes, CPU, memory per node, ensures both efficiency and
>>> scalability.
>>> 
>>> == Proposal ==
>>> 
>>> The goal of SystemML is to create a commercial friendly, scalable and
>>> extensible machine learning framework for data scientists to create or
>>> extend machine learning algorithms using a declarative syntax. The
>>> machine
>>> learning framework enables data scientists to develop algorithms
>>> locally
>>> without the need of a distributed cluster, and scale up and scale out
>>> the
>>> execution of these algorithms to distributed Apache Hadoop MapReduce
>>> or
>>> Apache Spark clusters.
>>> 
>>> == Background ==
>>> 
>>> SystemML started as a research project in the IBM Almaden Research
>>> Center
>>> around 2007 aiming to enable data scientists to develop machine
>>> learning
>>> algorithms independent of data and cluster characteristics.
>>> 
>>> == Rationale ==
>>> 
>>> SystemML enables the specification of machine learning algorithms
>>> using a
>>> declarative machine learning (DML) language. DML includes linear
>>> algebra
>>> primitives, statistical functions, and additional constructs. This
>>> high-level language significantly increases the productivity of data
>>> scientists as it provides (1) full flexibility in expressing custom
>>> analytics and (2) data independence from the underlying input formats
>>> and
>>> physical data representations.
>>> 
>>> SystemML computations can be executed in a variety of different modes.
>>> It
>>> supports single node in-memory computations and large-scale
>>> distributed
>>> cluster computations. This allows the user to quickly prototype new
>>> algorithms in local environments but automatically scale to large data
>>> sizes as well without changing the algorithm implementation.
>>> 
>>> Algorithms specified in DML are dynamically compiled and optimized
>>> based on
>>> data and cluster characteristics using rule-based and cost-based
>>> optimization techniques. The optimizer automatically generates hybrid
>>> runtime execution plans ranging from in-memory single-node execution
>>> to
>>> distributed computations on Apache Spark or Apache Hadoop MapReduce.
>>> This
>>> ensures both efficiency and scalability. Automatic optimization
>>> reduces or
>>> eliminates the need to hand-tune distributed runtime execution plans
>>> and
>>> system configurations.
>>> 
>>> == Initial Goals ==
>>> 
>>> The initial goals to move SystemML to the Apache Incubator is to
>>> broaden
>>> the community foster the contributions from data scientists to develop
>>> new
>>> machine learning algorithms and enhance the existing ones. Ultimately,
>>> this
>>> may lead to the creation of an industry standard in specifying machine
>>> learning algorithms.
>>> 
>>> == Current Status ==
>>> 
>>> The initial code has been developed at the IBM Almaden Research Center
>>> in
>>> California and has recently been made available in GitHub under the
>>> Apache
>>> Software License 2.0. The project currently supports a single node (in
>>> memory computation) as well as distributed computations utilizing
>>> Apache
>>> Hadoop MapReduce or Apache Spark clusters.
>>> 
>>> === Meritocr

Re: [VOTE] Graduate Groovy from the Incubator

[Julian Hyde]

+1 (binding)

Looked over the mailing lists, JIRA, releases. Project seems to be ticking over 
nicely. Good luck!

Julian


> On Oct 28, 2015, at 1:43 PM, Konstantin Boudnik  wrote:
> 
> +1 (binding, reiterating my earlier vote on dev@groovy)
> 
> On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote:
>> Following discussions [1] about its current status, the Groovy community
>> has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s
>> total, 5 are binding:
>> 
>>Guillaume Laforge
>>Cédric Champeau
>>Paul King
>>Jochen Theodorou
>>Pascal Schumacher
>>Emmanuel Lécharny (binding)
>>Bertrand Delacretaz (binding)
>>Andrew Bayer (binding)
>>Jim Jagielski (binding)
>>Konstantin Boudnik (binding)
>>Russel Winder
>>Guillaume Alleon
>> 
>> The Groovy community has:
>> * completed all required paperwork:
>>https://incubator.apache.org/projects/groovy.html
>> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
>> * completed the name check procedure:
>>https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
>> * addressed 50+ JIRAs:
>>http://is.gd/1tACON
>> * voted in multiple new committers/PPMC members
>> 
>> Therefore, I'm calling a VOTE to graduate Groovy with the following Board
>> resolution. The VOTE will run for at least 72 hours, ending
>> Saturday, October 31st 8 PM PST.
>> 
>> [ ] +1 Graduate Apache Groovy from the Incubator.
>> [ ] +0 Don't care.
>> [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
>> 
>> Regards,
>>Cos
>> 
>> [1] http://is.gd/DX41lO
>> [2] http://is.gd/pPweq3
>> [3] http://is.gd/VTLiqO
>> 
>>  Apache Groovy graduation resolution draft
>> 
>> Establish the Apache Groovy Top-Level 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 evolution
>> and maintenance of the Groovy programming language,
>> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> (PMC), to be known as the "Apache Groovy Project", be and hereby is
>> established pursuant to Bylaws of the Foundation; and be it further
>> 
>> RESOLVED, that the Apache Groovy Project be and hereby is responsible
>> for the evolution and maintenance of the Groovy programming language;
>> and be it further
>> 
>> RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy
>> Project, and to have primary responsibility for management of the
>> projects within the scope of responsibility of the Apache Groovy
>> 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 Groovy Project
>> PMC:
>> 
>>Cédric Champeau 
>>Paul King 
>>Guillaume Laforge 
>>Pascal Schumacher 
>>Jochen Theodorou 
>>Andrew Bayer 
>>Konstantin Boudnik 
>> 
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
>> appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with
>> the migration and rationalization of the Apache Incubator Groovy
>> podling; and be it further
>> 
>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> Groovy 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: New Podling Website

[Julian Hyde]

+1 to jekyll also.

I’m a git fanboy but in my opinion, for the purposes of publishing web sites 
svnpubsub is superior to gitpubsub. Why? Websites contain a lot of generated 
code such as javadoc, and I don’t want that living in my git repo (and everyone 
else’s copy of it) forever. I recommend keeping the source of your web site 
(markdown, a few images, and of course the code from which the javadoc is 
generated) in git in a “site” folder, and map the generated “site/target” 
folder to svn. 

Julian

> On Nov 3, 2015, at 8:12 AM, Luke Han  wrote:
> 
> Jekyll is a awesome tool, easy to use with Markdown supported and
> static HTML will be generated for the final website...
> 
> Recommend to try it and feel free to check our how to guide as a reference:
> http://kylin.incubator.apache.org/development/howto_docs.html
> 
> Thanks.
> 
> Luke
> 
> 
> 
> Best Regards!
> -
> 
> Luke Han
> 
> On Wed, Nov 4, 2015 at 12:05 AM, Luciano Resende 
> wrote:
> 
>> What's the recommended technology to use to build a new podling website ?
>> In the past I have used CMS, but I have seen recent discussions that CMS
>> might be getting deprecated... I was wondering if there is something around
>> Markdown, or should I just go for pure HTML ?
>> 
>> Also, I would like to setup gitpubsub, but the current whimsy tool only
>> give the svnpubsub option or cms.
>> 
>> Thoughts are welcome...
>> 
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>> 


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

Re: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Julian Hyde]

I’d like to clarify one thing. I believe that the licensing issue [1] was fixed 
in release 1.1-incubating.

Issues were raised during the 1.1 release vote, and the vote may have had some 
procedural problems, and release 1.0 had the aforementioned problem, but 
release 1.1 is sound.

Julian

[1] https://issues.apache.org/jira/browse/KYLIN-999

> On Nov 3, 2015, at 2:38 PM, John D. Ament  wrote:
> 
> Sure, to reiterate comments made in other threads.
> 
> The issue started with a missing SGA.  The SGA missing was problematic for
> a few reasons:
> 
> - The discussion thread was started without all required pre-steps resolved.
> - The vote thread was started before the SGA was submitted to the secretary.
> 
> In the meanwhile, a release vote was started for Kylin where supposedly
> previously fixed licensing issues were found to not be resolved.  In that
> case, it was noted that the issue was raised before, the JIRA marked as
> resolved, however the issue wasn't actually resolved.  From there, it seems
> that pressure was put on the IPMC member who had voted -1 to change his
> vote.  From my point of view, a graduating podling shouldn't have licensing
> issues in releases, due to the risks that it raises.  It seems odd to me
> that two major licensing problems came up so quickly for this one podling.
> 
> At this point, licensing issues to me do block the graduation of Kylin.  It
> can be resolved with a new release vote that fixes the licensing issue and
> I'll happy vote +1 if all licensing problems are resolved.  I would
> encourage the mentors to closely compare Kylin to the recently proposed
> maturity model and see if there are any gaps.
> 
> John
> 
> On Tue, Nov 3, 2015 at 2:27 PM Marvin Humphrey 
> wrote:
> 
>> On Mon, Nov 2, 2015 at 5:06 PM, John D. Ament 
>> wrote:
>> 
>>> At this point, I'd request that my vote remain listed as -1 on the board
>>> resolution.
>> 
>> A -1 on a graduation resolution is significant.  While a -1 on a release
>> VOTE
>> does not block the release, a -1 on a VOTE like graduation, entry into the
>> incubator, policy change, etc, ordinarily blocks progress.
>> 
>> We handle things this way at Apache because consensus decision keeps
>> communities together.  When issues are decided by majority rule, the
>> minority's opinions can be disregarded -- and the losing faction ends up
>> isolated.  In contrast, when issues are decided by consensus, the majority
>> has
>> to go the extra mile to consider the opinions of the minority and possibly
>> adjust their proposals.
>> 
>> So it would be helpful if you would please clarify whether you intend to
>> block
>> Kylin's graduation this month.  If not, please consider changing your
>> position
>> to -0 on graduation.  On the other hand, if you do intend to block
>> graduation,
>> please indicate what could persuade you to change your position.
>> 
>> 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: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Julian Hyde]

I stand corrected.

I now agree that kylin-1.1-incubating has a licensing issue.

I must say, it did not help that KYLIN-999 was marked "fixed in 1.1"
and the innocuous-looking KYLIN-1095 opened in its place.

I think Kylin needs to have a clean release, with no licensing issues,
before graduation.

Julian


On Tue, Nov 3, 2015 at 4:23 PM, Justin Mclean  wrote:
> HI,
>
> Oddly in the 1.x-staging branch  this has been done:
> https://github.com/apache/incubator-kylin/commit/4e483dacd45933da90a3941e01991814430c684f
>
> I guess I didn’t explain clearly enough how the issue should be addressed, 
> I’ll add the info to the JIRA.
>
> 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: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Julian Hyde]

On Tue, Nov 3, 2015 at 5:45 PM, Luke Han  wrote:
> To
> keep things simple, the new release will continue mark as v1.1 since
> there's no much code changes.

The release will have a significant difference in content. Giving a
distinct release an identical release number will not simplify things!
I suggest you call it 1.1.1 or something.

Julian

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

Re: Project Website Template

[Julian Hyde]

+1 

I had the same thought when I built Calcite’s site based on jekyll (actually 
cloned from Orc’s site). Thanks for making this template — I’m sure it will be 
helpful to new projects.

We should make it clear that it is optional, of course. But when Calcite 
entered the incubator there were entirely too many choices (and opportunities 
to make mistakes). The whole svnpubsub vs cms question, for instance, delayed 
our web site by about 6 months because we weren’t sure whether we could 
backtrack once we had made a decision. So I think it would be useful if there 
were some default choices to get incubator projects off and running quickly.

I also think it would be useful to provide a template for maven/java based 
projects. There would be a pom.xml, module/pom.xml and 
module/org/apache/foo/Foo.java, and just enough content in the pom.xml to be 
able to make a release by typing “mvn release:prepare … mvn release:perform”. 
If anyone is interested I’ll do it.

Luciano, Did you have a place in mind to put your template site? I think it 
would need to be in an apache project, not in github, so that any podling can 
import it without worrying about IP contamination.

Julian



> On Nov 7, 2015, at 1:21 PM, Ted Dunning  wrote:
> 
> 
> Easy is good
> 
> 
> The Jekyll work flow has worked well in the project I have mentored.  
> 
> Sent from my iPhone
> 
>> On Nov 7, 2015, at 10:04, Luciano Resende  wrote:
>> 
>> I have just spent a day or so building a new podling website based on
>> Jekyll and I tried to model it as a template, where a new project/podling
>> can easily modify _data/project.yml and configure it's name, dev list, user
>> list, jira, source repository, etc.
>> 
>> I was wondering if this would be good as a "template" where new projects
>> that come on board could easily fork to start their website and just change
>> the styles and contents of main page, and voila, the site would be ready,
>> with all the required trademarks and other apache requirements, etc
>> 
>> Thoughts ?
>> 
>> -- 
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
> 
> -
> 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: Project Website Template

[Julian Hyde]

> On Nov 7, 2015, at 6:40 PM, Luciano Resende  wrote:
> 
> On Sat, Nov 7, 2015 at 7:35 PM, Julian Hyde  wrote:
> 
>> I also think it would be useful to provide a template for maven/java based
>> projects. There would be a pom.xml, module/pom.xml and
>> module/org/apache/foo/Foo.java, and just enough content in the pom.xml to
>> be able to make a release by typing “mvn release:prepare … mvn
>> release:perform”. If anyone is interested I’ll do it.
> 
> I believe this is already available if your "parent pom" inherit from
> "apache pom".
> See: http://svn.apache.org/repos/asf/maven/pom/tags/apache-17/

In my experience you need a lot more in a pom than to just inherit from the 
apache pom. For example you need to configure maven-assembly-plugin to generate 
a artifacts called apache-foo-x.y-src rather than foo-x.y-src, and use 
checksum-maven-plugin to generate md5 and sha-1 checksums. Most projects will 
probably also want checkstyle, to generate a git.properties file containing the 
commit id, and set up some RAT exclusions.

Julian


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

Re: [VOTE] Release Apache Kylin 1.1.1 (incubating)

[Julian Hyde]

Forwarding my vote from dev@:

+1 binding

Julian


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

Re: Project Website Template

[Julian Hyde]

> On Nov 19, 2015, at 5:42 PM, Luciano Resende  wrote:
> 
> The strawman of the template is available in the newly created git
> repository
> https://git-wip-us.apache.org/repos/asf/apache-website-template.git


And mirrored at https://github.com/apache/apache-website-template 
, I see. It could use 
LICENSE and NOTICE files (including appropriate remarks about the included 
non-ASL files), a README, and headers on all files. I’ll start creating PRs at 
github.

Julian

Re: [VOTE] Accept Kudu into the Apache Incubator

[Julian Hyde]

+1

> On Nov 24, 2015, at 11:33 AM, Todd Lipcon  wrote:
> 
> On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon  wrote:
> 
>> Hi all,
>> 
>> Discussion on the [DISCUSS] thread seems to have wound down, so I'd like
>> to call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal
>> is pasted below and also available on the wiki at:
>> https://wiki.apache.org/incubator/KuduProposal
>> 
>> The proposal is unchanged since the original version, except for the
>> addition of Carl Steinbach as a Mentor.
>> 
>> Please cast your votes:
>> 
>> [] +1, accept Kudu into the Incubator
>> [] +/-0, positive/negative non-counted expression of feelings
>> [] -1, do not accept Kudu into the incubator (please state reasoning)
>> 
>> 
> I'll start the voting with my +1 (binding, assuming it's permitted to vote
> on your own proposal!)


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

Re: [VOTE] Accept Impala into the Apache Incubator

[Julian Hyde]

+1 (binding)

> On Nov 26, 2015, at 11:50 AM, Konstantin Boudnik  wrote:
> 
> Come to think of it a bit more, yes I am not satisfied with the outcome of
> the CTR/RTC exchange in the project.
> 
> Hence changing my vote to
> -1 [binding]
> 
> On Thu, Nov 26, 2015 at 11:47AM, Konstantin Boudnik wrote:
>> -0 [binding]
>> 
>> On Tue, Nov 24, 2015 at 01:03PM, Henry Robinson wrote:
>>> Hi -
>>> 
>>> The [DISCUSS] thread has been quiet for a few days, so I think there's been
>>> sufficient opportunity for discussion around our proposal to bring Impala
>>> to the ASF Incubator.
>>> 
>>> I'd like to call a VOTE on that proposal, which is on the wiki at
>>> https://wiki.apache.org/incubator/ImpalaProposal, and which I've pasted
>>> below.
>>> 
>>> During the discussion period, the proposal has been amended to add Brock
>>> Noland as a new mentor, to add one missed committer from the list and to
>>> correct some issues with the dependency list.
>>> 
>>> Please cast your votes as follows:
>>> 
>>> [] +1, accept Impala into the Incubator
>>> [] +/-0, non-counted vote to express a disposition
>>> [] -1, do not accept Impala into the Incubator (please give your reason(s))
>>> 
>>> As with the concurrent Kudu vote, I propose leaving the vote open for a
>>> full seven days (to close at Tuesday, December 1st at noon PST), due to the
>>> upcoming US holiday.
>>> 
>>> Thanks,
>>> Henry
>>> 
>>> 
>>> 
>>> = Abstract =
>>> Impala is a high-performance C++ and Java SQL query engine for data stored
>>> in Apache Hadoop-based clusters.
>>> 
>>> = Proposal =
>>> 
>>> We propose to contribute the Impala codebase and associated artifacts (e.g.
>>> documentation, web-site content etc.) to the Apache Software Foundation
>>> with the intent of forming a productive, meritocratic and open community
>>> around Impala’s continued development, according to the ‘Apache Way’.
>>> 
>>> Cloudera owns several trademarks regarding Impala, and proposes to transfer
>>> ownership of those trademarks in full to the ASF.
>>> 
>>> = Background =
>>> Engineers at Cloudera developed Impala and released it as an
>>> Apache-licensed open-source project in Fall 2012. Impala was written as a
>>> brand-new, modern C++ SQL engine targeted from the start for data stored in
>>> Apache Hadoop clusters.
>>> 
>>> Impala’s most important benefit to users is high-performance, making it
>>> extremely appropriate for common enterprise analytic and business
>>> intelligence workloads. This is achieved by a number of software
>>> techniques, including: native support for data stored in HDFS and related
>>> filesystems, just-in-time compilation and optimization of individual query
>>> plans, high-performance C++ codebase and massively-parallel distributed
>>> architecture. In benchmarks, Impala is routinely amongst the very highest
>>> performing SQL query engines.
>>> 
>>> = Rationale =
>>> 
>>> Despite the exciting innovation in the so-called ‘big-data’ space, SQL
>>> remains by far the most common interface for interacting with data in both
>>> traditional warehouses and modern ‘big-data’ clusters. There is clearly a
>>> need, as evidenced by the eager adoption of Impala and other SQL engines in
>>> enterprise contexts, for a query engine that offers the familiar SQL
>>> interface, but that has been specifically designed to operate in massive,
>>> distributed clusters rather than in traditional, fixed-hardware,
>>> warehouse-specific deployments. Impala is one such query engine.
>>> 
>>> We believe that the ASF is the right venue to foster an open-source
>>> community around Impala’s development. We expect that Impala will benefit
>>> from more productive collaboration with related Apache projects, and under
>>> the auspices of the ASF will attract talented contributors who will push
>>> Impala’s development forward at pace.
>>> 
>>> We believe that the timing is right for Impala’s development to move
>>> wholesale to the ASF: Impala is well-established, has been Apache-licensed
>>> open-source for more than three years, and the core project is relatively
>>> stable. We are excited to see where an ASF-based community can take Impala
>>> from this strong starting point.
>>> 
>>> = Initial Goals =
>>> Our initial goals are as follows:
>>> 
>>> * Establish ASF-compatible engineering practices and workflows
>>> * Refactor and publish existing internal build scripts and test
>>> infrastructure, in order to make them usable by any community member.
>>> * Transfer source code, documentation and associated artifacts to the ASF.
>>> * Grow the user and developer communities
>>> 
>>> = Current Status =
>>> 
>>> Impala is developed as an Apache-licensed open-source project. The source
>>> code is available at http://github.com/cloudera/Impala, and developer
>>> documentation is at https://github.com/cloudera/Impala/wiki. The majority
>>> of commits to the project have come from Cloudera-employed developers, but
>>> we have accepted some contributions from individuals from

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

[Julian Hyde]

Greg,

May I suggest a compromise? Enter incubation with no explicit commit policy and 
let the community choose a commit policy if and when they see fit.

Julian


> On Dec 1, 2015, at 2:35 PM, Greg Stein  wrote:
> 
> On Tue, Dec 1, 2015 at 4:32 PM, Bertrand Delacretaz 
> wrote:
> 
>> On Tue, Dec 1, 2015 at 10:51 PM, Henry Robinson  wrote:
>>> ...
>>> Binding -1s (4):
>>>Greg Stein
>>>Ralph Goers
>>>Roman Shaposhnik
>>>Konstantin Boudnik ...
>> 
>> Please indicate how the issues that are behind these -1s have been
>> addressed.
>> 
>> I might have missed something, just had a quick look at the VOTE thread.
>> 
> 
> They have not been addressed.
> 
> If I may speak for all of us: basically, we want to see podlings use CTR
> rather than begin with RTC. We believe that will grow a more inclusive
> community, which is one of the more serious problems that podlings tend to
> run into.
> 
> In this case, the podling is explicitly doing RTC, so we -1'd its entrance
> to the ASF.
> 
> Cheers,
> -g


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

Re: Impala commit policy

[Julian Hyde]

“No explicit commit policy” means that only committers can commit. It is each 
committer’s discretion whether they ask for others to review the change before 
they commit it, whether they check in code that doesn’t build, whether they run 
the test suite before committing.

This policy is the bare constitutional minimum. We would all hope and expect 
that the community would quickly agree on some policies, but that is up the 
community. They are not stupid, they want to produce high-quality software, and 
they want to grow their community, and they will figure out a policy that 
achieves these goals.

Julian


  

> On Dec 2, 2015, at 12:40 PM, Konstantin Boudnik  wrote:
> 
> I am not sure what "start with no explicit commit policy" even means. Will
> there be no commits, until the discussion on the subject happens?
> 
> How code changes will be going into the source base?
>  Cos
> 
> On Wed, Dec 02, 2015 at 10:01AM, Tom White wrote:
>> The vote to accept Impala into the incubator has passed
>> (http://s.apache.org/u6r), however there are still some concerns about
>> CTR/RTC. My main takeaways from the CTR/RTC thread are that it's not a
>> binary choice, and that it's entirely reasonable that different
>> communities have different commit policies at the ASF.
>> 
>> I think Julian Hyde's suggestion that the Impala podling start with no
>> explicit commit policy is a good one. Incubation should be used as a
>> time to work out what works best for a project. The initial Impala
>> community should discuss the commit policy as they go through the
>> process of setting up ASF infra and start growing the podling. In
>> particular this will include how Gerrit can be used as a tool to
>> facilitate reviews, and how that fits with ASF culture, which is
>> something that other projects are looking at too.
>> 
>> Cheers,
>> Tom
>> 
>> -
>> 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: Impala commit policy

[Julian Hyde]

Thanks, Roman. For the record, I don’t plan to contribute to Impala or Kudu, 
and I don’t like strict commit policies such as RTC. But I wanted to stand up 
for “states' rights”, the right of podlings and projects to determine their own 
processes and cultures.

Julian


> On Dec 2, 2015, at 6:42 PM, Roman Shaposhnik  wrote:
> 
> On Wed, Dec 2, 2015 at 4:24 PM, Julian Hyde  wrote:
>> “No explicit commit policy” means that only committers can commit.
>> It is each committer’s discretion whether they ask for others to review
>> the change before they commit it, whether they check in code that doesn’t
>> build, whether they run the test suite before committing.
>> 
>> This policy is the bare constitutional minimum. We would all hope and expect
>> that the community would quickly agree on some policies, but that is up the 
>> community.
>> They are not stupid, they want to produce high-quality software, and they 
>> want to grow
>> their community, and they will figure out a policy that achieves these goals.
> 
> If that's the expectation that is internalized by the podling community than
> I guess my concerns are somewhat taken care of to a point where I'd
> be comfortable giving the proposal a +0.
> 
> Let me explain why it is a +0 instead of +1. This will also be an opportunity
> for me to clarify my seemingly inconsistent position with Kudu proposal (which
> I deliberately +1ed).
> 
> It all comes back to trust and inclusiveness. I thought that Greg was super
> convincing at articulating that CTR policy is an indication, a proxy if you 
> will
> for those qualities. If CTR is there -- I know that the community is
> trusting and
> inclusive. My -1 for Impala was based on their strong resistance to CTR as
> a proxy measure of how ready they are to accept the "Apache Way". Them
> fighting the idea of CTR gave me a strong indication that they are resisting
> to being trusting and inclusive.
> 
> Now, of course, as any astute student of logic will know, necessity
> and sufficiency
> is not the same thing. While a presence of CTR policy is a strong indication 
> of
> the community getting the "Apache Way" the lack of it is not necessarily an
> indication of them not getting it. Impala community, however has one extra
> strike against it that wasn't allowing me to give it the same benefit
> of the doubt
> that Kudu community got (hence +1 for Kudu despite their instance on RTC).
> 
> Impala and its existing community are *not* new to Open Source. They've been
> out on GitHub since late 2012 and they have operated under a very explicit
> BDFL model. Based on their past attitude towards external contributions
> (personalized via statement of the project lead)  I have strong
> reasons to believe
> that they are going to have really tough time adjusting to the Apache 
> governance
> model AND when I saw that strong resistance to CTR that was it for me.
> 
> That said, this thread and the expectations articulated by Tom and others
> make me more comfortable. However, the lack of *actionable* suggestion
> for how they are going to integrate with Apache governance model
> makes it +0 and not +1.
> 
> Thanks,
> Roman.
> 
> -
> 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 Metron into Apache Incubator

[Julian Hyde]

+1 (binding)


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

December reports - Eagle and Concerted are running late

[Julian Hyde]

I am the mentor of two new projects - Eagle and Concerted. It seems that 
neither has filed a report yet. Concerted received a reminder and has a 
template report generated in https://wiki.apache.org/incubator/December2015 
; Eagle did not receive a 
reminder and its template does not appear on the page.

The report was due on Wed 2nd, but I have contacted both projects and asked 
them to file ASAP.

Any idea why Eagle did not appear on the schedule? (It might well be my fault, 
making a mistake setting up the schedule.)

Julian

Re: December reports - Eagle and Concerted are running late

[Julian Hyde]

On Fri, Dec 4, 2015 at 3:18 PM, Henry Saputra  wrote:
> I am seeing Eagle is in group 2: http://incubator.apache.org/report-groups.txt

And I see that it was you who put it in group 2, in r1711145 to podlings.xml. :)

But think they should be monthly at this point. December will be their
first report, monthly in Jan and Feb, then their next report will be
May per group 2. I'll fix it.

Julian

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

Re: apache-website-template git commit: Add LICENSE and NOTICE files

[Julian Hyde]

I’ve been making some changes to the template and submitting them as github 
pull requests. (I made 5 pull requests a couple of weeks ago, which weren’t 
noticed, and Luciano subsequently made very some similar changes. Frustrating.)

I don’t want to clutter this list with dev traffic, but there’s no other forum. 
In the absence of a dev list, Luciano, can I suggest that you watch github pull 
requests [1] closely. We can discuss on github, as long as you notice the pull 
requests come in.

Julian

[1] https://github.com/apache/apache-website-template/pulls


> On Dec 3, 2015, at 11:27 AM, Luciano Resende  wrote:
> 
> On Thu, Dec 3, 2015 at 6:16 AM, Marvin Humphrey 
> wrote:
> 
>> On Thu, Dec 3, 2015 at 5:17 AM, sebb  wrote:
>>> PING
>> 
>> I'd also like to see this addressed.  Licensing documentation for Incubator
>> sample code should adhere to best practices.
>> 
>>> On 28 November 2015 at 22:59, sebb  wrote:
 On 28 November 2015 at 16:26,   wrote:
>> 
> +The following components included on this website are distributed
>> under MIT license :
> +
> +- Jekyll
> +- Jekyll Bootstrap
> +- Bootstrap
> +- jQuery
> +
> +The MIT License (MIT):
> +
> +Permission is hereby granted, free of charge, to any person obtaining
>> a copy
> +of this software and associated documentation files (the "Software"),
>> to deal
> +in the Software without restriction, including without limitation the
>> rights
> +to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> sell
> +copies of the Software, and to permit persons to whom the Software is
> +furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice shall be
>> included in all
> +copies or substantial portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
>> SHALL THE
> +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING FROM,
> +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS IN THE
> +SOFTWARE.
> +
> +
 
 The LICENSE looks OK.
>> 
>> +1, it's OK, though I'd make one suggestion.
>> 
>> The addition of the MIT license text minus the copyright notice (the
>> intent is
>> clearly to generalize so that it applies to 4 different dependencies) is a
>> bit
>> irregular.  The copyright notice is an integral part of the MIT license --
>> it's actually a license template and is only completed when the copyright
>> notice has the owner filled in.
>> 
>>http://opensource.org/licenses/MIT
>> 
>> To addresss the irregularity, I'd suggest either prepending the template
>> line
>> `Copyright (c)  ` -- or simply omitting the text
>> of
>> the MIT license, instead including filepath pointers to where the deps
>> can be found in the distro.
>> 
> 
>> http://git-wip-us.apache.org/repos/asf/apache-website-template/blob/9e881e24/NOTICE
> --
> diff --git a/NOTICE b/NOTICE
> new file mode 100644
> index 000..a4fed15
> --- /dev/null
> +++ b/NOTICE
> @@ -0,0 +1,11 @@
 
 The ASF Copright header is missing
 
 See http://www.apache.org/legal/src-headers.html#notice
 
>> 
>> +1
>> 
>> Just the copyright notice, i.e. this:
>> 
>>  Apache [PRODUCT_NAME]
>>  Copyright [] The Apache Software Foundation
>> 
>> Actually, what should "[PRODUCT_NAME]" be in this case?
>> 
> +This product includes software developed at
> +The Apache Software Foundation (http://www.apache.org/).
> +
 
 That paragraph is OK
 
> +This product uses Jekyll software (http://jekyllrb.com/)
> +Copyright (c) 2008-2015 Tom Preston-Werner
> +
> +This product includes Boostrap software (http://getbootstrap.com/)
> +Copyright (c) 2011-2015 Twitter, Inc
> +
> +This product includes jQuery software (http://jquery.com/)
> +Copyright jQuery Foundation and other contributors,
>> https://jquery.org/
 
 AFAICT these 3 attributions are NOT necessary for MIT licensed code, see
 
 http://www.apache.org/dev/licensing-howto.html#permissive-deps
>> 
>> +1, those should definitely be removed.
>> 
>> Marvin Humphrey
>> 
> 
> 
> Again, apologies for taking a bit long to address this, as these comments
> got automatically archived.
> 
> I have addressed both of comments now, where :
> 
> - License now have one entry per dependency, with proper copyright notice
> - Notice file has been cleaned up and added Apache Copyright entry
> 
> Please let me know if there are other issues that still needs to be
> addressed.
> 
> -- 
> Luciano Resende

Re: apache-website-template git commit: Add LICENSE and NOTICE files

[Julian Hyde]

Thanks, Luciano. I've got a couple of issues to discuss, which I'll
log as github issues, so we can discuss there.

Julian


On Fri, Dec 4, 2015 at 10:37 PM, Luciano Resende  wrote:
> I have merged your changes now, and will push as soon as a fix couple
> little navigation issues.
>
> Thanks.
>
> On Friday, December 4, 2015, Julian Hyde  wrote:
>
>> I’ve been making some changes to the template and submitting them as
>> github pull requests. (I made 5 pull requests a couple of weeks ago, which
>> weren’t noticed, and Luciano subsequently made very some similar changes.
>> Frustrating.)
>>
>> I don’t want to clutter this list with dev traffic, but there’s no other
>> forum. In the absence of a dev list, Luciano, can I suggest that you watch
>> github pull requests [1] closely. We can discuss on github, as long as you
>> notice the pull requests come in.
>>
>> Julian
>>
>> [1] https://github.com/apache/apache-website-template/pulls
>>
>>
>> > On Dec 3, 2015, at 11:27 AM, Luciano Resende > > wrote:
>> >
>> > On Thu, Dec 3, 2015 at 6:16 AM, Marvin Humphrey > >
>> > wrote:
>> >
>> >> On Thu, Dec 3, 2015 at 5:17 AM, sebb >
>> wrote:
>> >>> PING
>> >>
>> >> I'd also like to see this addressed.  Licensing documentation for
>> Incubator
>> >> sample code should adhere to best practices.
>> >>
>> >>> On 28 November 2015 at 22:59, sebb >
>> wrote:
>> >>>> On 28 November 2015 at 16:26,  >
>> wrote:
>> >>
>> >>>>> +The following components included on this website are distributed
>> >> under MIT license :
>> >>>>> +
>> >>>>> +- Jekyll
>> >>>>> +- Jekyll Bootstrap
>> >>>>> +- Bootstrap
>> >>>>> +- jQuery
>> >>>>> +
>> >>>>> +The MIT License (MIT):
>> >>>>> +
>> >>>>> +Permission is hereby granted, free of charge, to any person
>> obtaining
>> >> a copy
>> >>>>> +of this software and associated documentation files (the
>> "Software"),
>> >> to deal
>> >>>>> +in the Software without restriction, including without limitation
>> the
>> >> rights
>> >>>>> +to use, copy, modify, merge, publish, distribute, sublicense, and/or
>> >> sell
>> >>>>> +copies of the Software, and to permit persons to whom the Software
>> is
>> >>>>> +furnished to do so, subject to the following conditions:
>> >>>>> +
>> >>>>> +The above copyright notice and this permission notice shall be
>> >> included in all
>> >>>>> +copies or substantial portions of the Software.
>> >>>>> +
>> >>>>> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> >> EXPRESS OR
>> >>>>> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> >> MERCHANTABILITY,
>> >>>>> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
>> >> SHALL THE
>> >>>>> +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> >>>>> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> >> ARISING FROM,
>> >>>>> +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >> DEALINGS IN THE
>> >>>>> +SOFTWARE.
>> >>>>> +
>> >>>>> +
>> >>>>
>> >>>> The LICENSE looks OK.
>> >>
>> >> +1, it's OK, though I'd make one suggestion.
>> >>
>> >> The addition of the MIT license text minus the copyright notice (the
>> >> intent is
>> >> clearly to generalize so that it applies to 4 different dependencies)
>> is a
>> >> bit
>> >> irregular.  The copyright notice is an integral part of the MIT license
>> --
>> >> it's actually a license template and is only completed when the
>> copyright
>> >> notice has the owner filled in.
>> >>
>> >>http://opensource.org/licenses/MIT
>> >>
>> >> To addresss the irregularity, I'd suggest either prepending the template
>> >> line
>> >> `Copyright (c)  ` 

Re: December reports - Eagle and Concerted are running late

[Julian Hyde]

I just posted Concerted’s report to the wiki. Apologies that it is so late, but 
Guarav Shukla from Concerted wrote the report a couple of days ago and wasn’t 
able to post it due to lack of karma. I figured that if they’ve gone to the 
effort to write the report, we might as well file it.

I also adjusted the project summary from “no report” to “getting started in the 
Incubator”. Hope that is OK.

Julian


> On Dec 4, 2015, at 8:38 PM, Henry Saputra  wrote:
> 
> Ah yes, I remember now it was me as part of the bootstrap, you are right.
> 
> Sorry about the mishap =(
> 
> Thanks Julian for catching the error.
> 
> - Henry
> 
> On Fri, Dec 4, 2015 at 3:45 PM, Julian Hyde  wrote:
>> On Fri, Dec 4, 2015 at 3:18 PM, Henry Saputra  
>> wrote:
>>> I am seeing Eagle is in group 2: 
>>> http://incubator.apache.org/report-groups.txt
>> 
>> And I see that it was you who put it in group 2, in r1711145 to 
>> podlings.xml. :)
>> 
>> But think they should be monthly at this point. December will be their
>> first report, monthly in Jan and Feb, then their next report will be
>> May per group 2. I'll fix it.
>> 
>> Julian
>> 
>> -
>> 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: DRAFT report December 2015 -- please review

[Julian Hyde]

Marvin,

Thanks for this. I don’t recall whether your preview “DRAFT report … please 
review” messages have contained detailed commentary. As someone who writes 
reports and also signs off podlings’ reports in the mentor role, it is very 
helpful to hear what you consider to be useful content.

Julian


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

Re: interested in joining the IPMC

[Julian Hyde]

After Marvin's message I was curious enough to look up the policy. It
is documented, and it is indeed as Marvin says:

http://incubator.apache.org/guides/participation.html#pmcer

I would encourage people to post links when responding to policy
questions. It is not necessary, but it helps counter the perception
(whether or not that perception is valid) that policy changes with
every message to this list.

Julian

On Sat, Dec 12, 2015 at 2:42 PM, Andrew Purtell
 wrote:
> We have had several people write in to general@ over the past few months with 
> this type of request. In at least one case a request triggered a vote on the 
> private list. We should update the incubator site with guidance on what is 
> the best way to approach the IPMC if this isn't ideal.
>
>
>> On Dec 12, 2015, at 11:33 AM, Marvin Humphrey  wrote:
>>
>>> On Sat, Dec 12, 2015 at 11:04 AM, James Taylor  
>>> wrote:
>>> Hello,
>>> I'm the PMC Chair for Apache Phoenix and a PMC member of Apache Calcite,
>>> both top level project and both of which I went through the incubation
>>> process. Recently several projects interested in going through incubation
>>> approached me to be a mentor, hence my interest in joining - so that I can
>>> help guide them through this process. I understand that the process for non
>>> ASF members is to initiate a vote on the private list. I'd appreciate it if
>>> that could start at your earliest convenience.
>>>
>>> Please let me know if I need to perform any further action before a vote is
>>> started.
>>
>> Hi James, thanks for your interest. For what it's worth, there's no
>> reason you couldn't help out a podling without being a Mentor.  And
>> the process for non-ASF-Members joining the Incubator PMC is actually
>> the same as for any other Apache PMC -- someone earns merit and then
>> is invited to join.
>>
>> Regardless of what happens in this specific case, if people are going
>> to initiate direct requests like this, I wish they would use the
>> private list.  Every once in a while somebody who has not earned merit
>> makes a request to join a PMC; it is awkward to rebuff such requests
>> discreetly when the request is public.  Apache private lists are not
>> supposed to be used a lot, but personnel discussions are one of the
>> main reasons we have them.
>>
>> 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
>

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

Re: [VOTE] Apache Slider (incubating) release 0.90.2-incubating

[Julian Hyde]

> On Jan 6, 2016, at 7:16 AM, Steve Loughran  wrote:
> 
>> On 5 Jan 2016, at 11:55, Daniel Gruno  wrote:
>> 
>> See http://compliance.rocks/result.html?1152a2a9 for a list of minor
>> nits (missing some license headers in a bunch of python scripts).
>> 
> nice script

+1

> I think some other projects keep their protoc generated source files in SCM 
> —what do they do license-wise?

Calcite’s process [1] is to generate the source files using a script that adds 
headers, then check them into git. The files, for example [2], are exempted 
from the usual checkstyle rules for formatting but have the usual Apache file 
headers.

Julian

[1] 
http://calcite.apache.org/docs/howto.html#rebuilding-generated-protocol-buffer-code
 

Re: Concerted may be in need of help

[Julian Hyde]

(Removing dev@concerted from the To: list.)

Good grief. No one is suggesting there should be "steady activity
requirement". I and other Concerted mentors just have a hunch that the
project isn't doing well, and thought it would be better to bring our
concerns to this list earlier rather than later. Let's not turn it
into a debate over policy. If anyone can think of ways to help this
project, then we'd love to hear your ideas. If you can't think of ways
to help the project, or don't think the project needs to be helped,
then don't help.

Julian

On Sat, Jan 9, 2016 at 12:21 PM, William A Rowe Jr  wrote:
> On Sat, Jan 9, 2016 at 1:27 PM, Chris Nauroth 
> wrote:
>
>>
>> As a Concerted mentor, I agree with the concern about lack of activity.  I
>> think this was a difficult month for the project considering both the
>> general drop in participation and the typical drop in activity that we
>> should expect to happen around the end-of-year holidays.  The monthly
>> reporting schedule implicitly requires that an incubating project show
>> some kind of demonstrable progress month-to-month.  Still, other podlings
>> did manage to sustain activity and complete a report during this time.
>>
>> I see John has already raised concern about lack of activity in the
>> mentor/shepherd notes.  I just seconded that myself.
>>
>> Can we consider giving the PPMC a chance to reset and aim to re-establish
>> steady activity this month?
>
>
> What is the steady activity requirement that has been injected into
> incubation?
>
> There are plenty of examples of projects that have enjoyed months and some
> years of lull between bursts of activity, usually around new requirements
> and
> interests by patch submittors or committers.
>
> By this reconning, there have been a number of times measured in weeks or
> months that the httpd and tomcat projects should have been folded.  Do we
> really believe that a steady state of activity is healthy?  On the
> contrary, it
> is the bursts of new activity that lead our projects into new and
> interesting
> territory, not an n commits/mo target.
>
> That said, we don't want podlings to linger here; release early, release
> often,
> demonstrate that new contributors are recognized as committers/[p]pmc
> members, and show us [incubator] that there isn't much more mentorship
> required for the effort to proceed in the model of the ASF.  A project that
> cannot get to a point of release in some reasonable time, e.g. a year or
> two, or who takes down their shingle and announces they can't attract a
> three+ community to sustain their effort, such projects should be retired.

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

Re: [VOTE] Accept the iota project into the Apache Incubator

[Julian Hyde]

+1 (binding)

Julian

> On Jan 19, 2016, at 10:43 PM, Jean-Baptiste Onofré  wrote:
> 
> +1 (binding)
> 
> Regards
> JB
> 
> On 01/19/2016 01:25 PM, Hadrian Zbarcea wrote:
>> I want to encourage more IPMC members to cast a vote, in case this
>> thread went unnoticed.
>> 
>> Cheers,
>> Hadrian
>> 
>> On 01/16/2016 03:40 PM, Hadrian Zbarcea wrote:
>>> The vote is as usually open for at least 72 hours.
>>> 
>>> Here's my +1.
>>> 
>>> Hadrian
>>> 
>>> 
>>> On 01/16/2016 03:12 PM, Hadrian Zbarcea wrote:
 Hi,
 
 The iota proposal [1] (initially Tempo) was proposed about 6 weeks ago.
 
 Because of the naming conflict that would have likely required to change
 name at graduation, the project name was changed to "Apache iota" (the
 greek letter), which resonates better with the IoT field the project
 targets and passed a summary podling name search.
 
 The code was made available in December for our review and answers on
 the general@ list have been answered.
 
 We think it's time to move to the next step, a formal vote. Therefore...
 
 Please cast your vote to:
 [] +1 - accept Apache iota as a new incubating project
 []  0 - not sure
 [] -1 - do not accept the Apache iota project (because: ...)
 
 Thanks,
 Hadrian
 
 
 [1] https://wiki.apache.org/incubator/IotaProposal
 [2] https://en.wikipedia.org/wiki/Iota
 
 
 -
 
 iota Proposal
 
 Abstract
 
 The Apache Foundation has been very successful in bringing together key
 software components that have enabled people to interact with each other
 via a variety of content platforms and it will no doubt continue to do
 so. At the same time modern society is becoming increasingly dependent
 on devices that interact with each other and with people. The amount of
 data that will be produced by devices will be orders of magnitude
 greater than what has been produced by humans in the past. In addition,
 the orchestration of devices and people will be an important area of
 growth for the foreseeable future. This new dynamic will eventually
 become manifest in a growing number of Apache projects that enable this
 to occur. Our wish is to contribute to this movement by contributing the
 iota system to the Open Source Community via the Apache Foundation.
 Apache iota is an open platform to interconnect any and all devices,
 sensors, people, and applications, henceforth referred to as points,
 through a scalable, secure, and modular architecture, enabling
 applications to generate analysis, create actions and/or add
 intelligence to their behaviors and patterns.
 
 Proposal
 
 Perhaps you are a homeowner configuring the interaction between your
 family and all the smart devices in your home. Or you might be a global
 company orchestrating millions of devices and people across different
 continents. Either way you face the same fundamental problem; namely,
 how do you manage many points in a secure robust and meaningful manner?
 Apache iota is an open source software system that enables homeowners
 and global companies to download a software system that provides secure
 and robust orchestration.
 
 The iota system consists of a variety of components:
 
 A basic but extensible desktop
 An extensible mechanism for capturing data from a variety of sources
 A set of translators that feed the data capture mechanism and a
 framework for the development of additional translators
 A secure means of moving data using digital envelopes based on symmetric
 and asymmetric encryption and decryption via Apache Kafka
 Optionally maintaining data encrypted in a datastore
 Support for a variety of data repositories
 Authentication and authorization using OAuth2
 Secure APIs for access to data and the system information
 User management
 Device management
 Automated software upgrades via Salt
 Configuration management
 Robust basic infrastructure based on Apache Mesos that enables
 scalability
 Dockerized applications
 Background
 
 We are in the midst of a revolution in which the Internet of Things
 (IoT) is poised to impact the development of our society in ways we can
 not even begin to imagine. Unfortunately, we know of no coherent OSS
 (Open Source Software) solution that can harness the potentialities of
 this increasingly important trend. Manufacturers of IoT devices, both in
 the consumer and industrial spaces, continue to develop proprietary
 systems. Apache iota is an open source IoT system that creates an open
 source solution enabling the orchestration of IoT devices that brings
 the benefits of OSS to this space. Apache iota was initially developed
 by Litbit and is deployed in a growing number of Indust

Re: [VOTE] Accept Beam into the Apache Incubator

[Julian Hyde]

+1 (binding)

> On Jan 28, 2016, at 10:42 AM, Mayank Bansal  wrote:
> 
> +1 (non-binding)
> 
> Thanks,
> Mayank
> 
> On Thu, Jan 28, 2016 at 10:23 AM, Seetharam Venkatesh <
> venkat...@innerzeal.com> wrote:
> 
>> +1 (binding).
>> 
>> Thanks!
>> 
>> On Thu, Jan 28, 2016 at 10:19 AM Ted Dunning 
>> wrote:
>> 
>>> +1
>>> 
>>> 
>>> 
>>> On Thu, Jan 28, 2016 at 10:02 AM, John D. Ament 
>>> wrote:
>>> 
 +1
 
 On Thu, Jan 28, 2016 at 9:28 AM Jean-Baptiste Onofré 
 wrote:
 
> Hi,
> 
> the Beam proposal (initially Dataflow) was proposed last week.
> 
> The complete discussion thread is available here:
> 
> 
> 
 
>>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3CCA%2B%3DKJmvj4wyosNTXVpnsH8PhS7jEyzkZngc682rGgZ3p28L42Q%40mail.gmail.com%3E
> 
> As reminder the BeamProposal is here:
> 
> https://wiki.apache.org/incubator/BeamProposal
> 
> Regarding all the great feedbacks we received on the mailing list, we
> think it's time to call a vote to accept Beam into the Incubator.
> 
> Please cast your vote to:
> [] +1 - accept Apache Beam as a new incubating project
> []  0 - not sure
> [] -1 - do not accept the Apache Beam project (because: ...)
> 
> Thanks,
> Regards
> JB
> 
> ## page was renamed from DataflowProposal
> = Apache Beam =
> 
> == Abstract ==
> 
> Apache Beam is an open source, unified model and set of
> language-specific SDKs for defining and executing data processing
> workflows, and also data ingestion and integration flows, supporting
> Enterprise Integration Patterns (EIPs) and Domain Specific Languages
> (DSLs). Dataflow pipelines simplify the mechanics of large-scale
>> batch
> and streaming data processing and can run on a number of runtimes
>> like
> Apache Flink, Apache Spark, and Google Cloud Dataflow (a cloud
>>> service).
> Beam also brings DSL in different languages, allowing users to easily
> implement their data integration processes.
> 
> == Proposal ==
> 
> Beam is a simple, flexible, and powerful system for distributed data
> processing at any scale. Beam provides a unified programming model, a
> software development kit to define and construct data processing
> pipelines, and runners to execute Beam pipelines in several runtime
> engines, like Apache Spark, Apache Flink, or Google Cloud Dataflow.
>>> Beam
> can be used for a variety of streaming or batch data processing goals
> including ETL, stream analysis, and aggregate computation. The
> underlying programming model for Beam provides MapReduce-like
> parallelism, combined with support for powerful data windowing, and
> fine-grained correctness control.
> 
> == Background ==
> 
> Beam started as a set of Google projects (Google Cloud Dataflow)
>>> focused
> on making data processing easier, faster, and less costly. The Beam
> model is a successor to MapReduce, FlumeJava, and Millwheel inside
> Google and is focused on providing a unified solution for batch and
> stream processing. These projects on which Beam is based have been
> published in several papers made available to the public:
> 
>  * MapReduce - http://research.google.com/archive/mapreduce.html
>  * Dataflow model  -
>> http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf
>  * FlumeJava - http://research.google.com/pubs/pub35650.html
>  * MillWheel - http://research.google.com/pubs/pub41378.html
> 
> Beam was designed from the start to provide a portable programming
> layer. When you define a data processing pipeline with the Beam
>> model,
> you are creating a job which is capable of being processed by any
>>> number
> of Beam processing engines. Several engines have been developed to
>> run
> Beam pipelines in other open source runtimes, including a Beam runner
> for Apache Flink and Apache Spark. There is also a “direct runner”,
>> for
> execution on the developer machine (mainly for dev/debug purposes).
> Another runner allows a Beam program to run on a managed service,
>>> Google
> Cloud Dataflow, in Google Cloud Platform. The Dataflow Java SDK is
> already available on GitHub, and independent from the Google Cloud
> Dataflow service. Another Python SDK is currently in active
>>> development.
> 
> In this proposal, the Beam SDKs, model, and a set of runners will be
> submitted as an OSS project under the ASF. The runners which are a
>> part
> of this proposal include those for Spark (from Cloudera), Flink (from
> data Artisans), and local development (from Google); the Google Cloud
> Dataflow service runner is not included in this proposal. Further
> references to Beam will refer to the Dataflow model, SDKs, and
>> runners
> which are a part of this proposal (Apache Beam) only. The

Re: Confusion over NOTICE vs LICENSE files

[Julian Hyde]

I can see how a TLP would not be receptive to someone nit-picking their 
LICENSE/NOTICE files. Asking for patches, as Marvin suggests, is one approach 
that might work. Another approach is for someone with expertise in licensing to 
approach a TLP and offer to take them through a licensing review. Of course the 
TLP is at liberty to refuse, but if they accepted, some knowledge would 
undoubtedly rub off. I can speak only for the Calcite project, but I think we’d 
be happy to go through such a process every couple of years.

Julian


> On Feb 3, 2016, at 6:32 PM, Marvin Humphrey  wrote:
> 
> On Wed, Feb 3, 2016 at 4:01 PM, Justin Mclean  wrote:
>> Perhaps it's time to ask TLP to review their LICENCE / NOTICE to be a little
>> more consistent with current policy?
> 
> I approached a bunch of Lucene PMC members about this at ApacheCon a couple
> years back and they were receptive to the idea.
> 
> However, I don't think we should approach any other TLPs, to be honest.  A lot
> of the issues we'd like to fix in TLP LICENSE and NOTICE files would improve
> compliance with Apache *policy*, not law.  TLPs are the Board's purview -- the
> Incubator's writ only extends to podlings.
> 
> We can let the Board know that poor TLP compliance with Apache licensing
> policy is complicating our work in the Incubator, and perhaps the Board will
> solicit our help as volunteers to work on that problem.  But I think that if
> an initiative to tackle TLP licensing documentation originates on
> general@incubator, that's asking for trouble.  The last thing we need is
> conflict with the Board over ostensible IPMC overreach.
> 
>> Any suggestion on how we would go about this?
> 
> For any TLP we approach, I think we need to ensure that any proposed revisions
> are real, valuable contributions to the community.
> 
> *   Provide patches, rather than point out flaws.
> *   Explain persuasively and coherently to the PMC why these patches should be
>applied, while minimizing what we ask of them in terms of review and
>research.
> *   If possible, provide project-specific improvements which will help the PMC
>handle licensing better and with less effort in the future.
> 
> We need to bear in mind that we are outsiders while a project's PMC members
> are charged with legal oversight of their project, and that there is generally
> limited energy and patience for dealing with legal stuff.
> 
>> Does the policy need to be made clearer first?
> 
> Yes, I think that's important -- it will help us to persuade PMCs that our
> proposed changes are both correct and worthwhile.
> 
> 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: [VOTE] Accept Quarks into the Apache Incubator

[Julian Hyde]

+1 (binding)

> On Feb 26, 2016, at 10:36 AM, James Taylor  wrote:
> 
> +1
> 
> On Fri, Feb 26, 2016 at 8:47 AM, Arvind Prabhakar  wrote:
> 
>> +1 (binding)
>> 
>> Regards,
>> Arvind
>> 
>> On Wed, Feb 24, 2016 at 9:01 AM, Katherine Marsden 
>> wrote:
>> 
>>> The Quarks proposal has been discussed on the incubator list.  The
>>> discussion thread is at:
>>> 
>>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3c56c27489.7090...@apache.org%3E
>>> 
>>> Feedback from the discussion including addition of mentor Justin Mclean
>>> has been incorporated into the proposal below and available on the wiki
>> at:
>>> https://wiki.apache.org/incubator/QuarksProposal
>>> 
>>> Please cast your vote to:
>>> [] +1 - accept Quarks as a new incubating project
>>> []  0 - not sure
>>> [] -1 - do not accept the Quarks project (because: ...)
>>> 
>>> Thanks,
>>> 
>>> Kathey Marsden
>>> 
>>> = Quarks Proposal =
>>> === Abstract ===
>>> Quarks is a stream processing programming model and lightweight runtime
>> to
>>> execute analytics at devices on the edge or at the gateway.
>>> 
>>> === Proposal ===
>>> . Quarks  is a programming model and runtime for streaming analytics at
>>> the edge.   Applications are developed using a functional flow api to
>>> define operations on data streams that is executed as a graph of "oplets"
>>> in a lightweight embeddable runtime.   The SDK provides capabilities like
>>> windowing, aggregation  and connectors with an extensible model for the
>>> community to expand its  capabilities.
>>> 
>>> === Background ===
>>> . Stream processing systems are commonly used to process  data from edge
>>> devices and there is a need to push some of the  streaming analytics to
>> the
>>> edge to reduce communication costs, react  locally and offload processing
>>> from the central systems.  Quarks was developed by IBM as an entirely new
>>> project to provide an SDK  and lightweight embeddable runtime for
>> streaming
>>> analytics at the edge.   Quarks was created to be an open source project
>>> that could provide edge  analytics to a broad community and foster
>>> collaboration on common  analytics and connectors across a broad
>> ecosystem
>>> of devices.
>>> 
>>> === Rationale ===
>>> . With the growth in number of connected devices (Internet of Things)
>>> there is a need to execute analytics at the edge in order to take local
>>> actions based upon sensor information and/or reduce the volume of data
>>> sent to back-end analytic systems to reduce communication cost.
>>> Quarks rationale is to provide  consistent and easy to use programming
>>> models to allow application developers to focus on their  application
>>> rather than issues like device connectivity, threading etc.   Quarks'
>>> functional data flow programming model is similar to systems  like Apache
>>> Flink, Beam (An incubating Apache project), Java 8 Streams & Apache
>> Spark.
>>> The API currently has language bindings for Java8, Java7 and Android.
>>> Quarks was developed to address requirements for analytics at the  edge
>> for
>>> IoT use cases that were not addressed by central analytic  solutions.  We
>>> believe that these capabilities will be useful to many  organizations and
>>> that the diverse nature of edge devices and use cases  is best addressed
>> by
>>> an open community. Therefore, we would like to contribute Quarks to the
>> ASF
>>> as an open source project and begin developing a community of developers
>>> and users within Apache.
>>> 
>>> === Initial Goals ===
>>> . Quarks initial code contribution provides:
>>> 
>>> * APIs for developing applications that execute  analytics using a
>>> per-event (data item) streaming paradigm including  support for windows
>>> against a stream for aggregation
>>> * A micro-kernel style runtime for execution.
>>> * Connectors for MQTT, HTTP, JDBC, File, Apache Kafka &  IBM Watson IoT
>>> Platform
>>> * Simple analytics aimed at device sensors (using Apache Common Math)
>>> * Development mode including a web-console to view the graph of running
>>> applications
>>> * Testing mechanism for Quarks applications that integrates with
>>> assertion based testing systems like JUnit
>>> * Android specific functionality such as producing a stream that
>> contains
>>> a phone's sensor events (e.g. ambient temperature, pressure)
>>> * JUnit tests
>>> .
>>> . All of the initial code is implemented using Java 8 and when built
>>> produces jars that can execute on Java 8, Java 7 and Android. The goal is
>>> to encourage community contributions in any area of Quarks, to  expand
>> the
>>> community (including new committers) and use of Quarks. We  expect
>>> contributions will be driven by real-world use of Quarks by  anyone
>> active
>>> in the IoT space such as auto manufactures, insurance  companies, etc. as
>>> well as individuals experimenting with devices such  as Raspberry Pis,
>>> Arduinos and/or smart phone apps etc. Contributions would be welcomed in
>>> any aspe

Re: [VOTE] Accept Tephra into the Apache Incubator

[Julian Hyde]

+1 (binding)

> On Mar 4, 2016, at 12:57 PM, Alan Gates  wrote:
> 
> +1 (binding).
> 
> Alan.
> 
>> On Mar 3, 2016, at 17:29, Poorna Chandra  wrote:
>> 
>> Hi All,
>> 
>> Tephra proposal was sent out for discussion last week. The proposal is
>> available at https://wiki.apache.org/incubator/TephraProposal
>> 
>> Please vote to accept Tephra into the Apache Incubator. The vote will be
>> open for the next 72 hours.
>> 
>> [ ] +1 Accept Tephra as an Apache Incubator podling.
>> [ ] +0 Abstain.
>> [ ] -1 Don’t accept Tephra as an Apache Incubator podling because ...
>> 
>> Thanks,
>> Poorna.
>> 
>> --
>> 
>> = Abstract =
>> 
>> Tephra is a system for providing globally consistent transactions on
>> top of Apache HBase and other storage engines.
>> 
>> = Proposal =
>> 
>> Tephra is a transaction engine for distributed data stores like Apache HBase.
>> It provides ACID semantics for concurrent data operations that span over 
>> region
>> boundaries in HBase using Optimistic Concurrency Control.
>> 
>> = Background =
>> 
>> HBase provides strong consistency with row- or region-level ACID
>> operations. However, it sacrifices cross-region and cross-table
>> consistency in favor of scalability. This trade-off requires application
>> developers to handle  the complexity of ensuring consistency when their
>> modifications span region boundaries. By providing support for global
>> transactions that span regions, tables, or multiple RPCs,
>> Tephra simplifies application development on top of HBase, without a
>> significant impact on performance or scalability for many workloads.
>> 
>> Tephra leverages HBase’s native data versioning to provide multi-versioned
>> concurrency control (MVCC) for transactional reads and writes.
>> With MVCC capability, each transaction sees its own consistent “snapshot” of
>> data, providing snapshot isolation of concurrent transactions.
>> MVCC along with conflict detection and handling enables Optimistic 
>> Concurrency
>> Control.
>> 
>> Tephra consists of three main components:
>> * Transaction Server – maintains global view of transaction state, assigns
>>  new transaction IDs and performs conflict detection;
>> * Transaction Client – coordinates start, commit, and rollback of
>> transactions; and
>> * Transaction Processor Coprocessor – applies filtering to the data read 
>> (based
>>  on a given transaction’s state) and cleans up any data from old
>>  (no longer visible) transactions.
>> 
>> Although Tephra only supports HBase now, it can be extended to support
>> transactions on any store that has multi-versioning and rollback
>> support. The transactions
>> can span over multiple stores and storage paradigms.
>> 
>> = Rationale =
>> 
>> Tephra has simple abstractions which can be used by an application to
>> add transaction support over HBase. By abstracting away transaction
>> handling using Tephra, the application is freed of
>> transaction logic, and the application developer can focus on the use case.
>> Also, Tephra can be extended to support transactions on data sources other
>> than HBase.
>> 
>> By making Tephra an Apache open source project, we believe that there will
>> be wider adoption and more opportunities for Tephra to be integrated
>> into other Apache projects.
>> 
>> = Current Status =
>> 
>> Tephra was built at Cask Data Inc. initially as part of
>> open-source framework Cask Data Application Platform (CDAP)
>> [[http://cdap.io/]].
>> It was later converted into an independent open source project with
>> Apache 2.0 License [[https://github.com/caskdata/tephra]].
>> 
>> Tephra is used in CDAP as the transaction engine. As part of CDAP, Tephra
>> has been deployed at multiple companies.
>> 
>> Apache Phoenix is using Tephra as transaction engine in the next release.
>> 
>> == Meritocracy ==
>> 
>> Our intent with this incubator proposal is to start building a diverse
>> developer community around Tephra following the Apache meritocracy model.
>> Since Tephra was initially developed in early 2013, we have had fast
>> adoption and contributions within Cask Data. We are looking forward to
>> new contributors. We wish to build a community based on Apache's
>> meritocracy principles, working with those who contribute significantly to
>> the project and welcoming them to be committers both during the incubation
>> process and beyond.
>> 
>> == Community ==
>> 
>> Core developers of Tephra are at Cask Data. Recently the developer community
>> has expanded to include folks from Apache Phoenix. We hope to extend our
>> contributor base significantly and we will invite all who are interested
>> in working on distributed transaction engine.
>> 
>> == Core Developers ==
>> 
>> A few engineers from Cask Data and outside have developed Tephra:
>> Andreas Neumann, Terence Yim, Gary Helmling, Andrew Purtell and
>> Poorna Chandra.
>> 
>> 
>> == Alignment ==
>> 
>> The ASF is the natural choice to host the Tephra project as its goal of
>> encouraging community-driven open sou

Re: Policy should be simple (was "Allowed Champions on podlings")

[Julian Hyde]

If you want to simplify policy, get rid of the champion. Or rather, reduce the 
champion’s role to nominating a project for incubation. Once the project has 
entered incubation, the champion’s role ends.

While Calcite was in incubation no one (including the champion) had a clue what 
the role of the champion was. Was the champion implicitly on the PPMC? Did they 
have a binding vote? Were they implicitly a mentor? If we needed karma to do 
xyz, should we email the champion or the mentors? It would be simpler if there 
were just mentors. And of course the champion can become a mentor if he/she 
wants to.

Julian


> On Mar 22, 2016, at 11:39 AM, Craig Russell  wrote:
> 
>> 
>> On Mar 22, 2016, at 11:25 AM, John D. Ament  wrote:
>> 
>> On Tue, Mar 22, 2016 at 12:19 PM Marvin Humphrey 
>> wrote:
>> 
>>> On Mon, Mar 21, 2016 at 9:57 AM, Craig Russell 
>>> wrote:
 There is a sorta technical reason for the Champion to be a member of the
>>> PMC
 of the sponsor.
 
 I’d expect the Champion to subscribe to the private@ list and to have
 binding votes on podling releases. These both require PMC membership.
 
 The alternative is to create two different “exceptions” that would allow
 Champions to subscribe to private@ and to have binding release votes.
>>> 
>>> These are legitimate concerns that would need to be dealt should such an
>>> unlikely scenario arise.  However, I don't think we need to carve
>>> exceptions
>>> into policy here -- other creative solutions are available, like voting the
>>> Champion onto the Sponsor PMC.
>>> 
>> 
>> Moreso, the champion is responsible for bringing the project into the ASF.
>> The Champion holds no bearing on the project after that point.
>> 
>> It sounds like what we're being pitched here is that the champion must stay
>> on to mentor the project.  That hasn't been followed too much.
> 
> I did not think this thread was discussing the role of the Champion, just the 
> pre-requisites.
> 
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion
> 
> During incubation, the Champion:
> 
>   • Coordinates the creation and timely delivery of the podling's board 
> reports.
>   • Keeps an eye on the mentors' activity and takes action (ask for new 
> mentors, talk to the Incubator PMC) if they don't seem to provide enough 
> oversight or mentorship to the podling,
> The podling can elect a new Champion at any time, and must notify the 
> Incubator PMC when that happens.
> 
> The podling reports indicate who the current Champion is, and that 
> information is kept up to date in the Incubator PMC's records (currently 
> content/podlings.xml@champion).
> 
> Craig
>> 
>> 
>>> 
>>> And I'd like to take this opportunity to make a more general point:
>>> 
>>> Policy should be simple.
>>> 
>>> There are many reasons that policy should be simple, and I'm sure others
>>> will
>>> be happy to weigh in with their own favorites.  But for me, this is the
>>> most compelling:
>>> 
>>> Complexity harms newcomers.
>>> 
>>> Right now, Apache's rules are so complex that we are all in perpetual
>>> violation.  You can't even know what all the rules are!
>>> 
>>> In such an environment, success is dependent, not on your own ability, but
>>> on
>>> securing alliances with powerful insiders who can help you bend or break
>>> the rules.
>>> 
>>> This state of affairs is not worthy of our core principles.  Particularly
>>> since the ASF does not exercise technical control over its projects, what
>>> we
>>> do here is not really that complicated.
>>> 
>>> Apache, and the Incubator in particular, welcomes newcomers.  It should be
>>> possible for a newcomers to discover and follow our rules largely through
>>> their own efforts.
>>> 
>>> Of course a rejoinder to "Policy should be simple" is "As simple as
>>> possible
>>> and no simpler".  But how close are we to "as simple as possible"?
>>> 
>>> Marvin Humphrey
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
> 
> Craig L Russell
> Architect
> craig.russ...@oracle.com
> P.S. A good JDO? O, Gasp!
> 
> 
> 
> 
> 
> 
> -
> 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 Quickstep into the Apache Incubator

[Julian Hyde]

as one of the
>> leading providers of database management and data processing solutions
>> and the corresponding Pivotal commercial product will continue to be
>> developed around the Quickstep project.
>> 
>> Moreover, Pivotal has a vested interest in making Quickstep successful
>> by driving its close integration with both existing projects
>> contributed to open source by Pivotal including Apache HAWQ
>> (incubating) and Greenplum Database, and sister ASF projects. We
>> expect this to further reduce the risk of orphaning the product.
>> 
>> == Inexperience with Open Source ==
>> Pivotal has embraced open source software since its formation by
>> employing contributors/committers and by shepherding open source
>> projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Individuals
>> working at Pivotal have experience with the formation of vibrant
>> communities around open technologies with the Cloud Foundry
>> Foundation, and continuing with the creation of a community around
>> Apache Geode (incubating), Apache HAWQ (incubating) and Apache MADlib
>> (incubating). Although some of the initial committers have not had the
>> experience of developing entirely open source, community-driven
>> projects, we expect to bring to bear the open development practices
>> that have proven successful on longstanding Pivotal open source
>> projects to the Quickstep community. Additionally, several ASF
>> veterans have agreed to mentor the project and are listed in this
>> proposal. The project will rely on their collective guidance and
>> wisdom to quickly transition the entire team of initial committers
>> towards practicing the Apache Way.
>> 
>> == Homogeneous Developers ==
>> While many of the initial committers are employed by Pivotal or at the
>> University of Wisconsin, we have already seen a healthy level of
>> interest from existing customers and partners. We intend to convert
>> that interest directly into participation and will be investing in
>> activities to recruit additional committers from other companies.
>> 
>> == Reliance on Salaried Developers ==
>> Many of the contributors are paid to work in the Big Data and data
>> processing space and nearly all are committed to a career in that
>> space. While they might wander from their current employers, they are
>> unlikely to venture far from their core expertise and thus will
>> continue to be engaged with the project regardless of their current
>> employers.
>> 
>> == Relationships with Other Apache Products ==
>> As mentioned in the Alignment section, Quickstep may consider various
>> degrees of integration and code exchange with Apache Hive, Apache HAWQ
>> (incubating), Apache YARN and Apache Mesos.
>> 
>> == An Excessive Fascination with the Apache Brand ==
>> While we intend to leverage the Apache ‘branding’ when talking to
>> other projects as testament of our project’s ‘neutrality’, we have no
>> plans for making use of Apache brand in press releases nor posting
>> billboards advertising acceptance of Quickstep into Apache Incubator.
>> 
>> == Documentation ==
>> The documentation is currently available at http://quickstep.cs.wisc.edu/
>> 
>> == Initial Source ==
>> Initial source code is currently licensed under Apache License v.2 and
>> is available at https://github.com/pivotalsoftware/quickstep.
>> 
>> == Source and Intellectual Property Submission Plan ==
>> As soon as Quickstep is approved to join the Incubator, the source
>> code will be transitioned via an exhibit to Pivotal's current Software
>> Grant Agreement onto ASF infrastructure. We know of no legal
>> encumbrances inhibiting the transfer of source code to the ASF.
>> 
>> == External Dependencies ==
>> 
>> Runtime dependencies:
>> * farmhash: https://github.com/google/farmhash [License: MIT]
>> * gflags: https://github.com/gflags/gflags [License: BSD]
>> * glog: https://github.com/google/glog [License: BSD]
>> * gperftools: https://github.com/gperftools/gperftools [License: BSD]
>> * linenoise: https://github.com/antirez/linenoise [License: BSD 2-Clause]
>> * protobuf: https://github.com/google/protobuf [License: BSD]
>> 
>> Build only dependencies:
>> * cmake: https://cmake.org/ [License: BSD]
>> * bison: https://www.gnu.org/software/bison/ [License: GPL with
>> exception for generated parsers]
>> * flex: http://flex.sourceforge.net [License: BSD]
>> 
>> Test only dependencies:
>> * benchmark: https://github.com/google/benchmark [License: Apache 2.0]
>> * cpplint: https://gi

Re: [VOTE] Accept Omid into the Apache Incubator

[Julian Hyde]

+1 (binding)

Julian

> On Mar 23, 2016, at 4:16 PM, Flavio Junqueira  wrote:
> 
> +1 (binding)
> 
> -Flavio
> 
>> On 23 Mar 2016, at 22:42, James Taylor  wrote:
>> 
>> +1 (binding)
>> 
>> On Wed, Mar 23, 2016 at 3:34 PM, Chris Nauroth 
>> wrote:
>> 
>>> +1 (binding)
>>> 
>>> --Chris Nauroth
>>> 
>>> 
>>> 
>>> 
>>> On 3/23/16, 3:31 PM, "Daniel Dai"  wrote:
>>> 
 Following the discussion earlier, I'm calling a vote to accept Omid as
 a new Incubator project.
 
 [ ] +1 Accept Omid into the Incubator
 [ ] +0 Indifferent to the acceptance of Omid
 [ ] -1 Do not accept Omid because ...
 
 The vote will be open for the next 72 hours.
 
 https://wiki.apache.org/incubator/OmidProposal
 
 Thanks,
 Daniel
 
 = Omid Proposal =
 
 === Abstract ===
 Omid is a flexible, reliable, high performant and scalable ACID
 transactional framework that allows client applications to execute
 transactions on top of MVCC key/value-based NoSQL datastores
 (currently Apache HBase) providing Snapshot Isolation guarantees on
 the accessed data.
 
 === Proposal ===
 Omid is a flexible open-source transactional framework that provides
 ACID transactions with Snapshot Isolation guarantees on top of NoSQL
 datastores. In particular, the current codebase brings the concept of
 transactions to the popular Apache HBase datastore. Omid offers great
 performance, it is highly available, and scalable. Omid's current
 version is able to scale to thousands of clients triggering concurrent
 transactions on application data stored in HBase. Omid can scale
 beyond 100K transactions per second on mid-range hardware while
 incurring in a minimal impact on the speed of data access in the
 datastore. We¹re currently experimenting with a prototype version that
 can improve the performance up to ~380K TPS.
 
 Omid has been publicly available as an open-source project in Github
 under Apache License Version 2.0 since 2011 [1]. During these years,
 it has generated certain interest in the open source community,
 especially since the public presentation of the first version in
 Hadoop Summit 2013 [2]. Currently the Github project has 241 Stars and
 93 forks. Yahoo Inc. submits this proposal to the Apache Software
 Foundation with the aim to transfer the Omid project -including its
 source code and documentation- to Apache in order to start the build
 of a stable open source community around it.
 
 [1] https://github.com/yahoo/omid
 [2] Omid presentation at Hadoop Summit 2013:
 
>>> https://www.youtube.com/watch?v=Rhdmo9pVGgU&index=68&list=PLSAiKuajRe2luyq
 LU464Nxz4aQe7EPBus
 
 === Background ===
 An Omid prototype was first released as an open-source project back in
 2011. Inspired by Google Percolator [1], it offered a lock-free
 approach to transactions in NoSQL datastores (See [2]). However,
 during these years, the design of Omid has evolved significantly.
 Whilst the current open-sourced version maintains many aspects of the
 original implementation, it is the result of a major redesign of the
 first prototype released in 2011.
 
 Omid has now a more decentralized design that does not sacrifice the
 consistency and performance of the original version. The current
 design also enables Omid to scale to thousands of clients executing
 transactions concurrently on application data stored in HBase.
 Internally, Omid still utilizes a lock-free approach to support
 multiple concurrent clients. Its design also relies on a centralized
 conflict detection component, the TSO, which now resolves in an
 efficient manner writeset collisions among concurrent transactions
 without having to piggyback commit information to the clients. Another
 important benefit of Omid is that it doesn't require any modification
 of the underlying key-value datastore, HBase in this case. Moreover,
 the recently added high availability algorithm allows to eliminate the
 single point of failure represented by the TSO in those system
 deployments requiring a higher degree of dependability. Last but not
 least, the provided user API is very simple, mimicking transaction
 managers in the relational world: begin, commit, rollback.
 
 Omid is used internally at Yahoo. Sieve, Yahoo¹s web-scale content
 management platform powering some of next-generation search and
 personalization products is using Omid as a transaction manager in its
 processing pipeline. Sieve essentially acts as a huge processing hub
 between content feeds and serving systems. It provides an environment
 for highly customizable, real-time, streamed information processing,
 with typical discovery-to-service latencies of just a few seconds. In
 terms of scale and availability, Omid¹s new desi

Re: [VOTE] Accept Quickstep into the Apache Incubator

[Julian Hyde]

+1 (binding)

> On Mar 28, 2016, at 11:50 AM, Rahul Iyer  wrote:
> 
> +1 (non-binding)
> 
> ​
> 
> 
>>> Please vote to accept Quickstep into the Apache Incubator.
>>> The vote will be open until Mon 3/28 noon PST.
>>> 
>>> [ ] +1 Accept Quickstep into the Apache Incubator
>>> [ ] +0 Abstain
>>> [ ] -1 Don't accept Quickstep into the Apache Incubator because ...
>> 
>> ​
>> 
>> 


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

Re: [VOTE] Release Eagle Version 0.3.0 RC3 (Incubating)

[Julian Hyde]

Forwarding my vote from dev:

+1 (binding)

Julian

> On Mar 28, 2016, at 5:05 PM, Dendukuri, Hemanth  wrote:
> 
> Hi all,
> 
>   The Apache Eagle community has voted on and approved the proposal to 
> release "Apache Eagle 0.3.0 Release Candidate 3 (incubating)".
>   The voting result is available at 
> https://s.apache.org/eagle-0.3.0-result
> 
> 
>   The Source file to be voted are located here: 
> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc3/
> 
>   Release Tag  :  
> https://github.com/apache/incubator-eagle/releases/tag/release-0.3.0-rc3
> 
> The commit to be voted upon: 
> https://github.com/apache/incubator-eagle/commit/b1d0a87ac0df1cc881427faafc637c152c180872
> 
>   Release artifacts are signed with the following key: 
> https://people.apache.org/keys/committer/hdendukuri.asc
> 
>   Here’s release notes:  
> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.3.0
> 
> 
>   Note that this is a source only release and we are voting on the 
> source. The hashes of the source are as follows:
> 
> 
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md5
>   a211a151d7f66c2516c5e41da1345128
> 
>   
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1
>   da7b4e60228cf1421dde4342c957aff16de81cbd
> 
> 
> 
>The vote is open for a minimum of 72 hours or until the necessary 
> number of votes (3 binding +1s) is reached.
> 
>[ ] +1 Release this Eagle 0.3.0 Incubator Release Candidate 3.
> 
>[ ]  0 I don't feel strongly about it, but I'm okay with the release
> 
>[ ] -1 Do not release this package because...
> 
> Please add "(binding)" if your vote is binding.
> 
> 
> Thanks,
> 
> Hemanth Dendukuri


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

Re: [VOTE] Release Eagle Version 0.3.0 RC3 (Incubating)

[Julian Hyde]

A reminder about whose votes are binding during this vote. Since this is a vote 
of the Incubator PMC (IPMC), your vote is only binding if you are an IPMC 
member.

To find out, look up your username using phonebook: 
http://people.apache.org/phonebook.html?uid=jhyde 
 and look for the line ‘PMC 
member of: … incubator’.

If you got it wrong, don’t worry: Hemanth will verify everyone’s standing 
before tallying the votes. And we welcome votes from everyone, even if your 
vote is not binding.

Julian


> On Mar 28, 2016, at 11:22 PM, Liangfei.Su  wrote:
> 
> Copy my vote from eagle dev dl.
> 
> +1, check sum verified.
> mvn clean install runs ok
> mvn apache-rat:check looks good
> 
> 
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ md5sum
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> a211a151d7f66c2516c5e41da1345128
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ cat
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md5
> a211a151d7f66c2516c5e41da1345128
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ sha
> sha1sum   sha224sum sha256sum sha384sum sha512sum
> shadowconfig  shasum
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ sha1sum
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> da7b4e60228cf1421dde4342c957aff16de81cbd
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz
> liasu@eagle-c3-lvs01-2-3954:~/rc3$ cat
> apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1
> da7b4e60228cf1421dde4342c957aff16de81cbd
> 
> 
> On Mon, Mar 28, 2016 at 10:58 PM, Zhao Qingwen  wrote:
> 
>> +1 (Binding)
>> 
>> 
>> Best Regards,
>> Qingwen Zhao | 赵晴雯
>> 
>> 
>> 
>> 
>> 2016-03-29 13:44 GMT+08:00 Henry Saputra :
>> 
>>> Sig file looks good
>>> Hash files look good
>>> NOTICE file exist
>>> LICENSE file exist
>>> DISCLAIMER file exist
>>> No 3rd party exe in source artifact
>>> 
>>> +1 (binding)
>>> 
>>> - Henry
>>> 
>>> 
>>> 
> On Mar 28, 2016, at 5:05 PM, Dendukuri, Hemanth >> 
 wrote:
> 
> Hi all,
> 
>  The Apache Eagle community has voted on and approved the
>> proposal
 to release "Apache Eagle 0.3.0 Release Candidate 3 (incubating)".
>  The voting result is available at
 https://s.apache.org/eagle-0.3.0-result
> 
> 
>  The Source file to be voted are located here:
 
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc3/
> 
>  Release Tag  :
 
>> https://github.com/apache/incubator-eagle/releases/tag/release-0.3.0-rc3
> 
> The commit to be voted upon:
 
>>> 
>> https://github.com/apache/incubator-eagle/commit/b1d0a87ac0df1cc881427faafc637c152c180872
> 
>  Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/hdendukuri.asc
> 
>  Here’s release notes:
 
>>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-eagle.git;a=blob_plain;f=CHANGELOG.txt;hb=refs/heads/branch-0.3.0
> 
> 
>  Note that this is a source only release and we are voting on
>> the
 source. The hashes of the source are as follows:
> 
>apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md<
 
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc3/apache-eagle-0.3.0-incubating-src-rc3.tar.gz.md5
 5
 a211a151d7f66c2516c5e41da1345128
> 
>  apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1<
 
>>> 
>> https://dist.apache.org/repos/dist/dev/incubator/eagle/0.3.0-incubating-rc3/apache-eagle-0.3.0-incubating-src-rc3.tar.gz.sha1
 
 da7b4e60228cf1421dde4342c957aff16de81cbd
> 
> 
> 
>   The vote is open for a minimum of 72 hours or until the
>>> necessary
 number of votes (3 binding +1s) is reached.
> 
>   [ ] +1 Release this Eagle 0.3.0 Incubator Release Candidate 3.
> 
>   [ ]  0 I don't feel strongly about it, but I'm okay with the
 release
> 
>   [ ] -1 Do not release this package because...
> 
> Please add "(binding)" if your vote is binding.
> 
> 
> Thanks,
> 
> Hemanth Dendukuri
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
>>> 
>> 

Re: [LAZY] Simplify Champion role

[Julian Hyde]

+1

> On Mar 31, 2016, at 11:37 AM, Shane Curcuru  wrote:
> 
> Marvin Humphrey wrote on 3/31/16 10:44 AM:
>> On Tue, Mar 29, 2016 at 3:54 AM, Bertrand Delacretaz
>>  wrote:
>> 
>>> As for the patch I suggest a slightly expanded definition of Champion,
>>> "A Member of the Apache Software Foundation who supports a Candidate's
>>> application for Incubation and acts as a liaison between the incoming
>>> podling and the Incubator in the early stages of incubation".
>>> 
>>> Apart from that I agree that the 2012 clarification of the Champion
>>> role does not make sense anymore, due to other (good) changes that
>>> happened in the meantime.
>> 
>> Thanks, Bertrand!
>> 
>> Here's an updated version of the patch simplifying the Champion role,
>> as discussed in another thread[1].
>> 
>>  https://paste.apache.org/KvMQ
> 
> +1.  The only concern is that we don't want to see lazy champions or
> mentors, so while this specific patch is fine, we will still need to
> ensure we find active mentors who get up and go when helping their podlings.
> 
> Should we start a mentor exercise program or the like?
> 
> 8-)
> 
> - Shane
>> 
>> If no one formally lodges a -1, I will claim lazy consensus after 72
>> hours and apply.
>> 
>> Marvin Humphrey
>> 
>> [1] https://s.apache.org/GDhG 
>> 
>> -
>> 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: Concerted may be in need of help

[Julian Hyde]

I agree. I think this project has been dead for a while, and we’re just 
prolonging the agony.

If we were to wind up the project, how would we proceed? A vote on concerted's 
dev list with lazy consensus, I presume?

Is there any reason why I should not start a discussion/vote right now?

Julian


> On Apr 7, 2016, at 10:50 AM, Chris Nauroth  wrote:
> 
> Hello John,
> 
> Thank you for bringing up the topic again.  As a Concerted mentor, I was
> planning to do the same today.
> 
> Just to confirm your observations, you are correct that there has been no
> further visible progress.  The only activity on the mailing list is from
> the mentors asking if anything is going on and reminding the community to
> file their reports.  Again, there is no report.
> 
> I'm not demanding any specific amount of activity, but complete lack of
> any activity sure makes it look like the podling is not viable.  I don't
> think there is any remaining action that could be done by either the
> mentors or the wider Incubator community to salvage it, but I'm certainly
> open to suggestions if anyone disagrees.
> 
> --Chris Nauroth
> 
> 
> 
> 
> On 4/7/16, 5:49 AM, "John D. Ament"  wrote:
> 
>> Sorry to bring back this long dead topic, but wanted to rehash what was
>> discussed here.
>> 
>> We're now 3 months later, and it seems that Concerted has not improved.
>> is
>> it time to call it?
>> 
>> John
>> 
>> On Sat, Jan 9, 2016 at 3:58 PM Ross Gardler 
>> wrote:
>> 
>>> +1
>>> 
>>> Everyone should read the subject and reset.
>>> 
>>> If IPMC members having nothing better to offer than "give up" then
>>> please
>>> refrain from offering your advice to mentors asking for constructive
>>> help.
>>> 
>>> That is not to say projects should linger, but unless mentors advise it
>>> we
>>> should not be interfering.
>>> 
>>> Ross
>>> 
>>> Sent from my Windows Phone
>>> 
>>> From: Julian Hyde<mailto:jh...@apache.org>
>>> Sent: ?1/?9/?2016 12:37 PM
>>> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
>>> Subject: Re: Concerted may be in need of help
>>> 
>>> (Removing dev@concerted from the To: list.)
>>> 
>>> Good grief. No one is suggesting there should be "steady activity
>>> requirement". I and other Concerted mentors just have a hunch that the
>>> project isn't doing well, and thought it would be better to bring our
>>> concerns to this list earlier rather than later. Let's not turn it
>>> into a debate over policy. If anyone can think of ways to help this
>>> project, then we'd love to hear your ideas. If you can't think of ways
>>> to help the project, or don't think the project needs to be helped,
>>> then don't help.
>>> 
>>> Julian
>>> 
>>> On Sat, Jan 9, 2016 at 12:21 PM, William A Rowe Jr 
>>> wrote:
>>>> On Sat, Jan 9, 2016 at 1:27 PM, Chris Nauroth
>>> 
>>>> wrote:
>>>> 
>>>>> 
>>>>> As a Concerted mentor, I agree with the concern about lack of
>>> activity.  I
>>>>> think this was a difficult month for the project considering both the
>>>>> general drop in participation and the typical drop in activity that
>>> we
>>>>> should expect to happen around the end-of-year holidays.  The monthly
>>>>> reporting schedule implicitly requires that an incubating project
>>> show
>>>>> some kind of demonstrable progress month-to-month.  Still, other
>>> podlings
>>>>> did manage to sustain activity and complete a report during this
>>> time.
>>>>> 
>>>>> I see John has already raised concern about lack of activity in the
>>>>> mentor/shepherd notes.  I just seconded that myself.
>>>>> 
>>>>> Can we consider giving the PPMC a chance to reset and aim to
>>> re-establish
>>>>> steady activity this month?
>>>> 
>>>> 
>>>> What is the steady activity requirement that has been injected into
>>>> incubation?
>>>> 
>>>> There are plenty of examples of projects that have enjoyed months and
>>> some
>>>> years of lull between bursts of activity, usually around new
>>> requirements
>>>> and
>>>> interes

Re: Concerted may be in need of help

[Julian Hyde]

Ok, I’ve started a DISCUSS thread.

> On Apr 7, 2016, at 11:24 AM, Roman Shaposhnik  wrote:
> 
> On Thu, Apr 7, 2016 at 11:17 AM, Julian Hyde  wrote:
>> I agree. I think this project has been dead for a while, and we’re just 
>> prolonging the agony.
> 
> As an initial Champion (but NOT a mentor) I have to agree :-(
> 
>> If we were to wind up the project, how would we proceed? A vote on 
>> concerted's dev list with lazy consensus, I presume?
>> 
>> Is there any reason why I should not start a discussion/vote right now?
> 
> You've got it! One of the active mentors needs to start a DISCUSS
> thread on dev@concerted
> and see where it goes from there.
> 
> Thanks,
> Roman.
> 
> -
> 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

[DISCUSS] Retirement of Concerted

[Julian Hyde]

Following a discussion[1], the Concerted community has voted to retire the 
project from incubation[2]. Per the retirement guide[3], the next step is an 
IPMC vote for retirement. Are there any objections or comments? If not, I shall 
start a vote shortly.

Julian

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-concerted-dev/201604.mbox/%3CCA7F1927-7C94-4FE2-98E1-06F1BA85D093%40apache.org%3E

[2] 
http://mail-archives.apache.org/mod_mbox/incubator-concerted-dev/201604.mbox/%3CD992543F-5F62-401B-A6A1-5AC647546C10%40apache.org%3E

[3] http://incubator.apache.org/guides/retirement.html


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

Re: [PROPOSAL] Gossip incubator proposal

[Julian Hyde]

In the Quickstep proposal, Roman explicitly listed himself as both Champion and 
Mentor. I think that is a good model to follow. If someone lists themselves 
only as Champion would I assume that their responsibilities end shortly after 
incubation starts.

To use the “it takes a village” metaphor, I think that incubator projects 
really need one or two committed parents rather than lots and lots of part-time 
aunts and uncles.

Julian


> On Apr 18, 2016, at 5:52 PM, P. Taylor Goetz  wrote:
> 
> Thanks for the input Henry!
> 
> I've seen proposals in the past come with what seems like a fully-baked list 
> of mentors, and others with a short list that could obviously benefit from 
> having more mentors and are looking for volunteers.
> 
> I think Gossip falls into the latter category and would welcome volunteer 
> mentors. So consider this a call for additional mentors.
> 
> In recent incubator discussions there's been some debate about the role of 
> champion and how it relates to mentoring. I'm personally not sure where I 
> stand in that debate, and so have not commented. I accepted the role of 
> champion with the intent of also acting as a mentor going forward.
> 
> Is that (champion also acting as a mentor) something that we (IPMC) think 
> should be explicitly called out in the proposal?
> 
> -Taylor
> 
>> On Apr 18, 2016, at 8:35 PM, Henry Saputra  wrote:
>> 
>> I would recommend getting more mentors to help. Especially almost half of
>> initial committers are not from Apache and the other half seemed very busy
>> with other projects.
>> 
>> - Henry
>> 
>>> On Mon, Apr 18, 2016 at 12:42 PM, P. Taylor Goetz  wrote:
>>> 
>>> Bump.
>>> 
>>> Are there any further comments/questions on the proposal? Or should we
>>> proceed with a VOTE?
>>> 
>>> -Taylor
>>> 
>>> 
 On Apr 13, 2016, at 6:58 PM, Edward Capriolo 
>>> wrote:
 
 Hello all,
 
 I would like to open up a discussion on the following proposal:
 https://wiki.apache.org/incubator/GossipProposal
 
 Besides those  mentioned in the proposal, thank you to Jake Ferrel, Lewis
 McGibbne, and Nate McCall who were a tremendous help!
 
 A copy of the proposal is below:
 
 = Abstract =
 
 Apache Gossip will be an implementation of the Gossip Protocol based
 on code available here: https://github.com/edwardcapriolo/gossip/
 which is already licenced using the glorious Apache V2 License.
 
 = Proposal =
 
 Apache Gossip aims to provide a gossip based consensus protocol
 written in Java for peer-to-peer communication to the Apache Incubator
 (http://incubator.apache.org/). This implementation will effectively
 scale from one to one-thousand node clusters. In addition to the code
 implementation, the project should produce specifications of the wire
 protocol, features, and expected behavior of the system such that
 compatible implementations can communicate.
 
 = Background =
 
 The gossip protocol has been implemented to varying levels of rigor by
 a number of entities. In particular, Apache Cassandra uses an
 implementation of gossip to locate peers and transmit up/down state.
 Apache Spark leverages tooling in Akka which provides peer-to-peer
 node discovery capabilities.
 
 *
>>> http://highscalability.com/blog/2011/11/14/using-gossip-protocols-for-failure-detection-monitoring-mess.html
 
 * https://en.wikipedia.org/wiki/Gossip_protocol
 
 = Rationale =
 
 With distributed computing becoming extremely widespread, and the
 growth of the buzz-factor of ‘the-internet-of-things’ it is
 increasingly important that networks of IP addressable devices can
 form a peer-to-peer network. Applications of peer-to-peer networks
 include generating crypto currency, managing hardware such as solar
 power micro-grids, and more traditional roles like grid/High
 Performance Computing and distributed storage systems. Different
 implements of gossip based consensus protocols have been implemented
 in numerous languages or as part of more complex software stacks. The
 Apache foundation should lead the effort of producing a purpose built
 tool that can be used by downstream projects to form peer-to-peer
 networks.
 
 = Initial Goals =
 
 * Migration of current code https://github.com/edwardcapriolo/gossip
 to the Apache Software Foundation
 * Secure communications
 * Transport security using a pre-shared key
 * Public Key Infrastructure
 * Introduce a cluster name to wire protocol to avoid misconfigurations
 * Effectively operate when systems have multiple network interfaces
 by controlling IP binding settings
 * Effectively operate when systems have Network Address Translations
 devices between them using a broadcast IP settings
 * Develop advanced integration testing from cluster sizes of 1-1000 nodes
 * Test

[VOTE] Retire Concerted

[Julian Hyde]

Following a discussion[1], the Concerted community has voted to retire the 
project from incubation[2]. Per the retirement guide[3], the next step is an 
IPMC vote for retirement.

This is a vote of the IPMC to confirm the decision to retire the podling.

[ ] +1 to retire Concerted from the Incubator
[ ] -1 to keep Concerted in the Incubator

This vote will be held open for at least 72 hours.

Here is my vote:

[x] +1 retire Concerted

Julian Hyde



[1] https://s.apache.org/concerted-retire-discuss

[2] https://s.apache.org/concerted-retire-vote

[3] http://incubator.apache.org/guides/retirement.html


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

[RESULT] [VOTE] Retire Concerted

[Julian Hyde]

With 8 +1 votes, the motion to retire Concerted is passed.

+1 John D. Ament
+1 Roman Shaposhnik
+1 Chris Nauroth
+1 P. Taylor Goetz
+1 Jake Farrell
+1 Jean-Baptiste Onofré 
+1 Sergio Fernández 
+1 Julian Hyde

Julian


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

Podlings in phonebook

[Julian Hyde]

The quickstep podling does not appear in the phonebook[1]. Are there any steps 
we missed in setting up the podling? (I know this is an infrastructure 
question, but I have a feeling that we need to update some of our process 
documents.)

Julian

[1] https://people.apache.org/phonebook.html?podling=quickstep 
 

Re: [VOTE] Accept Fluo into the Apache Incubator

[Julian Hyde]

+1 (binding)

Julian


> On May 13, 2016, at 11:22 AM, Billie Rinaldi  wrote:
> 
> Since discussion has died down, I would like to call a VOTE on accepting
> Fluo into the Apache Incubator.
> 
> Proposal: http://wiki.apache.org/incubator/FluoProposal
> 
> [ ] +1 Accept Fluo into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept Fluo into the Apache Incubator because…
> 
> This vote will be open for at least 72 hours.
> 
> Here is my +1 (binding).
> 
> Billie
> --
> 
> Fluo Proposal
> 
> Abstract
> 
> Fluo is a distributed system for incrementally processing large data sets
> stored in Accumulo.
> 
> Proposal
> 
> Fluo is a distributed transaction and notification system that enables the
> incremental processing of large data sets. Its transaction system allows
> for concurrent, cross-node updates to data stored in Accumulo. Its
> notification system enables developers to write code to be executed when
> observed data changes. Fluo provides a core API to perform transactional
> updates using minimalistic get/set methods. Fluo also provides a higher
> order recipes API that builds on the core API to support more complex
> methods for transactional updates.
> 
> Background
> 
> Several frameworks exist for batch (i.e Spark, MapReduce) and stream (i.e
> Storm, Spark Streaming) processing of data. While batch and stream
> processing have strong use cases, they are not suited for joining incoming
> data in real-time to a large existing data set. To fill this need, Google
> developed an incremental processing system called Percolator and described
> it in the paper, Large-scale Incremental Processing Using Distributed
> Transactions and Notifications1.
> 
> Rationale
> 
> Fluo fills the need for cross-row (and cross-node) transactions in Accumulo
> by providing it with an open source implementation of Percolator. Fluo also
> satisfies a gap in Accumulo’s ability to incrementally process data. Fluo
> also provides a novel recipes API which offers higher level abstractions
> for transactional updates.
> 
> Current Status
> 
> Fluo currently exists as an open source project on GitHub and has been in
> active development since 2013. The project has made an alpha release and
> two beta releases. The major features of Fluo outlined in this proposal
> have been implemented. Several example Fluo applications have been created
> and run successfully on clusters (up to 24 nodes).
> 
> Meritocracy
> 
> The Fluo project operates as a meritocracy and will continue to do so
> because we feel that a project comprised of a diverse set of committers
> will thrive. Therefore, we welcome new contributors and encourage them on
> their path to committership.
> 
> Community
> 
> Fluo is currently being used by a subset of the Accumulo community. The
> initial developers have been responsive to external contributions through
> pull requests and issues on GitHub. As Fluo releases a stable 1.0 version
> that is production-ready, we expect this community to grow. To encourage
> growth, we have created a project website with documentation, given talks
> at Meetups and the Accumulo Summit, and engaged with new users on GitHub
> and the Fluo mailing list.
> 
> Core Developers
> 
> The project was started by Keith Turner (an Apache Member and committer/PMC
> on Gora and Accumulo) in 2013, and the development has primarily consisted
> of his and Mike Walch’s continued efforts. Additional developers have
> contributed over time, which has led to new committers.
> 
> Alignment
> 
> Fluo is closely linked to the Accumulo community, and fits well within the
> larger Hadoop ecosystem at Apache. Fluo utilizes several Apache projects,
> such as Accumulo, YARN, Twill, and ZooKeeper. Enabling closer collaboration
> between these communities through its coexistence within the ASF would help
> further drive the success of them all.
> 
> In addition to our technical ties to other ASF projects, our development
> philosophy aligns with Apache philosophies. Based on our experience with
> existing Apache projects, we are interested in establishing formal
> governance with a PMC and community bylaws, which we feel would best be
> done within Apache.
> 
> Known Risks
> 
> Orphaned Products
> 
> Fluo could be orphaned if the project fails to gain adoption and the core
> developers abandon their interest (this is not anticipated). This risk can
> be mitigated by attracting more committers and developing further
> documentation to ease adoption.
> 
> Inexperience with Open Source
> 
> Fluo has been an open source project on GitHub from the start of its
> development. Several Fluo developers are committers on other ASF projects
> as well as open source projects outside ASF, and understand open source
> development.
> 
> Homogeneous Developers
> 
> The initial committers work for different employers. We hope add more
> developers from other employers and industries.
> 
> Reliance on Salaried Developers
> 
> While most of the initial committers are pa

Re: Additional mentor steps?

[Julian Hyde]

My reaction (being ignorant of the machinery behind phonebook and 
authorization) is that adding to asf-authorization-template on podling creation 
would be ok (since it is done only once per podling, by a mentor who presumably 
knows what they are doing) but adding to asf-authorization-template each time a 
committer is appointed is probably too error-prone.

I might be naive but it seems that the fact that x is a committer to podling y 
should be represented in one and only one place and the phonebook ought to 
drive from that.

Julian

> On May 14, 2016, at 1:01 PM, Roman Shaposhnik  wrote:
> 
> To answer back into the original thread (based on the question about
> Phonebook last week):
> 
> On Thu, Apr 28, 2016 at 6:51 PM, John D. Ament  wrote:
>> All,
>> 
>> Due to some changes in recent times around the ASF, I think I've identified
>> a new setup step for podlings.
>> 
>> I'd like to recommend adding to the asf-authorization-template as a setup
>> step to display the newly created podling in phonebook (
>> home.apache.org/phonebook.html) and that whenever a new committer is added
>> that this authorization template be updated.
>> 
>> Any objections? Questions or concerns?
> 
> I like the idea. My only concern is that what needs to be updated today
> is esoteric (puppet file?) and confusing (svn?). Is there any chance we
> can make it less so?
> 
> As I understand the key issue here is that we don't want to create LDAP
> entries for podling committers, correct?
> 
> Roman.
> 
> -
> 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] CarbonData incubation proposal

[Julian Hyde]

I see code derived from Mondrian in the org.carbondata.core.carbon package[1] 
(I’m familiar with Mondrian’s code structure because I wrote it). Mondrian was 
originally EPL and as such cannot be re-licensed under ASL. Everything is 
probably fine, but as part of incubation, we will need to make sure that this 
and other code has a clear progeny.

Julian

[1] 
https://github.com/HuaweiBigData/carbondata/tree/master/core/src/main/java/org/carbondata/core/carbon
 


> On May 19, 2016, at 10:04 AM, Liang Chen  wrote:
> 
> Hi Lars
> 
> Thanks for you participated in discussion.
> 
> Based on the below requirements, we investigated existing file formats in
> the Hadoop eco-system, but we could not find a suitable solution that
> satisfying requirements all at the same time, so we start designing
> CarbonData.
> R1.Support big scan & only fetch a few columns
> R2.Support primary key lookup response in sub-second. 
> R3.Support interactive OLAP-style query over big data which involve many
> filters in a query, this type of workload should response in seconds. 
> R4.Support fast individual record extraction which fetch all columns of the
> record. 
> R5.Support HDFS so that customer can leverage existing Hadoop cluster.
> 
> When we investigate Parquet/ORC, it seems they work very well for R1 and R5,
> but they does not meet for R2,R3,R4. So we designed CarbonData mainly to add
> following differentiating features:
> 
> 1.Stores data along with index: it can significantly accelerate query
> performance and reduces the I/O scans and CPU resources, where there are
> filters in the query.  CarbonData index is consisted of multiple level, a
> processing framework can leverage this index to reduce the task it needs to
> schedule and process, and it can also do skip scan in more finer grain unit
> (called blocklet) in task side scanning instead of scanning the whole file.
> 
> 2.Operable encoded data :Through supporting efficient compression and global
> encoding schemes, can query on compressed/encoded data, the data can be
> converted just before returning the results to the users, which is "late
> materialized".
> 
> 3.Column group: Allow multiple columns form a column group to store as row
> format, thus cost of column reconstructing is reduced.
> 
> 4.Supports for various use cases with one single Data format : like
> interactive OLAP-style query, Sequential Access (big scan), Random Access
> (narrow scan).
> 
> Please kindly let me know if the above info answer your questions.
> 
> Regards
> Liang
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-incubator-general.996316.n3.nabble.com/DISCUSS-CarbonData-incubation-proposal-tp49643p49652.html
> Sent from the Apache Incubator - General mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>