Re: [VOTE] Accept Impala into the Apache Incubator

[Alex Karasulu]

+1 (binding)

On Wed, Nov 25, 2015 at 10:44 AM, Tom White  wrote:

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

Re: [VOTE] Accept Kudu into the Apache Incubator

[Alex Karasulu]

+1 (binding)

On Tue, Nov 24, 2015 at 10:08 PM, Arvind Prabhakar 
wrote:

> +1 (binding)
>
> Regards,
> Arvind Prabhakar
>
> On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon  wrote:
>
> > Hi all,
> >
> > Discussion on the [DISCUSS] thread seems to have wound down, so I'd like
> to
> > call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal is
> > pasted below and also available on the wiki at:
> > https://wiki.apache.org/incubator/KuduProposal
> >
> > The proposal is unchanged since the original version, except for the
> > addition of Carl Steinbach as a Mentor.
> >
> > Please cast your votes:
> >
> > [] +1, accept Kudu into the Incubator
> > [] +/-0, positive/negative non-counted expression of feelings
> > [] -1, do not accept Kudu into the incubator (please state reasoning)
> >
> > Given the US holiday this week, I imagine many folks are traveling or
> > otherwise offline. So, let's run the vote for a full week rather than the
> > traditional 72 hours. Unless the IPMC objects to the extended voting
> > period, the vote will close on Tues, Dec 1st at noon PST.
> >
> > Thanks
> > -Todd
> > -
> >
> > = Kudu Proposal =
> >
> > == Abstract ==
> >
> > Kudu is a distributed columnar storage engine built for the Apache Hadoop
> > ecosystem.
> >
> > == Proposal ==
> >
> > Kudu is an open source storage engine for structured data which supports
> > low-latency random access together with efficient analytical access
> > patterns. Kudu distributes data using horizontal partitioning and
> > replicates each partition using Raft consensus, providing low
> > mean-time-to-recovery and low tail latencies. Kudu is designed within the
> > context of the Apache Hadoop ecosystem and supports many integrations
> with
> > other data analytics projects both inside and outside of the Apache
> > Software Foundation.
> >
> >
> >
> > We propose to incubate Kudu as a project of the Apache Software
> Foundation.
> >
> > == Background ==
> >
> > In recent years, explosive growth in the amount of data being generated
> and
> > captured by enterprises has resulted in the rapid adoption of open source
> > technology which is able to store massive data sets at scale and at low
> > cost. In particular, the Apache Hadoop ecosystem has become a focal point
> > for such “big data” workloads, because many traditional open source
> > database systems have lagged in offering a scalable alternative.
> >
> >
> >
> > Structured storage in the Hadoop ecosystem has typically been achieved in
> > two ways: for static data sets, data is typically stored on Apache HDFS
> > using binary data formats such as Apache Avro or Apache Parquet. However,
> > neither HDFS nor these formats has any provision for updating individual
> > records, or for efficient random access. Mutable data sets are typically
> > stored in semi-structured stores such as Apache HBase or Apache
> Cassandra.
> > These systems allow for low-latency record-level reads and writes, but
> lag
> > far behind the static file formats in terms of sequential read throughput
> > for applications such as SQL-based analytics or machine learning.
> >
> >
> >
> > Kudu is a new storage system designed and implemented from the ground up
> to
> > fill this gap between high-throughput sequential-access storage systems
> > such as HDFS and low-latency random-access systems such as HBase or
> > Cassandra. While these existing systems continue to hold advantages in
> some
> > situations, Kudu offers a “happy medium” alternative that can
> dramatically
> > simplify the architecture of many common workloads. In particular, Kudu
> > offers a simple API for row-level inserts, updates, and deletes, while
> > providing table scans at throughputs similar to Parquet, a commonly-used
> > columnar format for static data.
> >
> >
> >
> > More information on Kudu can be found at the existing open source project
> > website: http://getkudu.io and in particular in the Kudu white-paper
> PDF:
> > http://getkudu.io/kudu.pdf from which the above was excerpted.
> >
> > == Rationale ==
> >
> > As described above, Kudu fills an important gap in the open source
> storage
> > ecosystem. After our initial open source project release in September
> 2015,
> > we have seen a great amount of interest across a diverse set of users and
> > companies. We believe that, as a storage system, it is critical to build
> an
> > equally diverse set of contributors in the development community. Our
> > experiences as committers and PMC members on other Apache projects have
> > taught us the value of diverse communities in ensuring both longevity and
> > high quality for such foundational systems.
> >
> > == Initial Goals ==
> >
> >  * Move the existing codebase, website, documentation, and mailing lists
> to
> > Apache-hosted infrastructure
> >  * Work with the infrastructure team to implement and approve our code
> > review, build, and testing workflows in the context of the ASF
> >  * 

Re: [DISCUSS] Eagle incubator proposal

[Alex Karasulu]

Hi Arun,

Eagle sounds very promising. I just had a discussion with someone about
this exact need. I do however agree with Greg on the name. As far as I can
see, besides the name, your weakest point is the all eBay employed team.
It's not a blocker and can be fixed during incubation. Good luck to you.

Alex


On Tue, Oct 20, 2015 at 5:51 PM, Manoharan, Arun 
wrote:

> Hi Greg,
>
> Thank you for reviewing the proposal.
>
> Originally we thought Eagle might be trademarked by someone already but I
> went thru eBay legal team to get the clearance for the name to be used. We
> will look into it again to see if there will be potential problems.
>
> Thanks,
> Arun
>
> On 10/20/15, 1:52 AM, "Greg Stein"  wrote:
>
> >Hey there, Arun! ... I have no commentary on the proposal itself, as it
> >looks like a great proposal. I would suggest being a bit wary of the name,
> >as "Eagle" is a *very* popular PCB design program.
> >
> >On Mon, Oct 19, 2015 at 10:33 AM, Manoharan, Arun 
> >wrote:
> >
> >> Hello Everyone,
> >>
> >> My name is Arun Manoharan. Currently a product manager in the Analytics
> >> platform team at eBay Inc.
> >>
> >> I would like to start a discussion on Eagle and its joining the ASF as
> >>an
> >> incubation project.
> >>
> >> Eagle is a Monitoring solution for Hadoop to instantly identify access
> >>to
> >> sensitive data, recognize attacks, malicious activities and take
> >>actions in
> >> real time. Eagle supports a wide variety of policies on HDFS data and
> >>Hive.
> >> Eagle also provides machine learning models for detecting anomalous user
> >> behavior in Hadoop.
> >>
> >> The proposal is available on the wiki here:
> >> https://wiki.apache.org/incubator/EagleProposal
> >>
> >> The text of the proposal is also available at the end of this email.
> >>
> >> Thanks for your time and help.
> >>
> >> Thanks,
> >> Arun
> >>
> >> 
> >>
> >> Eagle
> >>
> >> Abstract
> >> Eagle is an Open Source Monitoring solution for Hadoop to instantly
> >> identify access to sensitive data, recognize attacks, malicious
> >>activities
> >> in hadoop and take actions.
> >>
> >> Proposal
> >> Eagle audits access to HDFS files, Hive and HBase tables in real time,
> >> enforces policies defined on sensitive data access and alerts or blocks
> >> user¹s access to that sensitive data in real time. Eagle also creates
> >>user
> >> profiles based on the typical access behaviour for HDFS and Hive and
> >>sends
> >> alerts when anomalous behaviour is detected. Eagle can also import
> >> sensitive data information classified by external classification
> >>engines to
> >> help define its policies.
> >>
> >> Overview of Eagle
> >> Eagle has 3 main parts.
> >> 1.Data collection and storage - Eagle collects data from various hadoop
> >> logs in real time using Kafka/Yarn API and uses HDFS and HBase for
> >>storage.
> >> 2.Data processing and policy engine - Eagle allows users to create
> >> policies based on various metadata properties on HDFS, Hive and HBase
> >>data.
> >> 3.Eagle services - Eagle services include policy manager, query service
> >> and the visualization component. Eagle provides intuitive user
> >>interface to
> >> administer Eagle and an alert dashboard to respond to real time alerts.
> >>
> >> Data Collection and Storage:
> >> Eagle provides programming API for extending Eagle to integrate any data
> >> source into Eagle policy evaluation framework. For example, Eagle hdfs
> >> audit monitoring collects data from Kafka which is populated from
> >>namenode
> >> log4j appender or from logstash agent. Eagle hive monitoring collects
> >>hive
> >> query logs from running job through YARN API, which is designed to be
> >> scalable and fault-tolerant. Eagle uses HBase as storage for storing
> >> metadata and metrics data, and also supports relational database through
> >> configuration change.
> >>
> >> Data Processing and Policy Engine:
> >> Processing Engine: Eagle provides stream processing API which is an
> >> abstraction of Apache Storm. It can also be extended to other streaming
> >> engines. This abstraction allows developers to assemble data
> >> transformation, filtering, external data join etc. without physically
> >>bound
> >> to a specific streaming platform. Eagle streaming API allows developers
> >>to
> >> easily integrate business logic with Eagle policy engine and internally
> >> Eagle framework compiles business logic execution DAG into program
> >> primitives of underlying stream infrastructure e.g. Apache Storm. For
> >> example, Eagle HDFS monitoring transforms audit log from Namenode to
> >>object
> >> and joins sensitivity metadata, security zone metadata which are
> >>generated
> >> from external programs or configured by user. Eagle hive monitoring
> >>filters
> >> running jobs to get hive query string and parses query string into
> >>object
> >> and then joins sensitivity metadata.
> >> Alerting Framework: Eagle Alert Framework 

Re: [VOTE] Accept Horn into the ASF incubator

[Alex Karasulu]

+1 (binding)

On Tue, Sep 1, 2015 at 2:47 PM, Bertrand Delacretaz 
wrote:

> On Tue, Sep 1, 2015 at 1:13 AM, Edward J. Yoon 
> wrote:
> > ..I would like to call a vote to accept Horn, as a new Apache Incubator
> > project...
>
> +1
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best Regards,
-- Alex

Re: [VOTE] Accept Brooklyn into the Incubator

[Alex Karasulu]

+1


On Mon, Apr 28, 2014 at 8:05 PM, Andrei Savu savu.and...@gmail.com wrote:

 +1

 -- Andrei Savu


 On Mon, Apr 28, 2014 at 6:49 AM, Chip Childers chipchild...@apache.org
 wrote:

  Based on the previous discussion of accepting Brooklyn into the Apache
  Incubator as a podling, I'd like to call a vote for this now.
 
  [ ] +1 Accept Brooklyn into the Incubator
  [ ] +/-0 Indifferent to the acceptance of Brooklyn
  [ ] -1 Do not accept Brooklyn because...
 
  The proposal can be found here:
  https://wiki.apache.org/incubator/BrooklynProposal
 
  (For the IPMC members, I believe we typically lock the proposal page
  making it read-only during the voting.  I'm not sure how to do this, or
  if I'm remembering correctly.  Can someone clarify?  I'll watch that
  page to be sure there are no changes during the voting process.)
 
  -chip
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduation of Apache Spark from the Incubator

[Alex Karasulu]

+1 (binding)


On Tue, Feb 11, 2014 at 6:50 AM, Mosharaf Chowdhury mosharafka...@gmail.com
 wrote:

 +1

 --
 Mosharaf Chowdhury
 http://www.mosharaf.com/


 On Mon, Feb 10, 2014 at 8:45 PM, Matei Zaharia matei.zaha...@gmail.com
 wrote:

  +1
 
  On Feb 10, 2014, at 8:27 PM, Chris Mattmann mattm...@apache.org wrote:
 
   Hi Everyone,
  
   This is a new VOTE to decide if Apache Spark should graduate
   from the Incubator. Please VOTE on the resolution pasted below
   the ballot. I'll leave this VOTE open for at least 72 hours.
  
   Thanks!
  
   [ ] +1 Graduate Apache Spark from the Incubator.
   [ ] +0 Don't care.
   [ ] -1 Don't graduate Apache Spark from the Incubator because..
  
   Here is my +1 binding for graduation.
  
   Cheers,
   Chris
  
    snip
  
   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software, for distribution at no charge to the
   public, related to fast and flexible large-scale data analysis
   on clusters.
  
   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Spark Project, be
   and hereby is established pursuant to Bylaws of the Foundation;
   and be it further
  
   RESOLVED, that the Apache Spark Project be and hereby is
   responsible for the creation and maintenance of software
   related to fast and flexible large-scale data analysis
   on clusters; and be it further RESOLVED, that the office
   of Vice President, Apache Spark 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 Spark
   Project, and to have primary responsibility for management
   of the projects within the scope of responsibility
   of the Apache Spark 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 Spark Project:
  
   * Mosharaf Chowdhury mosha...@apache.org
   * Jason Dai jason...@apache.org
   * Tathagata Das t...@apache.org
   * Ankur Dave ankurd...@apache.org
   * Aaron Davidson a...@apache.org
   * Thomas Dudziak to...@apache.org
   * Robert Evans bo...@apache.org
   * Thomas Graves tgra...@apache.org
   * Andy Konwinski and...@apache.org
   * Stephen Haberman steph...@apache.org
   * Mark Hamstra markhams...@apache.org
   * Shane Huang shane_hu...@apache.org
   * Ryan LeCompte ryanlecom...@apache.org
   * Haoyuan Li haoy...@apache.org
   * Sean McNamara mcnam...@apache.org
   * Mridul Muralidharam mridul...@apache.org
   * Kay Ousterhout kayousterh...@apache.org
   * Nick Pentreath mln...@apache.org
   * Imran Rashid iras...@apache.org
   * Charles Reiss wog...@apache.org
   * Josh Rosen joshro...@apache.org
   * Prashant Sharma prash...@apache.org
   * Ram Sriharsha har...@apache.org
   * Shivaram Venkataraman shiva...@apache.org
   * Patrick Wendell pwend...@apache.org
   * Andrew Xia xiajunl...@apache.org
   * Reynold Xin r...@apache.org
   * Matei Zaharia ma...@apache.org
  
   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matei Zaharia be
   appointed to the office of Vice President, Apache Spark, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification, or
   until a successor is appointed; and be it further
  
   RESOLVED, that the Apache Spark Project be and hereby is
   tasked with the migration and rationalization of the Apache
   Incubator Spark podling; and be it further
  
   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Spark podling encumbered upon the Apache Incubator
   Project are hereafter discharged.
  
   
  
  
  
 
 




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduation of Apache Spark from the Incubator

[Alex Karasulu]

I agree with Ted that these minor issues can be ironed out especially if
the community is open to constructive criticism as these folks are. IMHO
the health of the community is much more important than minor insignificant
shortcomings. Social development is changing many things and causing
incongruities in the way we're used to working: we need to adapt to them
instead of penalizing podlings. Many projects even years after graduation
stumble occasionally but eventually find their way.

With that said I also hope some of the mentors continue on with the
community's PMC after graduation.

+1 (binding)

-Alex



On Fri, Feb 7, 2014 at 9:08 AM, Andrew Hart ah...@apache.org wrote:

 +1 (binding)

 --Andrew

 On 2/6/14 10:51 PM, Sebastian Schelter wrote:

 +1 (binding)

 Fully agree with Ted's view on the Spark community.

 On 02/07/2014 06:32 AM, Ted Dunning wrote:

 +1 (binding)

 These wrinkles are not as big as they appear.  For instance, the issue
 with some committers not noticing that their accounts were live is actually
 due to a better submission and review process than most tlp's exhibit.

 The spark community has more of the apache spirit in it than most
 incubator projects lately. Notably they also take feedback about how to
 tune their processes very well.

 Sent from my iPhone

 On Feb 7, 2014, at 4:05, David Nalley da...@gnsa.us wrote:


 Hope this helps to ease your concern about Spark podling readiness to
 become TLP.



 I am a bit conflicted. Part of me is inclined to join Craig, Sebb, and
 Bertand and issue a -1. At the same time, there exist many +1s here
 from folks that I respect and trust, including the mentors of the
 podling; and I think they are far better placed than me to judge the
 true state of the podling.

 The part that disturbs me is that after the vote passed in the
 community, and came to the IPMC a mentor is still having to remind
 folks that things like strategy and roadmap discussions need to happen
 on the mailing list. That's a pretty foundational concept in my mind
 for an Apache project.

 The missing account issues are somewhat troubling, but also not really
 within the purview of the podling to fix either; though I find it odd
 that people committed to the podling (and many initial committers)
 haven't asked for their Apache account or needed to use it.

 Love to hear opinions, even if they are stating that I am meddling or
 crazy :)

 --David

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


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



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



 --
 Andrew F. Hart
 http://people.apache.org/~ahart


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




-- 
Best Regards,
-- Alex

Re: Apache project bylaws

[Alex Karasulu]

On Wed, Oct 2, 2013 at 11:58 PM, Marvin Humphrey mar...@rectangular.comwrote:

 On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote:
  I would like to propose a rewrite of [1] by borrowing heavily from [2]
 but
  making sure to emphasize that projects are allowed to have different
 rules
  for all of them (or is the code-commit veto required for all projects).
  Any objections to me trying to do that?

 Rather than a rewrite, I suggest proposing small, incremental, reversible
 changes.  Governance is easy to mess up.

 It would be so nice if we could write unit tests for governance docs to
 make
 sure that as they evolve they still solve all the old problems they were
 intended to address.


That's a really interesting perspective: governance rules as code, that can
be unit tested. Heh I like that.

-- 
Regards,
-- Alex

Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)

[Alex Karasulu]

+1 (binding)


On Tue, Oct 1, 2013 at 6:03 PM, Raminder Singh rsand...@gmail.com wrote:

 +1 (non-binding).

 Thanks
 Raminder

 On Sep 30, 2013, at 3:27 PM, Dave snoopd...@gmail.com wrote:

  I would like to call for a new vote on Usergrid, a multi-tenant
  Backend-as-a-Service stack for web  mobile applications based on RESTful
  APIs, as an Apache Incubator podling.
 
  The original proposal has been revised to name Dave Johnson as the
 Champion
  and to bring Jim Jagielski back in as a Mentor and to add John Lewis
  Mcgibbney as a Mentor. I also add some text to the Initial Committers
  section and a new Interested Contributors section to list those who have
  expressed interest in contributing.
 
  Here is a link to the revised proposal:
https://wiki.apache.org/incubator/UsergridProposal
 
  It is also pasted below:
 
 
  = Usergrid Proposal =
 
  == Abstract ==
 
  Usergrid is a multi-tenant Backend-as-a-Service stack for web  mobile
  applications, based on RESTful APIs.
 
 
  == Proposal ==
 
  Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”)
  composed of an integrated distributed NoSQL database, application layer
 and
  client tier with SDKs for developers looking to rapidly build web and/or
  mobile applications. It provides elementary services (user registration 
  management, data storage, file storage, queues) and retrieval features
  (full text search, geolocation search, joins) to power common app
 features.
 
  It is a multi-tenant system designed for deployment to public cloud
  environments (such as Amazon Web Services, Rackspace, etc.) or to run on
  traditional server infrastructures so that anyone can run their own
 private
  BaaS deployment.
 
  For architects and back-end teams, it aims to provide a distributed,
 easily
  extendable, operationally predictable and highly scalable solution.
  For front-end developers, it aims to simplify the development process by
  enabling them to rapidly build and operate mobile and web applications
  without requiring backend expertise.
 
 
  == Background ==
 
  Developing web or mobile applications obviously necessitates writing and
  maintaining more than just front-end code. Even simple applications can
  implicitly rely on server code being run to store users, perform database
  queries, serve images and video files, etc. Developing and maintaining
 such
  backend services requires skills not always available or expected of app
  development teams. Beyond that, the proliferation of apps inside of
  companies leads to the creation of many different, ad-hoc, unequally
  maintained backend solutions created by employees and contractors alike
 and
  hosted on a wide variety of environments. This is causing poor resource
  usage, operational issues, as well as security, privacy  compliance
  concerns.
 
  In response to this problem, companies have long tried to standardize
 their
  server-side stack or unify them behind an ESB or API strategy.
  Backends-as-a-Service follow a similar approach but their unique
  characteristic is strongly tying  1) a persistence tier (typically a
  database), 2) a server-side application tier delivering a set of common
  services and 3) a set of client-side application interface mechanisms.
 For
  example, a BaaS could package 1) MongoDB with 2) a node.js application
 that
  offers access through 3) WebSockets. In the case of Usergrid, the
 trifecta
  is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API.
 
  The Backend-as-a-Service approach has steadily gained popularity in the
  last few years with cloud providers such Parse.com, Stackmob.com and
  Kinvey.com, each operating tens of thousands of apps for tens of
 thousands
  of developers. The trend has already reached large organizations as well,
  with global companies such as Korea Telecom internally building a
  privately-run BaaS platform. But so far, there have been limited options
  for developers that want a non-proprietary, open option for hosting and
  providing these services themselves, or for enterprise and government
 users
  who want to provide these capabilities from their own data centers,
  especially on a very large scale.
 
 
  == Rationale ==
 
  The issue this proposal deals with is implicit in the name.
  Backend-as-a-Service platforms are usually offered solely as proprietary
  cloud services. They are typically closed sourced, hosted on public
 clouds,
  and require subscription payment. Usergrid opens the playing field, by
  making a fully-featured BaaS platform freely available to all. This
  includes developers that previously could not afford them, such as mobile
  enthusiasts, small boutiques, and cost-sensitive startups. This also
  includes large companies that benefit from a reference implementation
 they
  can deploy in trust, or extend to their needs without losing time writing
  less-vetted, less-performant boilerplate functionality.
 
  Usergrid has been open source since 2011 and has grown as an 

Re: The podling initial committers issue

[Alex Karasulu]

On Fri, Sep 27, 2013 at 6:29 PM, Marvin Humphrey mar...@rectangular.comwrote:

 On Fri, Sep 27, 2013 at 12:33 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:

  Perhaps the initial committers list should be split into two:
 
   - interested developers
   - initial committers
 
  This way a podling can engage with the interested developers and
  quickly form an (expanded) community. IMO when an existing project
  comes in, the initial committers list should consist of the original
  committers. Anyone interested should be added to interested
  developers.
 
  Empty, new proposals can either start with a list of initial
  committers or with a list of interested developers who get voted in by
  the mentors as they engage in a community on dev@.
  Existing projects can add new interested developers to either list,
  depending on what their preference is. I'd expect Apache committers
  with no prior stake in the project to explicitly ask to be listed as
  merely an interested developer and earn their merit through
  contribution rather than moving directly to committership.

 +1

 Adding an Interested Developers section is an improvement over the patch
 to
 the proposal template suggested at the top of the thread because it gives
 newcomers a way to express interest and the proposed podling a way to say
 Thanks!  I've added you... instead of Thanks but

 The new section should contain a note guiding interested parties to send
 email
 to general@incubator asking to be added.

 Martijn's suggestion preserves the best aspects of open enrollment while
 appropriately delaying delicate discussions about meritocracy and openness
 until incubation is underway.


Well put ... I think this is the solution in the process that will prevent
these kinds of misunderstandings in the future.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

