[jira] [Updated] (INCUBATOR-208) Transferring guide needs an editing pass

[Jim Apple (Jira)]

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

Jim Apple updated INCUBATOR-208:

Description: 
There are a number of issues with the transferring page:

"foundation/officers/irs-disclosures.txt" has some odd characters prepended and 
appended.

https://incubator.apache.org/guides/transferring.html#notes-status is a missing 
anchor

"Final Revision of Podling Incubation Records" has bizarre formatting.

I suspect these are not the only issues.

  was:
There are a number of issues with the transferring page:

"{{noformat}}#foundation/officers/irs-disclosures.txt*{{noformat}" has some odd 
characters prepended and appended.

https://incubator.apache.org/guides/transferring.html#notes-status is a missing 
anchor

"Final Revision of Podling Incubation Records" has bizarre formatting.

I suspect these are not the only issues.


> Transferring guide needs an editing pass
> 
>
> Key: INCUBATOR-208
> URL: https://issues.apache.org/jira/browse/INCUBATOR-208
> Project: Incubator
>  Issue Type: Bug
>  Components: guides
>Reporter: Jim Apple
>Assignee: Dave Fisher
>Priority: Major
>
> There are a number of issues with the transferring page:
> "foundation/officers/irs-disclosures.txt" has some odd characters prepended 
> and appended.
> https://incubator.apache.org/guides/transferring.html#notes-status is a 
> missing anchor
> "Final Revision of Podling Incubation Records" has bizarre formatting.
> I suspect these are not the only issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Re: DataSketches Proposal - Google Docs Link

[Jim Apple]

You could use a Google account that is not under Yahoo’s control, then let
anyone in the world add a comment, maybe.

On Mon, Feb 25, 2019 at 3:26 PM leerho  wrote:

> Ken,
> Yahoo does not allow me to create a shared link outside our company, except
> to individual email addresses.  So attempting to share it to the email
> general@incubator.apache.org may not work.  Nonetheless, several
> individuals were able to request access using their individual email
> accounts and I was able to add them.  I will try to add you using
> k...@apache.org, but if that doesn't work, I may need a gmail or
> equivalent
> account for you.
>
> Lee.
>
>
> On Mon, Feb 25, 2019 at 2:59 PM Kenneth Knowles  wrote:
>
> > I could not access that document. I suggest you need to turn on link
> > sharing.
> >
> > Kenn
> >
> > On Mon, Feb 25, 2019 at 12:00 PM lee...@gmail.com 
> > wrote:
> >
> > > Try this link:
> > >
> >
> https://docs.google.com/document/d/19JKevzFQNcaLA51LFLUlP1hzdFDW7oDJrJO8N6weDv8/edit?usp=sharing
> > >
> > >
> > > On 2019/02/25 05:55:50, leerho  wrote:
> > > > Yes I will try that tomorrow.
> > > >
> > > > On Sun, Feb 24, 2019 at 7:34 PM Kenneth Knowles 
> > wrote:
> > > >
> > > > > Can you share the Google doc with the proposal? Per Ted's advice,
> we
> > > can
> > > > > iterate quickly there and move it to the wiki when it becomes a bit
> > > more
> > > > > stable.
> > > > >
> > > > > Kenn
> > > > >
> > > > > On Fri, Feb 22, 2019 at 10:21 PM lee...@gmail.com <
> lee...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks for the offer.  i am a neophyte at this process and email
> > > app!   I
> > > > > > could use a lot of help getting this off the ground!  Also, I'm
> not
> > > sure
> > > > > > that Mr. Chen and Mr. Onofré have fully accepted taking this on
> :)
> > > > > >
> > > > > > Lee.
> > > > > >
> > > > > > On 2019/02/23 06:03:58, Kenneth Knowles  wrote:
> > > > > > > Nice.
> > > > > > >
> > > > > > > I would very much like to help mentor this project, though you
> > > already
> > > > > > have
> > > > > > > a couple good ones.
> > > > > > >
> > > > > > > I concur with incubator as sponsoring entity.
> > > > > > >
> > > > > > > Kenn (VP Apache Beam)
> > > > > > >
> > > > > > > On Fri, Feb 22, 2019 at 9:45 PM leerho 
> wrote:
> > > > > > >
> > > > > > > > I didn't realize that this mail list does not accept PDF
> files,
> > > > > > apparently
> > > > > > > > only text.  So let me try one more time ... :)  Please let me
> > > know if
> > > > > > > > this works!
> > > > > > > >
> > > > > > > >
> > > > > > > > = Apache DataSketches Proposal[1] =
> > > > > > > >
> > > > > > > > == Abstract ==
> > > > > > > >
> > > > > > > > DataSketches.GitHub.io is an open source, high-performance
> > > library
> > > > > of
> > > > > > > > stochastic streaming algorithms commonly called "sketches" in
> > the
> > > > > data
> > > > > > > > sciences. Sketches are small, stateful programs that process
> > > massive
> > > > > > data
> > > > > > > > as a stream and can provide approximate answers, with
> > > mathematical
> > > > > > > > guarantees, to computationally difficult queries
> > > orders-of-magnitude
> > > > > > faster
> > > > > > > > than traditional, exact methods.
> > > > > > > >
> > > > > > > > This proposal is to move DataSketches to the Apache Software
> > > > > > > > Foundation(ASF) transferring ownership of its copyright
> > > intellectual
> > > > > > > > property to the ASF.  Thereafter, DataSketches would be
> > > officially
> > > > > > known as
> > > > > > > > Apache DataSketches and its evolution and governance would
> come
> > > under
> > > > > > the
> > > > > > > > rules and guidance of the ASF.
> > > > > > > >
> > > > > > > > == Introduction ==
> > > > > > > >
> > > > > > > > The DataSketches library contains carefully crafted
> > > implementations
> > > > > of
> > > > > > > > sketch algorithms that meet rigorous standards of quality and
> > > > > > performance
> > > > > > > > and provide capabilities required for large-scale production
> > > systems
> > > > > > that
> > > > > > > > must process and analyze massive data. The DataSketches core
> > > > > > repository is
> > > > > > > > written in Java with a parallel core repository written in
> C++
> > > that
> > > > > > > > includes Python wrappers. The DataSketches library also
> > includes
> > > > > > special
> > > > > > > > repositories for extending the core library for Apache Hive
> and
> > > > > Apache
> > > > > > Pig.
> > > > > > > > The sketches developed in the different languages share a
> > common
> > > > > binary
> > > > > > > > storage format so that sketches created and stored in Java,
> for
> > > > > > example,
> > > > > > > > can be fully used in C++, and visa versa.  Because the stored
> > > sketch
> > > > > > > > "images" are just a "blob" of bytes (similar to picture
> > images),
> > > they
> > > > > > can
> > > > > > > > be shared across many different systems, languages and
> > platforms.
> > > > > > > >
> > > > > > > > The 

Re: [DISCUSS] Doris Proposal

[Jim Apple]

Looks good to me. Thanks!

On Thu, Jul 5, 2018 at 9:17 AM, Dave Fisher  wrote:

