Re: Looking for Champion

[Todd Lipcon]

On Fri, Jun 8, 2018 at 9:18 AM, Tim Armstrong 
wrote:

> > Meanwhile we found Impala is a very good MPP SQL query engine, so we
> integrated
> them together.
>
> Palo didn't integrate with Impala, it forked Impala's codebase and embedded
> it in its own repository. I don't remember any attempts from the Palo team
> to engage with the Impala community or attempt to work with us to
> contribute any improvements.
>
> It looks like Palo is still pulling in new code from Impala.  E.g. this
> commit includes a bunch of code I wrote as part of IMPALA-3200:
> https://github.com/baidu/palo/commit/2419384e8a211f10e7636afc6d3423
> 700ba22b5a#diff-1c501d9a8b5c3d1d1cce48d5e1fb0edf
>
> The code isn't owned by any individual, I contributed it to Apache and it's
> free for anyone to do what they want to do with it, but pulling in
> improvements from other projects without any attempt to attribute it or
> contribute improvements back seems contrary to the Apache way.
>

+1. Also briefly browsing the code I found suspicious commits like this one:
https://github.com/baidu/palo/commit/6486be64c319fe0beb8c6b4430c1662de54f182e

... in which a GPL license copyright by Oracle was "fixed" to be an Apache
license copyright Baidu.

So if this project does enter incubation I think we should be extra careful
to audit the origins of all of the source code.

-Todd


> On Fri, Jun 8, 2018 at 9:12 AM, Todd Lipcon  wrote:
>
> > On Thu, Jun 7, 2018 at 11:55 PM, Li,De(BDG)  wrote:
> >
> > > Hi, Jim
> > >
> > > Thank you for your response.
> > > Actually, we start Palo in several years ago, and that time we
> developed
> > > the storage engine based on Mesa technology.
> > > Meanwhile we found Impala is a very good MPP SQL query engine, so we
> > > integrated them together.
> > >
> >
> > From what I can tell of the Palo source, it's not so much an integration
> as
> > a copied-and-modified codebase, right? i.e Palo does not use Impala as a
> > dependency, but rather shares a lot of code from the Impala project that
> > has since diverged.
> >
> >
> > >
> > > With this integration, the goal of Palo is to implement a single,
> > > full-featured, mysql protocol compatible data warehousing.
> > >
> >
> > That sounds pretty similar to the goals of the Impala project. Impala
> isn't
> > MySQL-compatible at the moment but that seems more like a particular
> > feature that could be added rather than a distinct identity of the
> project.
> > Otherwise, Impala's goal is to be a full featured data warehouse engine
> as
> > well.
> >
> > Generally Apache has no rules against multiple projects fulfilling
> similar
> > goals or use cases, even when those projects might compete. However I
> think
> > it would be relatively unusual to incubate a project that appears to be
> > derived from a fork of an existing project, at least without first
> > considering whether the additional feature set could be contributed back
> to
> > the existing community.
> >
> > -Todd
> >
> >
> > > 在 2018/6/8 下午1:55， "Jim Apple"  写入:
> > >
> > > >Hello! As a contributor to Impala, I’d be interested in hearing
> thoughts
> > > >from the Palo community about integration between Impala and Palo.
> > > >
> > > >For instance, are there any apparent design goals of Impala that the
> > Palo
> > > >community thinks are fundamentally incompatible with Palo?
> > > >
> > > >Thanks,
> > > >Jim
> > > >
> > > >On 2018/06/08 04:45:32, "Li,De(BDG)"  wrote:
> > > >> Hi all,
> > > >>
> > > >> I am Reed, as a developer worked with the team for Palo (a MPP-based
> > > >>interactive SQL data warehousing).
> > > >> https://github.com/baidu/palo/wiki/Palo-Overview
> > > >>
> > > >> We propose to contribute Palo as an Apache Incubator project, and
> > > >> we are still looking for possible Champion if anyone would like to
> > > >>volunteer. Thanks a lot.
> > > >>
> > > >> Best Regards,
> > > >> Reed
> > > >>
> > > >> ===
> > > >> The draft of the proposal as below:
> > > >>
> > > >> #Apache Palo
> > > >>
> > > >> ##Abstract
> > > >>
> > > >> Palo is a MPP-based interactive SQL data warehousing for reporting
> and
> > > >>analysis.
> &

Re: Looking for Champion

[Todd Lipcon]

t; * clang (BSD)
> >> * Google gtest (Apache Software License v2.0)
> >>
> >> ##Required Resources
> >>
> >> ###Mailing List
> >>
> >> There are currently no mailing lists. The usual mailing lists are
> >>expected to be set up when entering incubation:
> >>
> >>
> >>priv...@palo.incubator.apache.org<mailto:private@
> palo.incubator.apache.or
> >>g>
> >> d...@palo.incubator.apache.org<mailto:d...@palo.incubator.apache.org>
> >>
> >>comm...@palo.incubator.apache.org<mailto:commits@
> palo.incubator.apache.or
> >>g>
> >>
> >> ###Subversion Directory
> >>
> >> Upon entering incubation: https://github.com/baidu/palo.
> >> After incubation, we want to move the existing repo from
> >>https://github.com/baidu/palo to Apache infrastructure.
> >>
> >> ###Issue Tracking
> >>
> >> Palo currently uses GitHub to track issues. Would like to continue to
> >>do so while we discuss migration possibilities with the ASF Infra
> >>committee.
> >>
> >> ###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
> >>
> >> * Ruyue Ma (https://github.com/maruyue,
> >>maru...@baidu.com<mailto:maru...@baidu.com>)
> >> * Chun Zhao (https://github.com/imay,
> >>buaa.zh...@gmail.com<mailto:buaa.zh...@gmail.com>)
> >> * Mingyu Chen (https://github.com/morningman,chenmin...@baidu.com)
> >> * De Li（https://github.com/lide-reed,
> >>mailtol...@sina.com）<mailto:mailtol...@sina.com%EF%BC%89>
> >> * Hao Chen (https://github.com/chenhao7253886,
> >>chenha...@baidu.com<mailto:chenha...@baidu.com>)
> >> * Chaoyong Li (https://github.com/cyongli,
> >>lichaoy...@baidu.com<mailto:lichaoy...@baidu.com>)
> >> * Bin Lin (https://github.com/lingbin,
> >>lingbi...@gmail.com<mailto:lingbi...@gmail.com>)
> >>
> >> ##Affiliations
> >>
> >> The initial committers are employees of Baidu Inc.. The nominated
> >>mentors are employees of TODO.
> >>
> >> ##Sponsors
> >>
> >> ###Champion
> >>
> >> TODO
> >>
> >> ###Nominated Mentors
> >>
> >> * sijie guo, guosi...@gmail.com<mailto:guosi...@gmail.com>
> >> * Luke Han, luke...@apache.org<mailto:luke...@apache.org>
> >> * Zheng Shao, zs...@apache.org<mailto:zs...@apache.org>
> >>
> >> ###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
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [VOTE] Resolution to graduate Apache Impala to TLP

[Todd Lipcon]

+1 (binding) from me!

Todd

On Nov 8, 2017 8:28 PM, "Jim Apple" <jbap...@cloudera.com> wrote:

> The graduation of Impala to a TLP has been discussed[0] on dev@impala,
> voted on[1] on dev@impala, and discussed[2] on general@incubator. All
> threads were open 72 hours or more, and all seem to have quiesced.
>
> This is a call for a VOTE to graduate Impala to a TLP. The draft resolution
> is below. Please select from:
>
> [ ] +1: Graduate Impala to a TLP
> [ ] +-0: Neither graduate nor do not graduate Impala to a TLP
> [ ] -1: Do NOT graduate Impala to a TLP, because ...
>
> 
>
> [0]: <
> https://lists.apache.org/thread.html/2f5db4788aff9b0557354b9106c032
> 8a29c1f90c1a74a228163949d2@%3Cdev.impala.apache.org%3E
> >
>
> [1]: <
> https://lists.apache.org/thread.html/a5a7c6895b3e019347d6e4e4cf49d6
> 7d094d31b8f2c7b4d59200f3e4@%3Cdev.impala.apache.org%3E
> >
>
> [2]: <
> https://lists.apache.org/thread.html/6b8598408f76a472532923c5a7fc51
> 0470b21671677ba3486568c57e@%3Cgeneral.incubator.apache.org%3E
> >
>
> 
>
> Establish the Apache Impala Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a high-performance distributed SQL engine.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Impala Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Impala Project be and hereby is responsible
> for the creation and maintenance of software related to a
> high-performance distributed SQL engine; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Impala" 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 Impala
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Impala
> 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 Impala Project:
>
> * Alex Behm <ab...@apache.org>
> * Bharath Vissapragada <bhara...@apache.org>
> * Brock Noland <br...@apache.org>
> * Carl Steinbach <c...@apache.org>
> * Casey Ching <ca...@apache.org>
> * Daniel Hecht <dhe...@apache.org>
> * Dimitris Tsirogiannis <dtsirogian...@apache.org>
> * Henry Robinson <he...@apache.org>
> * Ishaan Joshi <ish...@apache.org>
> * Jim Apple <jbap...@apache.org>
> * John Russell <jruss...@apache.org>
> * Juan Yu <j...@apache.org>
> * Lars Volker <l...@apache.org>
> * Lenni Kuff <lsk...@apache.org>
> * Marcel Kornacker <mar...@apache.org>
> * Martin Grund <mgr...@apache.org>
> * Matthew Jacobs <mjac...@apache.org>
> * Michael Brown <mi...@apache.org>
> * Michael Ho <k...@apache.org>
> * Sailesh Mukil <sail...@apache.org>
> * Skye Wanderman-Milne <s...@apache.org>
> * Taras Bobrovytsky <taras...@apache.org>
> * Tim Armstrong <tarmstr...@apache.org>
> * Todd Lipcon <t...@apache.org>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jim Apple be appointed to
> the office of Vice President, Apache Impala, to serve in accordance with
> and subject to the direction of the Board of Directors and the Bylaws of
> the Foundation until death, resignation, retirement, removal or
> disqualification, or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Impala PMC be and hereby is tasked
> with the creation of a set of bylaws intended to encourage open
> development and increased participation in the Apache Impala Project;
> and be it further
>
> RESOLVED, that the Apache Impala Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Impala
> podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Impala podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
>

Re: [DISCUSS] Resolution to graduate Apache Impala to TLP

[Todd Lipcon]

Hey John,

I'm not sure if Jim (proposed PMC chair) has surveyed all the PMC members
recently but I'm in touch with a good number of the PMC so I think I have a
good sense, and I'll take a whack at answering this:

It looks like of the proposed 24 PMC members, 15 work at Cloudera, the
original organization which developed Impala prior to its contribution to
the incubator. The other 9 are at a mix of employers, but as best I know,
are not currently "sponsored" by their employers to contribute to the
Impala project.

As is natural with any project, it will be easier for people to be active
contributors and committers if someone is employing them to do so, and the
PMC membership reflects that. However, I've seen that the Impala community
has also made great efforts in a few areas:

- Jim has been making a bunch of "tutorial" style posts[1] to the dev
mailing list with instructions on how to navigate the Impala code base,
write tests, and fix example bugs for new contributors. I believe he has
also added these to various repositories like the "help wanted" page at the
ASF as well as "yourfirstpr" and "up-for-grabs" on github. Unfortunately it
seems like

- Similarly, the Impala community maintains a long list of "newbie" issues
which a new contributor can use to ramp up with[2]. In other communities
I've seen these "newbie" JIRAs are a nice way for people to take on a small
patch before getting started with something large, especially in large code
bases.

- Questions on the dev list from new contributors are always answered
promptly and with good amounts of encouragement, eg [3] and [4] from
earlier this week.

- In addition to trying to recruit new developers through the ways
described above, it's clear that design discussion, project decisions, and
code review are all being done in the open based on Apache principles. A
quick glance at recent dev@ archives shows various discussions about
project scope, implementation choices, etc. They've also been consistently
adding new committers and PMC members through incubation.

- Lastly, I'll note that in the last year the Impala community has started
to build more close ties with other ASF communities. For example, Impala
and Apache Kudu are now sharing common code for RPC, and representatives
from the Impala community are now contributing regularly on Apache Parquet
(two were recently voted committers). These cross-project collaborations,
are, IMO, one of the things that make the ASF more than a "Switzerland for
intellectual property" as some have disparagingly described it, and it's
great to see Impala taking part in that.

That said, I don't want to paint a completely rosy picture: even with the
above efforts, it seems the majority of day-to-day contributions are still
coming from contributors affiliated with a single entity. The Impala
community has recognized that, and, based on the above efforts, I imagine
they plan to continue to try to expand the community even after graduation.

As for whether this should block graduation, I'll quote Roy here from a
2012 discussion:

>
> There is no diversity requirement at the ASF.  There is a behavior
> requirement for graduation and a behavior requirement for TLPs.
> We must not confuse the two.  If the Incubator says that there is a
> diversity requirement for graduation, ignore it (or at least figure
> out what the docs were supposed to say and then do that).


... and other proponents of the same philosophy can be found from other
graduation proposals.

It's clear to me that Impala is *behaving* like a TLP, and it's *despite*
their best efforts that the diversity hasn't improved as much as one might
hope. The unfortunate fact of life here is that the number of engineers out
there who are interested in contributing code to query engines is
relatively low (and most of those few are kept very busy by their
employers), so it's not terribly surprising that we haven't seen hordes
come out of the woodwork.

As for risk of abandonment, I believe that it's quite low. Cloudera has
historically contributed to many other ASF projects and with rare
exceptions the level of contribution has grown over time rather than
diminished. This is certainly the case with Impala as well, if you compare
the number of active contributors over time. Some of Cloudera's core
products are powered by Impala, and running at large numbers of enterprise
customers with multi-year support contracts, so it would be a pretty long
shot to imagine it being abandoned.

(lest anyone shout "bias!", I'll disclose that Cloudera also pays my
salary, but on a different internal team)

-Todd

[1] https://lists.apache.org/list.html?dev@impala.apache.
org:lte=1y:%22New%20Impala%20Contributors%22
[2] https://issues.apache.org/jira/browse/IMPALA-6096?filter=12341668
[3] https://lists.apache.org/thread.html/02e19a37be25f3db07b874a7602b3c
4ac66d2e1499b66bda53b561f6@%3Cdev.impala.apache.org%3E
[4] https://lists.apache.org/thread.html/4e77e2f13a9a69fa7c55c413bfc529

Re: [DISCUSS] Resolution to graduate Apache Impala to TLP

[Todd Lipcon]

Seems there isn't much discussion. Given the high number of +1s on the
podling vote, maybe time to move this to a VOTE on general?

-Todd

On Wed, Nov 1, 2017 at 7:59 AM, Jim Apple <jbap...@cloudera.com> wrote:

> My methodology was to make it opt-out - I discussed this with one of
> our mentors, todd@, and he viewed it as a good way to go about it. I
> emailed all PPMC members and mentors to ask if they wanted to be on
> the PMC, letting them know that if they said nothing they would be
> included, and that they could resign at any time, present or future. I
> got one "no", 17 "yes", and seven non-responses. I know that three of
> the non-responders are people who want to be on the PMC (we have
> spoken about it).
>
> On Wed, Nov 1, 2017 at 7:45 AM, Mike Drob <md...@apache.org> wrote:
> > Hi Jim, have you verified with all of the proposed members that they
> would
> > like to continue on with the project once it completes incubation?
> >
> > On Tue, Oct 31, 2017 at 11:38 PM, Jim Apple <jbap...@cloudera.com>
> wrote:
> >
> >> The Impala community has discussed and voted positively on graduating
> >> to a TLP. Following the instructions from the graduation guide, this
> >> thread is for discussion.
> >>
> >> Community Discussion:
> >> https://lists.apache.org/thread.html/2f5db4788aff9b0557354b9106c032
> >> 8a29c1f90c1a74a228163949d2@%3Cdev.impala.apache.org%3E
> >>
> >> Community Vote:
> >> https://lists.apache.org/thread.html/a5a7c6895b3e019347d6e4e4cf49d6
> >> 7d094d31b8f2c7b4d59200f3e4@%3Cdev.impala.apache.org%3E
> >>
> >> Resolution:
> >>
> >> Establish the Apache Impala Project
> >>
> >> WHEREAS, the Board of Directors deems it to be in the best interests of
> >> the Foundation and consistent with the Foundation's purpose to establish
> >> a Project Management Committee charged with the creation and maintenance
> >> of open-source software, for distribution at no charge to the public,
> >> related to a high-performance distributed SQL engine.
> >>
> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> >> (PMC), to be known as the "Apache Impala Project", be and hereby is
> >> established pursuant to Bylaws of the Foundation; and be it further
> >>
> >> RESOLVED, that the Apache Impala Project be and hereby is responsible
> >> for the creation and maintenance of software related to a
> >> high-performance distributed SQL engine; and be it further
> >>
> >> RESOLVED, that the office of "Vice President, Apache Impala" 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 Impala
> >> Project, and to have primary responsibility for management of the
> >> projects within the scope of responsibility of the Apache Impala
> >> 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 Impala Project:
> >>
> >> * Alex Behm <ab...@apache.org>
> >> * Bharath Vissapragada <bh...@apache.org>
> >> * Brock Noland <br...@apache.org>
> >> * Carl Steinbach <cw...@apache.org>
> >> * Casey Ching <ca...@apache.org>
> >> * Daniel Hecht <dh...@apache.org>
> >> * Dimitris Tsirogiannis <dt...@apache.org>
> >> * Henry Robinson <he...@apache.org>
> >> * Ishaan Joshi <is...@apache.org>
> >> * Jim Apple <jb...@apache.org>
> >> * John Russell <jr...@apache.org>
> >> * Juan Yu <jy...@apache.org>
> >> * Lars Volker <lv...@apache.org>
> >> * Lenni Kuff <ls...@apache.org>
> >> * Marcel Kornacker <ma...@apache.org>
> >> * Martin Grund <mg...@apache.org>
> >> * Matthew Jacobs <mj...@apache.org>
> >> * Michael Brown <mi...@apache.org>
> >> * Michael Ho <kw...@apache.org>
> >> * Sailesh Mukil <sa...@apache.org>
> >> * Skye Wanderman-Milne <sk...@apache.org>
> >> * Taras Bobrovytsky <ta...@apache.org>
> >> * Tim Armstrong <ta...@apache.org>
> >> * Todd Lipcon <to...@apache.org>
> >>
> >> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jim Apple be appointed to
> >> the office of Vice Presi

Re: [VOTE] Impala 2.9.0 release candidate 1

[Todd Lipcon]

+1 (binding)

- compiled on el6
- looked at diff from 2.8, looking for any bad license/copyright/etc which
might be problematic, didnt see anything

-Todd

On Sun, Jun 11, 2017 at 5:29 AM, John D. Ament <johndam...@apache.org>
wrote:

> +1
>
> On Thu, Jun 8, 2017 at 5:23 PM Taras Bobrovytsky <taras...@apache.org>
> wrote:
>
> > Impala 2.9.0 release candidate 1 has passed a PPMC vote; this email is
> > a call for an IPMC vote.
> >
> > The PPMC vote thread is:
> > https://lists.apache.org/thread.html/f913ab0376f997fedd9a018715ce4b
> > 3e88da67226e26751ea0e1f105@%3Cdev.impala.apache.org%3E
> > http://mail-archives.apache.org/mod_mbox/impala-dev/201706.mbox/%
> > 3CCAAXWMB7EAUnMnshPaCWC3i69C-rdduA-URyFw%3DZ4GHaVD6jxwA%40mail.gmail.com
> %3E
> > <http://mail-archives.apache.org/mod_mbox/impala-dev/201706.mbox/%
> 3CCAAXWMB7EAUnMnshPaCWC3i69C-rdduA-URyFw%3DZ4GHaVD6jxwA%
> 40mail.gmail.com%3E>
> >
> > The vote result thread is:
> > https://lists.apache.org/thread.html/877a75e7905b41b87df9901c2eae77
> > b0331ccb8638905422bea06bb4@%3Cdev.impala.apache.org%3E
> >
> > The artifacts for testing are at
> > <https://dist.apache.org/repos/dist/dev/incubator/impala/2.9.0/RC1/>.
> > That is git tag 2.9.0-rc1, tree hash
> > 93a1ac914dab21c4e08c630178aa6f8235f2d6f6, visible at
> > <https://git-wip-us.apache.org/repos/asf?p=incubator-
> impala.git;a=tree;h=
> > 93a1ac914dab21c4e08c630178aa6f8235f2d6f6
> > <https://git-wip-us.apache.org/repos/asf?p=incubator-
> impala.git;a=tree;h=93a1ac914dab21c4e08c630178aa6f8235f2d6f6>
> > >.
> >
> > The KEYS are at <https://dist.apache.org/repos/dist/dev/incubator/
> > impala/KEYS <https://dist.apache.org/repos/dist/dev/incubator/
> impala/KEYS>
> > >.
> >
> > To run RAT, follow the instructions in bin/check-rat-report.py. To
> > build, follow the instructions in bin/bootstrap_build.sh.
> >
> > This vote will be open for at least 72 hours, or until the necessary
> > number of votes (3 +1) is reached.
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
>



-- 
Todd Lipcon
Software Engineer, Cloudera

TSU/ECCN notification for Impala podling

[Todd Lipcon]

Hey folks,

I'm helping out the Impala podling with their ECCN (crypto export) notice.
I added them to the page at http://www.apache.org/licenses/exports/ (well,
really I just committed a patch provided by Sailesh Mukil). The next step
is to send the TSU NOTIFICATION email to the various US Government email
addresses.