That's a really nice world Marcel. I'd love to believe that again. However
people will still have ill intentions even here at Apache. Just because we
say all these good things does not mean everyone feels the same way and
economics does rear it's ugly face.

Just look and see the control with which the CEO has ordered back the
minions and they have obeyed. There's nothing Apache Way-ish about this
coordinated effort.

I want to see people put an investment into a community by contributing to
it instead of piling on with zero investment. With such an investment, they
have a vested interest in that community. Without that there's no lose if
it fails and no incentive to make sure the community succeeds.

Combine this and one CEO pulling the strings then that's a bad combination.
That's not how Apache works. But I guess people will find the rhetoric to
justify this some way or another.



On Wed, Sep 25, 2013 at 11:59 AM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:

 It would be nice if everybody would started wearing their Apache hats and
 act as individuals that are interested in joining an exciting new project
 in the incubator. I would prefer it if everybody would assume good
 intentions here. We're all collaborating out in the open as a community, so
 let's all act in good faith until proven otherwise.

 Greetings, Marcel


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




-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

Stop talking and start contributing.

Show your commitment by contributing.

Show the present community who has worked on it for 2 years that you
understand their software and care enough to spend the time applying it.

This way when if your CEO says get out, you'll be like GTFO I value and I
invested my time in it. That's different than entering the project with
nothing to lose.

Don't expect people to just drink the cool aid here.

On Wed, Sep 25, 2013 at 12:57 PM, Dulitha Wijewantha dulit...@gmail.comwrote:

 The question here is not CEO's involvement. But rather the way everything
 reacted. Nobody likes to be accused for doing good things right? I am truly
 interested about the project but I do fear what will happen according to
 the mails sent by initial committers.. Also I didn't add my name to the
 wiki - I asked the *previous champion* of the project to add me to the
 initial committer list.

 You guys blame many people from one company coming in and then says that
 they shouldn't backdown. It's contradiction on it's own. So let's see
 things as it is -

 # First I was interested in the User-grid project coming under the apache
 umbrella
 # I wanted to contribute and help the project and mold it into a better one
 # I asked the *previous champion* to add us to the initial committer list
 # I get accused as *pilling* (this partly accuse WSO2 as well)
 # Sanjiva ask us not get involved in the project since the *current
 community* isn't welcoming
 # I withdraw my committer requests since the *current community* is
 accusing us for pilling

 *Minions aren't obliging*. I personally feel disrespected in the way people
 accuse each other for having underlying agendas. I was asking to contribute
 not *kill* the project. If we have a misunderstanding we should clear it
 out without disrespecting each other.

 PS: Also any sane person who looked at all the threads will never feel like
 contributing if they are been accused of. I personally get the feeling that
 apigee has coveted mission in bringing User-grid to Apache and not having
 other's involved in it. But hey all this can be a misunderstanding.

 Cheers




-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Wed, Sep 25, 2013 at 7:24 PM, Sanjiva Weerawarana sanj...@wso2.comwrote:

SNIP ...

Time to get past this and get the project going!


If we could have gotten here without the diversion, then the vote would not
have been derailed as it was.


 I will not offer to mentor
 nor will WSO2 commit our folks to it at this point (yes Alex as CEO I will
 decide whether we commit work time to this) but that's fine - there's
 plenty of other mentors and this project can easily get a community going
 without our help.


WSO2 folks should get involved especially to balance out Apigee. But this
does not happen naturally or correctly in 36 hours. If this podling enters
the Incubator, then all committers should contribute and demonstrate their
commitment to the project ... not to Apigee's CEO or to WSO2's CEO. This is
meritocracy in action and it leads to communities of individuals instead of
companies.

The problem was the unchecked manner, quantity and speed with which your
folks were being added to the committers list The community needs to vet
these guys just as much as anyone else. They should come in and engage this
community and start contributing, and hopefully becoming committers and
PPMC members. This will show the project is on the right track.


On Wed, Sep 25, 2013 at 6:42 PM, Joseph Schaefer joe_schae...@yahoo.com
 wrote:

  Thanks for clearing that up Jim.  Now who is going to make peace over all
  the spilled milk here?
 
  Sent from my iPhone
 
   On Sep 25, 2013, at 6:12 AM, Jim Jagielski j...@jagunet.com wrote:
  
  
   On Sep 25, 2013, at 12:39 AM, Joseph Schaefer joe_schae...@yahoo.com
 
  wrote:
  
   All things
   considered, would it be better if Sanjiva and colleagues
   ASKED to be included in the proposal instead of just adding
   themselves in an ad hoc fashion?
  
   Which is exactly what they did. They expressed an interest
   and were added when they specifically requested, and
   the adding was done by myself as Champion since I
   deemed the request sufficient.
  
  
   -
   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
 
 


 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 |
 +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




-- 
Best Regards,
-- Alex

Re: The podling initial committers issue

[Alex Karasulu]

On Wed, Sep 25, 2013 at 11:24 PM, Jim Jagielski j...@apache.org wrote:


 On Sep 25, 2013, at 1:01 PM, Dave snoopd...@gmail.com wrote:

  Here's what I think we should add:
 
  After a proposal is submitted to the incubator but before a vote is
 called
  the proposing community may choose to add additional committers who ask
 to
  be committers or may chose to defer adding new committers until the
 podling
  is in the Incubator and can use the normal ways of ASF meritocracy,
  nominate new committers, etc.
 
  Do people agree with that text?
 

 The normal ways stuff needs to be word-smithed. It's an
 obvious slam against the way 90-95% of how other proposals
 have been done and implies that somehow that's wrong.


There's no slam against podlings that have gone through an Incubator
process that was less meritocratic. This is not a failure of podlings
exposed to that process. It's just something we can make better, and more
consistent with our standard meritocratic policies for PMCs.


 If you delete everything after is in the Incubator... then
 it's a little less biased or leading.


I don't find this biased or leading. It's a genuine reference to mirror
policies that are the norm for PMCs.

Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Wed, Sep 25, 2013 at 11:41 PM, Dave snoopd...@gmail.com wrote:

 Thanks Sanjiva. I'm glad we we able to get things sorted out. And, thanks
 to everybody who gave us feedback and +1 votes.

 Since Usergrid is in need, I'd like to volunteer to be the champion.


I'm good with that.


 Since this is a change to the proposal I think we should edit the proposal
 and then I will nominate as the champion is supposed to do, then call a
 vote.


We need a fresh new vote thread. I think the discussions have already been
had so we might not need to revamp that again. We might also update the
wiki to note that the podling candidate is not following the open
enrollment model.

Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Thu, Sep 26, 2013 at 12:22 AM, Jim Jagielski j...@jagunet.com wrote:


 On Sep 25, 2013, at 3:54 AM, Lieven Govaerts lieven.govae...@gmail.com
 wrote:
   and that the incubator
  promotes this as 'the right thing to do' (which I didn''t know until
  now).

 Because it's NOT true. The right thing to do is what the
 podling determines; the whole problem was with uncontrolled
 piling on of completely unqualified people (for anyone who cared
 to read the entire thread), not *just* with additional committers being
 added to the proposal.

 It was the *method* that was the issue, not the actual
 act of adding committers per se.

 From Roy in
 http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3c55d28a90-8584-4410-b38c-e884f7926...@gbiv.com%3e
 :

   There is nothing wrong with the proposer asking for and accepting
   additional committers from the wide world of ASF.  I did that for
   Jackrabbit, for example, specifically because I wanted a lot of
   experienced ASF folks to help mentor the project (even though I was
   the only official Mentor).  However, that is significantly different
   from any wiki reader being able to add themselves just because they
   (or their boss) thinks it might be worth getting in on the ground
   floor of a project.

 IMO, the proposal always implies asking for help. That is, when
 I see a proposal proposed, I expect that the person is looking
 for feedback to their proposal, and would take Great idea; I'd
 love to help. Could I be added as a committer? as indication
 of someone who wants to help and can be added in a very low-risk
 fashion. The problem is that my world-view didn't jive w/ Alex
 nor Dave.
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

Sorry this went out accidentally ...

I'm going to pull out as a mentor and as a committer.

Thanks,
Alex


On Thu, Sep 26, 2013 at 1:05 AM, Alex Karasulu akaras...@apache.org wrote:




 On Thu, Sep 26, 2013 at 12:22 AM, Jim Jagielski j...@jagunet.com wrote:


 On Sep 25, 2013, at 3:54 AM, Lieven Govaerts lieven.govae...@gmail.com
 wrote:
   and that the incubator
  promotes this as 'the right thing to do' (which I didn''t know until
  now).

 Because it's NOT true. The right thing to do is what the
 podling determines; the whole problem was with uncontrolled
 piling on of completely unqualified people (for anyone who cared
 to read the entire thread), not *just* with additional committers being
 added to the proposal.

 It was the *method* that was the issue, not the actual
 act of adding committers per se.

 From Roy in
 http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3c55d28a90-8584-4410-b38c-e884f7926...@gbiv.com%3e
 :

   There is nothing wrong with the proposer asking for and accepting
   additional committers from the wide world of ASF.  I did that for
   Jackrabbit, for example, specifically because I wanted a lot of
   experienced ASF folks to help mentor the project (even though I was
   the only official Mentor).  However, that is significantly different
   from any wiki reader being able to add themselves just because they
   (or their boss) thinks it might be worth getting in on the ground
   floor of a project.

 IMO, the proposal always implies asking for help. That is, when
 I see a proposal proposed, I expect that the person is looking
 for feedback to their proposal, and would take Great idea; I'd
 love to help. Could I be added as a committer? as indication
 of someone who wants to help and can be added in a very low-risk
 fashion. The problem is that my world-view didn't jive w/ Alex
 nor Dave.
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




 --
 Best Regards,
 -- Alex




-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

Hi Niranjan, Dulitha,

It's fantastic to see you and others wanting to dive in and you're all more
than welcome. We're looking forward to your involvement to the fullest
extent possible in this community.

The initial aim of the community right now is to meet the incubator entry
requirements, enter the incubator, and immediately form the PPMC and
associated mailing lists. That way we can evaluate new committers based on
their contribution activity via standard meritocratic guidelines.

Without cluttering this thread, we can continue with these and other
discussions there once these structures are in place. Hopefully this will
not take long and we can get started quickly. Until then please start
looking at the initial code and trying to find low hanging issues to get a
jump start.

Cheers,
Alex



On Tue, Sep 24, 2013 at 9:06 AM, Niranjan Karunanandham 
niranjan.k...@gmail.com wrote:

 +1 for the proposal and I would like to be added as a committer to the
 usergrid project. I wasn't able to add myself as a committer before voting
 was called for. Therefore I request if the champion or a mentor can add me
 to the proposal.

 Thanks.


 On Tue, Sep 24, 2013 at 7:30 AM, Dulitha Wijewantha dulit...@gmail.comwrote:

 +1 for the proposal. I would liked to get added as an initial committer to
 the user-grid project. I didn't get a chance to add to the proposal before
 the vote was called. It would be great if the champion or a mentors can
 add
 it in the proposal (since now going under a vote).

 Thanks


 On Mon, Sep 23, 2013 at 11:46 PM, Marvin Humphrey mar...@rectangular.com
 wrote:

  On Mon, Sep 23, 2013 at 9:15 AM, Jim Jagielski j...@jagunet.com wrote:
   Did you see what you replied too?? propose a vote and
   the subject sez [VOTE]. :)
 
  It's probably an email client issue.   From the `Message-Id:` header of
  Sanjiva's emails, it looks like might be using Gmail.  With Gmail,
 changing
  the subject from '[PROPOSAL]...' to '[VOTE]...' -- or from '[VOTE]...'
 to
  '[DISCUSS]...' as I've done here -- is not enough to start a new
  conversation, i.e. thread.  Gmail de-dupes subjects where only
 bracketed
  text changes.
 
  There's not much to do for it except to raise awareness every once in a
  while.
 
  Marvin Humphrey
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --

 *Dulitha R. Wijewantha** Software Engineer*
 Tel: 94112793140 | Mobile: 94112793140
 dulit...@gmail.com | http://dulithawijewantha.com




 --
 *Niranjan Karunanandham*
 Senior Software Engineer
  M: +94 777 749 661 http:///




-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Wed, Sep 25, 2013 at 1:34 AM, Jim Jagielski j...@jagunet.com wrote:

 On Tue, Sep 24, 2013 at 02:40:19PM +0200, Lieven Govaerts wrote:
  On Tue, Sep 24, 2013 at 1:25 PM, Jim Jagielski j...@jagunet.com wrote:
   Alex, if people want to join and add themselves as
   committers, then they can. The bar to entry for podlings
   during the initial proposal stage is I'm interested :)
 
  Is there some more background available on why the barrier is set this
  low in the incubator? It seems unnatural to me. A large part of
  incubation of course is to attract new committers, but why not let the
  podling decide on which barrier it wants to use?

 I said initial proposal stage. After accepted and it actually becomes
 a podling then, of course, the podling decides how high or low that
 bar is.

 But we aren't talking about that.


So during the initial proposal stage anyone who volunteers goes in
without having to contribute? There's no input from the perspective
podliing?

-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Wed, Sep 25, 2013 at 2:14 AM, Jim Jagielski j...@jagunet.com wrote:

 On Wed, Sep 25, 2013 at 01:59:21AM +0600, Alex Karasulu wrote:
  On Wed, Sep 25, 2013 at 1:34 AM, Jim Jagielski j...@jagunet.com wrote:
 
   On Tue, Sep 24, 2013 at 02:40:19PM +0200, Lieven Govaerts wrote:
On Tue, Sep 24, 2013 at 1:25 PM, Jim Jagielski j...@jagunet.com
 wrote:
 Alex, if people want to join and add themselves as
 committers, then they can. The bar to entry for podlings
 during the initial proposal stage is I'm interested :)
   
Is there some more background available on why the barrier is set
 this
low in the incubator? It seems unnatural to me. A large part of
incubation of course is to attract new committers, but why not let
 the
podling decide on which barrier it wants to use?
  
   I said initial proposal stage. After accepted and it actually becomes
   a podling then, of course, the podling decides how high or low that
   bar is.
  
   But we aren't talking about that.
  
 
  So during the initial proposal stage anyone who volunteers goes in
  without having to contribute? There's no input from the perspective
  podliing?
 

 How can they have contributed if its a new podling?


So fill the bus with anybody who volunteers? That does not sound
meritocratic.

OK in the immortal words of a friend, I'm going to just be a committer on
every podling from now on.


-- 
Best Regards,
-- Alex

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Wed, Sep 25, 2013 at 5:57 AM, Jim Jagielski j...@jagunet.com wrote:


 On Sep 24, 2013, at 6:58 PM, Alex Karasulu akaras...@apache.org wrote:

 
  Put yourself in their shoes for a second? It's a big leap of faith for
 some
  projects to come and propose for incubation. You just scared the bejesus
  out of these guys even if they wanted to work with you.
 

 You have also made it clear that the proposed podling will
 be incredibly careful about who and when they give karma and
 merit to, potentially scaring off a huge number of potential
 committers, regardless of affiliation, who have likely
 gotten the impression that the current committer list
 consider themselves unimpeachable and a self-sustaining
 oligarchy.


That's a big leap and not fair to presume unless you've watched this
community in action under incubation.

Are they traumatized by this whole mess? Perhaps, but if they let it
stigmatize them into not letting any including WSO2 employees rightfully
earn their place as committers then they have a problem and should not be
here.


 I, for one, did not see any piling on, certainly nothing
 close to the levels that prompted that discussion from years
 ago nor that prompted Roy's post, at the start of all this.
 And FWIW, just because Roy expresses an opinion, it does not
 make it Biblical; Not that I don't agree with most of what Roy's
 comment indicates, but also starting off a podling with
 a heavy-handed control also hamstrings the podling just
 as badly.


How can you be sure they're going to have heavy-handed control tactics in
place?