> Hi -
>
> There was no reply yet. I made a change to the proposal.
>
> > On Jul 2, 2018, at 9:51 AM, Dave Fisher  wrote:
> >
> > Hi Jim,
> >
> >> On Jun 30, 2018, at 8:58 AM, Jim Apple 
> wrote:
> >>
> >> Can you help me understand which portion of this document addresses the
> >> discussions that occurred on the thread? The thread included discussion
> of
> >>
> >> 1. The name
> >> 2. Licence and copyright
> >
> > The remaining license and copyright issues are a natural part of
> Incubation and should be handled with the Mentor’s help.
> >
> >> 3. Attribution (Tim's Impala patch that was copied without attribution)
> >
> > Would additional text in the Impala part of the rationale help explain?
> Or, should a specific paragraph be added elsewhere?
> >
> >> 4. Impala integration
> >
> > The Doris team has a plan to handle this. Do you want it incorporated in
> the proposal? Or acknowledged along with (3)?
>
> I added the following to Community:
>
> "Doris makes use of Apache Impala. It was identified during early review
> of the proposal that the Doris community will need to work with Impala to
> define a suitable API."
>
> Regards,
> Dave
>
> >
> >> 5. Mentors and committer choices
> >>
> >> I only see #1 and #5 addressed in the wiki page, with no discussion on
> #2,
> >> #3, and #4. Am I missing something?
> >
> > Thanks,
> > Dave
> >
> >>
> >>
> >> On Fri, Jun 29, 2018 at 4:27 PM, Dave Fisher 
> wrote:
> >>
> >>> Hi -
> >>>
> >>> The Doris Proposal is available at https://wiki.apache.org/
> >>> incubator/DorisProposal
> >>>
> >>> It was updated to reflect the discussions that occurred under the
> thread
> >>> https://lists.apache.org/thread.html/74a3f3f945403b50515c658047d328
> >>> 4955288a637207e4f97ecc15d1@%3Cgeneral.incubator.apache.org%3E
> >>>
> >>> Please provide any necessary updates.
> >>>
> >>> We would like to start the VOTE on Monday.
> >>>
> >>> Regards,
> >>> Dave
> >>>
> >
>
>

Re: [DISCUSS] Doris Proposal

[Jim Apple]

Can you help me understand which portion of this document addresses the
discussions that occurred on the thread? The thread included discussion of

1. The name
2. Licence and copyright
3. Attribution (Tim's Impala patch that was copied without attribution)
4. Impala integration
5. Mentors and committer choices

I only see #1 and #5 addressed in the wiki page, with no discussion on #2,
#3, and #4. Am I missing something?


On Fri, Jun 29, 2018 at 4:27 PM, Dave Fisher  wrote:

> Hi -
>
> The Doris Proposal is available at https://wiki.apache.org/
> incubator/DorisProposal
>
> It was updated to reflect the discussions that occurred under the thread
> https://lists.apache.org/thread.html/74a3f3f945403b50515c658047d328
> 4955288a637207e4f97ecc15d1@%3Cgeneral.incubator.apache.org%3E
>
> Please provide any necessary updates.
>
> We would like to start the VOTE on Monday.
>
> Regards,
> Dave
>

Re: Looking for Champion

[Jim Apple]

Looks great!

On Thu, Jun 21, 2018 at 5:06 AM Li,De(BDG)  wrote:

> We have a general Plan or Roadmap:
>
> 1. Find out the code, modules, components which duplicates of Impala;
> 2. Determine the features which could be merged to Impala under Impala
> community support.
> 3, Define clearly the interface between the query engine and other
> components, such as the storage engine, metadata management, mysql server,
> load and export modules, web server and so on.
> 4. Separate the Impala query engine from Palo.
>
>
> Best Regards,
> Reed
>
> On 2018/6/19 下午9:48， "Jim Apple"  wrote:
>
> >>
> >> I'm not sure if Palo is just a storage system but definitely we will
> >> separate query engine from Palo.
> >>
> >
> >That's great news, and I think it will benefit users of Impala and Palo.
> >
> >
> >> Of cource, as you mentioned, "this could be a lot of work", so it will
> >> take a long time and we also hope that Impala community could support
> >>us.
> >>
> >
> >Yes, I expect so.
>
>

Re: Looking for Champion

[Jim Apple]

>
> I'm not sure if Palo is just a storage system but definitely we will
> separate query engine from Palo.
>

That's great news, and I think it will benefit users of Impala and Palo.


> Of cource, as you mentioned, "this could be a lot of work", so it will
> take a long time and we also hope that Impala community could support us.
>

Yes, I expect so.

Re: Looking for Champion

[Jim Apple]

Let me respond specifically to a few of these as a way to, I hope,
inspire the Palo community to reconsider contributing to Impala. It
could be a great opportunity for us to produce value by keeping the
query engine working smoothly while the Palo community can focus more
of their efforts on the storage system. There is some analogue here
with how Impala works on other storage systems.

> Firstly, as a query engine for Hadoop, Impala deeply depend on HDFS and
> HBase
> (At least several years ago it was like this)

Impala can run on other storage. See, for instance
http://impala.apache.org/docs/build/html/topics/impala_kudu.html and
http://impala.apache.org/docs/build/html/topics/impala_isilon.html

> Secondly, due to introduced Mesa data model. The Catalog is different from
> Impala.
> We developped a In-Memory Catalog and also support Rollup, aggregation
> data
> model. As a consequnce, we have to change sql grammar based on Impala.

Impala supports catalog data cached in memory, and adding new features
to Impala's SQL grammar is not forbidden. I think one of my first
largish contributions changed the grammar.

> Thirdly, it is a big difference in Cluster manager and node deployment.
> Contrast Impala, Query compiling, query execution coordination and catalog
> management of storage engine are integrated to be frontend daemon.
> Query execution and data storage are integrated to be backend daemon.

I'm not sure I understand - how is Palo different here?

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

Re: Looking for Champion

[Jim Apple]

I'm not a binding vote on incubator entry, but I think it would be
great to have roadmaps as soon as feasible on addressing Tim's concern
(which is deeply related to #2, "Licensing") and on addressing the
code and toil duplication.

On Mon, Jun 18, 2018 at 11:08 AM, Dave Fisher  wrote:
> Hi Li,De -
>
> Since I agreed to champion this project I think that we need a summary about
> what the Incubator PMC cares about in order to accept a podling. What the
> prospective project needs to address. We also need to be clear what should
> happen during Incubation and at what time. I think that many of the
> questions that came up in this thread had to do with assessing how much
> effort it will take to Incubate Palo (or whatever the name will be)
>
> (1) The name Palo. Since there seems to be an issue with that name we should
> have a new name. It is not unknown for a podling to change its name, but
> that does generate extra work for Infrastructure to change the name after
> podling start up. It would be our preference for Palo to find a new name
> prior to VOTING on the proposal. Please do this elsewhere and come back to
> me with the new name so that I can help with the updated proposal.
>
> (2) Licensing of the software. Several bits came up as questionable.
> Regardless of cleanup that has already occurred we have identified that we
> will need to be very careful. It will be important to discuss and carefully
> handle the Software Grant Agreement to make sure that the source listed is
> correct. I think that the SGA must come early during incubation.
>
> (3) Relationship with Impala. Palo has apparently forked portions of Impala.
> This means that some are concerned that there is a missed synergy with the
> Apache Impala project. Is there a clean interface that can be built between
> the projects? It would help if the Palo developers would explore this with
> Impala at d...@impala.apache.org.
>
> That said, part of the Incubation process is to learn the Apache Way. IMHO
> it is ok for the relationship between Impala PMC and a pooling PPMC to be a
> work in process.
>
> (4) Currently, Willem, Luke Han and Dave Fisher are qualified to officially
> mentor. I suggest that Sijie Guo and Zheng Shao be included as Initial
> Committers in order to help from within the PPMC.
>
> On Jun 14, 2018, at 11:03 AM, Jim Apple 
> wrote:
>
> I don't want to be a stickler, but I don't think "For issues mentioned by
> Jim, Todd and Tim, I have replied on last Saturday."
>
> To my email about Palo being an ASF project as a storage system without a
> query engine, you replied only, "We will seriously consider this proposal."
>
> I see no response to Tim's concern that "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.”
>
>
> Jim - do you need answers to these concerns prior to agreeing to accept this
> project into the Incubator?
>
> Regards,
> Dave
>
>
> On Thu, Jun 14, 2018 at 12:48 AM, Li,De(BDG)  wrote:
>
> Hi all,
>
> About Palo, we have fixed following issues.
>
> 1. Related Impala
> For issues mentioned by Jim, Todd and Tim, I have replied on last Saturday.
>
> 2、Lisence issue
> For issues mentioned by Todd and Ted.
> 1) be/aes/* come from mysql-5.6, GPL v2.1 license
> Fixed: removed aes related codes.
> https://github.com/baidu/palo/commit/ac770c33d445a4c18a0b74f56b28a4
> 180b30bf
> b7
> https://github.com/baidu/palo/commit/3c9f2ae6695ffebe41e39b6bf65440
> 77698f1c
> ed
>
> 2) be/util/mysql_dtoa.cpp copy from MySQL, GPL license
> Fixed: removed mysql_dtoa related codes.
> https://github.com/baidu/palo/commit/bfe1bc7cf39e165a7c52b2c9415509
> 75b1f841
> a1
>
> 3) be/http/mongoose.h, Copyright (c) 2004-2012 Sergey Lyubka
> Fixed: restored to original lisence, we are searching another http server
> to replace it.
> https://github.com/baidu/palo/commit/81baef34f48a2dbe7401712c5e0a50
> f59f04a8
> 31
>
> 4) be/rpc/*
> Fixed: We have replaced it with brpc, and we will remove Hypertable after
> few weeks for waiting users' upgrade to brpc.
> https://github.com/baidu/palo/tree/master/be/src/rpc
>
> 3、Dependency licenses
> For issue mentioned by Dave, It looks like that Palo have not depend on
> OpenLdap and cyrus-sasl directly,
> but some thirdpary libraries need them to compile, libcurl and gperftools
> for instance.
> For rapidjson, we are looking for alternative one.
>
> 4、About the name of Palo
> For issue mentioned by Julian.
> We are figuring out

Re: Looking for Champion

[Jim Apple]

>>>>across a
> >>>>> broad range of workloads provides a more elegant solution to the
> >>>>>problems
> >>>>> that hybrid architectures aim to solve. Palo is the solution.
> >>>>>>
> >>>>>> Palo is designed to be a simple and single tightly coupled system,
> >>>>>>not
> >>>>> depending on other systems. Palo provides high concurrent low latency
> >>>>>point
> >>>>> query performance, but also provides high throughput queries of
> >>>>>ad-hoc
> >>>>> analysis. Palo provides bulk-batch data loading, but also provides
> >>>>>near
> >>>>> real-time mini-batch data loading. Palo also provides high
> >>>>>availability,
> >>>>> reliability, fault tolerance, and scalability.
> >>>>>>
> >>>>>> ##Rationale
> >>>>>>
> >>>>>> Palo mainly integrates the technology of Google Mesa and Apache
> >>>>>>Impala.
> >>>>>>
> >>>>>> Mesa is a highly scalable analytic data storage system that stores
> >>>>> critical measurement data related to Google's Internet advertising
> >>>>> business. Mesa is designed to satisfy complex and challenging set of
> >>>>>users’
> >>>>> and systems’ requirements, including near real-time data ingestion
> >>>>>and
> >>>>> query ability, as well as high availability, reliability, fault
> >>>>>tolerance,
> >>>>> and scalability for large data and query volumes.
> >>>>>>
> >>>>>> Impala is a modern, open-source MPP SQL engine architected from the
> >>>>> ground up for the Hadoop data processing environment. At present, by
> >>>>>virtue
> >>>>> of its superior performance and rich functionality， Impala has been
> >>>>> comparable to many commercial MPP database query engine. Mesa can
> >>>>>satisfy
> >>>>> the needs of many of our storage requirements, however Mesa itself
> >>>>>does not
> >>>>> provide a SQL query engine; Impala is a very good MPP SQL query
> >>>>>engine, but
> >>>>> the lack of a perfect distributed storage engine. So in the end we
> >>>>>chose
> >>>>> the combination of these two technologies.
> >>>>>>
> >>>>>> Learning from Mesa’s data model, we developed a distributed storage
> >>>>> engine. Unlike Mesa, this storage engine does not rely on any
> >>>>>distributed
> >>>>> file system. Then we deeply integrate this storage engine with Impala
> >>>>>query
> >>>>> engine. Query compiling, query execution coordination and catalog
> >>>>> management of storage engine are integrated to be frontend daemon;
> >>>>>query
> >>>>> execution and data storage are integrated to be backend daemon. With
> >>>>>this
> >>>>> integration, we implemented a single, full-featured, high performance
> >>>>>state
> >>>>> the art of MPP database, as well as maintaining the simplicity.
> >>>>>>
> >>>>>> ##Current Status
> >>>>>>
> >>>>>> Palo has been an open source project on GitHub (
> >>>>> https://github.com/baidu/palo).
> >>>>>>
> >>>>>> ###Meritocracy
> >>>>>>
> >>>>>> Palo has been deployed in production at Baidu and is applying more
> >>>>>>than
> >>>>> 200 lines of business. It has demonstrated great performance benefits
> >>>>>and
> >>>>> has proved to be a better way for reporting and analysis based big
> >>>>>data.
> >>>>> Still We look forward to growing a rich user and developer community.
> >>>>>>
> >>>>>> ###Community
> >>>>>>
> >>>>>> Palo seeks to develop developer and user communities during
> >>>>>>incubation.
> >>>>>>
> >>>>>> ###Core Developers
> >>>>>>
> >>>>>> * Ruyue Ma (https://github.com/maruyue,
> >>>>>>maru.

Re: Looking for Champion

[Jim Apple]

>
> 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.
>

And this is something I'm really excited about. If only the storage system
part of Palo were contributed to the ASF, and simultaneously the Palo
community and the Impala community worked together to integrate the query
engine work of Palo into Impala, then this could provide a lot of benefit
to users, I think. My hope is that it would eliminate the toil the Palo
community is engaged in by rebasing Impala changes (as Tim noticed).
Impala, meanwhile, might benefit from some changes Palo has made, like SIMD
filtering.

This could be a lot of work, but the current system seems to already
include quite a lot of inefficiency from the duplication.

Re: Looking for Champion

[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.
> 
> ##Proposal
> 
> We propose to contribute the Palo codebase and associated artifacts (e.g. 
> documentation, web-site content etc.) to the Apache Software Foundation with 
> the intent of forming a productive, meritocratic and open community around 
> Palo’s continued development, according to the ‘Apache Way’.
> 
> Baidu owns several trademarks regarding Palo, and proposes to transfer 
> ownership of those trademarks in full to the ASF.
> 
> ###Overview of Palo
> 
> Palo’s implementation consists of two daemons: Frontend (FE) and Backend (BE).
> 
> **Frontend daemon** consists of query coordinator and catalog manager. Query 
> coordinator is responsible for receiving users’ sql queries, compiling 
> queries and managing queries execution. Catalog manager is responsible for 
> managing metadata such as databases, tables, partitions, replicas and etc. 
> Several frontend daemons could be deployed to guarantee fault-tolerance, and 
> load balancing.
> 
> **Backend daemon** stores the data and executes the query fragments. Many 
> backend daemons could also be deployed to provide scalability and 
> fault-tolerance.
> 
> A typical Palo cluster generally composes of several frontend daemons and 
> dozens to hundreds of backend daemons.
> 
> Users can use MySQL client tools to connect any frontend daemon to submit SQL 
> query. Frontend receives the query and compiles it into query plans 
> executable by the Backend. Then Frontend sends the query plan fragments to 
> Backend. Backend will build a query execution DAG. Data is fetched and 
> pipelined into the DAG. The final result response is sent to client via 
> Frontend. The distribution of query fragment execution takes minimizing data 
> movement and maximizing scan locality as the main goal.
> 
> ##Background
> 
> At Baidu, Prior to Palo, different tools were deployed to solve diverse 
> requirements in many ways. And when a use case requires the simultaneous 
> availability of capabilities that cannot all be provided by a single tool, 
> users were forced to build hybrid architectures that stitch multiple tools 
> together, but we believe that they shouldn’t need to accept such inherent 
> complexity. A storage system built to provide great performance across a 
> broad range of workloads provides a more elegant solution to the problems 
> that hybrid architectures aim to solve. Palo is the solution.
> 
> Palo is designed to be a simple and single tightly coupled system, not 
> depending on other systems. Palo provides high concurrent low latency point 
> query performance, but also provides high throughput queries of ad-hoc 
> analysis. Palo provides bulk-batch data loading, but also provides near 
> real-time mini-batch data loading. Palo also provides high availability, 
> reliability, fault tolerance, and scalability.
> 
> ##Rationale
> 
> Palo mainly integrates the technology of Google Mesa and Apache Impala.
> 
> Mesa is a highly scalable analytic data storage system that stores critical 
> measurement data related to Google's Internet advertising business. Mesa is 
> designed to satisfy complex and challenging set of users’ and systems’ 
> requirements, including near real-time data ingestion and query ability, as 
> well as high availability, reliability, fault tolerance, and scalability for 
> large data and query volumes.
> 
> Impala is a modern, open-source MPP SQL engine architected from the ground up 
> for the Hadoop data processing environment. At present, by virtue of its 
> superior performance and rich functionality， Impala has been comparable to 
> many commercial MPP database query engine. Mesa can satisfy the needs of many 
> of our storage requirements, however Mesa itself does not provide a SQL query 
> engine; Impala is a very good MPP SQL query engine, but the lack of a perfect 
> distributed storage engine. So in the end we chose the combination of these 
> two technologies.
> 
> Learning from Mesa’s data model, we developed a distributed storage engine. 
> Unlike Mesa, this storage engine does not rely on any distributed file 
> system. Then we deeply 

[jira] [Created] (INCUBATOR-208) Transferring guide needs an editing pass

[Jim Apple (JIRA)]

Jim Apple created INCUBATOR-208:
---

 Summary: Transferring guide needs an editing pass
 Key: INCUBATOR-208
 URL: https://issues.apache.org/jira/browse/INCUBATOR-208
 Project: Incubator
  Issue Type: Bug
  Components: guides
Reporter: Jim Apple


There are a number of issues with the transferring page:

"{{noformat}}#foundation/officers/irs-disclosures.txt*{{noformat}" has some odd 
characters prepended and appended.

https://incubator.apache.org/guides/transferring.html#notes-status is a missing 
anchor

"Final Revision of Podling Incubation Records" has bizarre formatting.

I suspect these are not the only issues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (INCUBATOR-207) Update advice-for-new-pmc-chairs.txt for new graduation guide

[Jim Apple (JIRA)]

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

Jim Apple resolved INCUBATOR-207.
-
Resolution: Fixed

LGTM, thanks!

> Update advice-for-new-pmc-chairs.txt for new graduation guide
> -
>
> Key: INCUBATOR-207
> URL: https://issues.apache.org/jira/browse/INCUBATOR-207
> Project: Incubator
>  Issue Type: Bug
>  Components: guides
>Reporter: Jim Apple
>Assignee: Craig L Russell
>
> https://svn.apache.org/repos/private/foundation/officers/advice-for-new-pmc-chairs.txt
>  links to https://incubator.apache.org/guides/graduation.html#transfer and  
> https://incubator.apache.org/guides/graduation.html#life-after-graduation , 
> which no longer exist.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (INCUBATOR-207) Update advice-for-new-pmc-chairs.txt for new graduation guide

[Jim Apple (JIRA)]

Jim Apple created INCUBATOR-207:
---

 Summary: Update advice-for-new-pmc-chairs.txt for new graduation 
guide
 Key: INCUBATOR-207
 URL: https://issues.apache.org/jira/browse/INCUBATOR-207
 Project: Incubator
  Issue Type: Bug
  Components: guides
Reporter: Jim Apple


https://svn.apache.org/repos/private/foundation/officers/advice-for-new-pmc-chairs.txt
 links to https://incubator.apache.org/guides/graduation.html#transfer and  
https://incubator.apache.org/guides/graduation.html#life-after-graduation , 
which no longer exist.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Graduation: who mails the board?

[Jim Apple]

Thank you for explaining!

On Sat, Nov 11, 2017 at 10:13 PM, Craig Russell <apache@gmail.com>
wrote:

> A resolution is added to the agenda by going to https://whimsy.apache.org/
> board/agenda/2017-11-15/ and clicking on "add resolution".
>
> If you do not have karma to do this, one of your mentors will have to do
> it for you.
>
> Craig
>
> > On Nov 11, 2017, at 8:44 PM, Jim Apple <jbap...@cloudera.com> wrote:
> >
> > I think I understand. I will write the email, but what is the mechanism
> by
> > which I "add the resolution to establish the project to the board
> agenda"?
> > Is that just the result of sending the email?
> >
> > On Sat, Nov 11, 2017 at 8:38 PM, Craig Russell <apache@gmail.com>
> wrote:
> >
> >> I agree this is a bit ambiguous.
> >>
> >> What you should do is to send a message to the board with a link to the
> >> [RESULT] message and add the resolution [to establish the project] to
> the
> >> board agenda.
> >>
> >> Craig
> >>
> >>> On Nov 11, 2017, at 8:33 PM, Jim Apple <jbap...@cloudera.com> wrote:
> >>>
> >>> Impala just passed the IPMC graduation-to-TLP vote. The graduation
> guide
> >>> says that the board is then emailed, but it is worded in the passive
> >> voice:
> >>> "Once the resolution has been finalized and consensus reached, it
> should
> >> be
> >>> submitted to the Board."
> >>>
> >>> Who is the intended sender of that email: the mentors, the IPMC, the
> >> PPMC,
> >>> or just whoever gets around to it first?
> >>
> >> Craig L Russell
> >> Secretary, Apache Software Foundation
> >> c...@apache.org http://db.apache.org/jdo
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Graduation: who mails the board?

[Jim Apple]

I think I understand. I will write the email, but what is the mechanism by
which I "add the resolution to establish the project to the board agenda"?
Is that just the result of sending the email?

On Sat, Nov 11, 2017 at 8:38 PM, Craig Russell <apache@gmail.com> wrote:

> I agree this is a bit ambiguous.
>
> What you should do is to send a message to the board with a link to the
> [RESULT] message and add the resolution [to establish the project] to the
> board agenda.
>
> Craig
>
> > On Nov 11, 2017, at 8:33 PM, Jim Apple <jbap...@cloudera.com> wrote:
> >
> > Impala just passed the IPMC graduation-to-TLP vote. The graduation guide
> > says that the board is then emailed, but it is worded in the passive
> voice:
> > "Once the resolution has been finalized and consensus reached, it should
> be
> > submitted to the Board."
> >
> > Who is the intended sender of that email: the mentors, the IPMC, the
> PPMC,
> > or just whoever gets around to it first?
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Graduation: who mails the board?

[Jim Apple]

Impala just passed the IPMC graduation-to-TLP vote. The graduation guide
says that the board is then emailed, but it is worded in the passive voice:
"Once the resolution has been finalized and consensus reached, it should be
submitted to the Board."

Who is the intended sender of that email: the mentors, the IPMC, the PPMC,
or just whoever gets around to it first?

[RESULT] Resolution to graduate Apache Impala to TLP

[Jim Apple]

The vote[0] to graduate Impala to a TLP is concluded. The result is to
recommend graduation.

Binding votes:
+1: Seven (John D. Ament, Pierre Smits, Todd Lipcon, Carl Steinbach,
Byung-Gon Chun, Jean-Baptiste Onofré, Tom White)
0: none
-1: none

Non-binding votes:
+1: One (Zheng, Kai)
0: none
-1: none

Thanks to the voters, who took time to vote.

0:
https://lists.apache.org/thread.html/4abfbf40b7d822cdc19421ea55de21f19ce70c4fd73c6f4c8cc98ce8@%3Cgeneral.incubator.apache.org%3E

[VOTE] Resolution to graduate Apache Impala to TLP

[Jim Apple]

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/2f5db4788aff9b0557354b9106c0328a29c1f90c1a74a228163949d2@%3Cdev.impala.apache.org%3E
>

[1]: <
https://lists.apache.org/thread.html/a5a7c6895b3e019347d6e4e4cf49d67d094d31b8f2c7b4d59200f3e4@%3Cdev.impala.apache.org%3E
>

[2]: <
https://lists.apache.org/thread.html/6b8598408f76a472532923c5a7fc510470b21671677ba3486568c57e@%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

[Jim Apple]

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

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

[DISCUSS] Resolution to graduate Apache Impala to TLP

[Jim Apple]

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/2f5db4788aff9b0557354b9106c0328a29c1f90c1a74a228163949d2@%3Cdev.impala.apache.org%3E

Community Vote:
https://lists.apache.org/thread.html/a5a7c6895b3e019347d6e4e4cf49d67d094d31b8f2c7b4d59200f3e4@%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 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.

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

Impala is conducting a community graduation vote

[Jim Apple]

Following
https://incubator.apache.org/guides/graduation.html#community_graduation_vote
, this is a notification that Impala is having a community graduation vote
at
https://lists.apache.org/thread.html/a5a7c6895b3e019347d6e4e4cf49d67d094d31b8f2c7b4d59200f3e4@%3Cdev.impala.apache.org%3E

What are the infra steps when a podling graduates?

[Jim Apple]

There used to be a long list of things to do when a podling graduates:

https://web.archive.org/web/20121203165354/https://incubator.apache.org/guides/graduation.html#project-first-steps

This is still referenced on that page ("Consider post graduation tasks"),
but it is not actually referenced on that page.

Re: [RESULT] Vote on Impala 2.10.0 release candidate 2

[Jim Apple]

I have updated the release instructions at
https://cwiki.apache.org/confluence/display/IMPALA/How+to+Release to
reflect this addition.

On Wed, Sep 13, 2017 at 10:10 AM, sebb  wrote:

> The summary is easy to read, but has no context.
>
> Ideally the result mail should either form part of the VOTE thread
> (reply and prefix the subject with [RESULT]) or should contain a link
> to the vote thread.
>
> Please could you consider addressing this for the next vote result?
>
> Thanks.
>
> Just my 2p
>
>
>
> On 13 September 2017 at 07:14, Bharath Vissapragada
>  wrote:
> > The vote has passed with the following tally.
> >
> > +1 (binding)
> >
> > - Brock Noland
> > - Carl Steinbach
> > - John D. Ament
> >
> > -1 (binding) - None
> > 0 - None
> >
> > Thanks everyone for testing and voting on the release.
>

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Jim Apple]

>  I'll be honest, I have no idea why they
> think they have to do it, but they do it.

I suspect it is because projects are motivated to graduate and believe
that one or more people on the IPMC with -1 their graduation if they
do not complete the model and put a check mark in every box.

I suspect they believe this because they see other discussions or
votes on this mailing list end up with -1 votes (or "fix it for your
next release" statements) that they believe go beyond the official
policy requirements of the issue at question.

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

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Jim Apple]

> It's *very* helpful to have podlings consider their growth using some
> form of structured and consistent criteria, so IPMC (and board) can
> consider how different podlings see themselves compared to past podling
> history.

I think the current Model has a number of vague statements that are
unlikely to be interpreted consistently without clarification. For
instance "The project is open and honest about the quality of its
code."

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

Re: [DRAFT] Incubator PMC Board Report - August 2017

[Jim Apple]

> * Podlings missing sign off, will be moved to failed to report

This is new, right? I don't see it in my email archives that "will be
moved to failed to report" has appeared previously.

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

Re: svn commit: r1802207 - /incubator/public/trunk/content/projects/impala.xml

[Jim Apple]

The rosters are then hidden from people who aren't committers on some ASF
project, yes?

On Mon, Jul 17, 2017 at 2:38 PM, John D. Ament 
wrote:

> Just as a reminder, podling rosters only need to be maintained in whimsy.
>
> John
>
> On Mon, Jul 17, 2017 at 4:09 PM  wrote:
>
>> Author: jbapple
>> Date: Mon Jul 17 20:09:21 2017
>> New Revision: 1802207
>>
>> URL: http://svn.apache.org/viewvc?rev=1802207=rev
>> Log:
>> Add Michael Brown to Impala PPMC
>>
>> Modified:
>> incubator/public/trunk/content/projects/impala.xml
>>
>> Modified: incubator/public/trunk/content/projects/impala.xml
>> URL: http://svn.apache.org/viewvc/incubator/public/trunk/
>> content/projects/impala.xml?rev=1802207=1802206=1802207=diff
>> 
>> ==
>> --- incubator/public/trunk/content/projects/impala.xml [utf-8] (original)
>> +++ incubator/public/trunk/content/projects/impala.xml [utf-8] Mon Jul
>> 17 20:09:21 2017
>> @@ -138,6 +138,11 @@
>>  
>>  
>>.
>> +  mikeb
>> +  Michael Brown
>> +
>> +
>> +  .
>>casey
>>Casey Ching
>>  
>> @@ -213,11 +218,6 @@
>>  
>>  
>>Committers
>> -  mikeb
>> -  Michael Brown
>> -
>> -
>> -  .
>>tmarshall
>>Thomas Tauber-Marshall
>>  
>>
>>
>>
>> -
>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: cvs-h...@incubator.apache.org
>>
>>

Updating XML status pages

[Jim Apple]

http://incubator.apache.org/guides/website.html says:

"Podling status files are maintained in SVN, and you should continue to
maintain them at
http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/;

Are those updated XML files ever published automatically? As of a few
months ago, we had to use https://cms.apache.org/incubator/publish?diff=1

Re: Looking for GPG key signers in Boston area

[Jim Apple]

"Signing keys SHOULD be linked into a strong web of trust."

On Mon, Jun 19, 2017 at 10:29 AM, John D. Ament  wrote:
> Is there a guide you're getting that from?  When I look at [1] it seems we
> trust the public registries, so nothing else should be needed.
>
> John
>
> [1]: https://www.apache.org/info/verification.html
>
>
> On Mon, Jun 19, 2017 at 1:28 PM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
>> Thanks John-
>>   My key is already listed there and is present in the KEYS file as well.
>>
>> Doesn’t the key also need to be verified by others at Apache to be
>> considered valid?
>>
>> —Eric
>>
>> > On Jun 19, 2017, at 1:12 PM, John D. Ament 
>> wrote:
>> >
>> > I think all you have to do is upload it via https://pgp.mit.edu/
>> ...
>> >
>> > John
>> >
>> > On Mon, Jun 19, 2017 at 1:11 PM Eric Friedrich (efriedri) <
>> > efrie...@cisco.com> wrote:
>> >
>> >> Apologies for this slightly unorthodox use of the mailer.
>> >>
>> >> I’m in the process of preparing a release for the Traffic Control
>> podling.
>> >> As the RM, I have to use my GPG key to sign the release.
>> >>
>> >> However, my GPG key is not yet tied into the web of trust and we cannot
>> >> pass the vote because of this.
>> >>
>> >> Is there anyone in the Boston area (preferably South or metro-west) that
>> >> would be willing to meet and verify my key ownership?
>> >>
>> >> Thanks!
>> >> Eric
>> >>
>> >>
>>
>>

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

Re: Clarification/typo on release votes (Re: [VOTE] Release Apache Tamaya 0.3-incubating)

[Jim Apple]

The third condition is implied by the second one.

I do not believe the second condition is implied by "Votes on whether
a package is ready to be released use majority approval -- i.e., at
least three PMC members must vote affirmatively for release, and there
must be more positive than negative votes." or "Refers to a vote
(sense 1) which has completed with at least three binding +1 votes and
more +1 votes than -1 votes. ( I.e. , a simple majority with a minimum
quorum of three positive votes.) Note that in votes requiring majority
approval a -1 vote is simply a vote against, not a veto. Compare
Consensus Approval. See also the description of the voting process."

http://www.apache.org/legal/release-policy

On Thu, Jun 15, 2017 at 7:09 PM, John D. Ament  wrote:
> Gah, this is what I was trying to convey.  But I don't think it's still
> 100% correct.
>
> You need a minimum of 3 +1's
> Your net positive votes must be 3 (e.g. if you have a -1 and 5 total votes,
> the other 4 votes must be +1's)
> You need more +1's than -1's
>
> I'm not sure what is written better.
>
> (trying to be more anal than Josh, but just to make sure everyone agrees)
>
> John
>
> On Thu, Jun 15, 2017 at 8:54 PM Josh Elser  wrote:
>
>> On 6/15/17 1:11 PM, Oliver B. Fischer wrote:
>> >
>> > Please note:
>> > This vote is a "majority approval" with a minimum of three +1 votes and
>> > no -1’s (see [4]).
>>
>> Just wanted to point out that your description of majority approval is
>> wrong. You need at least 3 +1's and more +1's than -1's. -1's are not
>> vetos in this case :)
>>
>> (since I had to be anal about it and correct you, let me take a look at
>> your RC too :P)
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

Re: [DRAFT] What the new Status Pages potentially look like

[Jim Apple]

Thank you for the responses.

>> 5. Make sure the Whimsy page applies to all projects. For instance,
>> Impala releases are source tarballs, so if "Binary Distribution
>> Licensing" means something about a non-source-tarball release
>> artefact, it's not meaningful for Impala.
>>
>
> Hmm that's interesting.  The ASF only releases source code.  However, the
> second check is that your resulting binary is also compliant.

The "your resulting binary" is for projects that distribute
convenience binaries?

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

Re: [DRAFT] What the new Status Pages potentially look like

[Jim Apple]

Here are some suggestions:

1. Only make this the reporting structure for new podlings.
Grandfather in old podlings to the old structure, since they may
already have workflows built around it. Impala does.

2. Provide a clear description of the meaning and formatting of each
field in comments on the YAML file itself.

3. Provide guidance on how long it takes from SVN checkin to whimsy
render change.

4. Use git, not SVN

5. Make sure the Whimsy page applies to all projects. For instance,
Impala releases are source tarballs, so if "Binary Distribution
Licensing" means something about a non-source-tarball release
artefact, it's not meaningful for Impala.

6. Give the fields on the whimsy page names that correspond,
one-to-one, with the YAML fields.

7. Give the Whimsy page headers more specific meanings. "Confirmation
of ASF Copyright Headers on Source Code on" could mean confirmation by
any number of people or committees. Which one is meant by this phrase?
If it's the IPMC, and the first approved release is what is meant by
this, change the name to "First Apache release" or something.

8. Provide the ability to lookup the information required to fill out
the status page. How can a podling find out when the SGA was received?
Please remember that podling personnel can change during incubation.

On Tue, Jun 13, 2017 at 6:04 PM, John D. Ament <johndam...@apache.org> wrote:
> Jim,
>
> For your specific cases, if all you want is to remove red text:
>
> - for :sga: enter the date in -MM-DD format of when the ASF Secretary
> acknowledged your SGA.  Based on the records I have its 2016-03-15
> - For the :asfCopyright: and :distributionRights: attributes, I would use
> 2017-01-20 as that's the day of the results of 2.8 which was the first
> release to have no issues during review.
>
> But please do continue to provide input, want to make sure we're building
> something useful, not a pain.
>
> HTH,
>
> John
>
> On Tue, Jun 13, 2017 at 8:52 PM Jim Apple <jbap...@cloudera.com> wrote:
>
>> I'm confused. The message to podlings@ said "If you're not sure what
>> to fill out, feel free to reach out."
>>
>> It sounds like there is no set way yet to fill it out.
>>
>> What can I do to get the bolded, red, inaccurate scare messages off of
>> our whimsy page?
>>
>> On Tue, Jun 13, 2017 at 5:30 PM, John D. Ament <john.d.am...@gmail.com>
>> wrote:
>> > Good points Dave.  To be honest, since this is a prototype I don't have
>> > answers any more than "If you think it should do that, we can make it do
>> > that"
>> >
>> > What I did have in mind:
>> >
>> > ---
>> > :issueTracker: jira|github|bugzilla
>> > :wiki: if using confluence, their space key
>> > :jira: if using jira, their issue key (though I suppose this can be
>> > multiple)
>> > :proposal: link to the proposal page.
>> > :asfCopyright: the date that we confirmed ASF copyright headers on the
>> > source code (e.g. the first time a source release passed without any
>> issues)
>> > :distributionRights: the date that we confirmed the resulting binary
>> > satisfied our release policies (e.g. the first time a release included a
>> > binary without any issues)
>> > :ipClearance: a link to the IP Clearance page for this podling.  I guess
>> > this can be multiple?
>> > :sga: date in which a SGA was received
>> > :website: http://impala.incubator.apache.org
>> > :graduationDate: to be filled in when the podling graduates
>> > :resolution: tlp|subproject , if subproject the TLP should be in here
>> > somehwere.  We may want to track as "sponsor."
>> >
>> > I can draft this up on a wiki page to gain more input.  What do you think
>> > about using https://wiki.apache.org/incubator/PodlingStatusBrainstorm to
>> > work through it?  I had a few more questions in line.
>> >
>> > On Tue, Jun 13, 2017 at 7:09 PM Dave Fisher <dave2w...@comcast.net>
>> wrote:
>> >
>> >> Hi John -
>> >>
>> >> These are excellent questions. I see each of these as being tuples of
>> >> various kinds.
>> >>
>> >> For example :sga: could have multiple grants each of which has a date
>> and
>> >> a file name to refer to in the foundation records.
>> >>
>> >>
>> > We don't usually expose the file name to people outside members, so I'm
>> not
>> > sure this would be useful.  Multiple dates are also not common.
>> >
>> >
>> >> The path to the source repository i

Re: [DRAFT] What the new Status Pages potentially look like

[Jim Apple]

I'm confused. The message to podlings@ said "If you're not sure what
to fill out, feel free to reach out."

It sounds like there is no set way yet to fill it out.

What can I do to get the bolded, red, inaccurate scare messages off of
our whimsy page?

On Tue, Jun 13, 2017 at 5:30 PM, John D. Ament <john.d.am...@gmail.com> wrote:
> Good points Dave.  To be honest, since this is a prototype I don't have
> answers any more than "If you think it should do that, we can make it do
> that"
>
> What I did have in mind:
>
> ---
> :issueTracker: jira|github|bugzilla
> :wiki: if using confluence, their space key
> :jira: if using jira, their issue key (though I suppose this can be
> multiple)
> :proposal: link to the proposal page.
> :asfCopyright: the date that we confirmed ASF copyright headers on the
> source code (e.g. the first time a source release passed without any issues)
> :distributionRights: the date that we confirmed the resulting binary
> satisfied our release policies (e.g. the first time a release included a
> binary without any issues)
> :ipClearance: a link to the IP Clearance page for this podling.  I guess
> this can be multiple?
> :sga: date in which a SGA was received
> :website: http://impala.incubator.apache.org
> :graduationDate: to be filled in when the podling graduates
> :resolution: tlp|subproject , if subproject the TLP should be in here
> somehwere.  We may want to track as "sponsor."
>
> I can draft this up on a wiki page to gain more input.  What do you think
> about using https://wiki.apache.org/incubator/PodlingStatusBrainstorm to
> work through it?  I had a few more questions in line.
>
> On Tue, Jun 13, 2017 at 7:09 PM Dave Fisher <dave2w...@comcast.net> wrote:
>
>> Hi John -
>>
>> These are excellent questions. I see each of these as being tuples of
>> various kinds.
>>
>> For example :sga: could have multiple grants each of which has a date and
>> a file name to refer to in the foundation records.
>>
>>
> We don't usually expose the file name to people outside members, so I'm not
> sure this would be useful.  Multiple dates are also not common.
>
>
>> The path to the source repository is missing completely.
>>
>
> Which source repository?  The podlings?  I have a prototype for gitbox
> podlings and think I can make it work for ASF git as well.  For SVN, we can
> assume default or have a list of values.
>
>
>>
>> Some of these items could be transitory. For example distributionRights
>> may be confirmed but then something is added which negates those rights
>> until the issue is cleared up.
>>
>>
> +1
>
>
>> I wonder if it makes sense to provide links to email threads and/or Wiki
>> pages with the details?
>>
>> Regards,
>> Dave
>>
>> > On Jun 13, 2017, at 8:22 AM, Jim Apple <jbap...@cloudera.com> wrote:
>> >
>> > What format of data is expected in the fields? Impala's new status
>> > page SVN config file
>> > <
>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/impala.yml
>> >
>> > is:
>> >
>> > ---
>> > :issueTracker: jira
>> > :wiki: IMPALA
>> > :jira: IMPALA
>> > :proposal: http://wiki.apache.org/incubator/ImpalaProposal
>> > :asfCopyright:
>> > :distributionRights:
>> > :ipClearance:
>> > :sga:
>> > :website: http://impala.incubator.apache.org
>> > :graduationDate:
>> > :resolution:
>> >
>> > I do not know how to fill out asfCopyright, distributionRights,
>> > ipClearance, or sga. Note that I believe I understand what these
>> > things ARE, I just don't know how to word them -- "asfCopyright: OK"?
>> >
>> > I also don't know which one(s) correspond to the bold red "No Release
>> > Yet" on <https://whimsy.apache.org/roster/ppmc/impala>. FWIW, Impala
>> > has had a couple of ASF releases.
>> >
>> > On Mon, Jun 12, 2017 at 6:02 PM, John D. Ament <johndam...@apache.org>
>> wrote:
>> >> All,
>> >>
>> >> We're piloting a new format for the podling status pages.  Specifically,
>> >> the current status page leaves a lot to be desired - it's basically
>> crafted
>> >> html, there's no structure and its hard to find missing items.  The end
>> >> goal is to have a web form editable in Whimsy, but until we get more
>> input
>> >> on what the content looks like I don't want to make changes like that.
>> I'm
>> >> askin

Re: Podling release vote terminology

[Jim Apple]

In that case, I oppose this change. I believe the status quo is just as
clear as this new proposal.

On Tue, May 9, 2017 at 11:30 AM, Craig Russell <apache@gmail.com> wrote:

> Hi Jim,
>
> Good questions.
>
> > On May 9, 2017, at 11:04 AM, Jim Apple <jbap...@cloudera.com> wrote:
> >
> > If PPMC members A, B, and C, who are not IPMC members, vote +1 on a
> > release, and then the second phase starts, acquires three +1 IPMC votes,
> > but A, B, and C change their votes to -1, does the release pass?
>
> Binding votes: 3 +1
> non-binding votes: 3 -1
>
> The binding votes determine the outcome. The vote passes.
> >
> > Hoe long must the first phase last? How long may it last?
>
> Usual rules. No change.
> >
> > If in the first phase, the vote is +3 to -4, may the release manager
> begin
> > the second phase?
>
> No. The usual rules apply to the first phase. More positive than negative
> votes. At least three PPMC members must cast votes in order to go to the
> second phase.
>
> Craig
> >
> > On Tue, May 9, 2017 at 11:00 AM, Craig Russell <apache@gmail.com>
> wrote:
> >
> >> I've seen a few (recent) incubator votes that imply that there are two
> >> separate, distinct votes: one in the podling and one in the incubator
> >> general. And lots of questions about binding votes and carried-over
> votes
> >> and whose votes are counted.
> >>
> >> I'd like to suggest:
> >>
> >> There is one vote for a podling release candidate. The first phase of
> the
> >> vote takes place on the podling dev list. Anyone can vote. An
> affirmative
> >> vote by three PPMC members (including mentors) is sufficient to start
> the
> >> second phase, which takes place on the incubator general list. An
> >> individual's vote can be changed any time during either phase until the
> >> final vote is tallied.
> >>
> >> All votes are counted. Only IPMC member votes are binding. The final
> tally
> >> counts affirmative, neutral, and negative votes from both phases
> combined
> >> and affirmative, neutral and negative binding votes from both phases
> >> combined.
> >>
> >> This terminology answers questions about:
> >>
> >> Whether PPMC votes are binding. They are not.
> >> Whether IPMC member votes on the first phase of voting carry over to the
> >> second phase. They do.
> >> Whether public votes in either phase count. They do.
> >> Whether public votes in either phase are binding. They are not.
> >>
> >> If we agree on the terminology, I'll see what documents need to be
> updated.
> >>
> >> Craig L Russell
> >> c...@apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podling release vote terminology

[Jim Apple]

If PPMC members A, B, and C, who are not IPMC members, vote +1 on a
release, and then the second phase starts, acquires three +1 IPMC votes,
but A, B, and C change their votes to -1, does the release pass?

Hoe long must the first phase last? How long may it last?

If in the first phase, the vote is +3 to -4, may the release manager begin
the second phase?

On Tue, May 9, 2017 at 11:00 AM, Craig Russell  wrote:

> I've seen a few (recent) incubator votes that imply that there are two
> separate, distinct votes: one in the podling and one in the incubator
> general. And lots of questions about binding votes and carried-over votes
> and whose votes are counted.
>
> I'd like to suggest:
>
> There is one vote for a podling release candidate. The first phase of the
> vote takes place on the podling dev list. Anyone can vote. An affirmative
> vote by three PPMC members (including mentors) is sufficient to start the
> second phase, which takes place on the incubator general list. An
> individual's vote can be changed any time during either phase until the
> final vote is tallied.
>
> All votes are counted. Only IPMC member votes are binding. The final tally
> counts affirmative, neutral, and negative votes from both phases combined
> and affirmative, neutral and negative binding votes from both phases
> combined.
>
> This terminology answers questions about:
>
> Whether PPMC votes are binding. They are not.
> Whether IPMC member votes on the first phase of voting carry over to the
> second phase. They do.
> Whether public votes in either phase count. They do.
> Whether public votes in either phase are binding. They are not.
>
> If we agree on the terminology, I'll see what documents need to be updated.
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Airflow voting on release artifacts

[Jim Apple]

Would virtualenv help by avoiding the "Requirement already satisfied"
complaints?

On Tue, Apr 25, 2017 at 2:05 PM, Bolke de Bruin  wrote:

> Thank you thinking with us, that’s really appreciated. Unfortunately, many
> of the assumptions from the Java world do not apply to the Python world:
>
> Version information inside the artefact needs to be in sync with the
> external filename.
>
> Examples:
>
> 1. Plain rename of the tar ball
>
> bolke$ pip install airflow-1.8.0rc11+apache.incubating.tar.gz
> Processing ./airflow-1.8.0rc11+apache.incubating.tar.gz
>   Requirement already satisfied (use --upgrade to upgrade):
> airflow==1.8.0rc5+apache.incubating from file:///Users/bolke/Documents/
> dev/airflow/dist/airflow-1.8.0rc11%2Bapache.incubating.tar.gz in
> /Users/bolke/Documents/dev/airflow_env/lib/python2.7/site-packages
>
> Note that although RC11 is mentioned RC5 is contained in the package and
> is not upgraded.
>
> 2. Rename of the package inside the tar ball
> bolke$ mv airflow-1.8.0rc5+apache.incubating airflow-1.8.0rc11+apache.
> incubating
> bolke$ tar cfz ../airflow-1.8.0rc11+apache.incubating.tar.gz
> airflow-1.8.0rc11+apache.incubating/
>
> bolke$ pip install airflow-1.8.0rc11+apache.incubating.tar.gz
> Processing ./airflow-1.8.0rc11+apache.incubating.tar.gz
>   Requirement already satisfied (use --upgrade to upgrade):
> airflow==1.8.0rc5+apache.incubating from file:///Users/bolke/Documents/
> dev/airflow/dist/airflow-1.8.0rc11%2Bapache.incubating.tar.gz in
> /Users/bolke/Documents/dev/airflow_env/lib/python2.7/site-packages
>
> 3. There is no “separate” build script. Pip will just install a binary
> (“wheel”) or uses the source package (as shown above). Both are used
> interchangeable by users. We only distribute source packages at the moment.
>
> @Alex: I have to think a little bit more about what you wrote, but it is
> currently confusing the hell out of me :). Furthermore, I am not sure if it
> applies considering the above #3.
>
> At the moment we seem stuck between a rock and a hard place. And as we
> would like to release a new version pretty soon, we probably want to vote
> twice for now, and including the IPMC, four times. Hopefully we can have a
> vote in rapid succession :-).
>
> Bolke
>
>
> > On 25 Apr 2017, at 17:33, Alex Harui  wrote:
> >
> >
> >
> > On 4/25/17, 1:43 AM, "Bolke de Bruin" > wrote:
> >
> >> Hi Bertrand,
> >>
> >>> On 25 Apr 2017, at 09:04, Bertrand Delacretaz
> >>>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini
> >>>  wrote:
>  ...Hitesh recently raised the issue that the artifact that passes the
>  vote
>  MUST be the one that we actually release...
> >>>
> >>> Yes in terms of having the same binary digests and signatures, but
> >>> renaming the files is fine IMO, especially for removing an -rc suffix
> >>> which makes total sense. I would just add that step to your release
> >>> process documentation to make it clear.
> >>>
>  ...Rename/rebuild after final vote (This is what Airflow is doing, and
>  Beam
>  does this, I believe)...
> >>>
> >>> I'd say rename yes but rebuild no, in order to keep the same digests
> >>> and signatures.
> >>>
> >>
> >> As mentioned earlier, that seems not to be possible. The metadata
> >> (filename) and version information inside the package need to be in
> sync.
> >> This how the python build tools and python ecosystem works.
> >
> > I'm not familiar with Python, but is it possible to have a command line
> > option that adds the "-rc" suffix in the right places?
> >
> > IMO, there are two "audiences".  One is the voters, and one is your
> > customers.  The customers should not be using the RC until after it is
> > approved unless they are volunteering to be a voter.  Voters are
> primarily
> > supposed to examine a source artifact, but if you also release a
> > "convenience binary" artifact, there are some examinations of that
> > "binary" artifact required.  For many projects this "convenience"
> artifact
> > is the one that the vast majority of customers consume.  AIUI, Python
> > doesn't have binaries, but IMO, there is no requirement that this
> > "convenience" artifact actually contains binaries.  A "convenience"
> > artifact is just supposed to be the source artifact processed by a build
> > script since many of your customer may not have, or may not want to
> > configure their machines to run whatever build script engine you choose
> > for your project.  Further, there is no requirement that I know of that
> > voters must test the "convenience" artifact by actually running it.  It
> > just makes sense to do so in most cases.  But if Python is interpreted
> > source, you may be able to use this to your advantage.
> >
> > So, your source package should consist of the source and build script
> > required to build this "customer"/"convenience" 

Re: [DISCUSS] Apache CarbonData podling graduation

[Jim Apple]

> Actually, the Maturity Model can be a very nice framework to organize
> incubation around.

If you're talking about a platonic MM, then I agree. If you are
talking about the MM at
https://community.apache.org/apache-way/apache-project-maturity-model.html,
I think it needs to be much more carefully written and much more
accurate to be a "nice framework". In particular, "aims to capture the
invariants of Apache projects ... A mature Apache project complies
with all the elements of this model" is wishful thinking or outdated
or both.

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

Re: [DISCUSS] Podling report format changes

[Jim Apple]

Ah, sorry for the paragraphs, then.

On Tue, Jan 24, 2017 at 5:52 PM, John D. Ament <johndam...@apache.org> wrote:
> Jim,
>
> Don't read too deeply into my use of "Podling Maturity Assessment."  The
> sections of the current summary are simply "Ready to Graduate", "Some
> Community Growth", "No Release" and "Still Getting Started."  I'm simply
> asking the podling to decide which of those 4 best describe themselves.
>
> John
>
> On Tue, Jan 24, 2017 at 8:40 PM Jim Apple <jbap...@cloudera.com> wrote:
>
>> There were a number of people who opposed the use of the maturity
>> model on this list in 2016. For instance, Greg Stein said: "There has
>> been past controversy on including that as a graduation step. I'm not
>> clear that was a proper addition." and "The Board has never required
>> the IPMC to use the APMM as a requirement for graduation."
>>
>> I find it to be pretty strange. Two examples:
>>
>> 1. "Convenience binaries can be distributed alongside source code but
>> they are not Apache Releases -- they are just a convenience provided
>> with no guarantee."
>>
>> I don't imagine this REQUIRES binaries, since
>> http://www.apache.org/legal/release-policy says:
>>
>> "The Apache Software Foundation produces open source software. All
>> releases are in the form of the source materials needed to make
>> changes to the software being released."
>>
>> So, if this isn't requiring binary releases, it seems to simply be
>> limiting them. That's fair enough, but how is that level level 4 of
>> "Releases" while "Releases are signed and/or distributed along with
>> digests", which requires actual work, is only level 3. Level 4 can be
>> achieved whilst napping by not guaranteeing anything while
>> sleepwalking.
>>
>> 2.  A number of the items don't seem to be mentioned in any other
>> incubating guide or don't seem to me to be true of TLPs in general.
>> Adding them here makes it look like there is new incubator policy that
>> snuck in the back door. Here are things I don't recall seeing
>> elsewhere:
>>
>> "The code can be built in a reproducible way using widely available
>> standard tools." -- widely available?
>>
>> "The project is open and honest about the quality of its code." --
>> Does anywhere else in the incubation documentation describe any sort
>> of quality disclosure procedure? What does this even mean -- what is
>> the scale?
>>
>> "The project puts a high priority on backwards compatibility" -- Is
>> this mentioned anywhere else on the incubation webpages?
>>
>> "The way in which contributors can be granted more rights such as
>> commit access or decision power is clearly documented" -- is this even
>> true for most TLPs? I spent some time looking at how big data TLPs
>> describe commit bit approvals, and most seem to be extremely vague in
>> describing what constitutes enough of a contribution to be granted the
>> bit.
>>
>> "The project is independent from any corporate or organizational
>> influence." -- Didn't Stratos just get moved to the attic because its
>> main corporate backer stopped backing it? How many other TLPs are in
>> this same boat?
>>
>> On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament <john.d.am...@gmail.com>
>> wrote:
>> > All,
>> >
>> > The Incubator PMC has received feedback from the board that changes may
>> > need to be made to the structure of our report.  Specifically, there is
>> > confusion from the board members over how podlings get classified.  There
>> > is also a request to increase and improve mentor feedback on podling
>> > reports.  Based on this input, I would like to propose the following
>> > changes to our report format.  I would like to try to implement this for
>> > the March report, if not before then.
>> >
>> > 1. Eliminate the podling summary section of the report.  It shouldn't be
>> on
>> > the report manager to classify each podling.  We have begun leveraging a
>> > maturity model for podlings, while its not required to fulfill it serves
>> as
>> > an equivalent to this section.  The list of podlings who failed to report
>> > shall remain.
>> >
>> > 2. Add a "Podling Maturity Assessment" to the individual podling reports.
>> > This would give a clear opportunity for each podling to describe how they
>> 

Re: [DISCUSS] Podling report format changes

[Jim Apple]

There were a number of people who opposed the use of the maturity
model on this list in 2016. For instance, Greg Stein said: "There has
been past controversy on including that as a graduation step. I'm not
clear that was a proper addition." and "The Board has never required
the IPMC to use the APMM as a requirement for graduation."

I find it to be pretty strange. Two examples:

1. "Convenience binaries can be distributed alongside source code but
they are not Apache Releases -- they are just a convenience provided
with no guarantee."

I don't imagine this REQUIRES binaries, since
http://www.apache.org/legal/release-policy says:

"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released."

So, if this isn't requiring binary releases, it seems to simply be
limiting them. That's fair enough, but how is that level level 4 of
"Releases" while "Releases are signed and/or distributed along with
digests", which requires actual work, is only level 3. Level 4 can be
achieved whilst napping by not guaranteeing anything while
sleepwalking.

2.  A number of the items don't seem to be mentioned in any other
incubating guide or don't seem to me to be true of TLPs in general.
Adding them here makes it look like there is new incubator policy that
snuck in the back door. Here are things I don't recall seeing
elsewhere:

"The code can be built in a reproducible way using widely available
standard tools." -- widely available?

"The project is open and honest about the quality of its code." --
Does anywhere else in the incubation documentation describe any sort
of quality disclosure procedure? What does this even mean -- what is
the scale?

"The project puts a high priority on backwards compatibility" -- Is
this mentioned anywhere else on the incubation webpages?

"The way in which contributors can be granted more rights such as
commit access or decision power is clearly documented" -- is this even
true for most TLPs? I spent some time looking at how big data TLPs
describe commit bit approvals, and most seem to be extremely vague in
describing what constitutes enough of a contribution to be granted the
bit.

"The project is independent from any corporate or organizational
influence." -- Didn't Stratos just get moved to the attic because its
main corporate backer stopped backing it? How many other TLPs are in
this same boat?

On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament  wrote:
> All,
>
> The Incubator PMC has received feedback from the board that changes may
> need to be made to the structure of our report.  Specifically, there is
> confusion from the board members over how podlings get classified.  There
> is also a request to increase and improve mentor feedback on podling
> reports.  Based on this input, I would like to propose the following
> changes to our report format.  I would like to try to implement this for
> the March report, if not before then.
>
> 1. Eliminate the podling summary section of the report.  It shouldn't be on
> the report manager to classify each podling.  We have begun leveraging a
> maturity model for podlings, while its not required to fulfill it serves as
> an equivalent to this section.  The list of podlings who failed to report
> shall remain.
>
> 2. Add a "Podling Maturity Assessment" to the individual podling reports.
> This would give a clear opportunity for each podling to describe how they
> are doing, perhaps compared to the maturity model or our classic categories.
>
> 3. Change the mentor sign off section to include a per-mentor comment.
> E.g. instead of the current:
>
>   [ ](podling) mentor1
>   [ ](podling) mentor2
>   [ ](podling) mentor3
>
> It would be:
>
>   [ ](podling) mentor1
>   Comments:
>   [ ](podling) mentor2
>   Comments:
>   [ ](podling) mentor3
>   Comments:
>
> And rename Shepherd/Mentor notes: to just "Shepherd notes:"
>
> Thoughts?
>
> John

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

Re: [VOTE] Impala 2.8.0 release candidate 1

[Jim Apple]

Thank you for the vote and the careful checking.

On Fri, Jan 20, 2017 at 6:38 PM, Justin Mclean  wrote:
> Hi,
>
> +1 (binding)
>
> I checked:
> - name includes incubating
> - signatures and hashed correct
> - disclaimer exists
> - LICENSE is OK
> - NOTICE Is OK (but year is wrong - please fix for next release)
> - All apache source files have ASF headers
> - No unexpected binary files
> - Don't have an environment set up to compile
>
> And thanks for fixing the issues brought up in the last review.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

[RESULT] [VOTE] Impala 2.8.0 release candidate 1

[Jim Apple]

The release has passed. The vote is:

+1 (binding):

Tom White
John D. Ament
Justin Mclean

+1 (non-binding):

Ian Dunlop

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

Re: [VOTE] Impala 2.8.0 release candidate 1

[Jim Apple]

Thank you, John! We now need only one more binding +1 for this release.

On Thu, Jan 19, 2017 at 6:30 PM, John D. Ament <johndam...@apache.org> wrote:
> +1
>
> On Thu, Jan 12, 2017 at 10:58 AM Jim Apple <jbap...@cloudera.com> wrote:
>
>> Impala 2.8.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/f873d0f82f0619d7d9a18440a74ea2961e63e4db0c5216a9d08b6517@%3Cdev.impala.apache.org%3E
>>
>>
>> http://mail-archives.apache.org/mod_mbox/impala-dev/201701.mbox/%3CCAC-pSX2TG7z6L8qWP9NjmonJfmUfTD_xxHs-YH44C--3aaPFUQ%40mail.gmail.com%3E
>>
>> The vote result thread is:
>>
>>
>> https://lists.apache.org/thread.html/856ea124d95b58f251f2737955bd70b1160d29d9c3dd960e1bb90cea@%3Cdev.impala.apache.org%3E
>>
>>  The artifacts for testing are at
>> <https://dist.apache.org/repos/dist/dev/incubator/impala/2.8.0/RC1/>.
>> That is git tag 2.8.0-rc1, tree hash
>> cc8de358d5c64778d171ad47aa6b513d437ac4b0, visible at
>> <
>> https://git-wip-us.apache.org/repos/asf?p=incubator-impala.git;a=tree;h=cc8de358d5c64778d171ad47aa6b513d437ac4b0
>> >.
>>
>> The KEYS are at <
>> 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.
>>
>> One of the binding votes from the PPMC was Tom White, who is one of
>> our mentors and an IPMC member.
>>
>> 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)
>>
>> -
>> 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] Impala 2.8.0 release candidate 1

[Jim Apple]

Since sending this, we have accumulated one non-binding vote, for a
total of one binding and one non-binding +1.

We still need two binding +1s to officially release.

On Thu, Jan 12, 2017 at 7:57 AM, Jim Apple <jbap...@cloudera.com> wrote:
> Impala 2.8.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/f873d0f82f0619d7d9a18440a74ea2961e63e4db0c5216a9d08b6517@%3Cdev.impala.apache.org%3E
>
> http://mail-archives.apache.org/mod_mbox/impala-dev/201701.mbox/%3CCAC-pSX2TG7z6L8qWP9NjmonJfmUfTD_xxHs-YH44C--3aaPFUQ%40mail.gmail.com%3E
>
> The vote result thread is:
>
> https://lists.apache.org/thread.html/856ea124d95b58f251f2737955bd70b1160d29d9c3dd960e1bb90cea@%3Cdev.impala.apache.org%3E
>
>  The artifacts for testing are at
> <https://dist.apache.org/repos/dist/dev/incubator/impala/2.8.0/RC1/>.
> That is git tag 2.8.0-rc1, tree hash
> cc8de358d5c64778d171ad47aa6b513d437ac4b0, visible at
> <https://git-wip-us.apache.org/repos/asf?p=incubator-impala.git;a=tree;h=cc8de358d5c64778d171ad47aa6b513d437ac4b0>.
>
> The KEYS are at 
> <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.
>
> One of the binding votes from the PPMC was Tom White, who is one of
> our mentors and an IPMC member.
>
> 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)

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

Re: [VOTE] Impala 2.8.0 release candidate 1

[Jim Apple]

Thank you for taking the time to check the artifact and vote.

> I didn't RAT check because I didn't have a rat.xml to use the script
> against and I wasn't sure how to create one.

bin/check-rat-report.py describes, on lines 28-30, how to run it,
including how to create rat.xml.

> Also the build uses a lot of bandwidth and takes quite some time. Might
> be worth pointing that out.

Good point. bin/bootstrap_build.sh takes 30-45 minutes on an ec2
c3xlarge instance, which voters can read about (in order to compare it
to their build machines) here:
https://aws.amazon.com/ec2/instance-types/

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

[VOTE] Impala 2.8.0 release candidate 1

[Jim Apple]

Impala 2.8.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/f873d0f82f0619d7d9a18440a74ea2961e63e4db0c5216a9d08b6517@%3Cdev.impala.apache.org%3E

http://mail-archives.apache.org/mod_mbox/impala-dev/201701.mbox/%3CCAC-pSX2TG7z6L8qWP9NjmonJfmUfTD_xxHs-YH44C--3aaPFUQ%40mail.gmail.com%3E

The vote result thread is:

https://lists.apache.org/thread.html/856ea124d95b58f251f2737955bd70b1160d29d9c3dd960e1bb90cea@%3Cdev.impala.apache.org%3E

 The artifacts for testing are at
.
That is git tag 2.8.0-rc1, tree hash
cc8de358d5c64778d171ad47aa6b513d437ac4b0, visible at
.

The KEYS are at .

To run RAT, follow the instructions in bin/check-rat-report.py. To
build, follow the instructions in bin/bootstrap_build.sh.

One of the binding votes from the PPMC was Tom White, who is one of
our mentors and an IPMC member.

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)

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

Re: Podling request steps have been updated

[Jim Apple]

I think it would be good to include that information on the page, perhaps in #8.

On Tue, Jan 3, 2017 at 3:25 AM, John D. Ament <johndam...@apache.org> wrote:
> 1. Anyone who is on a PMC.  I suspect the actual ACL is committers.  For
> instance, only members of the Incubator PMC can request repos within the
> incubator namespace.
> 2. LDAP.  As can be seen with the recent blogs migration, the trend is to
> move towards the LDAP credentials.  There are some services that are
> purposely for users who don't have ICLAs on file, e.g. bug trackers, hence
> why we have two different credentials in places.
>
> John
>
> On Tue, Jan 3, 2017 at 12:00 AM Jim Apple <jbap...@cloudera.com> wrote:
>
>> Step 8: who has access to reporeq.apache.org? Which of a person's
>> various apache un/pw pairs is to be used to login?
>>
>> On Tue, Dec 27, 2016 at 8:45 AM, John D. Ament <johndam...@apache.org>
>> wrote:
>> > All,
>> >
>> > I just got done editing the podling request page on the public website.
>> > Its based on areas that have changed recently.
>> >
>> > http://www.apache.org/dev/infra-contact#requesting-podling
>> >
>> > If everyone could take a look and give feedback and where there needs to
>> be
>> > more detail, I would appreciate it.
>> >
>> > Thanks,
>> >
>> > John
>>
>> -
>> 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] Drop incubating requirement of Maven artifacts

[Jim Apple]

> Though I feel the pain for existing projects such as Groovy and
> Freemarker, they are not typical.

What percentage of active incubating projects had "a track record of
high-quality releases before entering incubation"?

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

Re: Podling request steps have been updated

[Jim Apple]

Step 8: who has access to reporeq.apache.org? Which of a person's
various apache un/pw pairs is to be used to login?

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

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jim Apple]

> If a project is well setup and mature then it should do incubation in under 6 
> months, isn't?

Are you sure? What does the CDF of incubation time look like? How many
finish in 6 months?

Beam just graduated in 10 months, and several people on this list
seemed to call it a model of incubation:

http://incubator.apache.org/projects/beam.html

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

Re: Incoming Website Changes

[Jim Apple]

I would be delighted if the answer became cut and dry, modulo the fact
that if the cut-and-dry document became a laundry list for everyone's
favorite thing, that could move the goalposts pretty far for existing
podlings.

On Tue, Nov 29, 2016 at 6:49 PM, John D. Ament <johndam...@apache.org> wrote:
> So personally I think its great to get input from current podlings on a
> subject like this.
>
> I've made some proposed changes on a separate thread, but I almost think
> between your comments and Roman's comments... should we just drop the
> current "policy" document and make the guides the policy documents?  There
> shouldn't be opinions on what makes a functioning podling, it should be
> pretty cut and dry:
>
> - public discussions
> - apache licensed code
> - made successful releases without issues
> - using ASF infra resources
>
> On Sun, Nov 27, 2016 at 4:17 PM Jim Apple <jbap...@cloudera.com> wrote:
>
>> One way to make The Guide clearer is to make The Policy more accurate.
>> As it is, The Policy is contradicted in various other places on the
>> lists or in the guide or in practice, so as a person who is trying to
>> understand what incubation and graduation are really like, The Policy
>> doesn't read as "The Policy" but as a single unreliable source in a
>> tangled web of practice and theory that includes The Guide.
>>
>> Consider this single snippet from The Policy:
>>
>> "Release plans are developed and excuted[sic] in public by the community.
>> (requirement on minimum number of such releases?)
>> Note: incubator projects are not permitted to issue an official
>> Release. Test snapshots (however good the quality) and Release plans
>> are OK.
>> Engagement by the incubated community with the other ASF communities,
>> particularly infrastructure@ (this reflects my personal bias that
>> projects should pay an nfrastructure[sic] "tax")."
>>
>> Line 2 is a question. Who wrote it? What is the answer? Why is there
>> an embedded question in The Policy at all?
>>
>> Line 3 seems contrary to actual practice.
>>
>> Line 4 includes "my personal bias". Whose bias is that? Is that bias
>> now policy, or is it still just a personal opinion?
>>
>> On Sat, Nov 26, 2016 at 7:35 PM, John D. Ament <johndam...@apache.org>
>> wrote:
>> > On Sat, Nov 26, 2016 at 10:19 PM Roman Shaposhnik <ro...@shaposhnik.org>
>> > wrote:
>> >
>> >> On Sun, Nov 27, 2016 at 6:16 AM, John D. Ament <john.d.am...@gmail.com>
>> >> wrote:
>> >> > On Sat, Nov 26, 2016 at 6:04 PM Greg Stein <gst...@gmail.com> wrote:
>> >> >
>> >> >> On Sat, Nov 26, 2016 at 4:06 PM, John D. Ament <
>> johndam...@apache.org>
>> >> >> wrote:
>> >> >>
>> >> >> > On Sat, Nov 26, 2016 at 4:57 PM Greg Stein <gst...@gmail.com>
>> wrote:
>> >> >> >
>> >> >> > > On Fri, Nov 25, 2016 at 8:26 AM, John D. Ament <
>> >> johndam...@apache.org>
>> >> >> > > wrote:
>> >> >> > > >...
>> >> >> > >
>> >> >> > > > Graduation Guide
>> >> http://incubator.apache.org/guides/graduation.html
>> >> >> > > >
>> >> >> > > > Added a link to the Maturity Model as a step to follow for
>> >> >> graduation.
>> >> >> > > >
>> >> >> > >
>> >> >> > > There has been past controversy on including that as a graduation
>> >> step.
>> >> >> > I'm
>> >> >> > > not clear that was a proper addition. Every discussion has said
>> >> that it
>> >> >> > can
>> >> >> > > be used as a *guide*, rather than as a checklist.
>> >> >> >
>> >> >> > I argued myself into adding this one.  While I don't disagree with
>> >> your
>> >> >> > perspective, every time a podling graduates it comes up from board
>> >> >> > members.
>> >> >>
>> >> >>
>> >> >> Some Directors != The Board
>> >> >>
>> >> >> The Board has never required the IPMC to use the APMM as a
>> requirement
>> >> for
>> >> >> graduation. And, I don't recall the IPMC making that requirement
>> either.
>> >> >>
&

Re: Github tagging, was Re: [VOTE] Release Apache Joshua 6.1 RC#2

[Jim Apple]

> You can just make the release on a branch rather than in a fork/mirror.

This is what Impala did and Github still happily treats those
off-master-branch tags as "releases".

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

Re: Github tagging, was Re: [VOTE] Release Apache Joshua 6.1 RC#2

[Jim Apple]

I am not subscribed to that list.

Can you elaborate on the process of moving release votes to a
different mirror/fork? Our votes, of course, happen on the mailing
list. The tagging happens in the official git repo. We do not have any
oficially-recognized-yet-unofficial mirrors, and the idea that we
would make a github mirror for the sole purpose of tagging commits
that Github would then consider releases of
apache-impala-incubating-mirror-only-for-votes seems byzantine.

On Tue, Nov 29, 2016 at 11:44 AM, John D. Ament <johndam...@apache.org> wrote:
> IMHO, the tags on github are not formal releases.  The fact that github
> marks it as a release is just an unfortunate side effect of how github
> works.  So its not a violation of ASF release process.  May be good to
> start a discussion on legal-discuss.  Let me know if you're subscribed, we
> can talk more there.
>
> Some projects have handled this by moving release votes to a different
> (mirror/fork) of the project.  I don't see anything wrong with taking that
> approach.
>
> John
>
> On Tue, Nov 29, 2016 at 2:41 PM Jim Apple <jbap...@cloudera.com> wrote:
>
>> > Also the 6.1 release has already been tagged and it available for public
>> download on github [4]  before this vote is finished. This is IMO against
>> Apache release policy [3] please remove.
>> > 3. http://www.apache.org/dev/release.html#what
>> > 4. https://github.com/apache/incubator-joshua/releases
>>
>> This interpretation by Github (that tags are public releases) is
>> happening to Impala without our knowledge or consent. Does this make
>> it against Apache release policy to tag release candidates?
>>
>> -
>> 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

Github tagging, was Re: [VOTE] Release Apache Joshua 6.1 RC#2

[Jim Apple]

> Also the 6.1 release has already been tagged and it available for public 
> download on github [4]  before this vote is finished. This is IMO against 
> Apache release policy [3] please remove.
> 3. http://www.apache.org/dev/release.html#what
> 4. https://github.com/apache/incubator-joshua/releases

This interpretation by Github (that tags are public releases) is
happening to Impala without our knowledge or consent. Does this make
it against Apache release policy to tag release candidates?

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

Re: Incoming Website Changes

[Jim Apple]

One way to make The Guide clearer is to make The Policy more accurate.
As it is, The Policy is contradicted in various other places on the
lists or in the guide or in practice, so as a person who is trying to
understand what incubation and graduation are really like, The Policy
doesn't read as "The Policy" but as a single unreliable source in a
tangled web of practice and theory that includes The Guide.

Consider this single snippet from The Policy:

"Release plans are developed and excuted[sic] in public by the community.
(requirement on minimum number of such releases?)
Note: incubator projects are not permitted to issue an official
Release. Test snapshots (however good the quality) and Release plans
are OK.
Engagement by the incubated community with the other ASF communities,
particularly infrastructure@ (this reflects my personal bias that
projects should pay an nfrastructure[sic] "tax")."

Line 2 is a question. Who wrote it? What is the answer? Why is there
an embedded question in The Policy at all?

Line 3 seems contrary to actual practice.

Line 4 includes "my personal bias". Whose bias is that? Is that bias
now policy, or is it still just a personal opinion?

On Sat, Nov 26, 2016 at 7:35 PM, John D. Ament  wrote:
> On Sat, Nov 26, 2016 at 10:19 PM Roman Shaposhnik 
> wrote:
>
>> On Sun, Nov 27, 2016 at 6:16 AM, John D. Ament 
>> wrote:
>> > On Sat, Nov 26, 2016 at 6:04 PM Greg Stein  wrote:
>> >
>> >> On Sat, Nov 26, 2016 at 4:06 PM, John D. Ament 
>> >> wrote:
>> >>
>> >> > On Sat, Nov 26, 2016 at 4:57 PM Greg Stein  wrote:
>> >> >
>> >> > > On Fri, Nov 25, 2016 at 8:26 AM, John D. Ament <
>> johndam...@apache.org>
>> >> > > wrote:
>> >> > > >...
>> >> > >
>> >> > > > Graduation Guide
>> http://incubator.apache.org/guides/graduation.html
>> >> > > >
>> >> > > > Added a link to the Maturity Model as a step to follow for
>> >> graduation.
>> >> > > >
>> >> > >
>> >> > > There has been past controversy on including that as a graduation
>> step.
>> >> > I'm
>> >> > > not clear that was a proper addition. Every discussion has said
>> that it
>> >> > can
>> >> > > be used as a *guide*, rather than as a checklist.
>> >> >
>> >> > I argued myself into adding this one.  While I don't disagree with
>> your
>> >> > perspective, every time a podling graduates it comes up from board
>> >> > members.
>> >>
>> >>
>> >> Some Directors != The Board
>> >>
>> >> The Board has never required the IPMC to use the APMM as a requirement
>> for
>> >> graduation. And, I don't recall the IPMC making that requirement either.
>> >>
>> >>
>> >> >   The IPMC did not prepare the maturity model, yet somehow it
>> >> > applies to podlings planning to graduate.
>> >> >
>> >>
>> >> Says who?
>> >>
>> >>
>> >> > I'll point out that the page itself states this is only a guide, not a
>> >> >
>> >>
>> >> On graduation.html, you list "Complete the Apache Project Maturity
>> Model"
>> >> as one of the preparation steps. That does not sound like a guide.
>> >>
>> >> policy.  So I don't think we've changed Incubator policy by adding a
>> link.
>> >> >
>> >>
>> >> By listing it like that on the graduation page, it is de facto policy.
>> >>
>> >>
>> >> > I could see it being stated as more of "compare the podlings actions
>> and
>> >> > behaviors against the maturity model.  I could also see it moving into
>> >> the
>> >> > "Other Issues" section of the guide instead of the checklist section.
>> >> >
>> >> > Thoughts?
>> >> >
>> >>
>> >> Personally, I'd be fine with the link under "Other Issues". Something
>> like
>> >> "You may find the APMM a useful guide, to look at different factors in
>> your
>> >> podling's community."  ( on phrasing)
>> >>
>> >>
>> > I think at this point, we're just arguing semantics.  I've drafted the
>> > following for the other issues section.  I've removed it from the
>> checklist
>> > section.
>>
>> The feedback I consistently get from all the podlings I mentor is that
>> it would be really great if our documentation clearly separated policy
>> from advice. In fact, having two separate documents is what they
>> all seem to have in mind. Today we have guides which are pretty verbose
>> and mix the two.
>>
>
> I've gotten the same type of questions.  The problem is that this line
> already exists in the graduation "guide"
>
> This is just a guide. Policy is stated here. (where here is a link to the
> actual policy document)
>
> Anyway you can think to make it clearer?
>
>
>
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

Re: How to denote unusual copyright circumstances, was Re: [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

Thanks, Stian - I'll fix this squeasel notification issue in LICENSE.

I'll talk to the Impala community about whether this is "important
enough" or "just an innocent embedded dependency".

On Thu, Oct 6, 2016 at 2:48 AM, Stian Soiland-Reyes  wrote:
> On 4 October 2016 at 20:21, Henry Robinson  wrote:
>>> > After further consideration, I have a patch in flight to fix that. It
>>> > is a compiled source file.
>>> >
>>> > However, my question was intended to be broader. As Henry notes, there
>>> > are some files that are Copyright Cloudera that were not part of the
>>> > SGA. How shall we annotate those to let future IPMC release voters
>>> > understand that the files are intentionally annotated the way they
>>> > are?
>>> >
>>>
>>> Is Cloudera willing to donate them?
>>>
>>
>> Perhaps - but these files belong to their own, separate projects, distinct
>> from Apache Impala, but are a bit too small to support a community and
>> therefore aren't good candidates for incubation.
>>
>> Isn't the right way to address this to make a note in LICENSE.txt? That's
>> what we do for compatibly-licensed files which have a non-ASF copyright
>> holder.
>
> They can still be donated to Impala with another Software Grant,
> however you would need that both from Cloudera Inc. and Sergey Lyubka
> (CTO of Cloudera) given the joint (c) at
> https://github.com/apache/incubator-impala/blob/master/be/src/thirdparty/squeasel/squeasel.c
>
> (I guess this code predates Sergey's co-founding of the Cloudera corporation)
>
>
> Somehow Cloudera's (c) is not noted in
> https://github.com/apache/incubator-impala/blob/master/be/src/thirdparty/squeasel/LICENSE
> and neither are listed in the top-level LICENSE - so that is what
> needs sorting out.
>
>
> Many ASF projects 'adapt' such free-hanging "bits and bobs code" under
> their umbrella - sometimes such code can get a "new life" - that's
> after all part of what open source is about.
>
>
> If they are in a SG it means they would be covered by the ASF license.
> But there should not be a big problem with them being mentioned in the
> LICENSE file with the compatible MIT license - at least if it's likely
> to be "dormant" code that won't evolve much under Apache. The only
> effect is that some of the protections of the ASF license then won't
> clearly apply - e.g. protection against patent litigation.
>
> I guess the main principle is that the 'main' project code should be
> covered by the software grant - having remnants from the same
> copyright holder that is not part of the software grant should
> understandably be a yellow flag.
>
>
> I think as a project (with mentors help) Impala will have to review if
> the code in question is "important enough" (e.g. contains a patented
> algorithm, or is core to how Impala works) to pursue additional
> Software Grant (or license change) from upstream or if it's just an
> innocent embedded dependency that can be noted it in the top level
> LICENSE.
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

[RESULT] [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

The vote passes with:

+1's (all binding)

Carl Steinbach
Justin Mclean
Tom White (one of Impala's mentors, see the PPMC vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-impala-dev/201609.mbox/%3ccaf-wd4sf4wrnjn6mjjfj7t07feuwe-kamdrmjmava1jg5-w...@mail.gmail.com%3E

or

https://lists.apache.org/thread.html/56d822c7bdda9229ff8bb8e986862f7e9f01729ebccdc278f5ae812f@%3Cdev.impala.apache.org%3E)

No other votes.

Thank you, everyone!

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

Re: How to denote unusual copyright circumstances, was Re: [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

After further consideration, I have a patch in flight to fix that. It
is a compiled source file.

However, my question was intended to be broader. As Henry notes, there
are some files that are Copyright Cloudera that were not part of the
SGA. How shall we annotate those to let future IPMC release voters
understand that the files are intentionally annotated the way they
are?

On Fri, Sep 30, 2016 at 4:41 PM, Justin Mclean  wrote:
> Hi,
>
>> This (an another couple of things in your review) might stay the same
>> in the next release, but be allowed (as I read it) under the licensing
>> rules.
>
> As long as it not compile source files it should be fine. It's not not binary 
> files i.e. jpg and pngs and the like are ok. What does contain the file?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

How to denote unusual copyright circumstances, was Re: [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

Thank you for the review, Justin. I have changed the subject so as not
to clutter the VOTE thread.

> - One possible binary file that shouldn’t be in the source release? [15] (not 
> sure what this is)

This (an another couple of things in your review) might stay the same
in the next release, but be allowed (as I read it) under the licensing
rules:

http://www.apache.org/legal/src-headers.html

How should we annotate those to clarify our beliefs to voters and reviewers?

Another example of a confusing thing that might stay the same is the
license and copyright on

> 9 ./be/src/thirdparty/squeasel/squeasel.?

This might not have been part of the SGA; I'll have to check. Assuming
for the purposes of this question that it was not part of the software
grant, how can we annotate that to clarify?

Thanks,
Jim

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

Re: [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

Hi Carl - is this a +1 to the release or to Tom's note about
Strata/Hadoop World?

On Thu, Sep 29, 2016 at 9:11 AM, Carl Steinbach <c...@apache.org> wrote:
> +1
>
>
> On Thu, Sep 29, 2016 at 8:22 AM, Todd Lipcon <t...@cloudera.com> wrote:
>
>> 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
>>

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

Re: [VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

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/530925a9689157059d6de31a4e3f97587154defd13328930112784a4@%3Cdev.impala.apache.org%3E
>
> The result of the vote:
>
> https://lists.apache.org/thread.html/477c2e59c44db5c19177b166fc8c285d940533963106cdf4c7f2ad6a@%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

[VOTE] Impala 2.7.0 release candidate 3

[Jim Apple]

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/530925a9689157059d6de31a4e3f97587154defd13328930112784a4@%3Cdev.impala.apache.org%3E

The result of the vote:

https://lists.apache.org/thread.html/477c2e59c44db5c19177b166fc8c285d940533963106cdf4c7f2ad6a@%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

How to add an incubator report to an "Immutable Page"?

[Jim Apple]

I'd like to add our incubator report for Impala[0] to the report wiki
page[1]. However, the header of that page informs me, when logged in
with my username "JimApple" that it is an "Immutable Page".

What is the procedure for getting append access to that page? I see
that sometimes people ask on this list[2] and I see that some users
have been able to append already[3], so I suspect that the page is not
immutable to everyone.

0: 
http://mail-archives.apache.org/mod_mbox/incubator-impala-dev/201607.mbox/%3CCAC-pSX1MVPGnTXy-fkXd3DdXz-U%3DFrnB4kAejyi0wv9GzsRUfw%40mail.gmail.com%3E

1: http://wiki.apache.org/incubator/August2016

2: 
http://mail-archives.apache.org/mod_mbox/incubator-general/201607.mbox/%3CCANPnQjd7jRiNSBCgpgUaPrBA1NKq_u9_3Vw5aiZKkiMtDeR44A%40mail.gmail.com%3E

3: https://wiki.apache.org/incubator/August2016?action=info

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