I see Sailesh emailed general@ 11 days ago asking about who can send this
notice but didn't hear back. So now I'm trying again on his behalf :) As an
IPMC member and ASF member can I send in the notification, or would we
prefer that someone else do it? The generated email attached below lists
Roman as the contact, but iirc Ted Dunning is the current IPMC chair.

---EMAIL HEADER---
To: cr...@bis.doc.gov, e...@nsa.gov, web_s...@bis.doc.gov
Cc: legal-arch...@apache.org, {applicable project list}
Subject: TSU NOTIFICATION - Encryption
---EMAIL BODY---
SUBMISSION TYPE:  TSU

SUBMITTED BY: Roman Shaposhnik

SUBMITTED FOR:The Apache Software Foundation

POINT OF CONTACT: Secretary, The Apache Software Foundation

FAX:  +1-919-573-9199

MANUFACTURER(S):  The Apache Software Foundation

PRODUCT NAME/MODEL #: Apache Impala

ECCN: 5D002

NOTIFICATION: http://www.apache.org/licenses/exports/

Re: [VOTE] Impala 2.7.0 release candidate 3

[Todd Lipcon]

Hey Jim,

Just a quick note: I think several of the mentors (myself included) might
be busy at Strata/Hadoop World this week, so might be tough to get the
votes in within 72 hours. If the required 3 votes aren't in by early next
week, I should have more time to check the release then.

Thanks
-Todd

On Tue, Sep 27, 2016 at 1:25 PM, Jim Apple <jbap...@cloudera.com> wrote:

> Oh, I forgot to mention - to check the RAT report, you can use the
> script in bin/check-rat-report.py and the list of files to exclude
> from bin/rat_exclude_files.txt
>
> On Tue, Sep 27, 2016 at 8:33 AM, Jim Apple <jbap...@cloudera.com> wrote:
> > The Impala PPMC has voted to release 2.7.0 release candidate 3:
> >
> > Proposal:
> >
> > http://mail-archives.apache.org/mod_mbox/incubator-impala-
> dev/201609.mbox/%3CCAC-pSX36EbVohLNXdg7pV7i3gkv5_
> JajZ8ekbZM9OguOi9fH0Q%40mail.gmail.com%3E
> >
> > Mirror:
> >
> > https://lists.apache.org/thread.html/530925a9689157059d6de31a4e3f97
> 587154defd13328930112784a4@%3Cdev.impala.apache.org%3E
> >
> > The result of the vote:
> >
> > https://lists.apache.org/thread.html/477c2e59c44db5c19177b166fc8c28
> 5d940533963106cdf4c7f2ad6a@%3Cdev.impala.apache.org%3E
> >
> > The artifacts for testing (including signatures and checksums):
> >
> > https://dist.apache.org/repos/dist/dev/incubator/impala/2.7.0/RC3/
> >
> > The KEYS:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/impala/KEYS
> >
> > The git tag:
> >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-impala.
> git;a=tag;h=refs/tags/2.7.0-rc3
> >
> > This vote will be open for at least 72 hours, or until the necessary
> > number of votes (3 +1) is reached.
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > Thanks,
> > Jim
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [VOTE] Accept Spot into the Apache Incubator

[Todd Lipcon]

 relevant developer documentation:
>
>  * oni-ingest
>  * oni-ml
>  * oni-oa
>  * oni-setup
>  * oni-nfdump
>  * oni-lda-c
>
> An Installation Guide is published in the project wiki:
>  * https://github.com/Open-Network-Insight/open-network-insight/wiki
> The Spot (currently Open Network Insight) website is managed via a
> Wordpress instance hosted by Bluehost:
>  * http://open-network-insight.org/
> A Docker-based demo is available via Docker Hub:
>  * https://hub.docker.com/r/opennetworkinsight/oni-demo/
>
> == Initial Source ==
>
> The Spot codebase is currently hosted on GitHub and will be
> transitioned to the ASF repositories during incubation. Spot and its
> submodules are currently licensed under several different licenses.
>
> No trademarks or domain names for Spot have been registered to date,
> and it will be up to the ASF’s discretion to do so. The project’s
> current website at open-network-insight.org will be redirected to
> spot.incubator.apache.org during incubation.
>
> Some portions of the code are imported from other open source projects
> under the Apache 2.0, BSD, or MIT licenses.
>
> == External Dependencies ==
>
> The full set of dependencies and licenses are:
>  * Jupyter: BSD
>  * D3js: BSD
>  * Nfdump: BSD
>  * Wireshark: GNU General Public License version 2
>  * Apache Hadoop: Apache License 2.0
>  * Apache Spark: Apache License 2.0
>  * JQuery: MIT
>  * ReactJS: BSD
>  * Bootstrap: MIT
>
> Issues related to GPL dependencies will be resolved during incubation.
>
> == Cryptography ==
>
> Spot does not currently include any cryptography-related code.
>
> == Required Resources ==
>
> === Developer and user mailing lists ===
>
>  * priv...@spot.incubator.apache.org (PMC)
>  * comm...@spot.incubator.apache.org (git push emails)
>  * iss...@spot.incubator.apache.org (JIRA issue feed)
>  * d...@spot.incubator.apache.org (code reviews plus dev discussion)
>  * u...@spot.incubator.apache.org (user questions)
>
> === Repository ===
>
>  * git://git.apache.org/spot
>
> === Issue Tracker ===
>
> We would like to import our current JIRA project into the ASF JIRA,
> such that our historical commit messages and code comments continue to
> reference the appropriate bug numbers.
>
> == Initial Committers ==
>
>  * Grant Babb
>  * Ricardo Barona
>  * Cesar Berho
>  * Jarek Jarcec Cecho
>  * Michael Czerny
>  * Nick Gamb
>  * Sai Ganji
>  * Gabriela Lima Garza
>  * Victor Gonzalez
>  * Mark Grover
>  * Morris Hicks
>  * Ritu Kama
>  * Austin Leahy
>  * Ashrith Mekala
>  * Diego Ortiz
>  * Sudharshan Rao PakalaSai
>  * Srinivasa Reddy
>  * Alan Ross
>  * Everardo Lopez Sandoval
>  * Nathan Segerlind
>  * Vartika Singh
>  * Nathanael Smith
>  * Carlos Villavicencio
>
> == Affiliations ==
>
>  * Grant Babb: Jask
>  * Ricardo Barona : Intel
>  * Cesar Berho: Intel
>  * Jarek Jarcec Cecho: StreamSets
>  * Michael Czerny: Cybraics
>  * Nick Gamb: Centrify
>  * Sai Ganji: Cloudwick
>  * Gabriela Lima Garza: Intel
>  * Victor Gonzalez: Intel
>  * Mark Grover: Cloudera
>  * Morris Hicks: Cloudera
>  * Ritu Kama: Intel
>  * Austin Leahy: eBay
>  * Ashrith Mekala: Cloudwick
>  * Diego Ortiz: Intel
>  * Sudharshan Rao PakalaSai: Cloudwick
>  * Srinivasa Reddy: Cloudera
>  * Alan Ross: Intel
>  * Everardo Lopez Sandoval: Intel
>  * Nathan Segerlind: Intel
>  * Vartika Singh: Cloudera
>  * Nathanael Smith: Intel
>  * Carlos Villavicencio: Intel
>
> == Sponsors ==
>
> === Champion ===
>
>  * Doug Cutting - Cloudera
>
> === Nominated Mentors ===
>
>  * Brock Noland - ASF Member, phData
>  * Jarek Jarcec Cecho - ASF Member, StreamSets
>  * Andrei Savu - Cloudera
>  * Uma Maheswara Rao G - Intel
>
> === Sponsoring Entity ===
>
> The Apache Incubator.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [NOTICE] Community vote to graduate Apache Kudu

[Todd Lipcon]

On Fri, Jul 1, 2016 at 10:35 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Fri, Jul 1, 2016 at 10:26 AM, Todd Lipcon <t...@apache.org> wrote:
> > On Fri, Jul 1, 2016 at 10:22 AM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> >> Is the status page accurate? Only one added committer and no releases
> while
> >> under incubation?
> >>
> >
> > Yes, just one added committer so far.
> >
> > We've had five releases during incubation (3 minor releases with new
> > features, and two bug-fix releases). You can find the links at
> > http://kudu.incubator.apache.org/releases/
> >
> > I wasn't aware that they should be listed on the status page. Where do
> they
> > go? I'll update the page.
>
> You can just put them in the news section (with dates) -- that's what
> I've seen with most
> other podlings I've evaluated.
>

OK, just added them.



>
> Also, Todd, could you please provide a breakdown of composition of the
> proposed
> PMC re: who's on it is an existing ASF member?
>
>
Sure. 6 of the proposed PMC are members:


  * Adar Dembo <a...@apache.org>
  * Binglin Chang <bch...@apache.org>
  * Chris Mattman <mattm...@apache.org>   
  * Dan Burkert <danburk...@apache.org>
  * David Alves <dral...@apache.org>
  * Jake Farrell <jfarr...@apache.org>
  * Jarek Jarcec Cecho <jar...@apache.org> 
  * Jean-Daniel Cryans <jdcry...@apache.org>
  * Julien Le Dem <jul...@apache.org>  
  * Michael Stack <st...@apache.org>  
  * Mike Percy <mpe...@apache.org>
  * Misty Stanley-Jones <mi...@apache.org>
  * Todd Lipcon <t...@apache.org>  


-Todd

Re: [NOTICE] Community vote to graduate Apache Kudu

[Todd Lipcon]

On Fri, Jul 1, 2016 at 10:22 AM, John D. Ament 
wrote:

> Is the status page accurate? Only one added committer and no releases while
> under incubation?
>

Yes, just one added committer so far.

We've had five releases during incubation (3 minor releases with new
features, and two bug-fix releases). You can find the links at
http://kudu.incubator.apache.org/releases/

I wasn't aware that they should be listed on the status page. Where do they
go? I'll update the page.

-Todd

[ANNOUNCE] Apache Kudu (incubating) 0.9.1 released

[Todd Lipcon]

The Apache Kudu (incubating) team is happy to announce the release of
Kudu 0.9.1!

Kudu is an open source storage engine for structured data which
supports low-latency random access together with efficient analytical
access patterns. It is designed within the context of the Apache Hadoop
ecosystem and supports many integrations with other data analytics projects
both inside and outside of the Apache Software Foundation.

This is a bug-fix release which fixes several issues in the prior 0.9.0
release. See
http://kudu.incubator.apache.org/releases/0.9.1/docs/release_notes.html for
more information on the resolved issues.

The release can be downloaded from:
http://kudu.incubator.apache.org/releases/0.9.1/

Regards,
The Apache Kudu (incubating) team
===