Re: [VOTE] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

 and as
 such they are committed to contributing to the effort.

 === Inexperience with Open Source ===
 The Usergrid project has been open source and under the ALv2 for 2 years on
 Github and many of its contributors came with previous open-source
 experience, (as referenced above), including active members of these
 communities:

 * Apache
 * Cassandra ( Hector)
 * Lucene
 * Hibernate
 * CouchDB
 * PhoneGap
 * jQuery

 Development in this open forum has resulted in a growing community of
 contributors, and the Usergrid project is now ready and eager to embrace and
 learn from Apache's wealth of experience. Usergrid would like to embrace an
 even greater culture of open participation as witnessed on so many Apache
 projects.

 === Homogenous Developers ===
 The core development team for Usergrid is a geographically and
 technologically diverse group. Apigee’s team is itself distributed, with
 contributors based in each timezone in the continental US. Additional
 regular contributors have joined us from India, Asia, Oceania, South
 America, the Middle East and Europe. While roughly half of our core
 developers come from a Java background, the other half is comprised of iOS,
 Ruby, and JavaScript developers.

 === Reliance on Salaried Developers ===
 Most of the principal developers are paid by their employers to contribute,
 but not all. Throughout the life of the project, we’ve seen passionate,
 personal commitment from all parties, as evidenced by our commit
 distribution on weekends
 (https://github.com/apigee/usergrid-stack/graphs/punch-card). We also
 believe, given the growing interest in mobile API services and the range of
 individuals and corporations that are eager to participate, that
 non-salaried contributions will grow. We know the The Apache Way will help
 us further accelerate this process.

 === Relationships with Other Apache Products ===
 There's much potential for collaboration with Apache Cordova and, of course,
 the Cassandra community because of the underlying foundations of Usergrid's
 scalability. In the future there may be more interactions with any of the
 communities that Usergrid has direct dependencies to.

 === A Excessive Fascination with the Apache Brand ===
 Although we are aware of the strength of the Apache brand, we are primarily
 interested in the transforming power of the Apache Way to help guide
 Usergrid towards a more diversified and meritocratic community. To that end,
 the brand's primary benefit for us is to help to attract more participants
 and diversify the community. Having several committers, PMC participants,
 and members of Apache as developers on Usergrid, there's little infatuation
 with the brand, and the Usergrid community is actively conscious of this not
 being a driver for joining the Apache community.


 == Documentation ==

 Information on Usergrid can be found at:
 https://developers.apigee.com/app-services.


 == Initial Source ==

 All initial sources can be found here: https://github/usergrid


 == Source and Intellectual Property Submission Plan ==

 The IP transfer for Usergrid is trivial due to it's single source and
 existing ASLv2 licensing.


 == External Dependencies ==

 Most dependencies are Apache compatible licenses (Category A). A small set
 of Category B licenses, like the CDDL exists. For more details please see
 Dependency Licenses.


 == Cryptography ==

 Not relevant to Usergrid since all code dealing with cryptography already
 comes from the JDK or from dependencies on  Apache Software.


 == Required Resources ==

 === Mailing lists ===
 * priv...@usergrid.incubator.apache.org (moderated)
 * d...@usergrid.incubator.apache.org
 * comm...@usergrid.incubator.apache.org

 === Subversion Directory ===
 We prefer to use Git as our source control system:
 git://git.apache.org/usergrid/. If possible, we would like to keep
 leveraging the extremely useful github facilities for workflow using a
 process much like that employed by the Apache Cordova project (documented
 here http://wiki.apache.org/cordova/ContributorWorkflow).

 === Issue Tracking ===
 JIRA Usergrid (USERGRID)

 === Other Resources ===
 None.


 == Initial Committers ==

 * Alberto Leal albert...@gmail.com (Globo.com)
 * Alex Karasulu akaras...@apache.org (Apigee)
 * Dave Johnson snoopd...@apache.org (Apigee)
 * Ed Anuff e...@anuff.com (Apigee)
 * Nate McCall zznat...@gmail.com (The Last Pickle)
 * Rod Simpson r...@rodsimpson.com (Apigee)
 * Scott Ganyo scottga...@apache.org (Apigee)
 * Shaozhuang Liu st...@hibernate.org
 * Sungju Jin sun...@softwaregeeks.org (Korea Telecom)
 * Tim Anglade timangl...@gmail.com (Apigee)
 * Todd Nine todd.n...@gmail.com (Apigee)
 * Jim Jagielski j...@apache.org (RedHat)


 == Affiliations ==

 * Apigee
 * Korea Telecom
 * Globo.com
 * The Last Pickle


 == Sponsors ==

 === Champion ===
 Jim Jagielski j...@apache.org

 === Nominated Mentors ===
 * Alex Karasulu akaras...@apache.org
 * Dave Johnson snoopd...@apache.org

 === Sponsoring Entity ===
 Incubator PMC

Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

 is an
 established startup with a large, diversified customer roster and Korea
 Telecom is a major, national telecommunications company. The continuity of
 Usergrid, as an open-source, vendor-independent product are in the interest
 of all parties. Beyond the vendors, Globo.com and many others large
 companies have been relying on Usergrid for critical applications and as
 such they are committed to contributing to the effort.

 === Inexperience with Open Source ===
 The Usergrid project has been open source and under the ALv2 for 2 years on
 Github and many of its contributors came with previous open-source
 experience, (as referenced above), including active members of these
 communities:

   * Apache
   * Cassandra ( Hector)
   * Lucene
   * Hibernate
   * CouchDB
   * PhoneGap
   * jQuery

 Development in this open forum has resulted in a growing community of
 contributors, and the Usergrid project is now ready and eager to embrace and
 learn from Apache's wealth of experience. Usergrid would like to embrace an
 even greater culture of open participation as witnessed on so many Apache
 projects.

 === Homogenous Developers ===
 The core development team for Usergrid is a geographically and
 technologically diverse group. Apigee’s team is itself distributed, with
 contributors based in each timezone in the continental US. Additional
 regular contributors have joined us from India, Asia, Oceania, South
 America, the Middle East and Europe. While roughly half of our core
 developers come from a Java background, the other half is comprised of iOS,
 Ruby, and JavaScript developers.

 === Reliance on Salaried Developers ===
 Most of the principal developers are paid by their employers to contribute,
 but not all. Throughout the life of the project, we’ve seen passionate,
 personal commitment from all parties, as evidenced by our commit
 distribution on weekends
 (https://github.com/apigee/usergrid-stack/graphs/punch-card). We also
 believe, given the growing interest in mobile API services and the range of
 individuals and corporations that are eager to participate, that
 non-salaried contributions will grow. We know the The Apache Way will help
 us further accelerate this process.

 === Relationships with Other Apache Products ===
 There's much potential for collaboration with Apache Cordova and, of course,
 the Cassandra community because of the underlying foundations of Usergrid's
 scalability. In the future there may be more interactions with any of the
 communities that Usergrid has direct dependencies to.

 === A Excessive Fascination with the Apache Brand ===
 Although we are aware of the strength of the Apache brand, we are primarily
 interested in the transforming power of the Apache Way to help guide
 Usergrid towards a more diversified and meritocratic community. To that end,
 the brand's primary benefit for us is to help to attract more participants
 and diversify the community. Having several committers, PMC participants,
 and members of Apache as developers on Usergrid, there's little infatuation
 with the brand, and the Usergrid community is actively conscious of this not
 being a driver for joining the Apache community.


 == Documentation ==

 Information on Usergrid can be found at:
 https://developers.apigee.com/app-services.


 == Initial Source ==

 All initial sources can be found here: https://github/usergrid


 == Source and Intellectual Property Submission Plan ==

 The IP transfer for Usergrid is trivial due to it's single source and
 existing ASLv2 licensing.


 == External Dependencies ==

 Most dependencies are Apache compatible licenses (Category A). A small set
 of Category B licenses, like the CDDL exists. For more details please see
 Dependency Licenses.


 == Cryptography ==

 Not relevant to Usergrid since all code dealing with cryptography already
 comes from the JDK or from dependencies on  Apache Software.


 == Required Resources ==

 === Mailing lists ===
   * priv...@usergrid.incubator.apache.org (moderated)
   * d...@usergrid.incubator.apache.org
   * comm...@usergrid.incubator.apache.org

 === Subversion Directory ===
 We prefer to use Git as our source control system:
 git://git.apache.org/usergrid/. If possible, we would like to keep
 leveraging the extremely useful github facilities for workflow using a
 process much like that employed by the Apache Cordova project (documented
 here http://wiki.apache.org/cordova/ContributorWorkflow).

 === Issue Tracking ===
 JIRA Usergrid (USERGRID)

 === Other Resources ===
 None.


 == Initial Committers ==

   * Alberto Leal albert...@gmail.com (Globo.com)
   * Alex Karasulu akaras...@apache.org (Apigee)
   * Dave Johnson snoopd...@apache.org (Apigee)
   * Ed Anuff e...@anuff.com (Apigee)
   * Nate McCall zznat...@gmail.com (The Last Pickle)
   * Rod Simpson r...@rodsimpson.com (Apigee)
   * Scott Ganyo scottga...@apache.org (Apigee)
   * Shaozhuang Liu st...@hibernate.org
   * Sungju Jin sun...@softwaregeeks.org (Korea Telecom

Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Tue, Sep 17, 2013 at 1:57 PM, Lieven Govaerts
lieven.govae...@gmail.com wrote:

SNIP ...

 As I'm setting up a similar infrastructure for a mobile application
 now, this project interests me a lot. I have made some different
 design choices so it'll be interesting to compare the benefits of my
 approach against choices made by the usergrid team.

We welcome your opinions, and your involvement. This is exactly what
we've been looking forward to.

 I'll dig into the code more deeply and join (with contributions) were I can.

Awesome!

 Definitely a good addition to the apache incubator!

Thanks,
-- Alex

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

Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator

[Alex Karasulu]

On Mon, Sep 16, 2013 at 8:05 PM, Luciano Resende luckbr1...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 6:39 AM, Jim Jagielski j...@jagunet.com wrote:

 I would like to propose Usergrid, a multi-tenant Backend-as-a-Service
 stack for web  mobile applications based on RESTful APIs, as an Apache
 Incubator podling.

SNIP ...

 I'm glad to see a multi-tenant Backend-as-a-Service coming to Apache.
 Please feel free to add me as a mentor, and I'm most likely contribute to
 this project if time permits as this is an area I have interest.

Luciano, that sounds great! I've just added you to the list of
mentors. Looking forward to working with you on this one. There's a
lot of potential for Wink and OSGi related work on this project so it
might be your cup of tea.

-- 
Best Regards,
-- Alex

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

Re: [VOTE] Accept Storm into the Incubator

[Alex Karasulu]

+1 (binding)

On Fri, Sep 13, 2013 at 6:51 AM, Hyunsik Choi hyun...@apache.org wrote:
 +1 (non binding)

 2013년 9월 13일 금요일에 Doug Cutting님이 작성:

 Discussion about the Storm proposal has subsided, issues raised now
 seemingly resolved.

 I'd like to call a vote to accept Storm as a new Incubator podling.

 The proposal is included below and is also at:

   https://wiki.apache.org/incubator/StormProposal

 Let's keep the vote open for four working days, until 18 September.

 [ ] +1 Accept Storm into the Incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept Storm because...

 Doug


 = Storm Proposal =

 == Abstract ==

 Storm is a distributed, fault-tolerant, and high-performance realtime
 computation system that provides strong guarantees on the processing
 of data.

 == Proposal ==

 Storm is a distributed real-time computation system. Similar to how
 Hadoop provides a set of general primitives for doing batch
 processing, Storm provides a set of general primitives for doing
 real-time computation. Its use cases span stream processing,
 distributed RPC, continuous computation, and more. Storm has become a
 preferred technology for near-realtime big-data processing by many
 organizations worldwide (see a partial list at
 https://github.com/nathanmarz/storm/wiki/Powered-By). As an open
 source project, Storm’s developer community has grown rapidly to 46
 members.

 == Background ==

 The past decade has seen a revolution in data processing. MapReduce,
 Hadoop, and related technologies have made it possible to store and
 process data at scales previously unthinkable. Unfortunately, these
 data processing technologies are not realtime systems, nor are they
 meant to be. The lack of a Hadoop of realtime has become the biggest
 hole in the data processing ecosystem. Storm fills that hole.

 Storm was initially developed and deployed at BackType in 2011. After
 7 months of development BackType was acquired by Twitter in July 2011.
 Storm was open sourced in September 2011.

 Storm has been under continuous development on its Github repository
 since being open-sourced. It has undergone four major releases (0.5,
 0.6, 0.7, 0.8) and many minor ones.


 == Rationale ==

 Storm is a general platform for low-latency big-data processing. It is
 complementary to the existing Apache projects, such as Hadoop. Many
 applications are actually exploring using both Hadoop and Storm for
 big-data processing. Bringing Storm into Apache is very beneficial to
 both Apache community and Storm community.

 The rapid growth of Storm community is empowered by open source. We
 believe the Apache foundation is a great fit as the long-term home for
 Storm, as it provides an established process for community-driven
 development and decision making by consensus. This is exactly the
 model we want for future Storm development.

 == Initial Goals ==

* Move the existing codebase to Apache
* Integrate with the Apache development process
* Ensure all dependencies are compliant with Apache License version 2.0
* Incremental development and releases per Apache guidelines

 == Current Status ==

 Storm has undergone four major releases (0.5, 0.6, 0.7, 0.8) and many
 minor ones. Storm 0.9 is about to be released. Storm is being used in
 production by over 50 organizations. Storm codebase is currently
 hosted at github.com, which will seed the Apache git repository.

 === Meritocracy ===

 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already
 expressed interest in this project, and we intend to invite additional
 developers to participate. We will encourage and monitor community
 participation so that privileges can be extended to those that
 contribute.

 === Community ===

 The need for a low-latency big-data processing platform in the open
 source is tremendous. Storm is currently being used by at least 50
 organizations worldwide (see
 https://github.com/nathanmarz/storm/wiki/Powered-By), and is the most
 starred Java project on Github. By bringing Storm into Apache, we
 believe that the community will grow even bigger.

 === Core Developers ===

 Storm was started by Nathan Marz at BackType, and now has developers
 from Yahoo!, Microsoft, Alibaba, Infochimps, and many other companies.

 === Alignment ===

 In the big-data processing ecosystem, Storm is a very popular
 low-latency platform, while Hadoop is the primary platform for batch
 processing. We believe that it will help the further growth of
 big-data community by having Hadoop and Storm aligned within Apache
 foundation. The alignment is also beneficial to other Apache
 communities (such as Zookeeper, Thrift, Mesos). We could include
 additional sub-projects, Storm-on-YARN and Storm-on-Mesos, in the near
 future.

 == Known Risks ==

 === Orphaned Products ===

 The risk of the Storm project being abandoned is minimal. There are at
 least 50 organizations (Twitter, Yahoo!, Microsoft, Groupon, 

Re: [PROPOSAL] Samza Proposal

[Alex Karasulu]

+1

I would love to see the documents comparing and contrasting Samza with
MUPD8 and Storm.


On Sat, Jul 27, 2013 at 2:53 AM, Enis Söztutar e...@apache.org wrote:

 +1 on incubation.

 Enis


 On Tue, Jul 23, 2013 at 7:17 PM, Chris Riccomini
 criccomini@gmail.comwrote:

  Hey Henry and Debo,
 
  Thanks for calling this out. Samza's feature set includes:
 
 - *Simpe API:* Unlike most low-level messaging system APIs, Samza
 provides a very simple call-back based process message API that
  should be
 familiar to anyone that's used Map/Reduce.
 - *Managed state:* Samza manages snapshotting and restoration of a
 stream processor's state. Samza will restore a stream processor's
 state
  to
 a snapshot consistent with the processor's last read messages when the
 processor is restarted.
 - *Fault tolerance:* Samza will work with YARN to restart your stream
 processor if there is a machine or processor failure.
 - Durability: Samza uses Kafka to guarantee that no messages will ever
 be lost.
 - *Scalability:* Samza is partitioned and distributed at every level.
 Kafka provides ordered, partitioned, replayable, fault-tolerant
 streams.
 YARN provides a distributed environment for Samza containers to run
 in.
 - *Pluggable:* Though Samza works out of the box with Kafka and YARN,
 Samza provides a pluggable API that lets you run Samza with other
  messaging
 systems and execution environments.
 - *Processor isolation:* Samza works with Apache YARN, which supports
 processor security through Hadoop's security model, and resource
  isolation
 through Linux CGroups.
 
  Some of these feature are available in S4, and some are not. The same
 holds
  true for Storm.
 
  The open source stream processing systems that are available are actually
  quite young, and no single system offers a complete solution. Problems
 like
  how a stream processor's state (e.g. counts) should be managed, whether a
  stream should be buffered remotely on disk or not, what to do when
  duplicate messages are received or messages are lost, and how to model
  underlying messaging systems are all pretty new.
 
  Samza's main differentiators are:
 
 - State is modeled as a stream. When a processor fails and is
 restarted,
 the state stream is entirely replayed to restore it.
 - Streams are ordered, partitioned, replayable, and fault tolerant.
 - YARN is used for processor isolation, security, and fault tolerance.
 - All streams are materialized to Kafka.
 
  If you guys are interested, I have much more in-depth documents comparing
  and contrasting Samza with MUPD8 and Storm.
 
  Cheers,
  Chris
 
 
  On Tue, Jul 23, 2013 at 6:48 PM, Henry Saputra henry.sapu...@gmail.com
  wrote:
 
   Looks like this is similar to S4 (http://incubator.apache.org/s4/)
 which
   allow stream and real time data processing via DAG?
  
  
   - Henry
  
  
   On Tue, Jul 23, 2013 at 10:47 AM, Chris Ricco 
 criccomini@gmail.com
   wrote:
  
Hey All,
   
Sending along an incubator proposal for Samza.
   
Thanks!
Chris
   
https://wiki.apache.org/incubator/SamzaProposal
   

   
== Abstract ==
   
Samza is a stream processing system for running continuous
 computation
  on
infinite streams of data.
   
== Proposal ==
   
Samza provides a system for processing stream data from
  publish-subscribe
systems such as Apache Kafka. The developer writes a stream
 processing
task, and executes it as a Samza job. Samza then routes messages
  between
stream processing tasks and the publish-subscribe systems that the
   messages
are addressed to.
   
== Background ==
   
Samza was developed at LinkedIn to enable easier processing of
  streaming
data on top of Apache Kafka. Current use cases include content
  processing
pipelines, aggregating operational log data, data ingestion into
distributed database infrastructure, and measuring user activity
 across
different aggregation types.
   
Samza is focused on providing an easy to use framework to process
   streams.
It uses Apache YARN to provide a mechanism for deploying stream
   processing
tasks in a distributed cluster. Samza also takes advantage of YARN to
   make
decisions about stream processor locality, co-partition of streams,
 and
provide security. Apache Kafka is also leveraged to provide a
 mechanism
   to
pass messages from one stream processor to the next. Apache Kafka is
  also
used to help manage a stream processor's state, so that it can be
   recovered
in the event of a failure.
   
Samza is written in Scala. It was developed internally at LinkedIn to
   meet
our particular use cases, but will be useful to many organizations
   facing a
similar need to reliably process large amounts of streaming data.
Therefore, we would like to share it the 

Re: [VOTE] Graduation of Apache Mesos

[Alex Karasulu]

+1 (binding)


On Thu, Jun 13, 2013 at 10:39 AM, Christian Grobmeier
grobme...@gmail.comwrote:

 Looks good! +1

 On Wed, Jun 12, 2013 at 10:03 PM, Mattmann, Chris A (398J)
 chris.a.mattm...@jpl.nasa.gov wrote:
  Hi All,
 
  The Apache Mesos community is ready to graduate. They have added
  committers and PPMC members while in the Incubator; have made a
  few releases; are discussing their issues on list and in the Apache
  way, and are inclusive and representative of Apache's goals as a
  Foundation.
 
  I'm extremely happy to put them up for Incubator graduation.
  We've VOTEd as a community to move forward with this:
 
  DISCUSS thread here: http://s.apache.org/XAu
  VOTE thread here: http://s.apache.org/K8C
  VOTE RESULT: Message-ID: cdde1f13.d6ea1%chris.a.mattm...@jpl.nasa.gov
 
  Project Incubator status page here:
  http://incubator.apache.org/projects/mesos.html
 
  Board resolution pasted at bottom of email.
 
  Existing tallies from the community VOTE:
 
  +1
  Chris Mattmann*
  Vinod Kone
  Benjamin Hindman
  Benjamin Mahler
  Yan Xiu
  Deepal Jayasinghe
  Brenden Matthews
  Matei Zaharia
  Ant Elder*
  Konstantin Boudnik
 
  * - indicates IPMC
 
  Please VOTE to graduate Apache Mesos from the Incubator. Though
  only Incubator PMC member VOTEs are binding, all are welcome to
  voice your opinion. I'll leave the VOTE open for at least 72 hours,
  and hopefully can get enough VOTEs in time to close it by Saturday
  or Sunday in time for the board meeting on 6/19.
 
  [ ] +1 Graduate Apache Mesos from the Incubator.
  [ ] +0 Don't care.
  [ ] -1 Don't graduate Apache Mesos from the Incubator because..
 
  Thanks everyone!
 
  Cheers,
  Chris
 
 
  ---board resolution
  WHEREAS, the Board of Directors deems it to be in the best
  interests of the Foundation and consistent with the
  Foundation's purpose to establish a Project Management
  Committee charged with the creation and maintenance of
  open-source software, for distribution at no charge to the
  public, related to efficient cluster management, resource
  isolation and sharing across distributed applications.
 
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
  Committee (PMC), to be known as the Apache Mesos Project, be
  and hereby is established pursuant to Bylaws of the Foundation;
  and be it further
 
  RESOLVED, that the Apache Mesos Project be and hereby is
  responsible for the creation and maintenance of software
  related to efficient cluster management, resource isolation
  and sharing across distributed applications; and be it further
  RESOLVED, that the office of Vice President, Apache Mesos 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 Mesos Project, and to have primary responsibility for
  management of the projects within the scope of responsibility
  of the Apache Mesos 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 Mesos Project:
 
   * Ali Ghodsi a...@apache.org
  * Andy Konwinski and...@apache.org
  * Benjamin Hindhman b...@apache.org
  * Benjamin Mahler bmah...@apache.org
  * Brian McCalister bri...@apache.org
  * Ian Holsman i...@apache.org
  * Matei Alexandru Zahari ma...@apache.org
  * Chris Mattmann mattm...@apache.org
  * Tom White tomwh...@apache.org
  * Vinod Kone vinodk...@apache.org
  * Brenden Matthews bren...@apache.org
  * Thomas Marshall tmarsh...@apache.org
  * Charles Reiss wog...@apache.org
 
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Benjamin Hindman be
  appointed to the office of Vice President, Apache Mesos, to
  serve in accordance with and subject to the direction of the
  Board of Directors and the Bylaws of the Foundation until
  death, resignation, retirement, removal or disqualification, or
  until a successor is appointed; and be it further
 
  RESOLVED, that the Apache Mesos Project be and hereby is
  tasked with the migration and rationalization of the Apache
  Incubator Mesos podling; and be it further
 
  RESOLVED, that all responsibilities pertaining to the Apache
  Incubator Mesos podling encumbered upon the Apache Incubator
  Project are hereafter discharged.
 
 
  ++
  Chris Mattmann, Ph.D.
  Senior Computer Scientist
  NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
  Office: 171-266B, Mailstop: 171-246
  Email: chris.a.mattm...@nasa.gov
  WWW:  http://sunset.usc.edu/~mattmann/
  ++
  Adjunct Assistant Professor, Computer Science Department
  University of Southern California, Los Angeles, CA 90089 USA
  ++
 
 
 
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For 

Re: [VOTE] Release Apache Mesos 0.12.0-incubating (RC1)

[Alex Karasulu]

No worries on the checksum. Looking good ...

+1 (binding)


On Wed, Jun 12, 2013 at 7:45 PM, Mattmann, Chris A (398J) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Hey Henry,

 Either way I don't think it's doctrine -- I've seen releases and voted on
 them with or without.
 I think it's nice to have a sha or sha1, but not required.

 Cheers,
 Chris

 ++
 Chris Mattmann, Ph.D.
 Senior Computer Scientist
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 171-266B, Mailstop: 171-246
 Email: chris.a.mattm...@nasa.gov
 WWW:  http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Assistant Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++






 -Original Message-
 From: Henry Saputra henry.sapu...@gmail.com
 Reply-To: general@incubator.apache.org general@incubator.apache.org
 Date: Tuesday, June 11, 2013 12:12 PM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Re: [VOTE] Release Apache Mesos 0.12.0-incubating (RC1)

 Does an incubator project release requires sha1 checksum too?
 
 From: http://www.apache.org/dev/release-signing.html:
 
 An SHA checksum *should* also be created and *must* be suffixed .sha
 
 Looks like it should but not required?
 
 - Henry
 
 
 On Mon, Jun 10, 2013 at 5:05 PM, Benjamin Mahler
 benjamin.mah...@gmail.comwrote:
 
  Please vote on releasing the following candidate as Apache Mesos
  (incubating) version 0.12.0. This will be the fourth incubator release
 for
  Mesos in Apache.
 
  The candidate for Mesos 0.12.0-incubating release is available at:
 
 
 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12
 .
 0-incubating.tar.gz
 
  The tag to be voted on is 0.12.0-rc1:
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-mesos.git;a=tag;h=57d
 7b9719dce662881b162eba10b5765a807d53c
 
  The MD5 checksum of the tarball can be found at:
 
 
 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12
 .
 0-incubating.tar.gz.md5
 
  The signature of the tarball can be found at:
 
 
 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12
 .
 0-incubating.tar.gz.asc
 
  PGP key used to sign the release:
  http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD0BEBB95D141A5B6
 
  Please vote on releasing this package as Apache Mesos 0.12.0-incubating!
 
  The vote is open until Thursday, June 13th at 00:00 UTC and passes if
  a majority
  of at least 3 +1 IPMC votes are cast.
 
  [ ] +1 Release this package as Apache Mesos 0.12.0-incubating
  [ ] -1 Do not release this package because ...
 
  To learn more about Apache Mesos, please see
  http://incubator.apache.org/mesos.
 


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




-- 
Best Regards,
-- Alex

Re: Vote on personal matters: majority vote vs consensus

[Alex Karasulu]

On Thu, Mar 28, 2013 at 12:11 AM, Niall Pemberton niall.pember...@gmail.com
 wrote:

 On Mon, Mar 25, 2013 at 12:12 AM, Roman Shaposhnik r...@apache.org wrote:
  On Sat, Mar 23, 2013 at 1:24 PM, Ted Dunning ted.dunn...@gmail.com
 wrote:
  One alternative to going for full-on majority voting is to recognize
 that a
  larger group is much more likely to have noisy vetoes by requiring
 that
  successful votes have n positive votes and m negative votes subject to
 some
  condition on n and m.  Majority requires n  m, strict Apache consensus
  requires n = 3 and m == 0.  It is easy to imagine other conditions
 such as
  n = 4 and m = 2 which still have some of the flavor of consensus in
 that
  a minority can block a decision, but allow forward progress even with
  constant naysayers or occasional random vetoes.
 
  Personally, I'd suggest keeping these options in our backpocket
  and turning back to considering them in case a simple majority
  proposal runs into an opposition somehow. At this point, I'd rather
  try a simple solution first.

 I was in favour of simple majority - but a vote passing with, for
 example 9+1 and 8-1 is as bad IMO as a vote failing because of alot of
 +1 and only one -1.

 So I've changed my mind on this - I think it should be 3/4 majority.
 This avoids a small minority stopping something, but also doesn't
 completely throw out consensus.


+1 - this sounds like the most reasonable proposal of all.

-- 
Best Regards,
-- Alex

Re: Identifying and removing inactive mentors

[Alex Karasulu]

On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:

 On Sun, Mar 24, 2013 at 8:27 PM, Benson Margulies bimargul...@gmail.com
 wrote:
  ...I would offer a compromise process. If someone does not even sign off
 the
  report for two or three months running, send an email to that person,
  copying general@, asking, politely, if they wish to remain a mentor

 IMO it's the podlings who need to make sure they have enough mentor
 energy available - they are best placed to judge that, and delegating
 that to them scales much better than burdening the incubator PMC.


In total agreement. No one knows better than the podling.


 We could simply ask the podlings to systematically include in their
 reports a comment about how they are doing in terms of mentors - do
 they feel they are adequately mentored, or should the IPMC help them
 find more active mentors?


+1

-- 
Best Regards,
-- Alex

Re: [RESULT][VOTE] Accept MRQL into the Incubator

[Alex Karasulu]

We're also missing Ant Elder from the Nominated Mentors list no?


On Sun, Mar 17, 2013 at 9:45 AM, ant elder ant.el...@gmail.com wrote:

 On Sat, Mar 16, 2013 at 11:07 PM, Edward J. Yoon edwardy...@apache.org
 wrote:

  The required action has been taken, so let me close this thread again.
  I apologize again for my mistake.
 
  The Sponsors are changed as following:
 
   == Champion ==
 
* Alex Karasulu akarasulu AT apache DOT org
 
== Nominated Mentors ==
 
 * Alex Karasulu akarasulu AT apache DOT org
 * Mohammad Nour mnour AT apache DOT org
 * Alan Cabrera adc AT apache DOT org
 
  The following IPMCers voted in favor:
 
   * Mohammed Nour El-Din
   * Alex Karasulu
   * Tommaso Teofili
   * Chris Mattmann
   * Christian Grobmeier
   * Niall Pemberton
 
  Thanks.
 
 
 Actually Edward we've discussed this within the Incubator PMC and the plan
 is to respect the original vote and leave you on as champion and mentor,
 the only change being the additional mentors. You're an Officer of the ASF
 which is close enough and there are now a lot of mentors who can provide
 any additional help should it be needed. Sorry from the Incubator that this
 got into such a mess.

...ant




-- 
Best Regards,
-- Alex

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[Alex Karasulu]

Looks like we can call this finally closed and approved. Edward I think we
can carry forward now.


On Sat, Mar 16, 2013 at 10:23 AM, Christian Grobmeier
grobme...@gmail.comwrote:

  True. I'm totally down with your reasoning.
 
  But don't you think it might be a formality we need to comply with,
 even if
  it does not make sense at this stage?
 
 
  There has been a vote, which passed with enough binding votes, no one has
  -1'd, and no one has retracted their vote. Lets wait till Monday and if
 the
  majority vote still passes just carry on with the additional mentors. I
  hope no one does -1, theres several experienced mentors now so nothing
  really to be gained from forcing some new vote.
 
 ...ant

 As already mentioned I am also +1 to this proposal now,


 --
 http://www.grobmeier.de
 https://www.timeandbill.de

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




-- 
Best Regards,
-- Alex

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[Alex Karasulu]

On Fri, Mar 15, 2013 at 10:21 AM, Edward J. Yoon edwardy...@apache.orgwrote:

  could you please close the Create MRQL tasks in the Infra Jira until
  the situation has been cleared up. Whenever this all has been sorted
  out you can reopen the issues.

 Sure.

 Since this might not be fixed soon, proposal can be changed
 (especially corporation volunteers). And, thank you for your
 suggestion, but I'm already in initial committers list.

 To IPMC, I would request you to focus more on reviewing Proposal in
 the future. The opportunity of MRQL should not be faded by my mistake.


Bravo! There was no malice in the vote, just a simple mistake. If need be I
or Mo can take on the Champion role.

Are there others from the IPMC that would be interested in mentoring MRQL?

-- 
Best Regards,
-- Alex

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[Alex Karasulu]

On Fri, Mar 15, 2013 at 3:01 PM, ant elder ant.el...@gmail.com wrote:

 On Fri, Mar 15, 2013 at 12:16 PM, Alex Karasulu akaras...@apache.org
 wrote:

  On Fri, Mar 15, 2013 at 10:21 AM, Edward J. Yoon edwardy...@apache.org
  wrote:
 
could you please close the Create MRQL tasks in the Infra Jira
 until
the situation has been cleared up. Whenever this all has been sorted
out you can reopen the issues.
  
   Sure.
  
   Since this might not be fixed soon, proposal can be changed
   (especially corporation volunteers). And, thank you for your
   suggestion, but I'm already in initial committers list.
  
   To IPMC, I would request you to focus more on reviewing Proposal in
   the future. The opportunity of MRQL should not be faded by my mistake.
  
  
  Bravo! There was no malice in the vote, just a simple mistake. If need
 be I
  or Mo can take on the Champion role.
 
  Are there others from the IPMC that would be interested in mentoring
 MRQL?
 
  --
  Best Regards,
  -- Alex
 

 The champion role is really just to help the proposal through any
 discussion prior to being accepted as a poddling so thats been done and it
 makes little difference now.


True. I'm totally down with your reasoning.

But don't you think it might be a formality we need to comply with, even if
it does not make sense at this stage?

Mohammed had volunteered to be a mentor so
 lets continue as that and I'll add myself as mentor too just to help if
 anymore is needed. So that gives plenty of mentors, we don't need more
 voting for that as the Incubator PMC can update mentors as it sees fit. So
 lets just continue on with that and the poddling accepted.


Based on your presence as a mentor along with Mo and myself I see this
poddling as accepted as well. If there's pressure to fill the Champion role
it can be handled on demand.

Ted, Dave is this situation now more acceptable and does it alleviate your
concerns? If not we want to know why and take steps to rectify the
situation accordingly. I personally really appreciate your diligence on
this matter. As a mentor I should have caught the problems you sited but
because of the Champion's ex-VP role (Hama?) I thought he was a member of
both the ASF and the IPMC. I should have checked.

-- 
Thanks,
-- Alex

Re: [VOTE] Accept Tajo into the Apache Incubator

[Alex Karasulu]

Indeed congratulations everyone!


On Fri, Mar 8, 2013 at 3:50 AM, edward yoon edward.y...@oracle.com wrote:

 Congratz guys!


 On 3/8/2013 9:17 AM, Owen O'Malley wrote:

 With 11 binding +1's and 5 non-binding +1's the vote passes. Jakob, can
 you
 start the process for setting up the project?

 Thanks, all.

 -- Owen


 On Mon, Mar 4, 2013 at 4:35 PM, Alex Karasulu akaras...@apache.org
 wrote:

  On Sat, Mar 2, 2013 at 3:48 AM, Alex Karasulu akaras...@apache.org
 wrote:

  +1 (binding)


  Just as an FYI, I'm also a mentor of this project.

 --
 Best Regards,
 -- Alex


 --
 Best Regards, Edward J. Yoon
 @eddieyoon



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




-- 
Best Regards,
-- Alex

Re: [VOTE] Accept MRQL into the Incubator

[Alex Karasulu]

, and new distributed back-ends, thus sustaining enough
 research interest. Another risk is that, when graduate students who
 write code graduate, they may leave their work undocumented and
 unfinished. We will strive to gain enough momentum to recruit
 additional committers from industry in order to eliminate these risks.

 == Inexperience with Open Source ==

 The initial developer has been involved with various projects whose
 source code has been released under open source license, but he has no
 prior experience on contributing to open-source projects. With the
 guidance from other more experienced committers and participants, we
 expect that the meritocracy rules will have a positive influence on
 this project.

 == Homogeneous Developers ==

 The initial committer comes from academia. However, given the interest
 we have seen in the project, we expect the diversity to improve in the
 near future.

 == Reliance on Salaried Developers ==

 Currently, the MRQL code was developed on the committer's volunteer
 time. In the future, UTA graduate students who will do some of the
 coding may be supported by UTA and funding agencies, such as NSF.

 == Relationships with Other Apache Products ==

 MRQL has some overlapping functionality with Hive and Tajo, which are
 Data Warehouse systems for Hadoop, and with Drill, which is an
 interactive data analysis system that can process nested data. MRQL
 has a more powerful data model, in which any form of nested data, such
 as XML and JSON, can be defined as a user-defined datatype. More
 importantly, complex data analysis tasks, such as PageRank, k-means
 clustering, and matrix multiplication and factorization, can be
 expressed as short SQL-like queries, while the MRQL system is able to
 evaluate these queries efficiently. Furthermore, the MRQL system can
 run these queries in BSP mode, in addition to MapReduce mode, thus
 achieving low latency and speed, which are also Drill's goals.
 Nevertheless, we will welcome and encourage any help from these
 projects and we will be eager to make contributions to these projects
 too.

 == An Excessive Fascination with the Apache Brand ==

 The Apache brand is likely to help us find contributors and reach out
 to the open-source community. Nevertheless, since MRQL depends on
 Apache projects (Hadoop and Hama), it makes sense to have our software
 available as part of this ecosystem.

 = Documentation =

 Information about MRQL can be found at http://lambda.uta.edu/mrql/

 = Initial Source =

 The initial MRQL code has been released as part of a research project
 developed at the University of Texas at Arlington under the Apache 2.0
 license for the past two years. The source code is currently hosted
 on GitHub at: 
 https://github.com/fegaras/**mrqlhttps://github.com/fegaras/mrqlMRQL’s 
 release artifact
 would consist of a single tarball of packaging and test code.

 = External Dependencies =

 The MRQL source code is already licensed under the Apache License,
 Version 2.0. MRQL uses JLine which is distributed under the BSD
 license.

 = Cryptography =

 Not applicable.

 = Required Resources =

 == Mailing Lists ==

 * mrql-private
 * mrql-dev
 * mrql-user

 == Subversion Directory ==

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

 == Issue Tracking ==

 * A JIRA issue tracker, MRQL

 == Wiki ==

  * Moinmoin wiki, http://wiki.apache.org/mrql

 = Initial Committers =

 * Leonidas Fegaras fegaras AT cse DOT uta DOT edu
 * Upa Gupta upa.gupta AT mavs DOT uta DOT edu
 * Edward J. Yoon edwardyoon AT apache DOT org
 * Maqsood Alam maqsoodalam AT hotmail DOT com
 * John Hope john.hope AT oracle DOT com
 * Mark Wall mark.wall AT oracle DOT com
 * Kuassi Mensah kuassi.mensah AT oracle DOT com
 * Ambreesh Khanna ambreesh.khanna AT oracle DOT com
 * Karthik Kambatla kasha AT cloudera DOT com

 = Affiliations =

 * Leonidas Fegaras (University of Texas at Arlington)
 * Upa Gupta (University of Texas at Arlington)
 * Edward J. Yoon (Oracle corp)
 * Maqsood Alam (Oracle corp)
 * John Hope (Oracle corp)
 * Mark Wall (Oracle corp)
 * Kuassi Mensah (Oracle corp)
 * Ambreesh Khanna (Oracle corp)
 * Karthik Kambatla (Cloudera)

 = Sponsors =

 == Champion ==

 * Edward J. Yoon edwardyoon AT apache DOT org

 == Nominated Mentors ==

 * Alex Karasulu akarasulu AT apache DOT org
 * Edward J. Yoon edwardyoon AT apache DOT org

 == Sponsoring Entity ==

 Incubator PMC




-- 
Best Regards,
-- Alex

Re: [PROPOSAL] MRQL for the Apache Incubator

[Alex Karasulu]

On Mon, Mar 4, 2013 at 12:31 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Sat, Mar 2, 2013 at 7:12 AM, Leonidas Fegaras fega...@cse.uta.edu
 wrote:
  == Champion ==
  * Edward J. Yoon edwardyoon AT apache DOT org
  == Nominated Mentors ==
  * Alex Karasulu akarasulu AT apache DOT org
 ...

 Is Edward going to stay on as a mentor as well?

 Two (active) mentors is the bare minimum IMO.


I suspect so but let's hear from Edward himself.

Best Regards,
-- Alex

Re: [VOTE] Accept Tajo into the Apache Incubator

[Alex Karasulu]

On Sat, Mar 2, 2013 at 3:48 AM, Alex Karasulu akaras...@apache.org wrote:

 +1 (binding)


Just as an FYI, I'm also a mentor of this project.

-- 
Best Regards,
-- Alex

Re: [VOTE] Accept Tajo into the Apache Incubator

[Alex Karasulu]

+1 (binding)


On Sat, Mar 2, 2013 at 2:16 AM, Roman Shaposhnik ro...@shaposhnik.orgwrote:

 +1 (binding).

 I would also encourage you guys to take a look at Apache Bigtop
 as a way of integrating with the rest of Hadoop ecosystem and
 bring more testing into the fold.

 Looking forward to working with you!

 Thanks,
 Roman.

 On Thu, Feb 28, 2013 at 10:11 AM, Hyunsik Choi hyun...@apache.org wrote:
  Hi Folks,
 
  I'd like to call a VOTE for acceptance of Tajo into the Apache incubator.
  The vote will close on Mar 7 at 6:00 PM (PST).
 
  [] +1 Accept Tajo into the Apache incubator
  [] +0 Don't care.
  [] -1 Don't accept Tajo into the incubator because...
 
  Full proposal is pasted at the bottom on this email, and the
 corresponding
  wiki is http://wiki.apache.org/incubator/TajoProposal.
 
  Only VOTEs from Incubator PMC members are binding, but all are welcome to
  express their thoughts.
 
  Thanks,
  Hyunsik
 
  PS: From the initial discussion, the main changes are that I've added 4
 new
  committers. Also, I've revised some description of Known Risks because
 the
  initial committers have been diverse.
 
  
  Tajo Proposal
 
  = Abstract =
 
  Tajo is a distributed data warehouse system for Hadoop.
 
 
  = Proposal =
 
  Tajo is a relational and distributed data warehouse system for Hadoop.
 Tajo
  is designed for low-latency and scalable ad-hoc queries, online
 aggregation
  and ETL on large-data sets by leveraging advanced database techniques. It
  supports SQL standards. Tajo is inspired by Dryad, MapReduce, Dremel,
  Scope, and parallel databases. Tajo uses HDFS as a primary storage layer,
  and it has its own query engine which allows direct control of
 distributed
  execution and data flow. As a result, Tajo has a variety of query
  evaluation strategies and more optimization opportunities. In addition,
  Tajo will have a native columnar execution and and its optimizer. Tajo
 will
  be an alternative choice to Hive/Pig on the top of MapReduce.
 
 
  = Background =
 
  Big data analysis has gained much attention in the industrial. Open
 source
  communities have proposed scalable and distributed solutions for ad-hoc
  queries on big data. However, there is still room for improvement.
 Markets
  need more faster and efficient solutions. Recently, some alternatives
  (e.g., Cloudera's Impala and Amazon Redshift) have come out.
 
 
  = Rationale =
 
  There are a variety of open source distributed execution engines (e.g.,
  hive, and pig) running on the top of MapReduce. They are limited by MR
  framework. They cannot directly control distributed execution and data
  flow, and they just use MR framework. So, they have limited query
  evaluation strategies and optimization opportunities. It is hard for them
  to be optimized for a certain type of data processing.
 
 
  = Initial Goals =
 
  The initial goal is to write more documents to describe Tajo's internal.
 It
  will be helpful to recruit more committers and to build a solid
 community.
  Then, we will make milestones for short/long term plans.
 
 
  = Current Status =
 
  Tajo is in the alpha stage. Users can execute usual SQL queries (e.g.,
  selection, projection, group-by, join, union and sort) except for nested
  queries. Tajo provides various row/column storage formats, such as CSV,
  RowFile (a row-store file we have implemented), RCFile, and Trevni, and
 it
  also has a rudimentary ETL feature to transform one data format to
 another
  data format. In addition, Tajo provides hash and range repartitions. By
  using both repartition methods, Tajo processes aggregation, join, and
 sort
  queries over a number of cluster nodes. To evaluate the performance, we
  have carried out benchmark test using TPC-H 1TB on 32 cluster nodes.
 
 
  == Meritocracy ==
 
  We will discuss the milestone and the future plan in an open forum. We
 plan
  to encourage an environment that supports a meritocracy. The contributors
  will have different privileges according to their contributions.
 
 
  == Community ==
 
  Big data analysis has gained attention from open source communities,
  industrial and academic areas. Some projects related to Hadoop already
 have
  very large and active communities. We expect that Tajo also will
 establish
  an active community. Since Tajo already works for some features and is in
  the alpha stage, it will attract a large community soon.
 
 
  == Core Developers ==
 
  Core developers are a diverse group of developers, many of which are very
  experienced in open source and the Apache Hadoop ecosystem.
 
   * Eli Reisman ereisman AT apache DOT org
 
   * Henry Saputra hsaputra AT apache DOT org
 
   * Hyunsik Choi hyunsik AT apache DOT org
 
   * Jae Hwa Jung jhjung AT gruter DOT com
 
   * Jihoon Son ghoonson AT gmail DOT com
 
   * Jin Ho Kim jhkim AT gruter DOT com
 
   * Roshan Sumbaly rsumbaly AT gmail DOT com
 
   * Sangwook Kim swkim AT inervit DOT com
 
   * Yi A Liu yi DOT a DOT liu AT intel DOT 

Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Alex Karasulu]

+1 (binding)


On Sat, Feb 16, 2013 at 4:08 AM, Arun C Murthy a...@hortonworks.com wrote:

 +1 (binding)

 Arun

 On Feb 14, 2013, at 5:26 PM, Devaraj Das wrote:

  Hi Folks,
 
  Thanks for participating in the discussion. I'd like to call a VOTE
  for acceptance of Apache Knox Hadoop Gateway Project into the
  Incubator. The vote will close on Feb 21 at 6:00 p.m.
 
  [ ]  +1 Accept Apache Open Climate Workbench into the Incubator
  [ ]  +0 Don't care.
  [ ]  -1 Don't accept Apache Open Climate Workbench into the Incubator
 because...
 
  Full proposal is pasted at the bottom of this email, and the
  corresponding wiki is http://wiki.apache.org/incubator/knox. Only
  VOTEs from Incubator PMC members are binding.
 
  Here's my +1 (binding).
 
  Thanks,
  Devaraj.
 
  p.s. In the last day, Tom White has been added as a mentor, and
  Venkatesh Seetharam has been added in the list of initial committers.
 
  
  Knox Gateway Proposal
 
  Abstract
 
  Knox Gateway is a system that provides a single point of secure access
  for Apache Hadoop clusters.
 
  Proposal
 
  The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
  single point of authentication and access for Apache Hadoop services
  in a cluster. The goal is to simplify Hadoop security for both users
  (i.e. who access the cluster data and execute jobs) and operators
  (i.e. who control access and manage the cluster). The Gateway runs as
  a server (or cluster of servers) that serve one or more Hadoop
  clusters.
 
  Provide perimeter security to make Hadoop security setup easier
  Support authentication and token verification security scenarios
  Deliver users a single cluster end-point that aggregates capabilities
  for data and jobs
  Enable integration with enterprise and cloud identity management
 environments
 
  Background
 
  An Apache Hadoop cluster is presented to consumers as a loose
  collection of independent services. This makes it difficult for users
  to interact with Hadoop since each service maintains it’s own method
  of access and security. As well, for operators, configuration and
  administration of a secure Hadoop cluster is a complex and many Hadoop
  clusters are insecure as a result.
 
  The goal of the project is to provide coverage for all existing Hadoop
  ecosystem projects. In addition, the project will be extensible to
  allow for new and/or proprietary Hadoop components without requiring
  changes to the gateway source code. The gateway is expected to run in
  a DMZ environment where it will provide controlled access to these
  Hadoop services. In this way Hadoop clusters can be protected by a
  firewall and only limited access provided through the firewall for the
  gateway. The authentication components of the gateway will be modular
  and extensible such that it can be integrated with existing security
  infrastructure.
 
  Rationale
 
  Organizations that are struggling with Hadoop cluster security result
  in a) running Hadoop without security or b) slowing adoption of
  Hadoop. The Gateway aims to provide perimeter security that integrates
  more easily into existing organizations’ security infrastructure.
  Doing so will simplify security for these organizations and benefit
  all Hadoop stakeholders (i.e. users and operators). Additionally,
  making a dedicated perimeter security project part of the Apache
  Hadoop ecosystem will prevent fragmentation in this area and further
  increase the value of Hadoop as a data platform.
 
  Current Status
 
  Prototype available, developed by the list of initial committers.
 
  Meritocracy
 
  We desire to build a diverse developer community around Gateway
  following the Apache Way. We want to make the project open source and
  will encourage contributors from multiple organizations following the
  Apache meritocracy model.
 
  Community
 
  We hope to extend the user and developer base in the future and build
  a solid open source community around Gateway. Apache Hadoop has a
  large ecosystem of open source projects, each with a strong community
  of contributors. All project communities in this ecosystem have an
  opportunity to participate in the advancement of the Gateway project
  because ultimately, Gateway will enable the security capabilities of
  their project to be more enterprise friendly.
 
  Core Developers
 
  Gateway is currently being developed by several engineers from
  Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
  and Sumit Mohanty. All the engineers have deep expertise in
  middleware, security  identity systems and are quite familiar with
  the Hadoop ecosystem.
 
  Alignment
 
  The ASF is a natural host for Gateway given that it is already the
  home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data
  software projects. Gateway is designed to solve the security
  challenges familiar to the Hadoop ecosystem family of projects.
 
  Known Risks
 
  Orphaned products  Reliance on Salaried 

Re: [PROPOSAL] Knox Hadoop Gateway Project

[Alex Karasulu]

I thought about this a bit last night. If y'all are interested I too could
also mentor the project. That should add some diversity to the mentors
list. I see value in it and would like to see this community succeed.

I'm not affiliated with any company.


On Mon, Feb 11, 2013 at 9:23 PM, Eric Sammer esam...@cloudera.com wrote:

 Kevin:

 Makes complete sense.

 I'd like to offer to join the project, if it's accepted for incubation. I'm
 a committer on MRUnit and Flume, and on the PMC for both. I've helped both
 projects through the incubation phase, and I also know a little bit about
 this Hadoop thing. ;)

 Thanks!


 On Mon, Feb 11, 2013 at 9:28 AM, Kevin Minder
 kevin.min...@hortonworks.comwrote:

  Hi Eric,
  Let me answer your second question first.
 
  Q: Is it your intention to provide job submissions and data ingestion
 APIs
  for MR and HDFS, respectively?
  A: Yes we plan to progress the project to cover all existing ecosystem
  projects.  In addition the project is based on a modular framework that
  allows for each extension to cover services that are either new or
  proprietary.  Certainly there exist very high volume data ingest use
 cases
  for which using a gateway may be impractical but in general the idea is
 to
  support all required client interaction with Hadoop via the gateway.
 
  Now for your first question...
 
  Q: Can you explain a bit more about what the target use case is?
  A: One typical use case will be that the gateway will run in a DMW.  It
  will as you say be integrations with various directory services and is
  extensible to cover those not included.  The gateway will then propagate
  the identity into the Hadoop cluster using Hadoop specific mechanisms.
  The
  key point is that there will typically be a single port open on the
 client
  side to the gateway.  The Hadoop cluster is firewalled, only providing
  access to the Hadoop services to the gateway instances.
  A: Another use case is that an organization is already using some SSO
  solution and the gateway would be integrated with that to verify any SSO
  token and then propagate the identity to the Hadoop services.
 
  I will collect this and add it to the proposal wiki once I have privs to
  create the page.
 
  Thanks!
  Kevin.
 
 
  On 2/11/13 12:03 PM, Eric Sammer wrote:
 
  Kevin:
 
  Interesting proposal. Can you explain a bit more about what the target
 use
  case is? It sounds like there's SSO-ish functionality (presumably a
 doAs()
  machine) with integration with directory services, but the proposal also
  mentions a single point for data and jobs. Is it your intention to
  provide job submissions and data ingestion APIs for MR and HDFS,
  respectively? Do you plan to target other ecosystem projects such as
  HBase?
  Sorry if I missed this in the proposal.
 
  Thanks!
 
 
  On Mon, Feb 11, 2013 at 6:55 AM, Kevin Minder
  kevin.min...@hortonworks.com**wrote:
 
   Knox Gateway Proposal
 
  == Abstract ==
 
  Knox Gateway is a system that provides a single point of secure access
  for
  Apache Hadoop clusters.
 
  == Proposal ==
 
  The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
 single
  point of authentication and access for Apache Hadoop services in a
  cluster.
  The goal is to simplify Hadoop security for both users (i.e. who access
  the
  cluster data and execute jobs) and operators (i.e. who control access
 and
  manage the cluster). The Gateway runs as a server (or cluster of
 servers)
  that serve one or more Hadoop clusters.
 
  Provide perimeter security to make Hadoop security setup easier
  Support authentication and token verification security scenarios
  Deliver users a single cluster end-point that aggregates capabilities
 for
  data and jobs
  Enable integration with enterprise and cloud identity management
  environments
 
  == Background ==
 
  An Apache Hadoop cluster is presented to consumers as a loose
 collection
  of independent services. This makes it difficult for users to interact
  with
  Hadoop since each service maintains it’s own method of access and
  security.
  As well, for operators, configuration and administration of a secure
  Hadoop
  cluster is a complex and many Hadoop clusters are insecure as a result.
 
  == Rationale ==
 
  Organizations that are struggling with Hadoop cluster security result
 in
  a) running Hadoop without security or b) slowing adoption of Hadoop.
 The
  Gateway aims to provide perimeter security that integrates more easily
  into
  existing organizations’ security infrastructure. Doing so will simplify
  security for these organizations and benefit all Hadoop stakeholders
  (i.e.
  users and operators). Additionally, making a dedicated perimeter
 security
  project part of the Apache Hadoop ecosystem will prevent fragmentation
 in
  this area and further increase the value of Hadoop as a data platform.
 
  == Current Status ==
 
  Prototype available, developed by the list of initial committers.
 
  === Meritocracy ===
 

Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive

[Alex Karasulu]

On Tue, Feb 12, 2013 at 2:49 PM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 Hi,

 On Sat, Feb 9, 2013 at 6:03 AM, Mattmann, Chris A (388J)
 chris.a.mattm...@jpl.nasa.gov wrote:
  ...I'm -1 on this graduation...

 -1 from me as well, I agree with Chris' points.


Yes these were good points however I don't think the HCatalog community has
enough critical mass for a TLP at this point in time. I think this and the
overwhelming dependencies on Hive made the community favor merging under
the Hive TLP. I can understand both points of view coming from Chris and
from Alan.


 This looks either like an umbrella project (which we don't want
 anymore) or a PMC not trusting its committers.

 IMO the options are either graduating Hive as a TLP (assuming the


Bertrand I am presuming you meant HCatalog as a TLP here ...


 podling is in good standing for that to happen), or having Hive adopt
 the HCatalog code *and its committers*.


It is unfortunate that the Hive TLP does not trust the HCatalog community
enough to merge the two. However if we're looking at a new TLP for HCatalog
I think we're going to have to continue trying to build community a bit
longer.

-- 
Best Regards,
-- Alex

Re: [PROPOSAL] Knox Hadoop Gateway Project

[Alex Karasulu]

Hi Kevin,

This sounds like a much needed project. I endorse the concept but as
Bertrand pointed out you need a bit more diversity. Otherwise I see no
problem with moving forward.

Good luck!


On Mon, Feb 11, 2013 at 4:55 PM, Kevin Minder
kevin.min...@hortonworks.comwrote:

 Knox Gateway Proposal

 == Abstract ==

 Knox Gateway is a system that provides a single point of secure access for
 Apache Hadoop clusters.

 == Proposal ==

 The Knox Gateway (“Gateway” or “Knox”) is a system that provides a single
 point of authentication and access for Apache Hadoop services in a cluster.
 The goal is to simplify Hadoop security for both users (i.e. who access the
 cluster data and execute jobs) and operators (i.e. who control access and
 manage the cluster). The Gateway runs as a server (or cluster of servers)
 that serve one or more Hadoop clusters.

 Provide perimeter security to make Hadoop security setup easier
 Support authentication and token verification security scenarios
 Deliver users a single cluster end-point that aggregates capabilities for
 data and jobs
 Enable integration with enterprise and cloud identity management
 environments

 == Background ==

 An Apache Hadoop cluster is presented to consumers as a loose collection
 of independent services. This makes it difficult for users to interact with
 Hadoop since each service maintains it’s own method of access and security.
 As well, for operators, configuration and administration of a secure Hadoop
 cluster is a complex and many Hadoop clusters are insecure as a result.

 == Rationale ==

 Organizations that are struggling with Hadoop cluster security result in
 a) running Hadoop without security or b) slowing adoption of Hadoop. The
 Gateway aims to provide perimeter security that integrates more easily into
 existing organizations’ security infrastructure. Doing so will simplify
 security for these organizations and benefit all Hadoop stakeholders (i.e.
 users and operators). Additionally, making a dedicated perimeter security
 project part of the Apache Hadoop ecosystem will prevent fragmentation in
 this area and further increase the value of Hadoop as a data platform.

 == Current Status ==

 Prototype available, developed by the list of initial committers.

 === Meritocracy ===

 We desire to build a diverse developer community around Gateway following
 the Apache Way. We want to make the project open source and will encourage
 contributors from multiple organizations following the Apache meritocracy
 model.

 === Community ===

 We hope to extend the user and developer base in the future and build a
 solid open source community around Gateway. Apache Hadoop has a large
 ecosystem of open source projects, each with a strong community of
 contributors. All project communities in this ecosystem have an opportunity
 to participate in the advancement of the Gateway project because
 ultimately, Gateway will enable the security capabilities of their project
 to be more enterprise friendly.

 === Core Developers ===

 Gateway is currently being developed by several engineers from Hortonworks
 - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower and Sumit Mohanty.
 All the engineers have deep expertise in middleware, security  identity
 systems and are quite familiar with the Hadoop ecosystem.

 === Alignment ===

 The ASF is a natural host for Gateway given that it is already the home of
 Hadoop, Hive, Pig, HBase, Oozie and other emerging big data software
 projects. Gateway is designed to solve the security challenges familiar to
 the Hadoop ecosystem family of projects.

 == Known Risks ==

 === Orphaned products  Reliance on Salaried Developers ===

 The core developers plan to work full time on the project. We believe that
 this project will be of general interest to many Hadoop users and will
 attract a diverse set of contributors. We intend to demonstrate this by
 having contributors from several organizations recognized as committers by
 the time Knox graduates from incubation.

 === Inexperience with Open Source ===

 All of the core developers are active users and followers of open source.
 As well, Hortonworks has a strong heritage of success with contributions to
 Apache Hadoop Projects.

 === Homogeneous Developers ===

 The current core developers are from Hortonworks, however, we hope to
 establish a developer community that includes contributors from several
 corporations.

 === Reliance on Salaried Developers ===

 Currently, the developers are paid to do work on Gateway. However, once
 the project has a community built around it, we expect to get committers
 and developers from outside the current core developers.

 === Relationships with Other Apache Products ===

 Gateway is going to be used by the users and operators of Hadoop, and the
 Hadoop ecosystem in general.

 === A Excessive Fascination with the Apache Brand ===

 Our interest in developing Gateway in Apache project is to follow an
 established development model, 

Re: [VOTE] Graduate HCatalog from the incubator and become part of Hive

[Alex Karasulu]

+1 binding


On Tue, Feb 5, 2013 at 11:28 PM, Owen O'Malley omal...@apache.org wrote:

 +1 (binding)


 On Tue, Feb 5, 2013 at 1:26 PM, Jakob Homan jgho...@gmail.com wrote:

  +1 Binding.
 
 
  On Tue, Feb 5, 2013 at 1:24 AM, Alexander Alten-Lorenz
  wget.n...@gmail.comwrote:
 
   +1, non-binding
  
   - Alex
  
   On Feb 5, 2013, at 10:06 AM, Sushanth Sowmyan khorg...@gmail.com
  wrote:
  
And my axe! Erm... I mean, my +1.
   
   
On Mon, Feb 4, 2013 at 10:18 PM, Alan Gates ga...@hortonworks.com
   wrote:
FYI.
   
Alan.
   
Begin forwarded message:
   
From: Alan Gates ga...@hortonworks.com
Date: February 4, 2013 10:18:09 PM PST
To: hcatalog-...@incubator.apache.org
Subject: [VOTE] Graduate HCatalog from the incubator and become
 part
   of Hive
   
The Hive PMC has voted to accept HCatalog as a submodule of Hive.
   You
   can see the vote thread at
  
 
 http://mail-archives.apache.org/mod_mbox/hive-dev/201301.mbox/%3cCACf6RrzktBYD0suZxn3Pfv8XkR=vgwszrzyb_2qvesuj2vh...@mail.gmail.com%3e
 .
   We now need to vote to graduate from the incubator and become a
   submodule of Hive.  This entails the following:
   
1) the establishment of an HCatalog submodule in the Apache Hive
   Project;
2) the adoption of the Apache HCatalog codebase into the Hive
  HCatalog
   submodule; and
3) adding all currently active HCatalog committers as submodule
   committers on the Hive HCatalog submodule.
   
Definitions for all these can be found in the (now adopted) Hive
   bylaws at
  
 
 https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Bylaws+for+Submodule+Committer
   .
   
This vote will stay open for at least 72 hours (thus 23:00 PST on
   2/7/13).  PPMC members votes are binding in this vote, though input
 from
   all is welcome.
   
If this vote passes the next step will be to submit the graduation
   motion to the Incubator PMC.
   
Here's my +1.
   
Alan.
   
  
   --
   Alexander Alten-Lorenz
   http://mapredit.blogspot.com
   German Hadoop LinkedIn Group: http://goo.gl/N8pCF
  
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 




-- 
Best Regards,
-- Alex

Re: [VOTE][PROPOSAL] Hadoop Development Tools

[Alex Karasulu]

+1


On Wed, Nov 7, 2012 at 12:55 AM, Suresh Marru sma...@apache.org wrote:

 + 1 (binding)

 Suresh

 On Nov 6, 2012, at 10:57 AM, Adam Berry ambe...@yahoo-inc.com wrote:

  Hello,
 
  This proposal has been open for discussion for a a few weeks, so now
 submitting for a vote for this project to be accepted into the incubator.
 
  Cheers,
  Adam Berry
 
  = HDT (Hadoop Development Tools) =
 
  == Abstract ==
  Tools to support developing applications that use Apache Hadoop from
 within Eclipse.
 
  == Proposal ==
  Hadoop Development Tools are a set of extensions to Eclipse providing
 support for creating, launching and debugging distributed applications, as
 well as interacting with HDFS filesystems. This work will build on the
 existing Map Reduce Tools present in the Apache Hadoop project.
 
  == Background ==
  Map Reduce Tools have existed as part of contrib for Apache Hadoop.
 Unfortunately they are source tied to a single version of Hadoop, and
 development has stalled, with little movement past the Hadoop 0.20 line.
 
  == Rationale ==
  Support for newer versions of Hadoop from within Eclipse is regularly
 raised on the Hadoop mailing lists, so there is a clear need to drive these
 tools forward. Development tools generally are worked on separate from the
 target tools/platform, separating the tools out will allow for supporting
 multiple versions, so a developer could work with a heterogeneous
 environment.
 
  == Initial Goals ==
  * Give the tools project a home of its own.
  * Port current MapReduce tools feature set to all current release lines
 of Hadoop in a single Eclipse install.
  * Documentation and tutorials for all features.
  * Publish Eclipse update site, and join Eclipse marketplace listing.
  * Establish release cycle that combines support for Hadoop and Eclipse
 release cycles.
  * Look to build support for YARN, MRUnit and possibly other
 Hadoop-related projects.
 
  == Current Status ==
  The source for the current MapReduceTools lives in the contrib section
 of the Hadoop source. In its current implementation it is tied to the
 version of Hadoop against which it is compiled. The layout and API that it
 was developed with means that it can only be used with the 0.20 or 1.0
 Hadoop releases, the new layout and YARN api introduced with the 0.23 and
 2.0 lines are not supported.
 
 
  === Meritocracy ===
  Several people and companies have already expressed an interest in
 contributing to this project, and we hope to attract additional interest
 during the proposal discussion. We plan to invest and support a meritocracy
 that attracts, invites, and supports newcomers to build a vibrant and
  diverse community.
 
  === Community ===
  The target community is developers who are working developing Map/Reduce
 applications against Hadoop. Given the success of Hadoop the target group
 is likely to be quite large. Separation from the Hadoop community would
 make it easier to support multiple versions of hadoop, as well as merging
 the release cycles of Hadoop and Eclipse to provide predictable iteration
 and improvement in the toolset.
 
  === Core Developers ===
  The initial list of developers includes people experienced with Hadoop
 and developing against the Eclipse platform.
  * Adam Berry (amberry at yahoo-inc dot com)
  * Jeffrey Zemerick (jeffrrey at mtnfog dot com)
  * Evert Lammerts (Evert dot Lammerts at sara dot nl)
  * Simone Gianni (simoneg at apache dot org)
 
  === Alignment ===
  Hadoop Development Tools aligns with both Hadoop and Eclipse. Hadoop as
 the platform for the development target, and Eclipse as the IDE platform
 used as the base for the tools.
 
  == Known Risks ==
 
  === Orphaned Products ===
 
  === Inexperience with Open Source ===
  The committers have experience with Apache and Eclipse open source
 development.
 
  === Reliance on Salaried Developers ===
  Hadoop Development Tools will be developed with a mix of salaried and
 volunteer time.
 
  === Relationships with Other Apache Projects ===
  Hadoop Development Tools is closely related to Apache Hadoop.
 
  === An Excessive Fascination with the Apache Brand ===
  Given the success of Hadoop and associated projects, Apache is the
 natural place for the Hadoop Development Tools. Chris Mattman suggested the
 Apache Incubator as appropriate on the Hadoop general mailing list
 following the success that MRUnit had taking the path from Hadoop contrib
 to an Apache top level project.
 
  == Documentation ==
  Documentation for the current tools can be found at
 http://wiki.apache.org/hadoop/EclipsePlugIn
 
  == Initial Source ==
 
 http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/src/contrib/eclipse-plugin/
 
  ==  Source and Intellectual Property Submission Plan ==
  The source, and any suggested initial patches, are already hosted either
 in Apache’s Subversion or JIRA.
 
  ==  External Dependencies ==
  Eclipse Platform
  Eclipse Java Development Tools
 
  ==  Cryptography 