Apache Kudu (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does indicate
that the project has yet to be fully endorsed by the ASF.

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Tue, Jun 28, 2016 at 9:27 AM, Sergio Fernández  wrote:

>
>
> * Although redirections are correctly handled, I'd remove all getkudu.io
> links in the documentation to use the new canonical domain kudu.apache.org
>
> * I noticed you incubating releases are not clearly marked (version suffix)
> at http://kudu.apache.org/releases/ until you actually retrieve the file.
> I'd say it's something to remark, to know what releases happened before
> incubation, what during and what afterwards.
>
>
The above two are now addressed.


> * The podling status page http://incubator.apache.org/projects/kudu.html
> requires some work (I went there just to check the releases issue mentioned
> before).
>

What specific items did you note? It's up to date as far as I know, but
maybe I missed something we were supposed to edit?

-Todd

[RESULT] [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

72 hours have passed, so this vote is now closed. We had 6 binding +1s.
Thanks for voting!

-Todd


On Mon, Jun 27, 2016 at 8:10 AM, Todd Lipcon <t...@apache.org> wrote:

> Hi,
>
> The PPMC vote to release Apache Kudu (incubating) 0.9.1 RC1 passed and
> I'm now submitting this to the IPMC.
>
> Vote thread:
>
> http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201606.mbox/%3CCADY20s6%3D%2BnKNgvx%3DG_pKupQGiH%2B9ToS53LqExBwWM6vLp-ns9A%40mail.gmail.com%3E
>
> Result:
>
> http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201606.mbox/%3CCADY20s6gXTnV_vGqX1GrwecegdcFuEs9ovA2KPykkT524PaA3w%40mail.gmail.com%3E
>
> On the podling vote, one +1 (mine) is from an IPMC member, so carries over
> into this vote.
>
> This is a source-only release. The artifacts were staged here:
> https://dist.apache.org/repos/dist/dev/incubator/kudu/0.9.1-RC1/
>
> It was built from this tag:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=095b481e308ad954cfe36ff7f91751f43eaf6aa1
>
> The release notes can be found here (some links will only work when this
> version is released):
>
> https://github.com/apache/incubator-kudu/blob/master/docs/release_notes.adoc#rn_0.9.1
>
> KEYS file:
> http://www.apache.org/dist/incubator/kudu/KEYS
>
> Please try the release and vote; vote will be open for at least 72 hours.
>
> Thanks,
> -Todd
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Mon, Jun 27, 2016 at 11:20 PM, Justin Mclean 
wrote:

> Hi,
>
> +1 binding
>
> But would be good clarify licenses of patches and fix up the slightly
> confusing section in LICENSE.
>
>
Thanks for your thorough check as always. Notes below:


> I checked:
> - incubating in name
> - signature and hashes good
> - DISCLAIMER exists
> - NOTICE is good
> - LICENSE I think is missing a boost [1] and again I think the end section
> is confusing. Boost is MIT licensed and is in the source not just the
> binary [1]
>

The LICENSE.txt has:

thirdparty/boost_uuid/: Boost software license
  - See thirdparty/boost_uuid/LICENSE.txt

which as I understand it is the preferred way to include MIT-style licenses
in LICENSE.txt. That's based on
http://www.apache.org/dev/licensing-howto#permissive-deps
which says "add a pointer to the dependency's license within the
distribution and a short note summarizing its licensing".



> - all source files have Apache headers
> - no unexpected binary files
> - can compile from source
>
> There are a number of patches in [2], it’s not clear how they are licensed.
>
>
Good point. This isn't new in this release, but we should address it. Do
you think a README file in this directory would be sufficient? The patches
are a mix - either they're backports from upstream repositories (in which
case they're licensed the same as the source they are patching) or they are
in a couple cases a small local patch to fix some integration with the Kudu
build (in which case they're licensed as Apache, I suppose, but are trivial
enough that we'd be fine licensing them with the modified source). What's
the best way to handle this?

-Todd

Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org

[Todd Lipcon]

+1 (binding)

Having to switch domain names during graduation is a pain for users, SEO,
printed t-shirts, etc. Especially after many podlings arrive from outside
the ASF and already have to switch once when entering incubation, adding
the second switch is aggravating.

-Todd

On Tue, Jun 28, 2016 at 10:42 AM, Stian Soiland-Reyes <st...@apache.org>
wrote:

> +1 (non-binding)
>
> On 28 Jun 2016 3:29 p.m., "John D. Ament" <johndam...@apache.org> wrote:
>
> > All,
> >
> > Its been discussed a few times, and I'd like to provide clear feedback to
> > the infra team on how to implement going forward.
> >
> > Typically, the addresses $podling.apache.org and $
> > podling.incubator.apache.org work, and have worked for a while.
> >
> > This is a call to vote on whether the IPMC agrees to this or not.  If
> they
> > do, I will ask infra to further clean this up, as DNS seems to be an
> issue
> > at times for podlings.  The benefit is that for SEO, the website URL does
> > not change.
> >
> > I'm going to leave this open for 72 hours, at least and hope for some
> > binding votes on this subject.
> >
> > [+1] I want the two URLs to both work the same.
> > [+/- 0] Don't care
> > [-1] I want the $podling.incubator.apache.org URL to be the one that
> > works,
> > including emails.
> >
> > John
> >
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Tue, Jun 28, 2016 at 11:28 AM, Todd Lipcon <t...@apache.org> wrote:

> On Tue, Jun 28, 2016 at 11:25 AM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> Hi Todd,
>>
>> If the release managers log in to id.apache.org and put their
>> keys in their profile the kudu.asc will get generated automatically.
>>
>
> Hrm, when I log in, it shows:
>
> OpenPGP Public Key Primary Fingerprint: AEC77EAF
>
> which is correct. Perhaps something wrong with the autogeneration or the
> groups?
>
> Oh, perhaps I needed to enter the whole fingerprint: 1B5D 384B 734F 3680
5286 2EB5 5E43 CAB9 AEC7 7EAF

Tried that, we'll see if it propagates.

-Todd

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Tue, Jun 28, 2016 at 11:25 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Hi Todd,
>
> If the release managers log in to id.apache.org and put their
> keys in their profile the kudu.asc will get generated automatically.
>

Hrm, when I log in, it shows:

OpenPGP Public Key Primary Fingerprint: AEC77EAF

which is correct. Perhaps something wrong with the autogeneration or the
groups?

-Todd

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Tue, Jun 28, 2016 at 9:36 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Hi All,
>
> minor nit first:
>
> there are no KEYS present in:
>  
>
>
> And, the Git WP repo doesn’t have a KEYS file.
>
> Can someone point me to the KEYS file?
>
>
It's here:

https://dist.apache.org/repos/dist/release/incubator/kudu/KEYS

(how do we update the keys/group/kudu.asc file? In the TLPs I've been a
part of, I only seem to recall the KEYS file in the dist/ dir)

-Todd

[VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

Hi,

The PPMC vote to release Apache Kudu (incubating) 0.9.1 RC1 passed and
I'm now submitting this to the IPMC.

Vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201606.mbox/%3CCADY20s6%3D%2BnKNgvx%3DG_pKupQGiH%2B9ToS53LqExBwWM6vLp-ns9A%40mail.gmail.com%3E

Result:
http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201606.mbox/%3CCADY20s6gXTnV_vGqX1GrwecegdcFuEs9ovA2KPykkT524PaA3w%40mail.gmail.com%3E

On the podling vote, one +1 (mine) is from an IPMC member, so carries over
into this vote.

This is a source-only release. The artifacts were staged here:
https://dist.apache.org/repos/dist/dev/incubator/kudu/0.9.1-RC1/

It was built from this tag:
https://git-wip-us.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=095b481e308ad954cfe36ff7f91751f43eaf6aa1

The release notes can be found here (some links will only work when this
version is released):
https://github.com/apache/incubator-kudu/blob/master/docs/release_notes.adoc#rn_0.9.1

KEYS file:
http://www.apache.org/dist/incubator/kudu/KEYS

Please try the release and vote; vote will be open for at least 72 hours.

Thanks,
-Todd

Re: [VOTE] Apache Kudu (incubating) 0.8.0 RC1

[Todd Lipcon]

On Wed, Apr 6, 2016 at 7:21 PM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> +1 binding
>
> I checked:
> - file name contains incubating
> - signature and hash good
> - contains DISCLAIMER
> - LICENSE and NOTICE good
> - All source files have Apache headers
> - No unexpected binary files in source release
> - Can compile from source (on OS X it takes a while)
>
>
Yea, our fresh builds do take quite some time since we download and build a
bunch of dependencies as part of the build process. Thanks for slogging
through it and glad to hear it completed successfully!


> Only possible (very minor) thing I found is I think this file should be
> ASF licensed not Cloudera licensed? [1]
>
>
You're absolutely right. Sorry about that - my editor was still configured
to automatically add the old header when I created a new file. Just posted
a patch here for our next release: http://gerrit.cloudera.org:8080/#/c/2729/
(and also fixed my editor file templates!)


> Also amusing to note that this file [2] has 13 Apache headers in it all
> copyright Twitter, no other files has duplicate headers that I could find.
>
>
:) This one we just download from the upstream distribution, so can't
really take credit for this masterpiece. I'm sure the reason is that it's
"built" by concatenating a bunch of separate files.


> The build instructions mentioned in the readme are hosted on a non Apache
> web site. In fact all URLs to the expected incubator site redirect to this
> external site. I assume at some point this will be moved to Apache
> infrastructure?
>
>
Yes -- this is one of the tasks we have outstanding that we need to do in
the next month (ideally before our next report, since it was called out in
our previous report).

-Todd



> Thanks,
> Justin
>
> 1. ./src/kudu/util/memory/overwrite.h
> 2. ./www/bootstrap/js/bootstrap.js
> 3. http://getkudu.io/docs/installation.html#_build_from_source
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Podling Report Reminder - April 2016

[Todd Lipcon]

Hi Incubator,

It seems that this request for a report is in error -- we already completed
our initial three months of monthly reporting and should now be reporting
as part of group 2 (next report due in May). I missed updating the
podlings.xml file after our most recent report.

Shall I go ahead and remove Kudu from this month's report draft? I'll also
update podlings.xml to remove the monthly=true tag (I missed the
instructions to do this after the third monthly report).

-Todd

On Tue, Mar 29, 2016 at 4:03 AM, <johndam...@apache.org> wrote:

> -
> Apologies if you received this multiple times
> -
>
> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 20 April 2016, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, April 6th).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
>
> This should be appended to the Incubator Wiki page at:
>
> http://wiki.apache.org/incubator/April2016
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: [VOTE] Apache Kudu (incubating) 0.7.1 RC2

[Todd Lipcon]

On Tue, Mar 8, 2016 at 1:22 PM, Justin Mclean  wrote:

> Hi,
>
> > The specific cases of BSD-licensed software here is FindProtobuf.cmake,
> which
> > is a build-time-only dependency and does not become part of the binary
> > distribution.
>
> If there is a binary distribution why was it not voted on at the same
> time? Normally if something is the binary and not in the source your need a
> different LICENSE file for each type of release. [1][2]
>

There is no binary distribution, but we do want to make life easier for
downstream distributors (so they don't have to go on license scavenger
hunts). That's why the license file makes reference to binary distributions.

The above case refers to a file which is part of the source distribution
but _not_ the binary distribution. In that case, we provide a "pointer" to
the source, which has the license, rather than copy-pasting the license (as
discussed in the 0.7.0RC3 release thread:
http://mail-archives.apache.org/mod_mbox/incubator-general/201603.mbox/%3CCADY20s4RWd45kG7%2BrkAkkNg5Hh_7%2Bfy2LtSqh_ouhdXVccwLFQ%40mail.gmail.com%3E
)



>
> > Yes, that's what I thought, but in your previous vote, I understood that
> > you and others preferred the LICENSE.txt file to be "minimal" and include
> > "pointers" in cases where the license didn't _require_ the full text to
> be
> > reproduced.
>
> Legally AFAICS it meet the terms of the license. it’s just not consistent
> (i.e. mixing long and short forms of licenses) and may cause some confusion
> for anyone looking into it.
>

OK. Are you suggesting that for our next release we go back to fully
copying all licenses into LICENSE.txt rather than providing pointers? (i.e.
essentially reverting back to what we did for 0.7.0?)


>
> > https://github.com/svn2github/valgrind/blob/master/include/valgrind.h#L4
> 
>
> Subtle difference it says “BSD-style” (which in this context I think just
> means permissive). Compare the clauses in zlib and BSD and you see it’s
> zlib. Given they both permissive and both compatible with Apache it’s a
> very minor issue.
>

Right, it has some clauses from BSD and some from zlib. (it's not identical
to zlib either afaict). If you prefer we say "BSD style" instead of "Hybrid
BSD" I can make that change.

-Todd

Re: [VOTE] Apache Kudu (incubating) 0.7.1 RC2

[Todd Lipcon]

Hi Justin,

Thanks for voting (and for your +1 despite there being some questions).
Responses inline:

On Mon, Mar 7, 2016 at 7:01 PM, Justin Mclean  wrote:

> Hi,
>
> +1 binding
>
> I checked:
> - signatures and hashes fine
> - name contains incubating
> - DISCLAIMER exists
> - LICENSE and NOTICE good
> - No unexpected binaries
> - Source file have apache headers (some have extra ones)
> - Can compile on OS X (but it takes a while)
>
> I still think there’s a couple of minor issues with license.
> - For instance the added text "The following dependencies or pieces of
> incorporated source code have licenses such that either:...” is IMO
> incorrect. For instance BSD requires license to be both in source and
> binary distributions.
>

Right, that's true that the BSD license does require that (and that's why
most of the other licenses above in the file are for BSD source). The
specific cases of BSD-licensed software here is FindProtobuf.cmake, which
is a build-time-only dependency and does not become part of the binary
distribution. I should add a note to clarify that.


> - It’s unclear why the 1/2 dozen non Apache license software listed under
> this text are treated in a different way to the other bundled
> software.Wouldn’t it  be better to be consistent and handle all licenses
> the same way?
>

Yes, that's what I thought, but in your previous vote, I understood that
you and others preferred the LICENSE.txt file to be "minimal" and include
"pointers" in cases where the license didn't _require_ the full text to be
reproduced. I'm happy to revert the change we made for this release and go
back to what we did in the previous one, but I thought this was what was
requested.


> - This file [1] isn’t BSD as noted in the license but a modified zlib,
> notice the clauses about modifications
>
> The license file says "half BSD, half zlib". The file self-describes as a
"BSD-style license":
https://github.com/svn2github/valgrind/blob/master/include/valgrind.h#L4

But as you noted, it has some zlib-like clauses. So I think "half BSD half
zlib" is relatively accurate, no?


There also looks to be some minor issues with Apache headers in several
> files
>
> Several files have double Apache headers. For instance in src/kudu/util:
> bit-stream-utils.h, bit-stream-utils.inline.h, bit-util-test.cc,
> bit-util.h, logging.cclogging.h, rle-encoding.h, rle-test.cc,
> url-coding-test.cc, url-coding.h
>

Thanks. I think these were files that we borrowed from Apache Impala
(incubating) at some point when it already had the license header, and our
scripting which prepended the header got them wrong. Will fix.


> It also may be that Apache headers have been added to files that shouldn’t
> have them? For  Instance [2] is stated as BSD in the license file but has
> an Apache header. Was the original header removed? Also [3] has an Apache
> header but notes it's BSD licensed. These are not the only examples.
>

Aha, I see what happened with random-util.{cc,h}. In fact these files were
authored as part of Kudu, and _not_ BSD licensed. The mention of them in
LICENSE.txt is a hold-over from an earlier revision which contained some a
single function from WebRTC. That code was later refactored into random.h
as Random::Normal(...). We should just update the LICENSE.txt file to say
that random.h contains the BSD-licensed code and not random_util.cc.

I'll try to take a swing through for any other double-licensed stuff I can
find.

-Todd

Re: [VOTE] Accept Gearpump into the Apache Incubator

[Todd Lipcon]

eal-time stream
> > processing, they have fundamentally different architectures. In
> particular,
> > Gearpump adopts the micro-service model, building on the Akka framework,
> > for concurrency, isolation and error handling, which we believe is a
> future
> > trend for building distributed software. We look forward to collaboration
> > with other Apache communities.
> >
> >  An Excessive Fascination with the Apache Brand 
> > The ASF has a strong brand; we appreciate that fact and will protect the
> > brand. Gearpump is an existing open source project with many committers
> and
> > years of effort.  The reasons to join Apache are outlined in the
> Rationale
> > section above.
> >
> > === Documentation ===
> > Information on Gearpump can be found at:
> > Gearpump website: http://gearpump.io
> > Codebase: https://github.com/gearpump/gearpump
> >
> > === Initial Source and Intellectual Property Submission Plan ===
> > The Gearpump codebase is currently hosted on Github: https://github.com/
> > gearpump/gearpump. We will use this codebase to migrate to the Apache
> > foundation. The Gearpump source code is licensed under Apache License
> > Version 2.0 and will be kept that way. All contributions on the project
> > will be licensed directly to the Apache foundation through signed
> > Individual Contributor License Agreements or Corporate Contributor
> License
> > Agreements.
> >
> > === External Dependencies ===
> > All of Gearpump dependencies are distributed under Apache compatible
> > licenses.
> >
> > Gearpump leverages Akka which has Apache 2.0 licensing for current and
> > planned versions
> >
> http://doc.akka.io/docs/akka/2.3.12/project/licenses.html#Licenses_for_Dependency_Libraries
> >
> > === Cryptography ===
> > Gearpump does not include or utilize cryptographic code.
> >
> > === Required Resources ===
> > We request that following resources be created for the project to use
> >
> >  Mailing lists 
> >
> > gearpump-priv...@incubator.apache.org (with moderated subscriptions)
> > gearpump-dev
> > gearpump-user
> > gearpump-commits
> >
> >  Git repository 
> > Git is the preferred source control system: git://
> git.apache.org/gearpump
> >
> >  Documentation 
> > https://gearpump.incubator.apache.org/docs/
> >
> >  JIRA instance 
> > JIRA Gearpump (GEARPUMP)
> > https://issues.apache.org/jira/browse/gearpump
> >
> > === Initial Committers ===
> > * Xiang Zhong 
> >
> > * Tianlun Zhang 
> >
> > * Qian Xu 
> >
> > * Huafeng Wang 
> >
> > * Kam Kasravi 
> >
> > * Weihua Jiang 
> >
> > * Tomasz Targonski 
> >
> > * Karol Brejna 
> >
> > * Gang Wang 
> >
> > * Mark Chmarny 
> >
> > * Xinglang Wang 
> >
> > * Lan Wang 
> >
> > * Jianzhong Chen 
> >
> > * Xuefu Zhang 
> >
> > * Rui Li 
> >
> > === Affiliations ===
> > * Xiang Zhong –  Intel
> >
> > * Tianlun Zhang –  Intel
> >
> > * Qian Xu –  Intel
> >
> > * Huafeng Wang –  Intel
> >
> > * Kam Kasravi –  Intel
> >
> > * Weihua Jiang –  Intel
> >
> > * Tomasz Targonski – Intel
> >
> > * Karol Brejna – Intel
> >
> > * Mark Chmarny – Intel
> >
> > * Gang Wang – Intel
> >
> > * Mark Chmarny  – Intel
> >
> > * Xinglang Wang  – Ebay
> >
> > * Lan Wang – Huawei
> >
> > * Jianzhong Chen – Cloudera
> >
> > * Xuefu Zhang – Cloudera
> >
> > * Rui Li  – Intel
> >
> > === Sponsors ===
> >
> >  Champion 
> > Andrew Purtell 
> >
> >  Nominated Mentors 
> > * Andrew Purtell 
> >
> > * Jarek Jarcec Cecho 
> >
> > * Todd Lipcon 
> >
> > * Xuefu Zhang 
> >
> > * Reynold Xin 
> >
> >  Sponsoring Entity 
> > Apache Incubator PMC​
> >
> > ​
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

On Tue, Mar 1, 2016 at 6:18 PM, Justin Mclean 
wrote:

> Hi,
>
> > OK. In the case that we've incorporated code, we could switch to doing:
> >
> > """
> > src/kudu/gutil/valgrind.h: Hybrid BSD (half BSD, half zlib)
> > src/kudu/util (some portions): 3-clause BSD license
> > src/kudu/util (HdrHistogram-related classes): public domain
> > src/kudu/util/{random-util.cc},{random.h}: some portions adapted from
> > WebRTC project (modules/video_coding/main/test/test_util.cc) under a
> > 3-clause BSD license.
> >
> >  For full license text of the above licenses, please refer to the license
> > headers at the top of the respective files.
> > """
> >
> > ...and then make sure that those files contain the full text of the
> > license
>
> That covers all license requirements AFAICS.
>
> > , instead of copy-pasting the text into LICENSE.txt.
>
> I’d prefer the short form in the license point to the full text but that's
> just my personal preference.
>
> The Kudu PPMC are free to deal with it in this way of they want.
>
>
Thanks again for the input. I started to do as you suggested and just refer
to the headers, but then I realized a slight complication -- this makes
life harder for binary distributors. Currently, a binary distribution can
simply include the 'LICENSE.txt' file (eg in
/usr/share/doc/kudu/LICENSE.txt or somesuch) and be sure that they comply
with the 2nd clause of the BSD license. If instead we refer to the source,
a binary distributor would have to do the work of copy-pasting these
notices back up into the LICENSE.txt file or other documentation in order
to comply.

Given that you said the PPMC is free to choose either way, I'll propose to
the other PPMC members that we stay with the status quo and continue
copying these licenses into the top-level file, so that binary distributors
dont have to go on a scavenger hunt.

-Todd

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

On Tue, Mar 1, 2016 at 4:05 PM, Justin Mclean <justinmcl...@me.com> wrote:

> Hi,
>
> > I seem to recall reading some place or another that pointers
> > to licenses in the forms of URLs or textual references are frowned upon,
> > because licenses may change over time, or the links may break
>
> Correct. Also most licenses say you much include the full text of the
> license in your distribution.
>
>
OK. In the case that we've incorporated code, we could switch to doing:

"""
src/kudu/gutil/valgrind.h: Hybrid BSD (half BSD, half zlib)
src/kudu/util (some portions): 3-clause BSD license
src/kudu/util (HdrHistogram-related classes): public domain
src/kudu/util/{random-util.cc},{random.h}: some portions adapted from
WebRTC project (modules/video_coding/main/test/test_util.cc) under a
3-clause BSD license.

  For full license text of the above licenses, please refer to the license
headers at the top of the respective files.
"""

...and then make sure that those files contain the full text of the
license, instead of copy-pasting the text into LICENSE.txt. Does that sound
like the best path forward?

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

Hi Justin,

I'm working on making the changes you suggested below. A few follow-up
questions:

On Mon, Feb 22, 2016 at 5:48 PM, Justin Mclean  wrote:

> Hi,
>
> > Hmm, I'm not seeing this -- got a line number? Line 614 in LICENSE.txt
> > says "StumbleUpon”.
>
> Sorry it was WebRTC line 360 and also LevelDB line 315.
>
>
WebRTC and LevelDB are both projects that were released by Google. So, the
BSD license's 3rd clause refers to Google rather than the project names.
So, will leave this.

> Can you clarify what this means?
>
> See [1] basically a pointer to the full test of the license in the source
> release.
> 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
>

In the example provided in the link above, the "pointer" takes the form of
a file path 'deps/superwidget/'. But in our case, we are not fully
including the source distro where the code came from. Rather, we derived
some of our code from some of their code, piece-by-piece. So, we can't
point to their LICENSE file as a path within our source distro, as it's not
fully bundled. I seem to recall reading some place or another that pointers
to licenses in the forms of URLs or textual references are frowned upon,
because licenses may change over time, or the links may break, and thus
it's better to make sure the license text is captured at the time the
dependency is included.

Does that sound reasonable?

> Given it's not software so much as a template for a publication, there
> > isn't a particular open source license associated with it. But, we
> > received permission to redistribute, which we cited in the commit
> > message above and added the header requested by the ACM.
>
> I don’t know the full details and INAL but as far as I can tell under the
> terms of that license you have to pay to redistribute it.
>
> Even if you got permission to distribute from ACM are 3rd parties allowed
> to take this file and redistribute that?
>
> Either way it should be noted in LICENSE I think.
>

We are working around this by removing the file in question.

-Todd

Re: Project Kudu. .NET edition

[Todd Lipcon]

On Sat, Feb 27, 2016 at 12:13 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Fri, Feb 26, 2016 at 5:33 PM, Todd Lipcon <t...@cloudera.com> wrote:
>> To be slightly more specific, we cleared it with the _legal team_ for
>> the .NET foundation (who runs the project that Roman spotted), not
>> just some engineers.
>
> Great! I just wanted to capture a bit of serendipitous discovery on my part
> and make sure we're not in trouble.
>
> Also, capturing the above would be a very useful note in your
> PODLINGNAMESEARCH JIRA.

Noted! https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-93

-Todd

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

Re: Project Kudu. .NET edition

[Todd Lipcon]

On Sat, Feb 27, 2016 at 9:33 AM, Josh Elser <josh.el...@gmail.com> wrote:
> Has the podling gone through the PODLINGNAMESEARCH process yet?

Not yet. Thanks for the reminder.

>
> Seems like that would come up in the shakedown, then -- just mentioning it
> because you came across it now, Roman?
> On Feb 26, 2016 5:33 PM, "Todd Lipcon" <t...@cloudera.com> wrote:
>
>> To be slightly more specific, we cleared it with the _legal team_ for
>> the .NET foundation (who runs the project that Roman spotted), not
>> just some engineers.
>>
>> -Todd
>>
>> On Fri, Feb 26, 2016 at 5:16 PM, Todd Lipcon <t...@cloudera.com> wrote:
>> > Hi Roman,
>> >
>> > Before we first publicly used the name, we were in touch with that
>> > project team, and got permission to do so. Additionally, I think the
>> > project scope/purpose is different enough that it wouldn't cause
>> > confusion. (fwiw based on tweets, I think there is also a fast food
>> > chain in Saudi Arabia named Kudu)
>> >
>> > If the ASF needs some documentation of this, I'll see what we can dig up.
>> >
>> > -Todd
>> >
>> > On Fri, Feb 26, 2016 at 5:10 PM, Roman Shaposhnik <ro...@shaposhnik.org>
>> wrote:
>> >> Hi!
>> >>
>> >> while working on some .NET Foundation
>> >> projects I've come across:
>> >> https://www.dotnetfoundation.org/kudu
>> >>
>> >> Not sure how much of a problem this could
>> >> be for Apache Kudu (incubating).
>> >>
>> >> Thanks,
>> >> Roman.
>> >>
>> >> -
>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Todd Lipcon
>> > Software Engineer, Cloudera
>>
>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>



-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: Project Kudu. .NET edition

[Todd Lipcon]

To be slightly more specific, we cleared it with the _legal team_ for
the .NET foundation (who runs the project that Roman spotted), not
just some engineers.

-Todd

On Fri, Feb 26, 2016 at 5:16 PM, Todd Lipcon <t...@cloudera.com> wrote:
> Hi Roman,
>
> Before we first publicly used the name, we were in touch with that
> project team, and got permission to do so. Additionally, I think the
> project scope/purpose is different enough that it wouldn't cause
> confusion. (fwiw based on tweets, I think there is also a fast food
> chain in Saudi Arabia named Kudu)
>
> If the ASF needs some documentation of this, I'll see what we can dig up.
>
> -Todd
>
> On Fri, Feb 26, 2016 at 5:10 PM, Roman Shaposhnik <ro...@shaposhnik.org> 
> wrote:
>> Hi!
>>
>> while working on some .NET Foundation
>> projects I've come across:
>> https://www.dotnetfoundation.org/kudu
>>
>> Not sure how much of a problem this could
>> be for Apache Kudu (incubating).
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera



-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: Project Kudu. .NET edition

[Todd Lipcon]

Hi Roman,

Before we first publicly used the name, we were in touch with that
project team, and got permission to do so. Additionally, I think the
project scope/purpose is different enough that it wouldn't cause
confusion. (fwiw based on tweets, I think there is also a fast food
chain in Saudi Arabia named Kudu)

If the ASF needs some documentation of this, I'll see what we can dig up.

-Todd

On Fri, Feb 26, 2016 at 5:10 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> Hi!
>
> while working on some .NET Foundation
> projects I've come across:
> https://www.dotnetfoundation.org/kudu
>
> Not sure how much of a problem this could
> be for Apache Kudu (incubating).
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

Thanks, we'll check with legal before our next release (or just remove the file)

-Todd

On Mon, Feb 22, 2016 at 5:57 PM, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
>> Right, we actually noticed this as well and got in touch with the ACM
>> to clarify the licensing. We already fixed it for the next release in
>> this commit:
>> https://github.com/apache/incubator-kudu/commit/6991cd432d0be35743995b3ca7cb5eedc072e3cb
>>
>> Given it's not software so much as a template for a publication, there
>> isn't a particular open source license associated with it. But, we
>> received permission to redistribute, which we cited in the commit
>> message above and added the header requested by the ACM. We figured
>> that it wasn't necessary to re-spin the RC given the response was
>> basically that we were in the clear.
>
> Probably best to double check on legal discuss re this if your not already 
> done so.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

Hey Justin,

Thanks a lot for taking the time to check out the rc and vote. A
couple notes inline:

On Mon, Feb 22, 2016 at 4:32 PM, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
> +1 (binding). Nice work on the LICENSE.
>
> I checked:
> - signature and hashes correct
> - release name contain incubating
> - DISCLAIMER exits
> - LICENSE file has some minor issues (see below)
> - NOTICE good
> - unable to compile on OS X (but notes say it only has experiment support)
>
> Minor issues LICENSE file:
> - BSD for Async HBase has "Google Inc.” in the 3rd clause probably a copy and 
> paste error?

Hmm, I'm not seeing this -- got a line number? Line 614 in LICENSE.txt
says "StumbleUpon".

> - Path to WebRTC licensed files should include src/kudu/util/random.h
> - Missing license in LICENSE for FindGMock [1]
> - Possible incorrect Apache header on BSD license in file [2]? Should also be 
> in LICENSE.
> - Header with copyright Cloudera which should be ASF? [3]

Thanks, will fix the four above for our next release.

> - Short form i.e. pointers to license file are preferred.

Can you clarify what this means? I thought, with the BSD license in
particular, it's important to reproduce the whole license because
there is a "substitution" of a company name into one of the clauses?

> There is possibly a more serious issue with the licensing of this file [4]. 
> See also [5][6].
>
> From inside the file:
> "Permission to make digital or hard copies of all or part of this work for 
> personal or classroom use is granted without fee provided that copies are not 
> made or distributed for profit or commercial advantage and that copies bear 
> this notice and the full citation on the first page.  To copy otherwise, to 
> republish, to post on servers or to redistribute to lists, requires prior 
> specific permission and/or a fee.”
>
> May be serious enough for another RC? IMO Up to the RM/PMC to decide that or 
> fix in the next incubating release.
>

Right, we actually noticed this as well and got in touch with the ACM
to clarify the licensing. We already fixed it for the next release in
this commit:
https://github.com/apache/incubator-kudu/commit/6991cd432d0be35743995b3ca7cb5eedc072e3cb

Given it's not software so much as a template for a publication, there
isn't a particular open source license associated with it. But, we
received permission to redistribute, which we cited in the commit
message above and added the header requested by the ACM. We figured
that it wasn't necessary to re-spin the RC given the response was
basically that we were in the clear.

> A few other minor things:
> - NOTICE file file line should probably be "Apache Kudu (incubating)" rather 
> than "Apache Kudu”

Will fix.

> - There’s another github mirror here https://github.com/cloudera/kudu - does 
> anyone else think that a little odd?

Since we originally lived at that location, we have a lot of stars,
watchers, and forks from that repository. So, we wanted to continue
maintaining it as a mirror, though we've edited the header on the top
of the page to indicate that it's not the primary source control.
We've been figuring this is no different than other projects that have
multiple github mirrors.


>
> JFYI The OSX compile error was (after about 1/2 hour of compiling things):
> + make -j8 install
> CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.14 -I m4
> /bin/sh: aclocal-1.14: command not found
> make: *** [aclocal.m4] Error 127

Interesting. I run on Ubuntu but hopefully another Kudu developer will
pipe up and might know what's going on here - probably missing some
'brew install ' in the docs.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Todd Lipcon]