Re: [VOTE] Accept Drill into the Apache Incubator

[Alex Karasulu]

+1 (binding)

On Wed, Aug 8, 2012 at 8:33 AM, Mattmann, Chris A (388J) 
chris.a.mattm...@jpl.nasa.gov wrote:

 +1 (binding). Good luck and sounds cool!

 Cheers,
 Chris

 On Aug 7, 2012, at 7:41 PM, Ted Dunning wrote:

  I would like to call a vote for accepting Drill for incubation in the
  Apache Incubator. The full proposal is available below.  Discussion
  over the last few days has been quite positive.
 
  Please cast your vote:
 
  [ ] +1, bring Drill into Incubator
  [ ] +0, I don't care either way,
  [ ] -1, do not bring Drill into Incubator, because...
 
  This vote will be open for 72 hours and only votes from the Incubator
  PMC are binding.  The start of the vote is just before 3AM UTC on 8
  August so the closing time will be 3AM UTC on 11 August.
 
  Thank you for your consideration!
 
  Ted
 
  http://wiki.apache.org/incubator/DrillProposal
 
  = Drill =
 
  == Abstract ==
  Drill is a distributed system for interactive analysis of large-scale
  datasets, inspired by
  [[http://research.google.com/pubs/pub36632.html|Google's Dremel]].
 
  == Proposal ==
  Drill is a distributed system for interactive analysis of large-scale
  datasets. Drill is similar to Google's Dremel, with the additional
  flexibility needed to support a broader range of query languages, data
  formats and data sources. It is designed to efficiently process nested
  data. It is a design goal to scale to 10,000 servers or more and to be
  able to process petabyes of data and trillions of records in seconds.
 
  == Background ==
  Many organizations have the need to run data-intensive applications,
  including batch processing, stream processing and interactive
  analysis. In recent years open source systems have emerged to address
  the need for scalable batch processing (Apache Hadoop) and stream
  processing (Storm, Apache S4). In 2010 Google published a paper called
  Dremel: Interactive Analysis of Web-Scale Datasets, describing a
  scalable system used internally for interactive analysis of nested
  data. No open source project has successfully replicated the
  capabilities of Dremel.
 
  == Rationale ==
  There is a strong need in the market for low-latency interactive
  analysis of large-scale datasets, including nested data (eg, JSON,
  Avro, Protocol Buffers). This need was identified by Google and
  addressed internally with a system called Dremel.
 
  In recent years open source systems have emerged to address the need
  for scalable batch processing (Apache Hadoop) and stream processing
  (Storm, Apache S4). Apache Hadoop, originally inspired by Google's
  internal MapReduce system, is used by thousands of organizations
  processing large-scale datasets. Apache Hadoop is designed to achieve
  very high throughput, but is not designed to achieve the sub-second
  latency needed for interactive data analysis and exploration. Drill,
  inspired by Google's internal Dremel system, is intended to address
  this need.
 
  It is worth noting that, as explained by Google in the original paper,
  Dremel complements MapReduce-based computing. Dremel is not intended
  as a replacement for MapReduce and is often used in conjunction with
  it to analyze outputs of MapReduce pipelines or rapidly prototype
  larger computations. Indeed, Dremel and MapReduce are both used by
  thousands of Google employees.
 
  Like Dremel, Drill supports a nested data model with data encoded in a
  number of formats such as JSON, Avro or Protocol Buffers. In many
  organizations nested data is the standard, so supporting a nested data
  model eliminates the need to normalize the data. With that said, flat
  data formats, such as CSV files, are naturally supported as a special
  case of nested data.
 
  The Drill architecture consists of four key components/layers:
  * Query languages: This layer is responsible for parsing the user's
  query and constructing an execution plan.  The initial goal is to
  support the SQL-like language used by Dremel and
  [[https://developers.google.com/bigquery/docs/query-reference|Google
  BigQuery]], which we call DrQL. However, Drill is designed to support
  other languages and programming models, such as the
  [[http://www.mongodb.org/display/DOCS/Mongo+Query+Language|Mongo Query
  Language]], [[http://www.cascading.org/|Cascading]] or
  [[https://github.com/tdunning/Plume|Plume]].
  * Low-latency distributed execution engine: This layer is responsible
  for executing the physical plan. It provides the scalability and fault
  tolerance needed to efficiently query petabytes of data on 10,000
  servers. Drill's execution engine is based on research in distributed
  execution engines (eg, Dremel, Dryad, Hyracks, CIEL, Stratosphere) and
  columnar storage, and can be extended with additional operators and
  connectors.
  * Nested data formats: This layer is responsible for supporting
  various data formats. The initial goal is to support the column-based
  format used by Dremel. Drill is designed to support 

Re: Board will be proposing a new TLP

[Alex Karasulu]

On Sat, Jun 30, 2012 at 3:53 PM, Emmanuel Lécharny elecha...@gmail.com wrote:
 Le 6/30/12 2:23 PM, Jim Jagielski a écrit :

 Since all code was developed w/i the ASF, by ASF people, and
 is under the ALv2 (either implied/confirmed by the authors or
 explicit in the code itself), there is some debate on whether
 or not Incubation is even required...

 Sure we should go through incubation, to make sure the peeps being STV code
 *knows* about the Apache Way...

 Or is this simple non-sense ?

No I don't think this is non-sense. However note that as Jim pointed
out, the difference here, that would favor the direct TLP route, is
the fact that everyone working on the voting tool are already Apache
Committers and Members. Conceivably they already know the Apache
Way. Then again a quick incubation process might help get an extra
sanity check from the Incubator.

Your point makes sense considering outside participants to build a
larger community around the tool. Incubation might be a good
environment for a mass influx of new to Apache, interested parties
to participate. But it does not sound like they're going to be
directly involved, knocking on our doors immediately. Also there's no
IP to vet. I presume this is more a matter of making the software an
official Apache Product with PMC endorsed releases that other
organizations like OpenStack can use immediately.

+1 Setup TLP without incubation, yet I can understand arguments for a
quick incubation.

-- 
Best Regards,
-- Alex

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

Re: [VOTE] [PROPOSAL] Allura to enter the Incubator

[Alex Karasulu]

On Thu, Jun 21, 2012 at 10:35 PM, Daniel Gruno rum...@cord.dk wrote:

 On 06/21/2012 06:34 PM, Rich Bowen wrote:
  [ ] +1 I recommend that Allura becomes an Apache Incubator project



+1 (binding)

-- 
Best Regards,
-- Alex

Re: [PROPOSAL] Apache Parser

[Alex Karasulu]

On Fri, Jun 1, 2012 at 5:37 AM, Greg Stein gst...@gmail.com wrote:

 On May 31, 2012 5:31 AM, Greg Stein gst...@gmail.com wrote:
 ...
  (that said, I agree: this seems like it should be a proposal to
  Commons, so we just need to handle that redirection)

 And I didn't read the proposal closely enough, but took from Ralph's
 comment that this was some Java code. ... but no, it is a C-based project.
 Thus, I don't think Apache Commons has any bearing here.

 I'm +1 on the proposal.


Technically I'm a +1. Where else does an Apache Httpd style configuration
parser fit best? Immediately examples like Xerces come to mind of projects
with similar technical merit. BTW to me this has nothing to do with Java
vs. C code. The concept is sound.

My concern only rests on having enough committers to jell community around
it, even in the incubator. If we can get a couple more people committed,
not as mentors but as contributors (perhaps from local Apache communities),
then any concerns I may have vanish. I'm wondering just how a PPMC will
function.


 Give it a shot to build a community. That is part of what the Incubator is
 all about.


True. However this feels like the corner case of corner cases with a single
committer. I'd like to help Seungyoung get some committers first before
rushing to incubate. Perhaps we can ask the community now, who else is
interested as participating at the committer level?

Maybe (off the top of my head) the code base is small enough for an IP
clearance and this can be a contribution to the Apache Httpd project. This
way it has a chance to grow there with the support from that TLP? Maybe
this is a good Apache Labs project candidate.

At this point the Incubator just seems like a heavy weight process. I'm
thinking there's a better way.

-- 
Best Regards,
-- Alex

Re: [PROPOSAL] Apache Parser

[Alex Karasulu]

On Fri, Jun 1, 2012 at 9:11 AM, Alex Karasulu akaras...@apache.org wrote:



 On Fri, Jun 1, 2012 at 5:37 AM, Greg Stein gst...@gmail.com wrote:

 On May 31, 2012 5:31 AM, Greg Stein gst...@gmail.com wrote:
 ...
  (that said, I agree: this seems like it should be a proposal to
  Commons, so we just need to handle that redirection)

 And I didn't read the proposal closely enough, but took from Ralph's
 comment that this was some Java code. ... but no, it is a C-based project.
 Thus, I don't think Apache Commons has any bearing here.

 I'm +1 on the proposal.


 Technically I'm a +1. Where else does an Apache Httpd style configuration
 parser fit best? Immediately examples like Xerces come to mind of projects
 with similar technical merit. BTW to me this has nothing to do with Java
 vs. C code. The concept is sound.

 My concern only rests on having enough committers to jell community around
 it, even in the incubator. If we can get a couple more people committed,
 not as mentors but as contributors (perhaps from local Apache communities),
 then any concerns I may have vanish. I'm wondering just how a PPMC will
 function.


If there was a sponsoring PMC other than the Incubator this might not be
much of a concern.




 Give it a shot to build a community. That is part of what the Incubator is
 all about.


 True. However this feels like the corner case of corner cases with a
 single committer. I'd like to help Seungyoung get some committers first
 before rushing to incubate. Perhaps we can ask the community now, who else
 is interested as participating at the committer level?

 Maybe (off the top of my head) the code base is small enough for an IP
 clearance and this can be a contribution to the Apache Httpd project. This
 way it has a chance to grow there with the support from that TLP? Maybe
 this is a good Apache Labs project candidate.


Oh and regarding Apache Labs I was thinking this might be a special case. I
know Labs projects are for existing committers to start off internal
projects. But this route might not have the community fostering potential
as an incubating project.


 At this point the Incubator just seems like a heavy weight process. I'm
 thinking there's a better way.


Kind of torn and perplexed regarding this candidate. Looking forward to
hear more opinions on the matter.


 --
 Best Regards,
 -- Alex




-- 
Best Regards,
-- Alex

Re: [PROPOSAL] Apache Parser

[Alex Karasulu]

On Thu, May 31, 2012 at 12:31 PM, Greg Stein gst...@gmail.com wrote:

 On Thu, May 31, 2012 at 5:20 AM, Alex Karasulu akaras...@apache.org
 wrote:
 ...
  insufficient mass (from the committer perspective). We need a minimum of
 3
  committers to consider this a community applying to the Incubator.

 Careful... we need three for *acceptance*.


Ah 3 binding votes yes. But I thought we needed at least 3 committers for
critical mass to spark community growth. My bad.


 Many *proposals* arrive,
 asking for the necessary quorum of committers.


Is this quorum 3 committers?



 (that said, I agree: this seems like it should be a proposal to
 Commons, so we just need to handle that redirection)


That's what I was thinking.


 Cheers,
 -g

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




-- 
Best Regards,
-- Alex

Re: Shepherds for podling reports

[Alex Karasulu]

On Sat, May 5, 2012 at 6:27 PM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On May 2, 2012, at 1:53 AM, Jukka Zitting wrote:

 Hi,

 In order to better share the effort of reviewing podling reports and
 giving constructive feedback where needed, I'd like to propose
 something like the shepherd model the ASF board is using for project
 reports. For each report a single shepherd [*] is assigned
 responsibility for a deeper review of the report and any followups
 that may be needed. Of course anyone within the IPMC is still welcome
 to help in the review, and in any case the mentors of a podling should
 review and sign off on the reports of their podlings.

 Any volunteer shepherds? Please sign up by adding your name to [1].

 [1] http://wiki.apache.org/incubator/IncubatorShepherds
 [*] A shepherd watching over a podling... Perhaps someone has a better
 agricultural term in mind? :-)

 I feel that I should state my opinion, and this is just my humble opinion, 
 that the solution to a problem is not to add more process, bureaucracy, and 
 roles.

 It's my opinion that this task should be done by the mentors, period.  If 
 people have spare bandwidth they then should sign up to be a mentor.

 Just my 2 cents.

Thanks Alan, I always appreciate your input.

However I think Jukka is simply asking for more fresh eye balls to
help in the review before submission of the composite report. The
shear time, and volume of work required to properly review all those
Incubator Podling reports can be overwhelming for a single person:
delegation is very sensible.

I don't think there's more process or more bureaucracy. IMHO it's a
good, non-bureaucratic evolutionary step towards better management.
Honestly when I try to put myself into the IPMC Chair's perspective to
understand the amount of work and responsibility he has, I get
overwhelmed.

-- 
Best Regards,
-- Alex

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

Re: [VOTE] CloudStack for Apache Incubator

[Alex Karasulu]

+1 (binding)

-- 
Best Regards,
-- Alex

Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator

[Alex Karasulu]

On Sat, Apr 7, 2012 at 8:33 AM, Kevin Kluge kevin.kl...@citrix.com wrote:

 Brett, thanks for the comments.  I put some responses in line.

  -Original Message-
  From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett
 Porter
  Sent: Friday, April 06, 2012 4:53 PM
  To: general@incubator.apache.org
  Cc: general@incubator.apache.org
  Subject: Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator
 
  Hi Kevin,
 
  I made a couple of minor edits.
 
  A few more suggestions...
 
  I think you could drop the last sentence of the rationale. The ASF
 doesn't
  have any strategic goals to cover particular technology area.

 Sure, will remove it.

 
  Th alignment section looks fine as is, but it's not strictly necessary to
  speculate on other projects you might use. There's no requirement to
  depend on other ASF projects instead of other suitable choices.


This was actually nice to see because it showed just how many ASF projects
the software depends on but as you say it's not necessary.


  The addition of the dependency and license tables is informative, but I'd
  leave the actions and remarks for a status page later - as others have
 said
  these problems can be resolved in incubation.


+1


 That's good.  The presence of those columns makes the proposal a bit of a
 moving target -- either we edit them as we make progress on the
 unacceptable dependencies or the document becomes out of date.   I will
 remove them and start a separate, active document to track progress.

 
  On that note though - I believe java mail and the server API are
 available
  under compatible licenses.
 
  You've mentioned there are original contributors now less involved in the
  code. Are they likely to still be involved in other activities that are
 part of the
  decision making of the project?

 Yes, Will and Sheng are both influential.   Will does engineering
 management at Citrix and so has input on the day-day activities of many of
 the initial committers.  Sheng provides input on longer term direction for
 the project based on his observations across the industry.  Both will have
 opinions on how the project should be run.

 -kevin


 
  Thanks,
  Brett
 
  On 05/04/2012, at 4:03 PM, Kevin Kluge kevin.kl...@citrix.com wrote:
 
   I updated the proposal at
  http://wiki.apache.org/incubator/CloudStackProposal.   I have included
 the
  embedded source dependencies, binary dependencies, and contributor e-
  mail addresses.  There are some open questions in the dependencies (e.g.,
  treatment of dependencies that have no discernible license), but my
  impression is that these issues do not need resolution before entering
  incubation.  Please correct me if that's wrong.
  
   I believe the proposal is now complete, pending additional feedback.


These touch up changes pretty much complete the proposal and we're ready to
kick off a [VOTE] thread. Thoughts?

-- 
Best Regards,
-- Alex

Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator

[Alex Karasulu]

On Wed, Apr 4, 2012 at 1:00 PM, Mohammad Nour El-Din 
nour.moham...@gmail.com wrote:

 Hi...

 On Wed, Apr 4, 2012 at 9:41 AM, Martijn Dashorst 
 martijn.dasho...@gmail.com
  wrote:

  On Wed, Apr 4, 2012 at 7:57 AM, Kevin Kluge kevin.kl...@citrix.com
  wrote:
   Citrix is pursuing patents based on prior CloudStack work and expects
 to
  continue to do
   so in the future.  Citrix is getting these patents to protect the
  CloudStack user community.
   Consider the case where some other entity states that the use of
  CloudStack is infringing
   on their patents.  Citrix could use these patents to fight this entity
  and defend the
   community.  An incremental benefit is that if Citrix (or any other
  CloudStack-friendly
   entity) has a patent then that patent cannot be acquired by an
  unfriendly entity.
 
  Anyone with about $15B can buy Citrix, and start wreaking havoc with
  the patents. See Google with its acquisition of Motorola, or Oracle
  with its acquisition of Sun (Java?). Or Citrix can sell its patent
  portfolio to a shell company, keeping a license and let the shell
  start suing the rest of the world (see Apple, Microsoft etc). There
  are many avenues to abuse the patents.
 

 I read section 3 of [1], and AFAIU and if the above scenario hold does this
 mean that such company X can sue ASF for example ?


IANAL either but I can at least gauge this much from the PR side. If a
commercial entity decides to sue the ASF, a highly respected, non-profit
organization (charity), it will be the mother of all negative PR
campaigns: an instant kiss of death IMHO. Once kissed, you first turn into
an ugly SCO-like toad. Then you die a slow miserable lonely death that
everyone looks forward to. I think any company in their right mind would
consider this PR dimension and the impact that the action will inevitably
have on their image before deciding to litigate against the ASF.


 Sorry if it is a stupid
 question but I am no lawyer at all :).


Not stupid at all and perhaps someone can answer this for the both of us.

However I presume the worst for safety sake, you can always be litigated
against :-). But the best policy is good citizenship and diplomacy on our
part, which we've done well as a Foundation. That's why we have the respect
in the general community. This is why even if someone has a valid legal
case against us, the PR dimension will most likely thwart litigation.

-- 
Best Regards,
-- Alex

Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator

[Alex Karasulu]

On Wed, Apr 4, 2012 at 4:17 AM, Kevin Kluge kevin.kl...@citrix.com wrote:

 Thanks, Brett.  We appreciate your help.

 -kevin

 -Original Message-
 From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter
 Sent: Tuesday, April 03, 2012 5:28 PM
 To: general@incubator.apache.org
 Subject: Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator

 Hi Kevin,

 On 04/04/2012, at 3:17 AM, Kevin Kluge wrote:

  Hi All,
 
  We would like to propose CloudStack to be an Apache Incubator project.
 
  CloudStack provides control plane software that can be used to create an
 IaaS cloud. It includes an HTTP-based API for user and administrator
 functions and a web UI for user and administrator access. Administrators
 can provision physical infrastructure (e.g., servers, network elements,
 storage) into an instance of CloudStack, while end users can use the
 CloudStack self-service API and UI for the provisioning and management of
 virtual machines, virtual disks, and virtual networks.   Additional
 information is available at http://cloudstack.org/ and
 http://docs.cloudstack.org/.
 
  The draft proposal document is available at
 http://wiki.apache.org/incubator/CloudStackProposal.   There are a few
 incomplete sections in the proposal.  We have left XXX marks by those as
 reminders, and we'll complete those sections in the next few days as the
 proposal evolves.
 
  We're excited about the opportunity to work with ASF and the community
 to create an Incubator project for cloud orchestration.  We'll welcome all
 feedback on the proposal.  Thanks.

 The proposal looks good - I appreciate that you've called out some of the
 challenges directly.

 I'm able to help mentor the project, so I've added my name to the wiki.


I'd also like to help, been following you guys for some time and think you
have a good community around a great product. I've been looking for a solid
Java based alternative to oVirt before finding CloudStack. I also have
added myself to the wiki as a mentor.

-- 
Best Regards,
-- Alex

Re: CloudStack Incubation proposal

[Alex Karasulu]

On Wed, Apr 4, 2012 at 3:04 AM, Dennis E. Hamilton
dennis.hamil...@acm.orgwrote:

 Minor nit:

 In economic terms, Apache OpenOffice and LibreOffice are not complementary.

  - Dennis

 In computing, an example of complements are hardware and software.
  Software vendors want the hardware to be free (more for us!) and hardware
 vendors want the software to be free (more for us!).  Throw in
 telecommunication carriers, smartphones, and software and it gets really
 exciting.

 There is some other term needed for independent producers that deliver
 comparables while cooperating in areas of mutual interest.


A Nash Equilibrium perhaps?


 Although monopolistic competition arises (mines better than yours), it is
 moderated in the case of open-source efforts.  (Perhaps this is because
 there cannot be abuse of, let alone achievement of, monopoly power where
 feature differentiation is in the open-source code base.)

 -Original Message-
 From: Jim Jagielski [mailto:j...@apache.org]
 Sent: Tuesday, April 03, 2012 13:32
 To: general@incubator.apache.org
 Cc: Simon Phipps
 Subject: Re: CloudStack Incubation proposal


 On Apr 3, 2012, at 3:27 PM, Andreas Kuckartz wrote:

  On 03.04.2012 20:10, Jim Jagielski wrote:
 
  Oh come on... 1st of all, it's a joke.
 
  One I do not find funny at all.

 You should have. It was funny. Maybe you need a
 funny bone transplant?

 
  And 2ndly, people could complain that we should
  refuse the donation and force them to
  put all their code/energies into OpenStack...
 
  CloudStack and OpenStack seem to be complementary and they use the same
  license. I expect collaboration between these projects to increase not
  decrease.
 

 LO and AOOo are complementary and they are setup so that
 code can move in a very Pro-LO direction. I would like
 collaboration between these projects to increase not
 decrease.



 -
 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




-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies bimargul...@gmail.comwrote:

 On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org
 wrote:
  On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote:
 
  On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies 
 bimargul...@gmail.com
  wrote:
   Leo, are you out there?
 
  Hmm? Oh, this again...
 
  Having company names or trademarks in java namespaces is a pretty
  stupid convention. It gets us mess like this...
 
  There is no policy that incubating java projects must rename to use an
  org.apache namespace. There has never been such a policy. We don't
  need such a policy. There's (typically/usually/knock on wood) no
  legal/trademark issue. There's ample precedent of keeping 'legacy'
  namespaces around 'a while' for backwards compatibility. And that's
  fine.
 
  At the same time, (incubating) projects should definitely carefully
  consider whether it is reasonable to change their namespaces, how to
  go about it, etc. Incubation can be a good time and/or trigger to make
  such changes, especially for projects for whom backwards compatibility
  isn't a big issue (yet) or that are doing a major revision as part of
  coming here.
 
  With my incubator PMC hat on, I like to see that a project community
  has thought this situation through, discussed it on their dev list,
  and got to some kind of consensus on what to do. I'd imagine such
  plans will include a strategy for eventually having all their code end
  up in an org.apache namespace or at least not in a com.company
  namespace.
 
  I'm sure other people said all this already, apologies for the noise,
  but hey, I got prodded, so... :-)
 
 
  cheerio,
 
 
  Leo
 
 
 
  Not trying to beat a dead horse to death here but I'm starting to think
  that we might have had some basis to these package namespace issues. The
  recent private Lucene-Commons threads show what can happen if this policy
  is that hmmm liberal. Don't know if that's the right choice of words.

 Alex, there's an educational opportunity out there, yes.


Indeed. It might be a good idea perhaps to have every project at a minimum
publish an informative section on their site listing any kind of intrusion
into package spaces that are not owned by the project.

This way at a minimum there is some awareness.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@apache.org wrote:

 On 03/07/2012 11:31 PM, Alex Karasulu wrote:
  Not trying to beat a dead horse to death here but I'm starting to think
  that we might have had some basis to these package namespace issues. The
  recent private Lucene-Commons threads show what can happen if this policy
  is that hmmm liberal. Don't know if that's the right choice of words.

 The differences between the cases should inform any policy.

 In one case you have the inclusion of an older package name for
 back-compatibility by the same community that created the older API.  In
 the other case you have the inclusion of an API that conflicts with one
 managed by a different, still-active community.


Regardless of the situation in which this occurs the potential problem is a
namespace conflict. But I hear ya. The social situation is very different.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey mar...@rectangular.comwrote:

 On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
  On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@apache.org
 wrote:
 
   On 03/07/2012 11:31 PM, Alex Karasulu wrote:
Not trying to beat a dead horse to death here but I'm starting to
 think
that we might have had some basis to these package namespace issues.
 The
recent private Lucene-Commons threads show what can happen if this
 policy
is that hmmm liberal. Don't know if that's the right choice of words.
  
   The differences between the cases should inform any policy.
  
   In one case you have the inclusion of an older package name for
   back-compatibility by the same community that created the older API.
  In
   the other case you have the inclusion of an API that conflicts with one
   managed by a different, still-active community.
 
 
  Regardless of the situation in which this occurs the potential problem
 is a
  namespace conflict. But I hear ya. The social situation is very
 different.

 My impression was that there were two issues.

 First was the technical issue of a namespace conflict.  It seems as though
 there may be good reasons why exceptions should be made on a case-by-case
 basis, as Doug implies.


+1


 The second was the community issue of potentially advantaging a commercial
 entity; this response seemed to satisfy people:

http://s.apache.org/mz


+1


In fact, Sqoop already has a plan in place to completely remove
com.cloudera.* namespace from its contents via the next major revision
 of
the product. The work for that has already started and currently exists
under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope that in a
few months time, we will have feature parity in this branch with the
trunk, which is when we will promote it to the trunk.

 I would think that any generic policy would need to take both of those
 issues
 into account.


I feel the Cloudera folks have benign concerns in this case and this is not
an attempt to take advantage. As you reminded us above they're simply
trying to facilitate compatibility to accomodate their users which is
admirable. Also as Doug pointed out they're in control of both namespaces
so they can handle it without conflict.

However my primary point was when you start allowing this practice even
just a little for benign, positive reasons (as is the case for Scoop), it
can quickly lead to chaos through misuse, and result in community discord.
It's not easy to quantify/clarify whether the usage is meant for good, used
carelessly without consideration, or used explicitly to gain a commercial
advantage. It's going to start ruffling feathers at some point or another
when accusations start flying. Some folks are going to be pissed due to
disruptions, some are going to be on a witch hunt, others are going to have
valid concerns, some just won't care, while those accused will fight
vehemently feeling unjustly attacked. In the end, this feels like a
pandora's box. We just saw how damaging this can be with the recent
Lucene/Solr incident concerning commons CSV. [Just using a reference here
to minimise public discussion of a private list thread.]

So is there a way we can allow the practice to occur at a minimal scale
with positive gains, without the potential negative impact?

My rather weak suggestion of having projects explicitly announce the cases
where they infringe on another project or party's namespace just raises
awareness and makes it so the potentially infringing party exposes it's
intentions before accusations start flying. I'm sure there are better
solutions to this problem where we minimize the administrative overhead and
the negative impact. I just could not think of a better way at this point.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote:

 On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com
 wrote:
  Leo, are you out there?

 Hmm? Oh, this again...

 Having company names or trademarks in java namespaces is a pretty
 stupid convention. It gets us mess like this...

 There is no policy that incubating java projects must rename to use an
 org.apache namespace. There has never been such a policy. We don't
 need such a policy. There's (typically/usually/knock on wood) no
 legal/trademark issue. There's ample precedent of keeping 'legacy'
 namespaces around 'a while' for backwards compatibility. And that's
 fine.

 At the same time, (incubating) projects should definitely carefully
 consider whether it is reasonable to change their namespaces, how to
 go about it, etc. Incubation can be a good time and/or trigger to make
 such changes, especially for projects for whom backwards compatibility
 isn't a big issue (yet) or that are doing a major revision as part of
 coming here.

 With my incubator PMC hat on, I like to see that a project community
 has thought this situation through, discussed it on their dev list,
 and got to some kind of consensus on what to do. I'd imagine such
 plans will include a strategy for eventually having all their code end
 up in an org.apache namespace or at least not in a com.company
 namespace.

 I'm sure other people said all this already, apologies for the noise,
 but hey, I got prodded, so... :-)


 cheerio,


 Leo



Not trying to beat a dead horse to death here but I'm starting to think
that we might have had some basis to these package namespace issues. The
recent private Lucene-Commons threads show what can happen if this policy
is that hmmm liberal. Don't know if that's the right choice of words.

Best,
Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote:

 On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote:
  Hi Daniel...
 
  On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote:
   We had a very similar discussion about the back word compatibility
   classes/package names when Subversion graduated and we deemed it OK for
   them.
   In fact, I believe they still of org.tigris packages in their codebase
   long
   after graduation.   See:
  
  
  
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah
   l/src/org/
  
  
   I don't see why we would or should hold Sqoop to a different or higher
   standard at this point.   I agree with Jukka that if we, as a
 foundation,
   would like to re-address this, fine, take it to trademarks@ and start
 a
   discussion.   However, from an INCUBATOR standpoint, the precedent and
   expectations have  been set.
  
   That's my $0.02 cents worth.
 
  Thanks a lot for this, but would you elaborate more on why this has been
  accepted ? My believe is that there is some clarification that should be
  added to documentation so it is more clear for all people in the future,
  your input on this example would help indeed.

 You could likely read the mail archives if you want all the details.
 general@incubator in Nov 2009 had a thread,  dev@subversion in Jan 2010
 had a
 thread, and I think the graduation vote in Feb 2010 had more discussions.

 Basically, the Subversion had binary compatibility rules and there was no
 real legal requirement to force a huge disruption in the community by
 changing the package names.   The project had a plan to deprecate
 them/create
 wrappers/whatever so when it was appropriate to break compatibility they
 would.


Did they remove those packages or did they remain?

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote:

 On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din
 nour.moham...@gmail.com wrote:
  On the other hand, I totally respect that Cloudera's interest to support
  their customers and provide backword compatibility, but this is *not* the
  point at all, the point is this *should* not, and even allow me to say
 this
  is *must* not be the problem of Apache, and yes I agree with the opinion
  that this is a matter to be decided by Sqoop team but not to make
 Apache's
  problem. So also let not get more into this!!!

 Or course this is Apache's problem. You can't have your cake and eat
 it too. If you accept code for a project you accept the community as
 well. Say Apache accepts a project like Open Office, should we ignore
 the existing community and not concern ourselves with backward
 compatibility for that project as well, because the original code
 wasn't birthed at Apache?


That's a very slippery slope. Maybe some projects get way too much leeway
because of the big flashing lights. Regardless of how big the press
headlines are all projects should be held to the same standard.

No project should be allowed to graduate without solving all issues
pertaining to marks. It's a failure of the incubator in the past for
allowing other projects to do so. I'm shocked it was allowed.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote:

 On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote:
 
  On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote:
 
   On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote:
Hi Daniel...
   
On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org
 wrote:
 We had a very similar discussion about the back word compatibility
 classes/package names when Subversion graduated and we deemed it OK
 for
 them.
 In fact, I believe they still of org.tigris packages in their
 codebase
 long
 after graduation.   See:



  
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah
 l/src/org/


 I don't see why we would or should hold Sqoop to a different or
 higher
 standard at this point.   I agree with Jukka that if we, as a
   foundation,
 would like to re-address this, fine, take it to trademarks@ and
 start
   a
 discussion.   However, from an INCUBATOR standpoint, the precedent
 and
 expectations have  been set.

 That's my $0.02 cents worth.
   
Thanks a lot for this, but would you elaborate more on why this has
 been
accepted ? My believe is that there is some clarification that should
 be
added to documentation so it is more clear for all people in the
 future,
your input on this example would help indeed.
  
   You could likely read the mail archives if you want all the details.
   general@incubator in Nov 2009 had a thread,  dev@subversion in Jan
 2010
   had a
   thread, and I think the graduation vote in Feb 2010 had more
 discussions.
  
   Basically, the Subversion had binary compatibility rules and there
 was no
   real legal requirement to force a huge disruption in the community by
   changing the package names.   The project had a plan to deprecate
   them/create
   wrappers/whatever so when it was appropriate to break compatibility
 they
   would.
  
  
  Did they remove those packages or did they remain?

 They remain.

 Keeping them is the right thing for our community and product. That is our
 determination, and is our Right.


Sorry but I don't think that's right.


 Sqoop has determined backwards compatibility is important to their
 community and wants to keep this (deprecated) interface for a while. So
 where is the problem here, people?


It's fine but those com.cloudera packages don't need to be hosted here.
They can be hosted elsewhere and the backwards compatibility issue can
still be handled.


 Really. What is the problem with the extra interfaces?


The package namespace is not ours. It's that simple G.


 There is no legal (trademark or copyright) problem that I'm aware of. There
 is no technical problem that I'm aware of.


OK do we have the right to create any kind of package or class under
com.cloudera (or any other companies packages)?

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 2:38 PM, Mark Struberg strub...@yahoo.de wrote:

 strictly -1 for forcing a name change on graduation.


Maybe we have some confusion here. No one is talking about changing the
name of the podling.

The discussion pertains to the presence of com.cloudera packages in the
source code of a podling for the sake of backwards compatibility with
Cloudera products.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote:

 Has nothing to do with incubation. You're talking about Foundation-wide
 policy. You cannot impose different naming rules on podlings, than what is
 imposed on TLPs. Please see my response in the original thread. You need a
 Board resolution and rationale.


I'm glad you phrased it like this. It totally takes us out of the scope of
the perceived problem. As you say you have to apply the same rules until
policies change, if they change. You're amazingly cogent dude! It's a
strong argument that I can't disagree with even though I am convinced the
perceived problem is quite serious.

I'll withdraw my veto on the other VOTE thread but I really want to
evaluate this in this discussion thread.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 3:07 PM, Alex Karasulu akaras...@apache.org wrote:

 On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote:

 On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote:
 
  On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote:
 
   On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote:
Hi Daniel...
   
On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org
 wrote:
 We had a very similar discussion about the back word compatibility
 classes/package names when Subversion graduated and we deemed it
 OK
 for
 them.
 In fact, I believe they still of org.tigris packages in their
 codebase
 long
 after graduation.   See:



  
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah
 l/src/org/


 I don't see why we would or should hold Sqoop to a different or
 higher
 standard at this point.   I agree with Jukka that if we, as a
   foundation,
 would like to re-address this, fine, take it to trademarks@ and
 start
   a
 discussion.   However, from an INCUBATOR standpoint, the precedent
 and
 expectations have  been set.

 That's my $0.02 cents worth.
   
Thanks a lot for this, but would you elaborate more on why this has
 been
accepted ? My believe is that there is some clarification that
 should
 be
added to documentation so it is more clear for all people in the
 future,
your input on this example would help indeed.
  
   You could likely read the mail archives if you want all the details.
   general@incubator in Nov 2009 had a thread,  dev@subversion in Jan
 2010
   had a
   thread, and I think the graduation vote in Feb 2010 had more
 discussions.
  
   Basically, the Subversion had binary compatibility rules and there
 was no
   real legal requirement to force a huge disruption in the community
 by
   changing the package names.   The project had a plan to deprecate
   them/create
   wrappers/whatever so when it was appropriate to break compatibility
 they
   would.
  
  
  Did they remove those packages or did they remain?

 They remain.

 Keeping them is the right thing for our community and product. That is our
 determination, and is our Right.


 Sorry but I don't think that's right.


 Sqoop has determined backwards compatibility is important to their
 community and wants to keep this (deprecated) interface for a while. So
 where is the problem here, people?


 It's fine but those com.cloudera packages don't need to be hosted here.
 They can be hosted elsewhere and the backwards compatibility issue can
 still be handled.


 Really. What is the problem with the extra interfaces?


 The package namespace is not ours. It's that simple G.


 There is no legal (trademark or copyright) problem that I'm aware of.
 There
 is no technical problem that I'm aware of.


 OK do we have the right to create any kind of package or class under
 com.cloudera (or any other companies packages)?


Greg's right. Jukka was as well but for some reason I did not immediately
get it.

We cannot hold Scoop to a standard which we don't apply to other TLPs and
this needs to be a Foundation wide policy discussion. I still think the
practice of bundling classes and packages which are not in our namespace is
a serious issue. I'll take this up the other discussion thread.

I am withdrawing my veto and I apologize for any inconvenience this may
have caused the Scoop community.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 3:35 PM, Mohammad Nour El-Din 
nour.moham...@gmail.com wrote:

 On Wed, Feb 29, 2012 at 2:32 PM, Alex Karasulu akaras...@apache.org
 wrote:

  On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote:
 
   Has nothing to do with incubation. You're talking about Foundation-wide
   policy. You cannot impose different naming rules on podlings, than what
  is
   imposed on TLPs. Please see my response in the original thread. You
 need
  a
   Board resolution and rationale.
  
  
  I'm glad you phrased it like this. It totally takes us out of the scope
 of
  the perceived problem. As you say you have to apply the same rules until
  policies change, if they change. You're amazingly cogent dude! It's a
  strong argument that I can't disagree with even though I am convinced the
  perceived problem is quite serious.
 
  I'll withdraw my veto on the other VOTE thread but I really want to
  evaluate this in this discussion thread.
 

 I agree with this, I believe that Sqoop deserve to be graduated for a lot
 of reasons and even the discussion in hand it is not all their fault it is
 fault of Mentors and a problem of lacking of clear information about such
 situation, so IMO as I explained before we proceed with the vote and bring
 that issue in a more general ASF wide level.


Yep you did say that at first and you were right. It just takes a while for
me to absorb ;).

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 3:32 PM, Alex Karasulu akaras...@apache.org wrote:

 On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote:

 Has nothing to do with incubation. You're talking about Foundation-wide
 policy. You cannot impose different naming rules on podlings, than what is
 imposed on TLPs. Please see my response in the original thread. You need a
 Board resolution and rationale.


 I'm glad you phrased it like this. It totally takes us out of the scope of
 the perceived problem. As you say you have to apply the same rules until
 policies change, if they change. You're amazingly cogent dude! It's a
 strong argument that I can't disagree with even though I am convinced the
 perceived problem is quite serious.

 I'll withdraw my veto on the other VOTE thread but I really want to
 evaluate this in this discussion thread.


OK to get back on track with this discussion I've taken a snippet from the
original thread and pasted it here:


 They remain.

 Keeping them is the right thing for our community and product. That is our
 determination, and is our Right.


 Sorry but I don't think that's right.


 Sqoop has determined backwards compatibility is important to their
 community and wants to keep this (deprecated) interface for a while. So
 where is the problem here, people?


 It's fine but those com.cloudera packages don't need to be hosted here.
 They can be hosted elsewhere and the backwards compatibility issue can
 still be handled.


 Really. What is the problem with the extra interfaces?


 The package namespace is not ours. It's that simple G.


 There is no legal (trademark or copyright) problem that I'm aware of.
 There
 is no technical problem that I'm aware of.


 OK do we have the right to create any kind of package or class under
 com.cloudera (or any other companies packages)?


I'd like to approach it by answering this question. Because if we look at
it like this then we'll start seeing the issues this could cause.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

I'd like the address this and Greg's other email but let's move this over
to the other discussion thread so this one can close and Scoop can continue
forward.

On Wed, Feb 29, 2012 at 3:39 PM, Ian Dickinson i...@epimorphics.com wrote:

 On 29/02/12 13:07, Alex Karasulu wrote:

  [snip]

  There is no legal (trademark or copyright) problem that I'm aware of.
 There
 is no technical problem that I'm aware of.



 OK do we have the right to create any kind of package or class under
 com.cloudera (or any other companies packages)?

 This is a red-herring in my view: no packages or classes are being created
 if a project leaves a compatibility layer in place. The class/package names
 are merely not being deleted. Presuming that the original code was part of
 the inceptional code grant, one can conclude that the company in question
 doesn't mind their namespace being used by ASF projects *for that purpose*.

 Ian


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




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 3:45 PM, Greg Stein gst...@gmail.com wrote:

 On Feb 29, 2012 8:07 AM, Alex Karasulu akaras...@apache.org wrote:
 
  On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote:
 ...
   They remain.
  
   Keeping them is the right thing for our community and product. That is
 our
   determination, and is our Right.
  
  
  Sorry but I don't think that's right.

 Please explain what information you have that states we cannot use
 org.tigris.subversion for our deprecated APIs. I'm very curious because I
 wasn't aware of any prohibition on this. You seem to know something the
 Subversion community does not. Explain, please.

 (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if
 you do)