Porting over my +1 from the podling vote. Not sure if it's binding in the
IPMC context if I already voted as PPMC.

Todd
On Feb 22, 2016 7:10 AM, "Jean-Daniel Cryans"  wrote:

> Hi,
>
> The PPMC vote to release Apache Kudu (incubating) 0.7.0's RC3 passed and
> I'm now submitting this to the IPMC.
>
> Vote thread:
>
> http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201602.mbox/%3CCAGpTDNepARg8zW%2BXdoorQV48KSfkemi5HLuzgeeJarMTXcNF%3Dw%40mail.gmail.com%3E
>
> Result:
>
> http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201602.mbox/%3CCAGpTDNdHR2Ji5rxahWN1z6Z64F8TEL6jMsepGZrr_rBWNuKGnA%40mail.gmail.com%3E
>
> The is a source-only release. The artifacts were staged here:
> https://dist.apache.org/repos/dist/dev/incubator/kudu/0.7.0-RC3/
>
> Please try the release and vote; vote will be open for at least 72 hours.
>
> Thanks,
>
> J-D
>

Re: Confusion over NOTICE vs LICENSE files

[Todd Lipcon]

-
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> --
> 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
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Confusion over NOTICE vs LICENSE files

[Todd Lipcon]

For the sake of all of these discussions, are "bundled dependencies" and
"work derived from other projects source code" 100% equivalent? In many
cases we've copied (or ported) small bits of code from other projects and
believe them to be 'derived work' from a copyright standpoint. My
assumption is that there's no difference between that and "bundling" in
which you are typically taking a release artifact as-is from another
project.

-Todd

On Tue, Jan 26, 2016 at 10:52 AM, Marvin Humphrey <mar...@rectangular.com>
wrote:

> On Tue, Jan 26, 2016 at 9:10 AM, Todd Lipcon <t...@cloudera.com> wrote:
> > Yea, even after this thread I'm not entirely sure on whether copyright
> > statements need to be duplicated from original source files into NOTICE
> or
> > not.
>
> Copyright statements on their own within a source file?  They do not.
>
> > For example, Subversion's LICENSE file mentions the 'linenoise' library
> and
> > its copyrights, but its NOTICE file doesn't.
>
> That is the propagation of the *entire* BSD-2 *license* for linenoise from
> the
> source file to the LICENSE file. All members of the BSD license family are
> templates which require insertion of a copyright statement.
>
>
> http://svn.apache.org/viewvc/subversion/trunk/LICENSE?revision=1714640=markup#l369
>
> Legally, not even the propagation of the BSD-2 license to LICENSE is
> required.
> So long as the bundled source files for linenoise retain that license
> header,
> the BSD-2 license is satisfied and redistribution is legally permitted.
>
> However, it is the policy of the ASF that the top level LICENSE file
> summarize
> information about the licensing of bundled dependencies. This provides a
> service to downstream consumers of ASF products -- they can examine the
> top-level LICENSE file instead of having to look through every last source
> file.
>
> Marvin Humphrey
>
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Confusion over NOTICE vs LICENSE files

[Todd Lipcon]

I started a Google doc to try to clear this up in a simple "if/then" type
layout:
https://docs.google.com/document/d/1eftfjrWpOG-dRkw9dZWRfcj3p_qCeE5xC-G0Y5j29Ck/edit

I have a bunch of confusion/open questions still, and email threads don't
seem to be the best way to clear these things up, because different people
have different opinions. Perhaps people could take a look at the above doc
and add comments? This could then become a reference guide (or adendum to
the existing licensing howto?).

-Todd

On Tue, Jan 26, 2016 at 11:35 AM, Ted Dunning <ted.dunn...@gmail.com> wrote:

> There really isn't a difference between things copied without modification
> and things copied with modification insofar as copyright is concerned.
>
> Copying without modification into a larger work is just a special case of a
> derived work. The change introduced is represented by adding the rest of
> the work.
>
>
>
> On Tue, Jan 26, 2016 at 11:01 AM, Todd Lipcon <t...@cloudera.com> wrote:
>
> > For the sake of all of these discussions, are "bundled dependencies" and
> > "work derived from other projects source code" 100% equivalent? In many
> > cases we've copied (or ported) small bits of code from other projects and
> > believe them to be 'derived work' from a copyright standpoint. My
> > assumption is that there's no difference between that and "bundling" in
> > which you are typically taking a release artifact as-is from another
> > project.
> >
> > -Todd
> >
> > On Tue, Jan 26, 2016 at 10:52 AM, Marvin Humphrey <
> mar...@rectangular.com>
> > wrote:
> >
> > > On Tue, Jan 26, 2016 at 9:10 AM, Todd Lipcon <t...@cloudera.com>
> wrote:
> > > > Yea, even after this thread I'm not entirely sure on whether
> copyright
> > > > statements need to be duplicated from original source files into
> NOTICE
> > > or
> > > > not.
> > >
> > > Copyright statements on their own within a source file?  They do not.
> > >
> > > > For example, Subversion's LICENSE file mentions the 'linenoise'
> library
> > > and
> > > > its copyrights, but its NOTICE file doesn't.
> > >
> > > That is the propagation of the *entire* BSD-2 *license* for linenoise
> > from
> > > the
> > > source file to the LICENSE file. All members of the BSD license family
> > are
> > > templates which require insertion of a copyright statement.
> > >
> > >
> > >
> >
> http://svn.apache.org/viewvc/subversion/trunk/LICENSE?revision=1714640=markup#l369
> > >
> > > Legally, not even the propagation of the BSD-2 license to LICENSE is
> > > required.
> > > So long as the bundled source files for linenoise retain that license
> > > header,
> > > the BSD-2 license is satisfied and redistribution is legally permitted.
> > >
> > > However, it is the policy of the ASF that the top level LICENSE file
> > > summarize
> > > information about the licensing of bundled dependencies. This provides
> a
> > > service to downstream consumers of ASF products -- they can examine the
> > > top-level LICENSE file instead of having to look through every last
> > source
> > > file.
> > >
> > > Marvin Humphrey
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Confusion over NOTICE vs LICENSE files

[Todd Lipcon]

Hey folks,

I'm working on tidying up the source for Apache Kudu (incubating) in order
to prepare for our first ASF release, and ran into a couple bits of
confusion:

1) In the case that we've borrowed code from another Apache 2.0 licensed
project, the licensing howto[1] says that there is no need to modify
LICENSE unless it transitively has dependencies with such a requirement. Is
this true even if the original dependency carries a copyright? For example,
we bundle Twitter's Bootstrap library and currently have attribution in our
LICENSE file[2] indicating the copyright (even though it's also at the top
of the relevant files). Not necessary? We can just entirely ignore such
dependencies in LICENSE and NOTICE so long as the original header's
maintained?

2) In other cases we've bundled MIT or BSD-licensed source. The license
says that redistributions must retain the text of the license. Is it
sufficient that that text be only in the source code, or should we also
duplicate it into LICENSE.txt as we've done for code derived from
AsyncHBase? [3]

3) We have many thirdparty dependencies which are not "bundled" in the
source release. Instead, our build process has a script which downloads
them from the internet, unpacks, and compiles them. So, despite not being
part of the artifact itself, they are required components for the build
(and in most cases become static-linked into the binary). We currently list
all of these dependencies and their licenses in LICENSE.txt. Is this
necessary, or should we move these into a separate file?

Thanks
-Todd

[1] http://www.apache.org/dev/licensing-howto
[2]
https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=blob;f=LICENSE.txt;h=347de4f88b5e6240f6e560b2b1208364d6042c55;hb=HEAD#l424
[3]
https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=blob;f=LICENSE.txt;h=347de4f88b5e6240f6e560b2b1208364d6042c55;hb=HEAD#l553

-- 
Todd Lipcon
Software Engineer, Cloudera

Re: File headers for third party utility code

[Todd Lipcon]

On Tue, Jan 5, 2016 at 2:39 AM, Steve Loughran 
wrote:

>
> One thing to try here is contribute all changes back to the original
> author(s), at least as patch submissions, so giving them the option to
> incorporate it.
>
>
Sure, I agree that makes sense in the case that you're borrowing someone
else's code and using it in the same way that they do. In our case, we're
not fixing bugs or improving, but rather adapting the code to a new context
in ways that don't make sense to the original one.

Most of the thirdparty software that we bundle, we pull in the original
sources and apply a few local patches[1]. In those cases we've submitted
the patches upstream and typically drop the patch when we upgrade to the
next version of the dependency.

-Todd
[1] https://github.com/cloudera/kudu/tree/master/thirdparty/patches

File headers for third party utility code

[Todd Lipcon]

Hi all,

I'm working on verifying licenses and copyrights, etc, in Apache Kudu
(incubating). There is one area I wanted to confirm the right way to
document in our LICENSE/NOTICE files:

Kudu makes use of a lot of open source utility code borrowed from (or
adapted from) other open source projects. In particular, we've borrowed a
lot of code from Chromium's "base" module[1] which is licensed under a BSD
3-clause license[2]. We also have some code from Google Supersonic[3]
licensed under the Apache License[4]. The majority of this borrowed code is
under a 'gutil' directory in the Kudu tree[5]. We also have some small
amounts of code borrowed from LevelDB under the BSD license[6].

Given that all of the borrowed code is under the Apache or BSD licenses,
the inclusion of the code is completely allowable under the license terms.
The only question is the best way to document the inclusion to best follow
established ASF practices. My understanding is that we should:

1) Maintain the original copyright notices and license headers in the files.
2) In the cases that we've made non-trivial changes to the source, we
should additionally add the ASF copyright notice at the top of the file,
and amend the original copyright statement with the words "Some portions"
as we've done for example in cache.cc[7].
3) In all files (regardless of whether we've made changes), we should add
the Apache license header above any existing license headers, while
maintaining the existing one.
4) In the LICENSE file, we should make note of the included code and its
copyrights as we have done here[8].

I'm aware that there is a notion that Apache projects should ask for
permission to borrow code rather than forking communities. However, this is
all very generic utility code with no standalone project community or
releases. In fact, many of these files can already be found copy-pasted
into many different open source projects beyond just Chromium or LevelDB.
So, I don't think there are any viable alternatives to copy-pasting.

Thanks
-Todd

[1] https://chromium.googlesource.com/chromium/src/base/+/master/
[2] https://chromium.googlesource.com/chromium/src/+/master/LICENSE
[3] https://github.com/google/supersonic
[4] https://github.com/google/supersonic/blob/master/LICENSE
[5] https://github.com/cloudera/kudu/tree/master/src/kudu/gutil
[6] https://github.com/google/leveldb/blob/master/LICENSE
[7] https://github.com/cloudera/kudu/blob/master/src/kudu/util/cache.cc#L15
[8] https://github.com/cloudera/kudu/blob/master/LICENSE.txt#L205

Re: File headers for third party utility code

[Todd Lipcon]