I was not clear here. I'm merely stating that I don't believe the practice
to be sound. Also I don't think it's a right TLPs should have. I was not
commenting on the current state of the subversion code base :).


   Sqoop has determined backwards compatibility is important to their
   community and wants to keep this (deprecated) interface for a while. So
   where is the problem here, people?
  
  
  It's fine but those com.cloudera packages don't need to be hosted here.

 The community says it is best for their product to bundle the deprecated
 APIs. Do you have some information from the community that says otherwise?


Nope.


  They can be hosted elsewhere and the backwards compatibility issue can
  still be handled.

 They can, but the community feels it best for their users to bundle it as
 part of the product. Do you know something about the users that leads you
 to believe they would prefer to get the deprecated interfaces from
 somewhere else? As a separate download? An extra step?


No, no and no.


 What do you know that the Sqoop devs do not?


Not suggesting I know anything more about their product and their community
than them. Their aims to maintain backwards compatibility is a good one.
This is not being debated.


   Really. What is the problem with the extra interfaces?
  
  
  The package namespace is not ours. It's that simple G.

 Are we allowed to use it? Is the namespace designed/defined for us to use
 it? Is somebody attempting to recover the deprecated namespace? Do the
 owners *want* us to continue using it?

 Those are the questions.


IMO, the issue is over and done if Cloudera has authorized our use of their
namespace in some written form. This makes it so they cannot come back and
complain for us using the namespace.


 I know Subversion is allowed to use org.tigris for its deprecated APIs. Who
 are you to say otherwise? Why do you assume you know better? How is it you
 know what package name I can or cannot use?

   There is no legal (trademark or copyright) problem that I'm aware of.
 There
   is no technical problem that I'm aware of.
 
 
  OK do we have the right to create any kind of package or class under
  com.cloudera (or any other companies packages)?

 I bet they would get pissed if we created arbitrary packages in their
 namespace, but that is NOT the question at hand.


No it is not the question at hand. But where do you draw the line is my
point.


 The question is whether we can continue to use the old package name for
 backwards compatibility purposes. Have you asked Cloudera or the community
 if anybody told them, no, we want our old package name back. No, I bet
 you didn't. I bet you saw com.cloudera and just generalized the issue into
 somebody else's namespace without full detail or background, which the
 community already had.


Foundation wide I see this as a policy that will eventually cause problems.
When the practice created to solve compatibility problems leads to
compatibility problems then ... you see where I'm going with this.

It's just better not to play this game at all. Just play it safe.

In the case of Scoop it's clear. But with the way we're growing you're not
going to be able to make sure collisions don't result. And that can
actually hurt other parties. The namespace mechanism is there to prevent
such collisions.


 You mentioned slippery slope earlier. Don't you see you're already on it?


Hahaha, yes actually I do but another slippery slope, the one I pointed out
above also exist. How do we stay off both?


 And this is the reason the Board stays out of technical decisions? Only the
 community knows best. You're on that slope, attempting to apply *your*
 technical mandates upon a project. But they know more than you.


I don't think I'm here trying to mandate how they're to procede
technically. It would be preposterous of me to do that. They know best, I'm
100% with you on that. But I don't think this is a technical discussion.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 3:54 PM, Greg Stein gst...@gmail.com wrote:

 On Feb 29, 2012 8:45 AM, Alex Karasulu akaras...@apache.org wrote:
 ...
  
   OK do we have the right to create any kind of package or class under
   com.cloudera (or any other companies packages)?
  
 
  I'd like to approach it by answering this question. Because if we look at
  it like this then we'll start seeing the issues this could cause.

 My rather snarky reply is in the other thread :-P


Indeed :).


 ... my cut/paste is poor
 on this tablet, so if you could haul it over here


Done.


-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

Seems we're continuing the discussion in both threads now. More inline ...

On Wed, Feb 29, 2012 at 3:39 PM, Ian Dickinson i...@epimorphics.com wrote:

 On 29/02/12 13:07, Alex Karasulu wrote:

  [snip]

  There is no legal (trademark or copyright) problem that I'm aware of.
 There
 is no technical problem that I'm aware of.



 OK do we have the right to create any kind of package or class under
 com.cloudera (or any other companies packages)?

 This is a red-herring in my view: no packages or classes are being created
 if a project leaves a compatibility layer in place.


The point I'm trying to make is when you do it at all you have to quantify
why. That get's tedious and error prone and with the rate of growth we're
dealing with that's just unmanageable IMO.


 The class/package names are merely not being deleted. Presuming that the
 original code was part of the inceptional code grant, one can conclude that
 the company in question doesn't mind their namespace being used by ASF
 projects *for that purpose*.


OK I'm completely content if the Co. in question does so in writing freeing
us of any responsibility.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 4:00 PM, Benson Margulies bimargul...@gmail.comwrote:

 I don't think it's a good question. I think that it is typical of the
 sort of hypothetical question which leads to heaps of scorn from Sam.


Please! Don't invoke Sam :).

Jokes aside take a look the my last two posts on the original thread.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 6:57 PM, Daniel Kulp dk...@apache.org wrote:


 As another point of reference, there is at least one case I'm aware of
 where
 we HAD to put some code developed at Apache into non-org.apache namespace
 in
 order for the code to work.   This was taken up on legal discuss and, at
 the
 time, no issues about doing so were raised.

 See:
 http://s.apache.org/WzP


That's certainly a horrible situation to be stuck in. This is a good
example for a valid exception IMO.



 And the CXF bug:
 https://issues.apache.org/jira/browse/CXF-1880

 In this case, it was new code developed at Apache and in the org.apache.cxf
 namespace, but in order for the code to actual work, there were shims
 necessary in com.sun.Now, this is a slightly different case in that no
 end-users would likely ever call (or really even see) this code.   It's
 just
 need to plugin into an external tool.

 So, IMO, code at Apache SHOULD be developed in the org.apache namespace,
 but
 projects need to be able to have some flexibility to use their judgment to
 figure out what is best for the needs of their community.   Projects
 should be
 encouraged to keep code outside org.apache to a minimum via shims or
 similar
 and also encourage end users to migrate to using the code in the org.apache
 namespace as soon as possible.


 Dan



 On Wednesday, February 29, 2012 11:02:33 AM Mohammad Nour El-Din wrote:
  I don't see that this getting to any clear end yet. So I suggest that we
  take this from a Sqoop instance to be a discussion on rules them selves.
 
  I would like to start a [VOTE] about whether it is a *must* for podlings
 to
  rename all packages before being a TLP or not over keeping the old
 package
  names for backward compatibility. What ever the consensus going to be
 built
  we definitely need to update the Incubator documents to clear this kind
 of
  issue. But before starting the vote I would like to consider others'
  opinions.
 
  Thoughts ?
 
  On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.org
 wrote:
   On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org
 wrote:
On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din
   
nour.moham...@gmail.com wrote:
 On the other hand, I totally respect that Cloudera's interest to
  
   support
  
 their customers and provide backword compatibility, but this is
 *not*
  
   the
  
 point at all, the point is this *should* not, and even allow me to
 say
   
this
   
 is *must* not be the problem of Apache, and yes I agree with the
  
   opinion
  
 that this is a matter to be decided by Sqoop team but not to make
   
Apache's
   
 problem. So also let not get more into this!!!
   
Or course this is Apache's problem. You can't have your cake and eat
it too. If you accept code for a project you accept the community as
well. Say Apache accepts a project like Open Office, should we ignore
the existing community and not concern ourselves with backward
compatibility for that project as well, because the original code
wasn't birthed at Apache?
  
   That's a very slippery slope. Maybe some projects get way too much
 leeway
   because of the big flashing lights. Regardless of how big the press
   headlines are all projects should be held to the same standard.
  
   No project should be allowed to graduate without solving all issues
   pertaining to marks. It's a failure of the incubator in the past for
   allowing other projects to do so. I'm shocked it was allowed.
  
   --
   Best Regards,
   -- Alex
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

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




-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu]

On Wed, Feb 29, 2012 at 7:16 PM, Patrick Hunt ph...@apache.org wrote:

 On Wed, Feb 29, 2012 at 5:23 AM, Alex Karasulu akaras...@apache.org
 wrote:
 
  The discussion pertains to the presence of com.cloudera packages in the
  source code of a podling for the sake of backwards compatibility with
  Cloudera products.

 Alex this is an incorrect summary of the facts, similar to the FUD you
 tried to spread on the original thread which Arvind provided detail
 on.


No need to degenerate the discussion here. What's not true about the
synopsis above? Did I miss something? We're talking about the presence of
com.cloudera packages here for backwards compatibility no?

Incidentally what exactly is it that you're maintaining backwards
compatibility with? I presumed it was a Cloudera product because of the
package name. If I'm wrong let me know.


 Sqoop was ASL licensed and had an open following long before it
 was accepted for incubation to Apache. The community is trying to
 rectify the short term migration requirements against doing the right
 thing by both Apache and that community.


OK that does not in any way invalidate my summary. You're just taking
swipes for no reason. Do you honestly think I'm trying to spread FUD here?

You guys might have had to deal with a lot of nasty jealous types not
liking that Cloudera is such a success. I'd like to think there are no
people like this here but I may be naive. I'm not one of those people. I
like to see Cloudera like commercialization occur but would like some care
taken to protect the foundation. The foundation gains through your
successes as well. So please don't classify me incorrectly: I'm not one of
those types.

I read more into Scoop and I think I'm going to be a happy user soon too.