On Mon, Jan 4, 2016 at 3:29 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 1/4/16, 3:02 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
> <shaposh...@gmail.com on behalf of ro...@shaposhnik.org> wrote:
> >
> >> 2) In the cases that we've made non-trivial changes to the source, we
> >> should additionally add the ASF copyright notice at the top of the file,
> >> and amend the original copyright statement with the words "Some
> >>portions"
> >> as we've done for example in cache.cc[7].
> >
> >I don't think you need to do that, but you do need an ASF license header.
> >
> >I don't think ASF encourages "Portions Copyright ... ASF" statements
> >on individual files.
> >
> >> 3) In all files (regardless of whether we've made changes), we should
> >>add
> >> the Apache license header above any existing license headers, while
> >> maintaining the existing one.
> >
> >Correct and it should also solve #2
>
> Doesn't #3 from http://www.apache.org/legal/src-headers.html#3party
> contradict this?
>
>
> 0. The term "third-party work" refers to a work not submitted directly to
> the ASF by the copyright owner or owner's agent.
> 1. Do not modify or remove any copyright notices or licenses within
> third-party works.
> 2. Do ensure that every third-party work includes its associated license,
> even if that requires adding a copy of the license from the third-party
> download site into the distribution.
> 3. Do not add the standard Apache License header to the top of third-party
> source files.
> 4. Minor modifications/additions to third-party source files should
> typically be licensed under the same terms as the rest of the rest of the
> third-party source for convenience.
> 5. Major modifications/additions to third-party should be dealt with on a
> case-by-case basis by the PMC.
>

Right, I guess I'm not sure what qualifies minor vs major. In some cases,
we've done trivial edits like putting things in a "kudu" namespace or
removing some portability code. In other cases, we've made more substantial
alterations to fit our codebase (eg
https://github.com/cloudera/kudu/commit/0ee3218b9edcd7e5e9d450307bc22d0eadfb53be
) but still kept the overall API/design. At what point do we go ahead and
add the Apache License header?

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Karma for Kudu podling committers

[Todd Lipcon]

Hi all,

I'm trying to follow the mentor guide to ensure that all of the initial
committers for the new Kudu podling have the correct karma. The guide seems
to be only half-updated for git, so having a bit of confusion here.

My understanding from the guide is that for git, the
asf-authorization-template is not used, but instead we just grant access to
the 'incubator' LDAP group. For the initial committers who did not
previously have Apache accounts, they do have the incubator group. For
other initial committers, they need to be added to the 'incubator' group.

I tried to use the modify_unix_group.pl utility per
http://www.apache.org/dev/pmc.html#karma-podling but seems that I have
insufficient access (I guess because I'm not the IPMC chair?) So, it seems
that the correct protocol is to email general@incubator or infra for this
request?

The committers who need access to our git repo are:

dralves
jdcryans
wang
danburkert
misty

LMK if instead I should file an INFRA ticket. We should also update the
mentor guide to clarify this aspect of karma granting.

-Todd

Re: Karma for Kudu podling committers

[Todd Lipcon]

Well, this is the confusion. I think there are _two_ things that need to be
granted: the SVN auth (which will let them update the SVN-managed site) and
the LDAP group membership (which isn't mentioned on that page).

Seems like one of you guys took care of the LDAP as well. But perhaps we
should update the mentor guide to explain that?

-Todd

On Mon, Dec 21, 2015 at 11:56 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> crud, looks like our emails crossed wires. Want me to revert?
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
>
>
> -Original Message-
> From: Marvin Humphrey <mar...@rectangular.com>
> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
> Date: Monday, December 21, 2015 at 11:49 AM
> To: "general@incubator.apache.org" <general@incubator.apache.org>
> Cc: "d...@kudu.incubator.apache.org" <d...@kudu.incubator.apache.org>
> Subject: Re: Karma for Kudu podling committers
>
> >On Mon, Dec 21, 2015 at 11:38 AM, Todd Lipcon <t...@apache.org> wrote:
> >
> >> The committers who need access to our git repo are:
> >>
> >> dralves
> >> jdcryans
> >> wang
> >> danburkert
> >> misty
> >
> >I've added the people in this group.  The technical permissions required
> >is
> >that you have to be any PMC chair (I'm currently the Lucy chair).  For
> >other
> >TLPs, it would be expected that the PMC chair would do the updating.  But
> >for
> >the Incubator, because the volume of podling committer adds is so large,
> >it
> >has long been the case that other Chairs will help out.
> >
> >  http://incubator.apache.org/guides/mentor.html#who-auth-karma
> >
> >  If no mentor has karma then an email should be posted to the IPMC
> >private
> >  list requesting that the grant is performed. One of the IPMCers with
> >karma
> >  will authorize the committer.
> >
> >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
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Moving Kudu and Impala to reporting group 2

[Todd Lipcon]

Thanks, Marvin, that works well for us from the Kudu perspective. (Too late
for the December report anyway IIRC)

-Todd

On Mon, Dec 14, 2015 at 12:39 PM, Marvin Humphrey 
wrote:

> Greets,
>
> We still have an imbalance for podlings in various reporting groups:
> not enough in group 2 (February, May, August, November), and too many
> in group 3 (March, June, September, December).
>
> I've taken the liberty of moving Kudu and Impala to group 2. This
> means that after they finish their first 3 monthly reports in January,
> February and March, their first quarterly report will come due in May.
>
> I did this once before for HAWQ and HORN. (For some reason, reporting
> group 3 is really popular.) After this change, we're approaching a
> decent balance:
>
>$ grep 'group="1"' content/podlings.xml | wc -l
>  17
>$ grep 'group="2"' content/podlings.xml | wc -l
>  16
>$ grep 'group="3"' content/podlings.xml | wc -l
>  20
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> 

Modifications to SGA

[Todd Lipcon]

Hi all,

I'm working on completing the SGA for the contribution of Kudu. Our legal
counsel has requested a few small changes to the text (just clarifications,
nothing substantial). Can I submit the amended SGA, or do I need to have
the changes signed off on the ASF side by some representative? Likely this
question will also apply to Impala, given the same counsel would be
involved on our side.

Whom should I work with to check the requested changes?

-Todd

[RESULT] [VOTE] Accept Kudu into the Apache incubator

[Todd Lipcon]

The vote for accepting Kudu into the Incubator has now closed. The vote
count is as follows:

+1 (binding): 29
+1 (not binding): 9
-1 (binding): 2

The full list of voters is reproduced below. Apologies if I mistakenly
counted a binding vote as non-binding (had to check the IPMC members list
for a number of people who didn't specify).

The -1 votes were related to code review policy which was discussed
thoroughly in a separate thread.

As this is a majority vote, the vote passes.

Thanks for voting!
-Todd

+1 (binding)
--
Todd Lipcon
Reynold Xin
Jarek Jarcec Cecho
Jacques Nadeau
Andrew Purtell
Arvind Prabhakar
Alex Karasulu
Jean-Baptiste Onofre
Chris Mattman
Jake Farrell
Edward Yoon
Julien Le Dem
Sean Busbey
Hyunsik Choi
John D Ament
Carl Steinbach
Brock Noland
Owen O'Malley
Tom White
Rob Vesse
Roman Shaposhnik
Chris Douglas
Doug Cutting
Hitesh Shah
Julian Hyde
Ted Dunning
Andrew Bayer
Michael Stack
Andrei Savu

+1 (not binding)
--
Mike Percy
Ashish Paliwal
Patrick Angeles
Luke Han
Amol Kekre
Joe Witt
Tony Kurc
Henry Robinson
Sree V

-1 (binding)

Ralph Goers
Greg Stein

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Wed, Nov 25, 2015 at 7:06 PM, Ralph Goers 
wrote:


> Much as I don’t care to participate in GPL projects I also don’t care to
> participate in pure RTC projects as both restrict me in ways I very much
> dislike,
>
>
You're entitled to that opinion. I personally don't care to participate in
CTR projects. So, as stated above, let's agree to disagree, and let each
community within Apache decide for themselves.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Wed, Nov 25, 2015 at 1:32 PM, Ralph Goers 
wrote:

> 1. What makes you think all bugs are caught during code reviews (they
> aren’t)?
>

They aren't. But some are. And catching them in code review is cheaper than
catching them when a user hits them.

Additionally, plenty of other things are caught in code reviews other than
bugs (style, compat issues, design issues, poor test coverage, etc)


> 2. What makes you think that code reviews after the commit are any less
> thorough than reviews required before the commit?
>
> If you don’t trust your community to do code reviews after you commit then
> there is a problem in your community. Forcing a code review to occur first
> won’t fix that.
>

Isn't it an issue of scalability? With pre-commit code reviews, typically
the uploader of the code will pick out one or two people to review the code
who know the area well. Or, if no one is picked by the submitter of the
patch, the committers will organically end up deciding who is to review the
code, at which point that reviewer ends up being a sort of shepherd for the
patch, sticking with the contributor through multiple revs until it's ready
for commit.

With post-commit review, do you expect to watch the mailing list and review
every patch that comes in? In a project like Hadoop, that's not feasible --
we've had ~35,000 lines of code changed in the last month in 267 patches.
If everyone tries to review every patch post-commit, you end up with n^2
work as the community grows.

Amusingly enough, I happened upon a chapter in "Producing Open Source
Software" that invoke's Greg's name on the subject of open source code
review (http://producingoss.com/en/setting-tone.html):

 There was no guarantee that every commit would be reviewed, though one
> might sometimes look over a change if one were particularly interested in
> that area of the code. Bugs slipped in that really could and should have
> been caught. A developer named Greg Stein, who knew the value of code
> review from past work, decided that he was going to set an example by
> reviewing every line of every single commit that went into the code
> repository. Each commit anyone made was soon followed by an email to the
> developer's list from Greg, dissecting the commit, analyzing possible
> problems, and occasionally praising a clever bit of code.


I'm impressed that Greg was able to do this with Subversion, but not sure
how it could work in a faster paced project, and also feel like this
practice produces a serious "bus factor" issue.

-Todd

Re: [VOTE] Accept Impala into the Apache Incubator

[Todd Lipcon]

On Tue, Nov 24, 2015 at 1:03 PM, 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
>

+1 (binding)

[VOTE] Accept Kudu into the Apache Incubator

[Todd Lipcon]

:

 * '''Twitter Bootstrap''': Apache 2.0
 * '''d3''': BSD 3-clause
 * '''epoch JS library''': MIT
 * '''lz4''': BSD 2-clause
 * '''gflags''': BSD 3-clause
 * '''glog''': BSD 3-clause
 * '''gperftools''': BSD 3-clause
 * '''libev''': BSD 2-clause
 * '''squeasel''':MIT license
 * '''protobuf''': BSD 3-clause
 * '''rapidjson''': MIT
 * '''snappy''': BSD 3-clause
 * '''trace-viewer''': BSD 3-clause
 * '''zlib''': zlib license
 * '''llvm''': University of Illinois/NCSA Open Source (BSD-alike)
 * '''bitshuffle''': MIT
 * '''boost''': Boost license
 * '''curl''': MIT
 * '''libunwind''': MIT
 * '''nvml''': BSD 3-clause
 * '''cyrus-sasl''': Cyrus SASL license (BSD-alike)
 * '''openssl''': OpenSSL License (BSD-alike)

 * '''Guava''': Apache 2.0
 * '''StumbleUpon Async''': BSD
 * '''Apache Hadoop''': Apache 2.0
 * '''Apache log4j''': Apache 2.0
 * '''Netty''': Apache 2.0
 * '''slf4j''': MIT
 * '''Apache Commons''': Apache 2.0
 * '''murmur''': Apache 2.0


'''Build/test-only dependencies''':

 * '''CMake''': BSD 3-clause
 * '''gcovr''': BSD 3-clause
 * '''gmock''': BSD 3-clause
 * '''Apache Maven''': Apache 2.0
 * '''JUnit''': EPL
 * '''Mockito''': MIT

== Cryptography ==

Kudu does not currently include any cryptography-related code.

== Required Resources ==

=== Mailing lists ===

 * priv...@kudu.incubator.apache.org (PMC)
 * comm...@kudu.incubator.apache.org (git push emails)
 * iss...@kudu.incubator.apache.org (JIRA issue feed)
 * d...@kudu.incubator.apache.org (Gerrit code reviews plus dev discussion)
 * u...@kudu.incubator.apache.org (User questions)


=== Repository ===

 * git://git.apache.org/kudu

=== Gerrit ===

We hope to continue using Gerrit for our code review and commit workflow.
The Kudu team has already been in contact with Jake Farrell to start
discussions on how Gerrit can fit into the ASF. We know that several other
ASF projects and podlings are also interested in Gerrit.



If the Infrastructure team does not have the bandwidth to support Gerrit,
we will continue to support our own instance of Gerrit for Kudu, and make
the necessary integrations such that commits are properly authenticated and
maintain sufficient provenance to uphold the ASF standards (e.g. via the
solution adopted by the AsterixDB podling).

== Issue Tracking ==

We would like to import our current JIRA project into the ASF JIRA, such
that our historical commit messages and code comments continue to reference
the appropriate bug numbers.

== Initial Committers ==

 * Adar Dembo a...@cloudera.com
 * Alex Feinberg a...@strlen.net
 * Andrew Wang w...@apache.org
 * Dan Burkert d...@cloudera.com
 * David Alves dral...@apache.org
 * Jean-Daniel Cryans jdcry...@apache.org
 * Mike Percy mpe...@apache.org
 * Misty Stanley-Jones mi...@apache.org
 * Todd Lipcon t...@apache.org

The initial list of committers was seeded by listing those contributors who
have contributed 20 or more patches in the last 12 months, indicating that
they are active and have achieved merit through participation on the
project. We chose not to include other contributors who either have not yet
contributed a significant number of patches, or whose contributions are far
in the past and we don’t expect to be active within the ASF.

== Affiliations ==

 * Adar Dembo - Cloudera
 * Alex Feinberg - Forward Networks
 * Andrew Wang - Cloudera
 * Dan Burkert - Cloudera
 * David Alves - Cloudera
 * Jean-Daniel Cryans - Cloudera
 * Mike Percy - Cloudera
 * Misty Stanley-Jones - Cloudera
 * Todd Lipcon - Cloudera

== Sponsors ==

=== Champion ===

 * Todd Lipcon

=== Nominated Mentors ===

 * Jake Farrell - ASF Member and Infra team member, Acquia
 * Brock Noland - ASF Member, StreamSets
 * Michael Stack - ASF Member, Cloudera
 * Jarek Jarcec Cecho - ASF Member, Cloudera
 * Chris Mattmann - ASF Member, NASA JPL and USC
 * Julien Le Dem - Incubator PMC, Dremio
 * Carl Steinbach - ASF Member, LinkedIn

=== Sponsoring Entity ===

The Apache Incubator

Re: [VOTE] Accept Kudu into the Apache Incubator

[Todd Lipcon]

On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon <t...@apache.org> 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!)

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Sun, Nov 22, 2015 at 12:28 PM, Konstantin Boudnik  wrote:

>
> Basing the "diversity" on affiliaiton (or any other arbitrary property) is
> quite bogus - I am with you and Roy on this. All I want to make sure that
> people who contributed code and, perhaps, became inactive for a period of
> time, are aware about the project trying to enter the incubation. Which
> might
> trigger their wish to participate again.
>
> Hopefully, the third time to clarify my initial point would be a charm ;)
>
>
Third time's the charm :)

I sent an email to our existing kudu-dev and kudu-user mailing lists:
https://groups.google.com/forum/#!topic/kudu-user/_0RfyNHWPZE

i also forwarded the email along with a specific note to encourage
continued contribution to those who have contributed patches in the past
but were not listed as initial committers.

Any other suggestions for the proposal? Otherwise it seems like
discussion's winding down and I'll call a VOTE on Monday or Tuesday.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Sun, Nov 22, 2015 at 12:18 PM, Konstantin Boudnik  wrote:

>  >
> > > The question is not to decide if C-T-R is The Apache Way over R-T-C.
> The
> > > question is wether a project entering incubation with a selected R-T-C
> > > mode is likely to exit incubation for the simple reason it will be very
> > > hard for this project to grow its community due to this choice. It's
> > > like starting a 100m race with a 20kb backpack on your shoulder...
> > >
> >
> > If you have any statistics that show this to be the case, I'd be very
> > interested. RTC is the norm in basically every Apache project I've been a
> > part of, many of which have thriving communities and are generally
> regarded
> > as successful software projects.
>
> Do you have any statistics on that, Todd? Would be very interesting to see,
> indeed.
>
>
I don't have incubator stats... nor do I have a good way to measure "most
active" or "most successful" projects in the ASF (seems that itself could
be a 'centithread'-worthy discussion). But a potential proxy could be the
number of stars on github:
https://github.com/search?utf8=%E2%9C%93=user%3Aapache=Repositories=searchresults
 (sort by number of stars)

Of the top ten:

Spark: RTC via github pull request
Storm: RTC (https://storm.apache.org/documentation/BYLAWS.html see "Code
Change")
Cassandra: RTC (based on my skimming the commit log which has "Reviewed by"
quite often)
CouchDB: RTC (http://couchdb.apache.org/bylaws.html see "RTC" section)
Kafka: RTC (based on "Reviewed by" showing up in recent commit logs)
Thrift: CTR
Mesos: RTC (based on reviewboard links in most of the recent commits)
Zookeeper: RTC (based on personal experience and comments above in this
thread)
Cordova: CTR (based on
https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
)
Hadoop: RTC (based on personal experience)

Briefly looking through the #11 through #30 projects I also see a
substantial number which operate on RTC (and others for which I don't know)

So, I don't think there's much evidence that RTC prevents a project from
becoming successful in the eyes of the developer community. Also worth
noting that several of these are relatively new TLPs (i.e. within the last
~3 years) whereas others are quite old but still active and successful.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein  wrote:

> Todd: as Ross notes, your three points about code reviews in a CTR project
> are quite valid, and match accepted engineering practices.
>
> What I haven't seen is an explanation why a committer must be treated the
> same as a drive-by. Both are subject to requiring "permission"[1] to make
> even the simplest of changes under RTC. Even worse, from else-thread, it
> sounds like under your control scheme, you don't even allow the committer
> to apply their own change [after review].


They can apply their own change once someone else has +1ed it. On Hadoop,
for example, the usual workflow when I review another committer's patch is
that I give them a +1 and they commit it themselves. On gerrit or github,
because the actual "commit" process is just clicking a button on a web UI,
it's more normal for the reviewer to be the one to commit it after giving
the +1 review, but both happen and either one's fine.


> A committer can give a binding +1
> to somebody else's work. But they aren't trusted to give that to their own
> work. Just like a drive-by contributor can't be trusted.
>

Right, they can't give it to their own work because it defeats the purpose
of the code review (discussed earlier).

Of course it's not hard and fast -- eg fixing a broken build due to a
missing 'import' statement or something would be totally fine to commit
without review, or fixing a grammar mistake in a comment, or anything else
that's obviously trivial. But once actual code is changing, it's expected
to get two pairs of eyes.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> None of your statements below are any different between RTC or CTR. The
> only time it makes aa difference is if no one does reviews.  My feeling is
> that a community that insists on RTC believes that code will not be
> reviewed unless committers are forced to do it.
>

Yep, that's my assumption. It's much more fun to write code than review it,
so "forcing" people to do it is a good idea. The other worry is that, in a
large community of developers, an implicit "people probably read the
commits as they come in" doesn't scale. Should every person read every
commit? Probably not. How do you know if someone else has already read the
commit, or signed up to do so? What if it takes you a few days to get
around to reviewing something, and by that point there are already a bunch
more patches stacked up on top making it impossible to revert or difficult
to modify? Who's in charge of fixing the bugs or issues in a post-commit
review?

I'm sure it works fine for many communities (I use CTR on some internal
infrastructure within small teams where bugs are less costly and the rate
of development is slow). But it doesn't work for all.


>
> All I can say, is that for me personally I have found the process of
> having to create a patch, submit a code review, wait for the review and
> participate in it, then wait for the commit to be onerous enough that I
> just don’t bother.


Sure, that's a big problem with some RTC workflows. Using gerrit or github
PRs makes the flow much easier -- for a trivial or small patch, the sort
that a "drive-by" contributor typically contributes, there probably won't
be any review comments. So, they just push the patch for review, and they
can be out of the loop for the rest of it. If the patch requires small
revisions (eg addressing a typo or something) I think it's fine for the
reviewer to just make the change themselves and commit on behalf of the
original author to avoid the issue you've raised. Most RTC workflows permit
this kind of thing in my experience.


> As I said, in a CTR community there are many times where branches are
> created and the code is reviewed there before being merged because the
> authors believe the code is significant enough to require it.


Amusingly enough, the RTC communities I'm a part of do the opposite: you
can make a branch which operates under CTR, so long as it's reviewed
sufficiently prior to its merge into trunk. This is great for rapid
development and prototyping when a small number of contributors are working
together on a new project.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 8:50 AM, Steve Loughran <ste...@hortonworks.com>
wrote:
... snipped...

>
> But at the same time, RTC dissuades me from doing the minor stuff, because
> the effort to submit a patch to correct a spelling error in a comment is so
> high. I think it can endanger code quality.
>
> There's also the fact that even those bigger patches I may do, will need
> to be reviewed before commit —and there's a backlog on the Hadoop codebase
> which includes a lot of mine. Other people are as lax about reviewing those
> patches as I (sadly) am about reviewing patches from people other than me.
> It takes effort and time, and if you are working on something full time,
> where that means evening and weekends as well as daytime, then its easy to
> neglect things.
>

Big +1. This is one of the reasons that I'm a big fan of gerrit for
contributions, and why a lot of people are big fans of github pull requests.

With the "post patch on JIRA (or mailing list)" workflow, the committer, in
order to review, has to download the patch, apply it, look at a diff with
more context, rebuild the project, type up notes, and paste them back into
the JIRA. If it's a simple patch and there are no notes, the committer
still has to manually apply it, write a commit message, and push from their
own box -- typically at least running a build in between to make sure they
didn't somehow mess up the patch application or commit their own WIP junk
from their repository.

This makes it at least a 5-10 minute process (often longer if my local
repository is in bad shape) to commit a trivial change contributed by a new
contributor.

Compare to gerrit: I see a patch up for review. It shows me the diff in
context along with the author's commit message. For a trivial patch, I can
review it in 30 seconds. When it's good to go, I hit a "Submit" button and
the rest of the workflow is taken care of. End-to-end time less than a
minute.

It might seem petty, but I've witnessed my own behavior in these two
different workflows. On Hadoop, I rarely go through the patch queue,
because I know that it's going to be a big pain to review even trivial
changes. There's a vicious cycle, because when changes aren't reviewed
quickly, they fall out of date, and then become harder to review, take more
effort from contributors to rebase, etc. On other projects that use gerrit,
I rarely see a mergeable trivial patch last longer than a couple hours
before someone clicks the necessary buttons to merge it.

This may all seem orthogonal to RTC vs CTR, but I think my point is this:
the actual review workflow strongly affects the rate of progress in RTC
projects.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

[DISCUSS] Kudu incubator proposal

[Todd Lipcon]

''': Boost license
 * '''curl''': MIT
 * '''libunwind''': MIT
 * '''nvml''': BSD 3-clause
 * '''cyrus-sasl''': Cyrus SASL license (BSD-alike)
 * '''openssl''': OpenSSL License (BSD-alike)

 * '''Guava''': Apache 2.0
 * '''StumbleUpon Async''': BSD
 * '''Apache Hadoop''': Apache 2.0
 * '''Apache log4j''': Apache 2.0
 * '''Netty''': Apache 2.0
 * '''slf4j''': MIT
 * '''Apache Commons''': Apache 2.0
 * '''murmur''': Apache 2.0


'''Build/test-only dependencies''':

 * '''CMake''': BSD 3-clause
 * '''gcovr''': BSD 3-clause
 * '''gmock''': BSD 3-clause
 * '''Apache Maven''': Apache 2.0
 * '''JUnit''': EPL
 * '''Mockito''': MIT

== Cryptography ==

Kudu does not currently include any cryptography-related code.

== Required Resources ==

=== Mailing lists ===

 * priv...@kudu.incubator.apache.org (PMC)
 * comm...@kudu.incubator.apache.org (git push emails)
 * iss...@kudu.incubator.apache.org (JIRA issue feed)
 * d...@kudu.incubator.apache.org (Gerrit code reviews plus dev discussion)
 * u...@kudu.incubator.apache.org (User questions)


=== Repository ===

 * git://git.apache.org/kudu

=== Gerrit ===

We hope to continue using Gerrit for our code review and commit workflow.
The Kudu team has already been in contact with Jake Farrell to start
discussions on how Gerrit can fit into the ASF. We know that several other
ASF projects and podlings are also interested in Gerrit.



If the Infrastructure team does not have the bandwidth to support Gerrit,
we will continue to support our own instance of Gerrit for Kudu, and make
the necessary integrations such that commits are properly authenticated and
maintain sufficient provenance to uphold the ASF standards (e.g. via the
solution adopted by the AsterixDB podling).

== Issue Tracking ==

We would like to import our current JIRA project into the ASF JIRA, such
that our historical commit messages and code comments continue to reference
the appropriate bug numbers.

== Initial Committers ==

 * Adar Dembo a...@cloudera.com
 * Alex Feinberg a...@strlen.net
 * Andrew Wang w...@apache.org
 * Dan Burkert d...@cloudera.com
 * David Alves dral...@apache.org
 * Jean-Daniel Cryans jdcry...@apache.org
 * Mike Percy mpe...@apache.org
 * Misty Stanley-Jones mi...@apache.org
 * Todd Lipcon t...@apache.org

The initial list of committers was seeded by listing those contributors who
have contributed 20 or more patches in the last 12 months, indicating that
they are active and have achieved merit through participation on the
project. We chose not to include other contributors who either have not yet
contributed a significant number of patches, or whose contributions are far
in the past and we don’t expect to be active within the ASF.

== Affiliations ==

 * Adar Dembo - Cloudera
 * Alex Feinberg - Forward Networks
 * Andrew Wang - Cloudera
 * Dan Burkert - Cloudera
 * David Alves - Cloudera
 * Jean-Daniel Cryans - Cloudera
 * Mike Percy - Cloudera
 * Misty Stanley-Jones - Cloudera
 * Todd Lipcon - Cloudera

== Sponsors ==

=== Champion ===

 * Todd Lipcon

=== Nominated Mentors ===

 * Jake Farrell - ASF Member and Infra team member, Acquia
 * Brock Noland - ASF Member, StreamSets
 * Michael Stack - ASF Member, Cloudera
 * Jarek Jarcec Cecho - ASF Member, Cloudera
 * Chris Mattmann - ASF Member, NASA JPL and USC
 * Julien Le Dem - Incubator PMC, Dremio

=== Sponsoring Entity ===

The Apache Incubator

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Tue, Nov 17, 2015 at 10:38 AM, Atri Sharma  wrote:

> Sounds great.
>
> I would love to be an help as a committer, if possible. This seems to be
> fantastic in line with my focus areas and can help existing big data
> projects to accelerate so Kudu's growth is something I would care about.
>

Hi Atri,

Thanks for the interest! Following the example of other recent incubator
projects, we would like to keep the initial committer list to those who are
already have a track record of contributions to the project. We'd love to
have you involved as a contributor during incubation, and of course would
be glad to add you as a committer after you've become a regular contributor.

Thanks
Todd

>

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik  wrote:

> On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning 
> wrote:
> > > ...RTC can be framed as "I don't trust you to do things right"...
> >
> > Or also "I don't trust myself 100% to do things right here and would
> > like systematic reviews of my commits".
>
> This sounds like "if I don't trust myself then no-one has to have this
> freedom/choice/ability", eh?
>

I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
project community decides to set up their process as such, I don't see why
the foundation should have any issues with it. That's all I've been arguing
in this thread: this whole discussion has pretty much no business in the
incubator.

-Todd

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Tue, Nov 17, 2015 at 4:42 PM, Konstantin Boudnik  wrote:

>
> > For now, I think "meritocracy" should be followed -- when contributors
> > demonstrate sufficient merit, we can add them as committers. Note that
> > there are plenty of my coworkers who have made small contributions in the
> > past, and they aren't listed as contributors either.
>
> So, you're saying that people were chosen to be listed or not as the
> contributors merely by the amount of the code they have contributed to the
> project. Am I reading this right?
>

As stated in the proposal:

"The initial list of committers was seeded by listing those contributors
who have contributed 20 or more patches in the last 12 months, indicating
that they are active and have achieved merit through participation on the
project. We chose not to include other contributors who either have not yet
contributed a significant number of patches, or whose contributions are far
in the past and we don’t expect to be active within the ASF."
Note that, since our documentation and web site are also versioned in git,
this includes one initial committer who has not written any code but has
been a major contributor to our docs and site.

This is well aligned with the process I've seen on the many ASF projects
I've been involved with. The ASF "get involved" page[1] says:

"Apache is a meritocracy. That is, once someone has shown sufficient
sustained committment to a project by helping out and contributing work to
the project (and the ASF) may be voted in by the project as a committer.

...[snipped]... If your work shows merit, the PMC for the project may hold
a vote to invite you to become a committer.
Note that becoming a committer is not just about submitting some patches;
it's also about helping out on the development and user discussion lists,
helping with documentation and the issue tracker, and showing long-term
interest. "

What we're proposing for Kudu is to follow the above model: show long-term
interest and sufficient sustained commitment, and you can become a
committer. While I appreciate that some incubator projects are happy to add
people without the above criteria, we'd prefer to follow the meritocratic
model as described above.

-Todd

[1] http://www.apache.org/foundation/getinvolved.html

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik  wrote:

>
> On the contrary... The business of the Incubator and IPMC is to help
> podlings
> and their communities to grok and follow the Apache Way. Trust is a
> foundation
> principal of a healthy community. Hence, this whole discussion has quite a
> lot
> of business in the incubator.
>

Except that there seems to be great disagreement among the Members as to
whether RTC is somehow anti-Apache-Way.

If you want to try to create an ASF-wide resolution that RTC doesn't follow
the Apache Way, and get the board/membership to vote on it, go ahead, but
it confuses podlings who are new to the ASF when people espouse personal
opinions as if they are ASF rules.

-Todd

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Tue, Nov 17, 2015 at 6:04 PM, Konstantin Boudnik  wrote:

> On Tue, Nov 17, 2015 at 04:53PM, Marvin Humphrey wrote:
> > On Tue, Nov 17, 2015 at 4:42 PM, Konstantin Boudnik 
> wrote:
> >
> > > So, you're saying that people were chosen to be listed or not as the
> > > contributors merely by the amount of the code they have contributed to
> the
> > > project. Am I reading this right?
> >
> > We've had this debate about committer cattle call additions many
> > times. The position that Todd is taking is completely reasonable. The
> > expectation that just about anybody can join a project during the
> > proposal phase is messed up and I wish that tradition had never caught
>
> That's not my point, Marvin. The people who contributed less than 20
> commits
> (hmm, why not 4 or a 107?) are still contributors. And in my opinion, they
> at
> least have to be invited to participate in the podling, if it is accepted
> by
> IPMC. So, I will re-phrase: "was an invitation to participate in the
> project
> extended to all contributors?".
>
> Shall it be done formally or by providing "Interested Party" is an
> implementation detail.
>
>
We haven't formally extended any invitation to these people to continue
participating in the project at the ASF. Those who are active in the
project I fully anticipate will continue to be active and work their way
towards committership. Others who contributed in the past but whom we
haven't seen in 12+ months are of course welcome to come back to the
project. In that case, I think it would be an easy vote to committership.

If anyone is interested in the project, feel free to edit the wiki and add
an "Interested Parties" section. I haven't seen that one before on other
proposals, and not sure what it accomplishes. The whole nature of the ASF
is that no explicit "invitations to participate" are necessary. Everyone is
by default invited to participate and contribute. To make that explicit,
though, I'll make sure to send out a note to all of our previous
contributors once we're accepted for incubation.

The reason that we elected to include the "active in the last 12 months"
was to avoid creating a project with a super-long list of employees of a
single company. Seeing such a list can be discouraging for new folks --
both because of the "wall of single employer" effect and because newcomers
to the community are likely to be confused why these people have been made
committers when they have never once participated inside the ASF.

If the IPMC at large feels that the above reasoning is inappropriate, we
can change the proposal to include a few more committers -- there's a small
handful of folks who made significant contributions to the project early on
that are no longer active. I don't imagine these people will end up
contributing or voting on releases, though, so it seems like an artificial
"stuffing" of the committer list.

Thanks
-Todd

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

>
>
> > Hi Atri,
> >
> > Thanks for the interest! Following the example of other recent incubator
> > projects, we would like to keep the initial committer list to those who
> are
> > already have a track record of contributions to the project. We'd love to
> > have you involved as a contributor during incubation, and of course would
> > be glad to add you as a committer after you've become a regular
> contributor.
>
> Considering that the project has been closed-sourced until very recently
> such
> "following" would surely create pretty high entry barrier for new
> committers.
> Which of course would be a concern, from the community growth perspective.
>

Sure, I expect the IPMC and our mentors to hold us to reasonable
expectations during incubation.

For now, I think "meritocracy" should be followed -- when contributors
demonstrate sufficient merit, we can add them as committers. Note that
there are plenty of my coworkers who have made small contributions in the
past, and they aren't listed as contributors either.

Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Tue, Nov 17, 2015 at 6:36 PM, Luke Han  wrote:

> In "community" section of this proposal, there are many companies
> have been mentioned including Xiaomi, Dropbox, Intel and Dremio,
> and said there are contributions from them.
>
> I think their engineers are more interesting and be involved
> in Kudu actively, why not think about to invite them to be committer first?
>

Per earlier messages on the thread and per the proposal: because they
haven't yet shown significant contributions over a sustained period.
Interest is one thing, but interest is not sufficient to become a committer
in a meritocracy. The folks called out in the community section are those
who have interest and are somewhere on the path towards committership, but
aren't there yet. I have every hope (and expectation) that they will get
there if they keep up their good work.

I would rather not discuss specific people's progress towards committership
in a public forum. Rather, I hoped that we could start with the proposed
committer list, and during incubation we can discuss potential new
committers and PMC members following the typical ASF processes on our
PPMC's private list. I'm counting on our experienced mentors to keep us all
honest -- they should absolutely call us out if the initial committers act
exclusionary or otherwise violate the ASF principles of being an inclusive
meritocracy.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <gst...@gmail.com> wrote:

> On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <t...@apache.org> wrote:
> >...
>
> > I think it's a _plus_ that contributors and committers contribute code in
> > the same way -- it's more of a level playing field for new people
> > contributing to the project.
> >
>
> "level playing field"?? seriously??
>
> I find no logical or valid reasoning to drag committers down to the same
> level as drive-by contributors.
>

I gave the logical and valid reasoning in previous posts in this thread:
1) no matter how seasoned a committer you are, you might make mistakes
which are easily caught in code review
2) no matter how good you are at coding, your code might not make sense to
a second pair of eyes, who can ask you to improve comments or docs
3) no matter if your code is perfect, the act of another person reading
your code builds shared ownership over the code, thus alleviating
bus-factor issues and improving the general feeling of a cohesive community
developing a single project instead of a loose coalition of people with
their own fiefdoms.

I believe this to be generally accepted in the software engineering
community. I don't know practices at every company, but I know at least
that most of the well-regarded technology companies I've met with have some
form of pre-commit review, and certainly many highly adopted open source
projects as well (especially in infrastructure software).

Either a high percentage of the world does this for "no logical or valid
reason" or this is just a matter of opinion, and like I said, we can agree
to disagree.

-Todd

Re: [DISCUSS] Kudu incubator proposal

[Todd Lipcon]

On Tue, Nov 17, 2015 at 10:51 PM, Henry Saputra <henry.sapu...@gmail.com>
wrote:

> Hi Todd,
>
> One concern, other IPMCs could help correct me if I am wrong, for
> project that already open source and accepting contributions from
> individuals which not part of initial committers is that it needs to
> get the consent or grant from those contributors when moving to ASF.
> Unless, the individuals have already signed the one for Cloudera when
> contributing to Kudu.
>
>
I believe that all contributors outside of Cloudera employees have signed
CLAs with Cloudera (either individual ones, or via their employers). That
said, if we need to track people down to get more explicit consent to
contribute code to Apache, I'm sure folks should be fine with it.

I'll await further instruction from the IPMC on this one.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 11:01 PM, Greg Stein <gst...@gmail.com> wrote:

> In RTC, a contributor sending in a patch, a pull request, or a JIRA/patch
> is handled exactly the same as any other committer. None are trusted to
> apply their change, until they receive review and permission from others.
> So you would think that "everybody" would get committer status on Day One.
> Why not? No effective difference between contributor and committer. "Oh, he
> gets a committer privilege bit to apply the change." ... That's it. A
> committer bit. No other difference from John Doe contributor.
>

The big difference is that once you're a committer, you can get a binding
code review (and thus commit other people's work). Being voted as a
committer is showing that the project feels you've obtained enough
experience with the code to carefully review and understand the context of
other contributors' work. In other words, the committer bit is not actually
about committing in an RTC word, but rather about reviewing. But "Reviewer"
doesn't have the same ring to it.

I think it's a _plus_ that contributors and committers contribute code in
the same way -- it's more of a level playing field for new people
contributing to the project.

FWIW other non-ASF projects do have something like the model you're
describing. For example, it's pretty easy to become a "Committer" on
Chromium, but it's somewhat more difficult to become an "Owner" (which
gives you the ability to binding review patches). Having contributed a
couple small things to that community, I found it perfectly reasonable.


> "Hey! We want to invite you to become a committer!" ... "oh. gee. yay. I'm
> so enthused. what a difference. NOT."
>

That hasn't been the reaction at all of new committers I've seen voted into
the various projects I've been a part of. Nor was it my reaction when I
became a committer on HBase and Hadoop a number of years back - in both
cases I was quite proud that the existing group of committers had deemed my
knowledge of the code sufficient to review and guide work by new
contributors.

Todd


>
> On Wed, Nov 18, 2015 at 12:06 AM, Dave Fisher <dave2w...@comcast.net>
> wrote:
>
> > I see the essence of what it means to be a committer. Being trusted to
> > both do the correct action and be willing to listen objectively to
> > criticism. In an CTR project it is clear to me that the point where a
> > project grants Committership should be the point where the PMC wants to
> > treat an individual's contribution as CTR rather than RTC. How does an
> RTC
> > project make THAT important decision?
> >
> > Regards,
> > Dave
> >
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny 
wrote:
>
> >>
> > Except that there seems to be great disagreement among the Members as to
> > whether RTC is somehow anti-Apache-Way.
> >
> > If you want to try to create an ASF-wide resolution that RTC doesn't
> follow
> > the Apache Way, and get the board/membership to vote on it, go ahead, but
> > it confuses podlings who are new to the ASF when people espouse personal
> > opinions as if they are ASF rules.
>
> That is not the point.
>
>
> The question is not to decide if C-T-R is The Apache Way over R-T-C. The
> question is wether a project entering incubation with a selected R-T-C
> mode is likely to exit incubation for the simple reason it will be very
> hard for this project to grow its community due to this choice. It's
> like starting a 100m race with a 20kb backpack on your shoulder...
>

If you have any statistics that show this to be the case, I'd be very
interested. RTC is the norm in basically every Apache project I've been a
part of, many of which have thriving communities and are generally regarded
as successful software projects.

Todd

RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

[editing subject since the discussion has veered away from Sentry]

On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers 
wrote:

> And I have to disagree with you Joe. To me, a mandatory RTC policy says
> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
> that you cannot commit your own work and every commit must be formally
> reviewed. I have found this process to be so onerous that I have never
> committed any code to the project, even though I really would like to.  I
> find the pace of this project to be fairly slow.  But it seems to fit
> within the corporate culture that most of the committers seem to work in.
>
> OTOH, I am involved in a project that uses CTR but where feature branches
> are frequently created to allow others to review and improve significant
> new work before it is integrated. As a consequence, new features are
> introduced at a much faster pace in this project.
>

I've seen this RTC vs CTR discussion come up a number of times over the
last ~6 years that I've been involved in ASF projects. For every strong
opinion in favor of CTR (like yours) there is a strong opinion in favor of
RTC (like mine).

The quick summary of my viewpoint is:

1) You're right, I don't trust anybody to make code changes to a complex
project with zero oversight. I currently work on a project that I
originally started, and was the only engineer on for a few months. Even
when I make changes to code that I wrote 100% of the module, I get others
to review my work, and you know what? It turns out better for it. Sometimes
they find bugs. Often they find areas where I didn't comment the code well,
design it as well as I could have, or missed potential performance
optimizations.

Coding's hard. Coding on complex projects is even harder. Some projects
aren't complex, and maybe on those a CTR policy makes a lot more sense. But
distributed systems, database storage engines, etc, are pretty hard to get
right, even for the "experts". I'm always glad to have a second pair of
eyes before I introduce a bug that takes down critical infrastructure.

2) Regardless of trust, code review helps build _shared ownership_ of code.
In community projects, without code review, it's easy to end up with "pet
features" or areas of code that only one person understands. When that
person moves on to new employment or new interests, the project is stuck
with a bunch of source code that no one understands how to maintain.
Forcing the original author to get some reviews before committing ensures
that there is a more likely path to project continuity after they move on
to new pastures.

3) Code reviews are a great way for engineers to learn from others in the
community. Earlier in my career, I certainly learned a lot from the
committers on projects like Hadoop and HBase where I "cut my teeth". And
even as a long-time committer on these systems, I still learn new things
from reviewing code written by newer members of the community. Review is
where a lot of the cross-contributor interaction takes place, so it helps
build a cohesive community.

Given #2 and #3, I see RTC as an extension of "community over code". Sure,
it might slow down the introduction of a new feature or fix to have to wait
to get a review from another community member. But, that's just code.
Getting more eyes and hands on the code builds the community.

After writing the above, I started to feel it was familiar and remember a
very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
- I'd recommend people go check that one out to see the various viewpoints.

I don't anticipate that the above arguments will convince you, or anyone
else who believes in CTR, to change your mind. But, as mentioned in some
other recent incubator threads, let's not use the incubator as a
battleground for personal opinions. There are successful Apache projects
following all sorts of development models, and the important thing is only
that (a) projects build inclusive communities, and (b) projects follow
proper licensing/release/etc processes for legal reasons.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein <gst...@gmail.com> wrote:

> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <t...@apache.org> wrote:
> >...
>
> > 1) You're right, I don't trust anybody to make code changes to a complex
> > project with zero oversight. I currently work on a project that I
> >
>
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
>
> All software is hard. Your project is no more complex than others.
>
>
Having worked on projects in pretty much every layer of the software stack,
I think we'll just have to agree to disagree.

Thankfully, the actual rules of the ASF have nothing to say on this matter,
and it's diversity of opinions that makes it an interesting community. I
just don't want projects in incubation (or considering incubation) to think
that the ASF mandates one or the other style of development.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

IP clearance for properly licensed code

[Todd Lipcon]

Hi all,

Another hopefully simple question:

The Mentor guide contains the following text:

>
> Existing codebases need to be imported through the standard IP clearance
> process. This means that a Software Grant Agreement (SGA
> ) or Contributor License
> Agreement (CLA ) need to be
> submitted for all copyright owners. This process may take a while so it is
> best to start as soon as the podling is accepted.


How does this rule apply to sections of code that are released publicly
under a suitable license (eg Apache/BSD/MIT) but were originally written
from a different context? For example, I am working on an incubation
proposal for a project that includes portions of code copied from the
Chromium open source project, which is released under a BSD license but
holds a copyright notice by "The Chromium Authors". It's unlikely that
these authors would submit the appropriate paperwork to the ASF.

Assuming that the imported project retains the notice of the original
copyright, and the commits which import the code suitably track the
provenance of the code, my understanding is this is acceptable under the
licenses and foundation policy. However, the text in the mentor guide seems
to indicate otherwise.

Thanks
Todd

Re: Releases during incubation?

[Todd Lipcon]

Thanks, Joe!

-Todd

On Mon, Nov 9, 2015 at 5:22 PM, Joe Schaefer <joes...@gmail.com> wrote:

> Subversion cut a release while in incubation on their old system.
> Shouldn't pose a problem for others.
>
> On Mon, Nov 9, 2015 at 8:03 PM, Todd Lipcon <t...@apache.org> wrote:
>
> > Hey folks,
> >
> > Hopefully quick policy question here:
> >
> > Once a project is under proposal for incubation, what is the foundation
> > policy on that project making releases outside of Apache from its current
> > home?
> >
> > For example, suppose there's an open source project FooBar, with a public
> > release FooBar 1.0.0 in use by various people out in the world. FooBar is
> > then proposed to the incubator. During the discussion/voting timeframe,
> > someone discovers a bug in FooBar 1.0.0, and the team would like to
> release
> > FooBar 1.0.1 from the project's current home (eg github). Would this be
> an
> > issue?
> >
> > More controversial variant:
> >
> > How about early during the incubation period, while the project is still
> in
> > the process of transitioning the necessary infrastructure, etc, into the
> > ASF repositories? Assuming that the project is making good faith efforts
> > towards making a release compatible with ASF guidelines, would it be
> > allowed to make "external" releases during this initial period of
> > incubation, for the purposes of bug fixes?
> >
> > Thanks
> > Todd
> >
>

Releases during incubation?

[Todd Lipcon]

Hey folks,

Hopefully quick policy question here:

Once a project is under proposal for incubation, what is the foundation
policy on that project making releases outside of Apache from its current
home?

For example, suppose there's an open source project FooBar, with a public
release FooBar 1.0.0 in use by various people out in the world. FooBar is
then proposed to the incubator. During the discussion/voting timeframe,
someone discovers a bug in FooBar 1.0.0, and the team would like to release
FooBar 1.0.1 from the project's current home (eg github). Would this be an
issue?

More controversial variant:

How about early during the incubation period, while the project is still in
the process of transitioning the necessary infrastructure, etc, into the
ASF repositories? Assuming that the project is making good faith efforts
towards making a release compatible with ASF guidelines, would it be
allowed to make "external" releases during this initial period of
incubation, for the purposes of bug fixes?

Thanks
Todd

Re: [VOTE] Accept HTrace into the Apache Incubator

[Todd Lipcon]

+1 (can't recall if my vote is binding as a Member, or if you have to be
IPMC)

On Wed, Nov 5, 2014 at 11:32 AM, Stack st...@duboce.net wrote:

 +1

 On Wed, Nov 5, 2014 at 11:16 AM, Roman Shaposhnik r...@apache.org wrote:

  Following the discussion earlier in the thread:
 http://s.apache.org/Dk7
 
  I would like to call a VOTE for accepting HTrace
  as a new incubator project.
 
  The proposal is available at:
 
  https://wiki.apache.org/incubator/HTraceProposal
 
  Vote is open until at least Sunday, 9th November 2014, 23:59:00 UTC
 
   [ X] +1 accept HTrace in the Incubator
   [ ] ±0
   [ ] -1 because...
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 




-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [VOTE] Accept Parquet into the incubator

[Todd Lipcon]

, attracting
 over 40 contributors (see
 https://github.com/Parquet/parquet-mr/graphs/contributors) from a diverse
 group of companies.
 Several of the core contributors to the project are deeply familiar with
 OSS and Apache specifically: Julien Le Dem was until recently the PMC Chair
 for Apache Pig, and Dmitriy Ryaboy, Aniket Mokashi, and Jonathan Coveney
 are also Apache Pig committers with contributions to several other Apache
 projects. Todd Lipcon and Tom White are committers to Apache Hadoop and
 multiple other related projects. Brock Noland is a Hive committer.

 === Homogenous Developers ===

 The initial committers come from a number of companies and countries.
 Parquet has an active community of developers, and we are committed to
 recruiting additional committers based on their contributions to the
 project. The java library component alone has contributions from 31
 individual github accounts, 14 of which contributed over 1000 lines of
 code.

 === Reliance on Salaried Developers ===

 It is expected that Parquet development will occur on both salaried time
 and on volunteer time, after hours. The majority of initial committers are
 paid by their employers to contribute to this project. However, they are
 all passionate about the project, and we are confident that the project
 will continue even if no salaried developers contribute to the project. As
 evidence of this statement, we present the GitHub punchcard (see
 https://github.com/Parquet/parquet-mr/graphs/punch-card) showing that a
 lot
 of activity happens on weekends. We are committed to recruiting additional
 committers including non-salaried developers.

 === Relationships with Other Apache Products ===

 As mentioned in the Alignment section, Parquet is closely related to
 Hadoop. It provides an API that allowed it to be easily integrated with
 many other apache projects: Pig, Hive, Avro, Thrift, Spark, Drill, Crunch,
 Tajo. Some of the features it provides are similar to the ORC file format
 which is part of the Hive project. However Parquet focused on being
 framework agnostic and language independent and has been really successful
 to that end. On top of the Apache projects mentioned above, Parquet is also
 integrated with other open source projects, including Protocol Buffers,
 Cloudera Impala or Scrooge. We look forward to continue collaborating with
 those communities, as well as other Apache communities.

 === An Excessive Fascination with the Apache Brand ===

 Parquet is an already healthy and well known open source project. This
 proposal is not for the purpose of generating publicity. Rather, the
 primary benefits to joining Apache are those outlined in the Rationale
 section.

 == Documentation ==

 Documentation is currently located as README markdown files:

  * https://github.com/Parquet/parquet-format
  * https://github.com/Parquet/parquet-mr

 == Source and Intellectual Property Submission Plan ==

 The Parquet codebase is currently hosted on Github:
 https://github.com/Parquet.

 These are the codebases that we would migrate to the Apache foundation.

 == External Dependencies ==


  * Junit: EPL
  * Apache Commons: ALv2
  * Apache Thrift: ALv2
  * Apache Maven: ALv2
  * Apache Avro: ALv2
  * Apache Hadoop: ALv2
  * Google Guava: ALv2
  * Google Protobuf: New BSD License

 == Cryptography ==

 We do not expect Parquet to be a controlled export item due to the use of
 encryption.

 == Required Resources ==

 === Mailing lists ===

  * priv...@parquet.incubator.apache.org
  * comm...@parquet.incubator.apache.org
  * d...@parquet.incubator.apache.org

 == Subversion Directory ==

 Git is the preferred source control system:

  * git://git.apache.org/parquet-format
  * git://git.apache.org/parquet-mr

 == Issue Tracking ==

 We'd like to keep using the Git review and issue tracking tools.
 Controlling Pull requests closing through git commit messages in
 git.apache.org

 == Initial Committers ==

  * Aniket Mokashi aniket...@gmail.com
  * Brock Noland br...@apache.org
  * Chris Aniszczyk caniszc...@gmail.com
  * Dmitriy Ryaboy dvrya...@apache.org
  * Jake Farrell jfarr...@apache.org
  * Jonathan Coveney jcove...@gmail.com
  * Julien Le Dem jul...@apache.org
  * Lukas Nalezenec lukas.naleze...@gmail.com
  * Marcel Kornacker mar...@cloudera.com
  * Mickael Lacour
  * Nong Li n...@cloudera.com
  * Remy Pecqueur
  * Ryan Blue b...@cloudera.com
  * Tianshuo Deng dengtians...@gmail.com
  * Tom White tomwh...@apache.org
  * Wesley Peck

 == Affiliations ==

  * Aniket Mokashi - Twitter
  * Brock Noland - Cloudera
  * Chris Aniszczyk - Twitter
  * Dmitriy Ryaboy - Twitter
  * Jake Farrell
  * Jonathan Coveney - Twitter
  * Julien Le Dem - Twitter
  * Lukas Nalezenec
  * Marcel Kornacker - Cloudera
  * Mickael Lacour - Criteo
  * Nong Li - Cloudera
  * Remy Pecqueur - Criteo
  * Ryan Blue - Cloudera
  * Tianshuo Deng - Twitter
  * Tom White - Cloudera
  * Wesley Peck - ARRIS, Inc.

 == Sponsors ==

 === Champion ===

  * Todd Lipcon

Re: [PROPOSAL] Parquet

[Todd Lipcon]

: Julien Le Dem is the current PMC Chair for
 Apache Pig, and Dmitriy Ryaboy, Aniket Mokashi, and Jonathan Coveney are
 also Apache Pig committers with contributions to several other Apache
 projects. Todd Lipcon and Tom White are committers to Apache Hadoop and
 multiple other related projects. Brock Noland is a Hive committer.

 === Homogenous Developers ===

 The initial committers come from a number of companies and countries.
 Parquet has an active community of developers, and we are committed to
 recruiting additional committers based on their contributions to the
 project. The java library component alone has contributions from 31
 individual github accounts, 14 of which contributed over 1000 lines of
 code.

 === Reliance on Salaried Developers ===

 It is expected that Parquet development will occur on both salaried time
 and on volunteer time, after hours. The majority of initial committers are
 paid by their employers to contribute to this project. However, they are
 all passionate about the project, and we are confident that the project
 will continue even if no salaried developers contribute to the project. As
 evidence of this statement, we present the GitHub punchcard (see
 https://github.com/Parquet/parquet-mr/graphs/punch-card) showing that a
 lot
 of activity happens on weekends. We are committed to recruiting additional
 committers including non-salaried developers.

 === Relationships with Other Apache Products ===

 As mentioned in the Alignment section, Parquet is closely related to
 Hadoop, Pig, Avro, Thrift, YARN and Mesos in a numerous ways. We look
 forward to collaborating with those communities, as well as other Apache
 communities (including Apache S4 which focuses on stateful low-latency
 processing).

 === An Excessive Fascination with the Apache Brand ===

 Parquet is an already healthy and well known open source project. This
 proposal is not for the purpose of generating publicity. Rather, the
 primary benefits to joining Apache are those outlined in the Rationale
 section.

 == Documentation ==

 Documentation is currently located as README markdown files:

 * https://github.com/Parquet/parquet-format
 * https://github.com/Parquet/parquet-mr

 == Source and Intellectual Property Submission Plan ==

 The Parquet codebase is currently hosted on Github:
 https://github.com/Parquet.

 This is the exact codebase that we would migrate to the Apache foundation.

 == External Dependencies ==

  * Junit: EPL
  * Apache Commons: ALv2
  * Apache Thrift: ALv2
  * Apache Maven: ALv2
  * Apache Avro: ALv2
  * Apache Hadoop: ALv2
  * Google Guava: ALv2

 == Cryptography ==

 We do not expect Parquet to be a controlled export item due to the use of
 encryption.

 == Required Resources ==

 === Mailing lists ===

  * parquet-dev
  * parquet-user

 == Subversion Directory ==

 Git is the preferred source control system: git://git.apache.org/parquet

 == Issue Tracking ==

 JIRA: Parquet (PARQUET)

 == Initial Committers ==

  * Aniket Mokashi
  * Brock Noland
  * Chris Aniszczyk z...@twitter.com
  * Dmitriy Ryaboy dmit...@twitter.com
  * Jake Farrell
  * Julien Le Dem jul...@apache.org
  * Lukas Nalezenec
  * Marcel Kornacker
  * Mickael Lacour
  * Nong Li
  * Remy Pecqueur
  * Tianshuo Deng
  * Tom White

 == Affiliations ==

  * Aniket Mokashi - Twitter
  * Brock Noland - Cloudera
  * Chris Aniszczyk - Twitter
  * Dmitriy Ryaboy - Twitter
  * Jake Farrell
  * Julien Le Dem - Twitter
  * Lukas Nalezenec
  * Marcel Kornacker - Cloudera
  * Mickael Lacour - Criteo
  * Nong Li - Cloudera
  * Remy Pecqueur - Criteo
  * Tianshuo Deng - Twitter
  * Tom White - Cloudera

 == Sponsors ==

 === Champion ===

  * Todd Lipcon

 === Nominated Mentors ===

  * Tom White
  * Chris Mattmann
  * Jake Farrell

 === Sponsoring Entity ===

 The Apache Incubator

 --
 Cheers,

 Chris Aniszczyk
 http://aniszczyk.org
 +1 512 961 6719




-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [PROPOSAL] Accumulo for the Apache Incubator

[Todd Lipcon]

On Tue, Sep 6, 2011 at 8:09 AM, Steve Loughran ste...@apache.org wrote:
 1300 lines: heavily modified versions of Hadoop BloomFilters

 -any plan to contribute back to hadoop-core, or are they too incompatible
 now?


 419 lines: modified Hadoop TeraSortIngest to sort data using Accumulo
 325 lines: our Value is an immutable version of Hadoop BytesWritable

 -any plan to contribute back to hadoop-core?
...
 I understand why you've forked off your own versions of some of the Hadoop
 and HBase core -it is not only your right, it gets the changes in on your
 schedule. I have been known to do this myself.


Without derailing this thread too much, just to put things in
perspective: HBase has a fork of Hadoop's IPC. This makes up about
4000 lines of HBase's code. It's not a big deal. That's why we like
the Apache license. Good engineers should always be evaluating the
tradeoffs between staying with mainline and having to maintain a fork
of a particular piece of code. Sometimes the latter makes sense, even
within two closely-related projects.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: [PROPOSAL] Accumulo for the Apache Incubator

[Todd Lipcon]

 solution is to form a Collaborative Research and Development 
 Agreement (CRADA) between the Apache Software Foundation and the US 
 Government, but this will not solve the underlying problem that U.S. law does 
 not grant copyright to works of government employees.  At this time a CRADA 
 is not necessary but should it be determined that a CRADA is necessary, we 
 would like to work through that process during the incubation phase of 
 Accumulo rather than before acceptance as this may take time to enter into an 
 agreement.

 == External Dependencies ==
 jetty (Apache and EPL), jline (BSD), jfreechart (LGPL), jcommon (LGPL), slf4j 
 (MIT), junit (CPL)

 == Cryptography ==
 none

 == Required Resources ==
  * Mailing Lists
   * accumulo-private
   * accumulo-dev
   * accumulo-commits
   * accumulo-user

  * Subversion Directory
   * https://svn.apache.org/repos/asf/incubator/accumulo

  * Issue Tracking
   * JIRA Accumulo (ACCUMULO)

  * Continuous Integration
   * Jenkins builds on https://builds.apache.org/

  * Web
   * http://incubator.apache.org/accumulo/
   * wiki at http://wiki.apache.org or http://cwiki.apache.org

 == Initial Committers ==
  * Aaron Cordova (aaron at cordovas dot org)
  * Adam Fuchs (adam.p.fuchs at ugov dot gov)
  * Eric Newton (ecn at swcomplete dot com)
  * Billie Rinaldi (billie.j.rinaldi at ugov dot gov)
  * Keith Turner (keith.turner at ptech-llc dot com)
  * John Vines (john.w.vines at ugov dot gov)
  * Chris Waring (christopher.a.waring at ugov dot gov)

 == Affiliations ==
  * Aaron Cordova, The Interllective
  * Adam Fuchs, National Security Agency
  * Eric Newton, SW Complete Incorporated
  * Billie Rinaldi, National Security Agency
  * Keith Turner, Peterson Technology LLC
  * John Vines, National Security Agency
  * Chris Waring, National Security Agency

 == Sponsors ==
  * Champion: Doug Cutting
  * Nominated Mentors: Benson Margulies, ?, ?
  * Sponsoring Entity: Apache Incubator

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





-- 
Todd Lipcon
Software Engineer, Cloudera

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

Re: [VOTE] Release Thrift 0.2.0

[Todd Lipcon]

Great. Here's the tally:

+1s:
Kevan Miller
Joe Schaefer
ant elder
Upayavira

-1s: none

So, this release is good to go. I'll post it to the download page,
update website, etc, this weekend.

Thanks, everyone

-Todd


On Fri, Dec 11, 2009 at 6:23 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 On Dec 10, 2009, at 9:17 PM, Todd Lipcon wrote:

 Hi Kevan,

 Responses below:

 On Thu, Dec 10, 2009 at 1:24 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 What's the license for the file: doc/thrift.tex?


 This was contributed by Facebook, and thus falls under the Facebook
 CLA as Apache 2.0 licensed. I'm not sure how it got missed in the
 license audit, but since it's only part of the source tree, doesn't
 link with anything (solely documentation), and actually doesn't get
 installed by make install, is it a release blocker? (ie do I need to
 roll an rc1 and call a new vote on thrift-dev, or can I just fix it in
 svn for next release?)

 Thanks for the info. I'll be ok with next release. Here's my +1

 --kevan
 -
 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 Thrift 0.2.0

[Todd Lipcon]

Hi all,

Joe has pointed out that I didn't include the link to the tarball and
signature:

http://people.apache.org/~todd/thrift-0.2.0-incubating-rc0.tar.gz

Signatures (mine and Joe's):
http://people.apache.org/~todd/thrift-0.2.0-incubating-rc0.tar.gz.asc

Tarball md5sum: 9958c57c402c02171ba0bcc96183505c

Thanks in advance for voting!

-Todd


On Tue, Dec 8, 2009 at 11:47 PM, Todd Lipcon t...@cloudera.com wrote:

 The Thrift community voted on and has approved a proposal to release Thrift
 0.2.0. Pursuant to the Releases section of the Incubation Policy, we would
 now like to request the permission of the Incubator PMC to publish the
 tarball on the Thrift Download page.

 Please vote by 6 PM PST, Fri 12/11.

 Vote thread:

 http://mail-archives.apachttp://pastebin.com/m66dd05c1he.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912072000m42280008pa2262ec5d485e...@mail.gmail.com%3ehttp://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912072000m42280008pa2262ec5d485e...@mail.gmail.com%3e

 Results:

 http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912082254mc008e20xaa7f7b075366a...@mail.gmail.com%3e

 Thanks
 -Todd

Re: [VOTE] Release Thrift 0.2.0

[Todd Lipcon]

Hi Kevan,

Responses below:

On Thu, Dec 10, 2009 at 1:24 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 What's the license for the file: doc/thrift.tex?


This was contributed by Facebook, and thus falls under the Facebook
CLA as Apache 2.0 licensed. I'm not sure how it got missed in the
license audit, but since it's only part of the source tree, doesn't
link with anything (solely documentation), and actually doesn't get
installed by make install, is it a release blocker? (ie do I need to
roll an rc1 and call a new vote on thrift-dev, or can I just fix it in
svn for next release?)

 I note that there are a number of files in your distribution archive that are 
 not in svn. I only reviewed the distribution.

Those files are the output from bootstrap.sh (autotools generated
files) and belong only in the distributed source tarball, not in svn.
So no trouble here.

 I didn't see a KEYS file for your project. Assume that will be made available.


My key is available on a public keyserver:
http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x5E43CAB9AEC77EAF
As is joe's: 
http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0xB31B213D208F5064

Is it a requirement that the KEYS file be in the distribution, or
should it just be available in the download directory next to the
tarball, once we release?

Thanks,
-Todd

 https://issues.apache.org/jira/browse/LEGAL-58 would seem to cover my other 
 question... ;-)

 Assuming I understand the license that applies to doc/thrift.tex (and why it 
 doesn't contain a source license header), looks like I'd be +1.

 --kevan

 On Dec 10, 2009, at 2:50 PM, Todd Lipcon wrote:

 Hi all,

 Joe has pointed out that I didn't include the link to the tarball and
 signature:

 http://people.apache.org/~todd/thrift-0.2.0-incubating-rc0.tar.gz

 Signatures (mine and Joe's):
 http://people.apache.org/~todd/thrift-0.2.0-incubating-rc0.tar.gz.asc

 Tarball md5sum: 9958c57c402c02171ba0bcc96183505c

 Thanks in advance for voting!

 -Todd


 On Tue, Dec 8, 2009 at 11:47 PM, Todd Lipcon t...@cloudera.com wrote:

 The Thrift community voted on and has approved a proposal to release Thrift
 0.2.0. Pursuant to the Releases section of the Incubation Policy, we would
 now like to request the permission of the Incubator PMC to publish the
 tarball on the Thrift Download page.

 Please vote by 6 PM PST, Fri 12/11.

 Vote thread:

 http://mail-archives.apachttp://pastebin.com/m66dd05c1he.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912072000m42280008pa2262ec5d485e...@mail.gmail.com%3ehttp://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912072000m42280008pa2262ec5d485e...@mail.gmail.com%3e

 Results:

 http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912082254mc008e20xaa7f7b075366a...@mail.gmail.com%3e

 Thanks
 -Todd





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

[VOTE] Release Thrift 0.2.0

[Todd Lipcon]

The Thrift community voted on and has approved a proposal to release Thrift
0.2.0. Pursuant to the Releases section of the Incubation Policy, we would
now like to request the permission of the Incubator PMC to publish the
tarball on the Thrift Download page.

Please vote by 6 PM PST, Fri 12/11.

Vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912072000m42280008pa2262ec5d485e...@mail.gmail.com%3e

Results:
http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200912.mbox/%3c45f85f70912082254mc008e20xaa7f7b075366a...@mail.gmail.com%3e

Thanks
-Todd