And Arvind's comments below are noted but they don't change the existing
conditions today. It just means you have a plan for the future: this is
good.


 Arvind:

  ... it would have
  been easier for us[ sqoop community at apache] to drop any backward
 compatibility requirements and
  get releases out quickly. The reason we chose to invest a lot in
  preserving backward compatibility is for our community. Sqoop has an
  active community that we care deeply about and we have done our best
  to make sure continues to use Sqoop effectively. It is this thriving
  community that was the primary reason for Sqoop to have come into the
  incubator in the first place.

 Keep in mind also that this is a short term solution that has a longer
 term resolution (one already discussed on the other thread as well):

 Here is Arvind's response to Jukka proposing that Sqoop address the
 packaging issue post graduation:

  Thanks Jukka. In fact, Sqoop already has a plan in place to completely
  remove com.cloudera.* namespace from its contents via the next major
  revision of the product. The work for that has already started and
  currently exists under the branch sqoop2 [3], tracked by SQOOP-365
  [4]. We hope that in a few months time, we will have feature parity in
  this branch with the trunk, which is when we will promote it to the
  trunk.
 
  [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
  [4] https://issues.apache.org/jira/browse/SQOOP-365

 Patrick

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




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 4:52 PM, Ate Douma a...@douma.nu wrote:

 On 02/29/2012 02:45 PM, Greg Stein wrote:

 On Feb 29, 2012 8:07 AM, Alex Karasuluakaras...@apache.org**  wrote:


 On Wed, Feb 29, 2012 at 2:06 PM, Greg Steingst...@gmail.com  wrote:
 ...

 They remain.

 Keeping them is the right thing for our community and product. That is

 our

 determination, and is our Right.


  Sorry but I don't think that's right.


 Please explain what information you have that states we cannot use
 org.tigris.subversion for our deprecated APIs. I'm very curious because I
 wasn't aware of any prohibition on this. You seem to know something the
 Subversion community does not. Explain, please.

 (and yes, I know exactly who owns org.tigris.subversion; I'd like to see
 if
 you do)

  Sqoop has determined backwards compatibility is important to their
 community and wants to keep this (deprecated) interface for a while. So
 where is the problem here, people?


  It's fine but those com.cloudera packages don't need to be hosted here.


 The community says it is best for their product to bundle the deprecated
 APIs. Do you have some information from the community that says otherwise?

  They can be hosted elsewhere and the backwards compatibility issue can
 still be handled.


 They can, but the community feels it best for their users to bundle it as
 part of the product. Do you know something about the users that leads you
 to believe they would prefer to get the deprecated interfaces from
 somewhere else? As a separate download? An extra step?

 What do you know that the Sqoop devs do not?

  Really. What is the problem with the extra interfaces?


  The package namespace is not ours. It's that simple G.


 Are we allowed to use it? Is the namespace designed/defined for us to use
 it? Is somebody attempting to recover the deprecated namespace? Do the
 owners *want* us to continue using it?

 Those are the questions.

 I know Subversion is allowed to use org.tigris for its deprecated APIs.
 Who
 are you to say otherwise? Why do you assume you know better? How is it you
 know what package name I can or cannot use?

  There is no legal (trademark or copyright) problem that I'm aware of.

 There

 is no technical problem that I'm aware of.



 OK do we have the right to create any kind of package or class under
 com.cloudera (or any other companies packages)?


 I bet they would get pissed if we created arbitrary packages in their
 namespace, but that is NOT the question at hand.


 To me this actually *is* the question at hand, but from a different
 perspective than you bring up.
 In my initial response on this I raised this as a question about
 affiliation and independence of the project towards the community.

 For all I know Cloudera might not get pissed off at all if arbitrary
 packages in their namespace are created. There are plenty Cloudera
 committers on Sqoop which could (legally be allowed to) do this themselves.

 So to me this is not a legal problem but one of community, diversity and
 independence of affiliation.

 How will the community perceive the project independence from Cloudera if
 it carries, and maintains a 3rd party namespace, to which several
 committers are commercially affiliated as employee.

 That IMO should be an concern for the Foundation, not solely a 'Right' of
 a PMC to decide on themselves.


I completely agree with this position as well. It escaped my focus as I was
more worried about the issue of namespace collisions.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 8:11 PM, Doug Cutting cutt...@apache.org wrote:

 On 02/29/2012 01:33 AM, Alex Karasulu wrote:
  No project should be allowed to graduate without solving all issues
  pertaining to marks. It's a failure of the incubator in the past for
  allowing other projects to do so. I'm shocked it was allowed.

 This is not a trademark issue.  Package names are subject to fair use.


It might not be a trademark issue per say, IANAL, but the package namespace
of another entity like a corporation belongs to them and at a minimum
should be respected. Of course this is not an issue as I said before if
that entity gives written permission to use their namespace. That fixes
this aspect of the problem.

I can't go off and mirror the namespace of Foo Co. without causing some
form of damage with the powerful distribution channels the ASF posses. Now
no one in their right mind would do that here (I hope) but potentials for
collisions are probably going to happen in the future.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Wed, Feb 29, 2012 at 8:20 PM, Doug Cutting cutt...@apache.org wrote:

 On 02/29/2012 06:19 AM, Alex Karasulu wrote:
  The class/package names are merely not being deleted. Presuming that the
   original code was part of the inceptional code grant, one can
 conclude that
   the company in question doesn't mind their namespace being used by ASF
   projects *for that purpose*.
  
  
  OK I'm completely content if the Co. in question does so in writing
 freeing
  us of any responsibility.

 I don't think this is required.

  ... the names of the Java language API files, packages, classes, and
 methods are not protectable as a matter of law ...

 http://www.groklaw.net/articlebasic.php?story=20110915194531435


Just saw this now. This makes me feel much better. But it does not prevent
a negative, and potentially damaging situation from occurring.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Apache Rave as TLP

[Alex Karasulu]

On Tue, Feb 28, 2012 at 10:33 AM, Ate Douma a...@douma.nu wrote:

 +1 (binding)


+1 (binding)

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote:

 The source code in Sqoop still exists in both com.cloudera.sqoop and
 org.apache.sqoop packages and most of the code appears to include the
 com.cloudera packages and not the org.apache packages.  While in the
 incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
 any policy statements on it in the Apache pages.


Good catch Alan. You are right we are not OK with this situation. It needs
to be corrected then another vote can be taken.

Thanks,
Alex



 On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:

  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop 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 related to efficiently transferring
bulk data between Apache Hadoop and structured datastores
for distribution at no charge to the public.
 
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Sqoop Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby is
responsible for the creation and maintenance of software
related to efficiently transferring bulk data between Apache
Hadoop and structured datastores; and be it further
 
RESOLVED, that the office of Vice President, Apache Sqoop 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 Sqoop Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Sqoop 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 Sqoop Project:
 
  * Aaron Kimball kimba...@apache.org
  * Andrew Bayer  aba...@apache.org
  * Ahmed Radwan  ah...@apache.org
  * Arvind Prabhakar  arv...@apache.org
  * Bilung Leeb...@apache.org
  * Greg Cottman  gcott...@apache.org
  * Guy le Marguyle...@apache.org
  * Jaroslav Cechojar...@apache.org
  * Jonathan Hsiehjmhs...@apache.org
  * Olivier Lamy  ol...@apache.org
  * Paul Zimdars  pzimd...@apache.org
  * Roman Shaposhnik  r...@apache.org
 
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
be appointed to the office of Vice President, Apache Sqoop, 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 Sqoop 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 Sqoop Project; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Sqoop podling; and be it further
 
RESOLVED, that all responsibilities pertaining to the Apache
Incubator Sqoop podling encumbered upon the Apache Incubator
Project are hereafter discharged.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: 

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
 wrote:
  Cloudera's compatibility issues are not our problem. These packages need
 to
  go.

 Citation needed.


I did not think we needed one: nor do I have one. It's common sense to me
that this causes issues. It combines the namespace of a foreign mark with
our own. We should not be releasing anything in the namespace belonging to
another entity.


 Without a written policy to that effect these things
 are up for each project to decide. Jarek's rationale sounds perfectly
 fine to me.


I highly respect you opinion here but I disagree regarding this argument
provided. There may be no policy to cite, and there may be examples of
where this was done before for the sake of backwards compatibility. It
still does not justify doing it.


 We have plenty of projects that provide such backwards compatibility
 wrappers or otherwise put stuff in non-apache namespaces for various
 reasons. See for example [1] or [2].


Understood. Examples are solid points supporting the argument but IMHO I
think this was a mistake that opens the door to several issues. Maybe we
need some clear policy regarding the matter. I'm more than ready to be
proven wrong on this matter so long as it does not present problems down
the line for us.


 [1]
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/
 [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/

 BR,

 Jukka Zitting


-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 4:09 PM, Mohammad Nour El-Din 
nour.moham...@gmail.com wrote:

 On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma a...@douma.nu wrote:

  On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote:
 
  Hi...
 
 1st of all, and I speaking about myself here, I believe this is
  partially my fault cause I am one of the mentors of Sqoop and I should
  have
  spotted such thing before moving the vote to general@
 
  I totally agree with Alex, more specifically I believe this is easy to
  solve.
 
  There is no problem to support some features or API(s)
  for backward compatibility but as Alex stated it should not be part of
  Apache's code, more specifically when it comes to be part of a TLP's
 code.
 
 
  I agree.
 
  And specifically as this seems to concern compatibility support for
  Cloudera own API, only needed for Cloudera customers.
  Keeping those com.cloudera packages in the code could imply a specific
  preference and affiliation with an external and commercial entity,
 thereby
  potentially jeopardizing the project independence.
 
  While I don't expect there was any intend to do so, even the impression
  itself can be considered harmful to the ASF and the project.
 
 
 
  The solution can be like packaging this code and host it on Cloudera or
  even Apache Extras [1] and a note is added to Sqoop website that if
 users
  want to have backward compatibility they should use that code besides
 the
  code of Apache.
 
 
  That sounds reasonable and hopefully easy to do (if not this case might
  even be more worrisome then).
  I'm not really sure though if Apache Extras is an appropriate location
  either. I think Apache Extras intends to convey an affiliation with the
 ASF
  and probably should value project independence high as well.
  If this really only concerns a thin layer to provide compatibility only
  for Cloudera's API, hosting and maintenance of this should be the
  responsibility of Cloudera itself.


 Good point, I agree on this


+1



 
 
  Ate
 
 
 
  Now the question is, and I ask this more specifically to the Sqoop
 people,
  Can you do this before the next board meeting, at least the extracting
  that
  code ? Cause if not I support Alex in that this vote should be cancelled
  and then we work out another one when Sqoop meets this criteria.
 
  Looking forward to your feedback!
 
  [1] - http://code.google.com/a/**apache-extras.org/hosting/
 http://code.google.com/a/apache-extras.org/hosting/
 
  On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasuluakaras...@apache.org**
  wrote:
 
   On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitting@gmail.**
  com jukka.zitt...@gmail.com
 
  wrote:
 
 
   Hi,
 
  On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@apache.org
  wrote:
 
  Cloudera's compatibility issues are not our problem. These packages
 
  need
 
  to
 
  go.
 
 
  Citation needed.
 
 
 
  I did not think we needed one: nor do I have one. It's common sense to
 me
  that this causes issues. It combines the namespace of a foreign mark
 with
  our own. We should not be releasing anything in the namespace belonging
  to
  another entity.
 
 
   Without a written policy to that effect these things
  are up for each project to decide. Jarek's rationale sounds perfectly
  fine to me.
 
 
   I highly respect you opinion here but I disagree regarding this
  argument
  provided. There may be no policy to cite, and there may be examples of
  where this was done before for the sake of backwards compatibility. It
  still does not justify doing it.
 
 
   We have plenty of projects that provide such backwards compatibility
  wrappers or otherwise put stuff in non-apache namespaces for various
  reasons. See for example [1] or [2].
 
 
   Understood. Examples are solid points supporting the argument but
 IMHO
  I
  think this was a mistake that opens the door to several issues. Maybe
 we
  need some clear policy regarding the matter. I'm more than ready to be
  proven wrong on this matter so long as it does not present problems
 down
  the line for us.
 
 
   [1]
 
   http://svn.apache.org/repos/**asf/subversion/trunk/**
  subversion/bindings/javahl/
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/
 
 
  [2] http://svn.apache.org/repos/**asf/geronimo/specs/trunk/
 http://svn.apache.org/repos/asf/geronimo/specs/trunk/
 
  BR,
 
  Jukka Zitting
 
 
   --
  Best Regards,
  -- Alex
 
 
 
 
 
 
  --**--**-
  To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org
 general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-help@incubator.apache.**org
 general-h...@incubator.apache.org
 
 


 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
 wrote:
  On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
  On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
 wrote:
  I'm not sure that JSR specs are the same as old Cloudera code.  JMHO.

 How about phrasing it as old Sqoop code instead. :-)

 Really it's about respect for existing users and others migrating to
 Apache. It's also about respect for the people doing the work. That's
 my understanding from discussions with the team at least.

   I don't see the technical requirement that this code needs to stay at
 Apache and not Cloudera.

 I agree that this potentially could be an issue, but whether it's a
 technical requirement is up to the team who's doing the work. If
 Apache feels that there is a requirement that no project releases
 code/document/etc... under any package other than org.apache.* then
 that should be clearly defined and communicated. At this point my
 understanding is there is no such requirement.


The Incubator is a work in progress, just like anything else here. I think
this is a policy we should adhere too from this point forward. The
technical problem is small in comparison to other issues this brings into
play.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 8:34 PM, Patrick Hunt ph...@apache.org wrote:

 On Tue, Feb 28, 2012 at 10:20 AM, Alex Karasulu akaras...@apache.org
 wrote:
  On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote:
  I agree that this potentially could be an issue, but whether it's a
  technical requirement is up to the team who's doing the work. If
  Apache feels that there is a requirement that no project releases
  code/document/etc... under any package other than org.apache.* then
  that should be clearly defined and communicated. At this point my
  understanding is there is no such requirement.
 
 
  I think this is a policy we should adhere too from this point forward.

 Apache wide policy or incubator policy? If it's not Apache wide then
 any project could just wait till graduation and do as they see fit.
 The idea of incubation is to ensure that a podling adheres to Apache
 policy before being let loose to run itself. If we make this an
 incubator only restriction we're saying that that's not the case.


That's a good point.


  The technical problem is small in comparison to other issues this brings
 into play.

 What issues? That people will be confused about whether Apache
 released/branded code, downloaded from Apache, where the majority of
 the code is org.apache packaged, but some subset of clearly marked
 deprecated code, defined as an aid for migration is Apache or not?
 Doesn't seem like an issue to me.


I think the issues were amply expressed in this thread. Just take a look at
what Ate, Mo, and I said earlier.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 11:25 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by my
 opinion that there
  are some things that are not solely up to the people that are doing the
 work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )

 Right.


It's not that anyone is holding Scoop to a higher standard. We just noticed
the issue now. I noticed because I'm a mentor on another project along side
Alan and since he posted I paid closer attention. I cannot and don't track
every podling. To be honest this is the first real encounter I've had with
Scoop. Sounds like something I could use :-) too. I want to see Scoop
graduate. I certainly don't want the Scoop guys thinking who's this jerk
getting in our way.

So I, nor the other's expressing concerns have anything against the Scoop
team. It's just chance that this project triggered the discussion. No one
is against Cloudera either. I don't know why people are bothering pointing
out the project came to the ASF Incubator from Github. Github is just a
repository. If you want to know where the code really came from then check
who the majority of contributors were before incubation. It makes no
difference: Cloudera or Github. The problem for us still persists.


 Basically the graduation vote by the IPMC is about determining whether
 the PPMC is capable of conducting itself according to the Apache Way
 and Apache policies on it's own.


I don't understand the rush to graduate. What difference does a month make
in the grand scheme of things? The sudden vehement push to include these
packages worries me. Graduating should not be more important than
addressing valid concerns.


 I didn't have time to look deeper
 into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
 PPMC is ready to take on that responsibility.


Rather than crudely drop a -1 we voiced our concerns as IPMC members, and
mentors to open up discussion about the matter. It's easy to drop the
package and solve the technical problem. If you need a -1 to stop the
process then you have mine.


 Along with that
 responsibility comes the right to make value judgements on topics like
 this where existing policies aren't clearly spelled out.


Honestly I've begun to be concerned after watching how vehemently the
Cloudera people came out of the woodwork to push graduation no matter what
concerns were expressed. IMHO that's not in line with the Apache Way as
far as our culture goes. So yes the impatience is triggering me to be
doubtful of their ability to handle the responsibility. At the end of the
day no project is more important than the ASF as a whole.


 Personally I think we should let the vote result stand with guidance
 to the new Sqoop PMC to discuss the matter with the branding team at
 trademarks@ to seek Apache-wide consensus. I encourage anyone who
 feels strongly about this (the point being made clearly has some
 merit) make their case to trademarks@ as it's IMHO not really the task
 of the Incubator to be forming new policy on this, especially with all
 the recent talk about scaling down the ambitions of the IPMC.


That's a good point and to a really large extent I agree with you. However
this is one of the last lines of defense we have before it becomes much
harder to rectify. While we have the issue on the radar let's take care of
it now. That will provide more drive to resolve it quickly.

So I'd rather get clarification on this grey area ASAP. I certainly cannot
brush it under the rug after noticing it. So let's play it safe, get some
resolution, then proceed forward. That's the best approach IMHO. Graduation
will occur in the near future so let's not sweat it.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Alex Karasulu]

On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote:

 On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Hi,
 
  On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by
 my opinion that there
  are some things that are not solely up to the people that are doing
 the work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )
 
  Right.
 
  Basically the graduation vote by the IPMC is about determining whether
  the PPMC is capable of conducting itself according to the Apache Way
  and Apache policies on it's own. I didn't have time to look deeper
  into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
  PPMC is ready to take on that responsibility. Along with that
  responsibility comes the right to make value judgements on topics like
  this where existing policies aren't clearly spelled out.

 Thanks Jukka. In fact, Sqoop already has a plan in place to completely
 remove com.cloudera.* namespace from its contents via the next major
 revision of the product. The work for that has already started and
 currently exists under the branch sqoop2 [3], tracked by SQOOP-365
 [4]. We hope that in a few months time, we will have feature parity in
 this branch with the trunk, which is when we will promote it to the
 trunk.

 [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
 [4] https://issues.apache.org/jira/browse/SQOOP-365

 
  Personally I think we should let the vote result stand with guidance
  to the new Sqoop PMC to discuss the matter with the branding team at
  trademarks@ to seek Apache-wide consensus. I encourage anyone who
  feels strongly about this (the point being made clearly has some
  merit) make their case to trademarks@ as it's IMHO not really the task
  of the Incubator to be forming new policy on this, especially with all
  the recent talk about scaling down the ambitions of the IPMC.

 This sounds like a great solution that addresses the concern and does
 not unduly penalize the Sqoop project.


You really should not be seeing this as being penalized. It's not about
that.

Alex

Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[Alex Karasulu]

  [X] +1 Recommend Jukka Zitting for the IPMC chair position.


+1

Re: [VOTE][PROPOSAL] Syncope join the Incubator

[Alex Karasulu]

+1 (binding)

-- 
Best of Luck,
-- Alex

Re: [DISCUSS] Syncope to Join the Apache Incubator

[Alex Karasulu]

On Fri, Feb 3, 2012 at 11:35 AM, Maurizio Cucchiara
mcucchi...@apache.orgwrote:

 Hi,
 I can't abstain from taking part (the call of the patriotic spirit).
 Jokes apart, I'm strongly interested in Identity Management (I have been
 looking for a good solution without success for a long time) and I would be
 honored to give my contribution.
 So I'm going to take the freedom to add myself to the initial committers
 list (obviously if there are no objection)

 Twitter :http://www.twitter.com/m_cucchiara
 G+  :https://plus.google.com/107903711540963855921
 Linkedin:http://www.linkedin.com/in/mauriziocucchiara


I am really interested especially since we started stuff like this in the
past like triple sec and the LDAP/KRB side built out over at directory is
so important for IdM. However I'm finding less and less time to mentor and
am trying unsuccessfully to effectively mentor the projects I'm already
involved with.

So it would be irresponsible of me to volunteer now. However guys give me a
rain check and when/if things do change I'm there to help in a hands-on way
since this topic and your project is very important to me.

Welcome, and I hope you succeed in all your endeavors and build a vibrant
community here at Apache.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] Syncope to Join the Apache Incubator

[Alex Karasulu]

On Wed, Feb 1, 2012 at 11:39 AM, Ross Gardler rgard...@opendirective.comwrote:

 On 1 February 2012 09:06, Emmanuel Lecharny elecha...@gmail.com wrote:
  On 2/1/12 1:04 AM, Benson Margulies wrote:
 
  Dear Proposed Syncope mentors:
 
  Please post messages on this thread indicating your prior experience
  as mentors,
 
  Does mentors have to have any experience ? Is this a new policy for
 being a
  mentor on an incubator project, or something you just are interested in ?

 Personally I find the request for mentors to justify themselves in
 this way quite disturbing. I do understand what Benson is trying to
 address here, I just don't think this is the right way. We have not,
 to my knowledge, agreed any changes to the mentor role. All people
 currently able to mentor have been pre-approved by the IPMC. Frankly I
 find it distasteful expecting volunteers with good intentions to
 further justify themselves.


+1

Indeed and very well put.


 That is not to say that things are OK as they are, but lets not take
 rash actions, lets figure it out and take one step at a time.


Also well put.


-- 
Best Regards,
-- Alex

Re: [DISCUSS] Syncope to Join the Apache Incubator

[Alex Karasulu]

On Tue, Jan 31, 2012 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi Simo!

 Sounds like a really nice project.

 But I wonder if there is some overlap with the Apache Shiro project [1]?


They're not the same as some have pointed out yet even if they were there's
nothing wrong with having overlapping projects or ones that even duplicate
each other functionally.

Alex

Re: [VOTE] Bloodhound to join the Incubator

[Alex Karasulu]

   Please vote:
   [X] +1 Accept Bloodhound for incubation
   [ ] +0 Don't care
   [ ] -1 Don't accept Bloodhound for incubation (please explain)
 
  The world needs a great issue tracker, and starting from the Trac base is
  Goodness.


Indeed.

+1

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate ACE from the Apache Incubator

[Alex Karasulu]

+1

binding ...

Cheers,
Alex

On Mon, Nov 21, 2011 at 2:07 PM, dav...@apache.org wrote:

 +1 (non-binding).
 It would be great to see Ace as a top level project.

 Best regards,

 David Bosschaert

 On 19 November 2011 01:33, Julien Vermillard jvermill...@gmail.com
 wrote:
  +1 binding
 
  On Friday, November 18, 2011, Alan D. Cabrera l...@toolazydogs.com
 wrote:
  +1  binding
 
 
  Regards,
  Alan
 
  On Nov 17, 2011, at 2:42 AM, Marcel Offermans wrote:
 
  In my opinion, ACE is ready to begin the process of graduating from the
  Apache Incubator to a Top Level Project.
 
  Since joining the incubator in in May 2009 we've added 4 new committers
  (12 in total now) from diverse organizations and did a release in May
 this
  year to demonstrate we follow the Apache guidelines. We've shown an
 ability
  to self-govern using accepted Apache practices and ACE continues to
 attract
  new contributors and users.
 
  The first step is to vote as a community, demonstrating that ACE is
  ready and willing to graduate. Once this vote is succesful we create a
  board resolution proposal or Charter and start a vote on the general
  incubator list. The full process is described at
  http://incubator.apache.org/guides/graduation.html#toplevel
 
  The vote is open for at least 72 hours.
 
  Greetings, Marcel
 
 
 
  -
  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




-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate ACE from the Apache Incubator

[Alex Karasulu]

On Mon, Nov 21, 2011 at 5:18 PM, Karl Pauls karlpa...@gmail.com wrote:

 On Mon, Nov 21, 2011 at 4:11 PM, ant elder ant.el...@gmail.com wrote:
  On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall he...@ungoverned.org
 wrote:
  On 11/21/11 09:41 , ant elder wrote:
 
  On Mon, Nov 21, 2011 at 2:18 PM, Karl Paulskarlpa...@gmail.com
  wrote:
 
  On Mon, Nov 21, 2011 at 3:08 PM, ant elderantel...@apache.org
  wrote:
 
  Well IMHO i don't think this release demonstrates that the poddling
  has an understanding of making or reviewing ASF releases and thats
 the
  point of requiring releases during incubation.
 
  So you want us to do a new release? Fine, whatever, we can just roll a
  new release which has the source distribution configured. That was a
  mistake in the first place as it makes the bundles not easily
  individually buildable.
 
  However, we still will not have a combined source release as we want
  to be able to release our bundles individually. Is that the resolution
  then? All we have to do is a do a micro release with the source
  distribution configured on a per artifact level?
 
  I agree the requirement for a single source release doesn't seem
  totally clear, I've said I think you should have one and so has sebb,
  it would be good to hear what other Incubator PMC people think. I
  think you need one for two main reasons:
 
  1) The ASF deals with source and the releases are how users get hold
  of that source. If a user is going to do development with the released
  ACE source they likely aren't going to be able to do very much useful
  with just single things like org.apache.ace.repository.imp. At the
  very least they're probably going to want
  org.apache.ace.repository.api too but likely there is a big network of
  the 60 something ACE modules that anyone doing most non-trivial ACE
  development is going to want. One source distribution makes this easy,
  making them have to download them all separately isn't particularly
  practical. That https://svn.apache.org/repos/asf/incubator/ace/trunk/
  is structured so the ASF committers can work with them as one single
  buildable checkout i think shows thats true.
 
  2) If there is only individually buildable source for each jar how are
  people really going to verify that the release is actually buildable
  and the artifacts match the SVN tag source when reviewing and voting
  on release votes? No one reviewing is really likely to download 60
  separate distros and build them all one by one are they?
 
  I disagree. There seems to be some misunderstanding that there is one
 single
  product that must be built.
 
  When you develop independently evolving modules, big bang releases do
 not
  make sense. Each module has its own release cycle. Occasionally you may
 end
  up creating some sort of distribution out of the modules and release
 that,
  but that is just one potential distribution.
 
 
  I agree thats an approach used and works in many projects but if that
  was really the case _here_  then surely the SVN would be structured so
  that there were separate trunk/branch/tag folders for each module,
  there would have been more releases than just the single 0.8.0
  release, and there would be separate release votes for each module
  being released.

 We have a tag per module and that is enough. Furthermore, we do
 combine several modules if it makes sense (i.e., we want to release
 them at the same time) in one vote as it would otherwise create a lot
 of extra traffic. That's all. It is the same set-up some of the other
 OSGi projects at the asf have (I did quite a lot of their releases).
 The only thing we missed was the source distributions per artifact.


And that IMHO is not enough to consider the release a failure. Let it be
noted and corrected for future releases. AFAIC there's no reason to hold
this podling back because of some minor release inconsistencies which are
natural as we shift from monolithic products to component based OSGi
products.

Best,
Alex

Re: Fw: [VOTE] Graduate ACE from the Apache Incubator

[Alex Karasulu]

On Mon, Nov 21, 2011 at 7:26 PM, Guillaume Nodet gno...@gmail.com wrote:

 That's really a good question.   I'm using apache projects a lot but I've
 never downloaded a single source release since ages, mostly using svn to
 checkout / build, or maven source jars for debugging within the ide as you
 said.
 I know it's a requirement, but it's not very useful for certain kind of
 projects imho..


Plus if I am going to make a bug fix or add a feature that I intend to
contribute back I will do it as a diff patch which I generate from version
control.

So having the sources in a release is worthless for me. Knowing the tag is
what I need to work the source, produce a patch and submit that back to the
community.

Regards,
Alex

Re: [VOTE] Accept Apache Callback for incubation

[Alex Karasulu]

+1

On Wed, Oct 12, 2011 at 12:29 PM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:

 On Tue, Oct 11, 2011 at 11:09 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Please VOTE:
 
 [ X] +1 Accept Apache Callback for incubation

 -Bertrand

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




-- 
Best Regards,
-- Alex

Re: [VOTE] Release HCatalog 0.2-incubating (RC1)

[Alex Karasulu]

On Tue, Sep 27, 2011 at 2:40 AM, Alan Gates ga...@hortonworks.com wrote:

 +1

 Verified checksums and signatures on both rpms and src tarball.
 Checked rat report.
 Verified LICENSE, NOTICE, and DISCLAIMER files.
 Tested the installation process, from both tarball and rpms.
 Ran the build and unit tests.


+1

Yeap all looks good. Good recovery from the last release attempt.

Regards,
Alex

Re: [VOTE] Accumulo to join the Incubator

[Alex Karasulu]

On Fri, Sep 9, 2011 at 7:22 PM, Doug Cutting cutt...@apache.org wrote:
 [ X ] +1 Accept Accumulo for incubation

Binding.

--Alex

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