Re: [PROPOSAL] : Airflow

[Scott Deboy]

Ll
On Mar 17, 2016 6:51 AM, "Jake Farrell"  wrote:

> Hi Siddharth
> Thanks for drafting a proposal and looking to bring Airflow to the Apache
> Incubator. Overall the proposal looks good, just a couple comments. The
> proposal has the incubator listed as the sponsor and a quick check shows
> Chris Riccomini is not on the IPMC or a member currently, details on roles
> are available at [1]. Not a blocker as you have members listed in your
> group of mentors and can ask that they step up as the champion.
>
> Mailing lists are in the old format, they should be
> - priv...@airflow.incubator.apache.org (moderated)
> - d...@airflow.incubator.apache.org
> - comm...@airflow.incubator.apache.org
>
> Github shows 109 contributors, but the proposal lists only 6 initial
> committers, where any of the other existing contributors considered for the
> proposal?
>
> When you submit the proposal please make sure to include the entire
> proposal in the email. If you have any questions please let us know
>
> -Jake
>
>
> [1]:
>
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion
>
> On Wed, Mar 16, 2016 at 8:28 PM, Siddharth Anand  >
> wrote:
>
> > https://wiki.apache.org/incubator/AirflowProposal
> >
> > Thoughts and comments are welcome!
> > -s (Sid)
> >
>

Re: [VOTE] Accept Log4cxx for Incubation

[Scott Deboy]

+1 (binding)

On 12/4/13, Marvin Humphrey mar...@rectangular.com wrote:
 On Wed, Dec 4, 2013 at 11:48 AM, Christian Grobmeier
 grobme...@gmail.com wrote:
 [ ] +1 Accept Log4cxx into the Incubator
 [ ] -1 Don't accept Log4cxx because...

 +1 (binding)

 Florian Seydoux florianseyd...@gmail.com (ICLA signed)
 chand priyankara ch...@engineering.com (ICLA signed)
 Nick Williams nickwilli...@apache.org (Apache Logging Committer)
 Thorsten Schöning tschoen...@am-soft.de
 Rhys Ulerich rhys.uler...@gmail.com (ICLA signed)
 Joseph Southwell jos...@southwell.org (ICLA signed)
 Alexandru Zbârcea zbarce...@gmail.com (ICLA signed)

 Christian Grobmeier grobmeier at apache dot org
 Scott Deboy sdeboy at apache dot org

 Good luck, everyone!

 Marvin Humphrey

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



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

Re: [VOTE] Apache Spark for the Incubator

[Scott Deboy]

+1

On 6/7/13, Ted Dunning ted.dunn...@gmail.com wrote:
 +1


 On Sat, Jun 8, 2013 at 7:34 AM, Mattmann, Chris A (398J) 
 chris.a.mattm...@jpl.nasa.gov wrote:

 Hi Folks,

 OK discussion has died down, time to VOTE to accept Spark into the
 Apache Incubator. I'll let the VOTE run for at least a week.

 So far I've heard +1s from the following folks, so no need for them
 to VOTE again unless they want to change their VOTE:

 +1

 Chris Mattmann*
 Konstantin Boudnik
 Henry Saputra*
 Reynold Xin
 Pei Chen
 Roman Shaposhnik*
 Suresh Marru*

 * -indicates IPMC

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

 Proposal text is below.

 === Abstract ===
 Spark is an open source system for large-scale data analysis on clusters.

 === Proposal ===
 Spark is an open source system for fast and flexible large-scale data
 analysis. Spark provides a general purpose runtime that supports
 low-latency execution in several forms. These include interactive
 exploration of very large datasets, near real-time stream processing, and
 ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
 with HDFS, HBase, Cassandra and several other storage storage layers, and
 exposes APIs in Scala, Java and Python.
 Background
 Spark started as U.C. Berkeley research project, designed to efficiently
 run machine learning algorithms on large datasets. Over time, it has
 evolved into a general computing engine as outlined above. Spark¹s
 developer community has also grown to include additional institutions,
 such as universities, research labs, and corporations. Funding has been
 provided by various institutions including the U.S. National Science
 Foundation, DARPA, and a number of industry sponsors. See:
 https://amplab.cs.berkeley.edu/sponsors/ for full details.

 === Rationale ===
 As the number of contributors to Spark has grown, we have sought for a
 long-term home for the project, and we believe the Apache foundation
 would
 be a great fit. Spark is a natural fit for the Apache foundation: Spark
 already interoperates with several existing Apache projects (HDFS, HBase,
 Hive, Cassandra, Avro and Flume to name a few). The Spark team is
 familiar
 with the Apache process and and subscribes to the Apache mission - the
 team includes multiple Apache committers already. Finally, joining Apache
 will help coordinate the development effort of the growing number of
 organizations which contribute to Spark.

 == Initial Goals ==
 The initial goals will most likely be to move the existing codebase to
 Apache and integrate with the Apache development process. Furthermore, we
 plan for incremental development, and releases along with the Apache
 guidelines.

 === Current Status ===
 == Meritocracy ==
 The Spark project already operates on meritocratic principles. Today,
 Spark has several developers and has accepted multiple major patches from
 outside of U.C. Berkeley. While this process has remained mostly informal
 (we do not have an official committer list), an implicit organization
 exists in which individuals who contribute major components act as
 maintainers for those modules. If accepted, the Spark project would
 include several of these participants as committers from the onset. We
 will work to identify all committers and PPMC members for the project and
 to operate under the ASF meritocratic principles.

 === Community ===
 Acceptance into the Apache foundation would bolster the already strong
 user and developer community around Spark. That community includes dozens
 of contributors from several institutions, a meetup group with several
 hundred members, and an active mailing list composed of hundreds of
 users.
 Core Developers
 The core developers of our project are listed in our contributors and
 initial PPMC below. Though many exist at UC Berkeley, there is a
 representative cross sampling of other organizations including
 Quantifind,
 Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends.


 === Alignment ===
 Our proposed effort aligns with several ongoing BIGDATA and U.S. National
 priority funding interests including the NSF and its Expeditions program,
 and the DARPA XDATA project. Our industry partners and collaborators are
 well aligned with our code base.

 There are also a number of related Apache projects and dependencies, that
 will be mentioned in the Relationships with Other Apache products
 section.

 == Known Risks ==

 === Orphaned Products ===
 Given the current level of investment in Spark - the risk of the project
 being abandoned is minimal. There are several constituents who are highly
 incentivized to continue development. The U.C. Berkeley AMPLab relies on
 Spark as a platform for a large number of long-term research projects.
 Several companies have build verticalized products which are tightly
 dependent on Spark. Other companies have devoted significant internal
 infrastructure investment 

Re: [VOTE] Accept Drill into the Apache Incubator

[Scott Deboy]

+1 (binding)

On Tue, Aug 7, 2012 at 7:41 PM, Ted Dunning ted.dunn...@gmail.com 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|Mongohttp://www.mongodb.org/display/DOCS/Mongo+Query+Language%7CMongoQuery
 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 schema-based
 formats such as Protocol Buffers/Dremel, Avro/AVRO-806/Trevni and CSV,
 and schema-less formats such as JSON, BSON or YAML. In addition, it is
 

Re: should podlings have informal chairs?

[Scott Deboy]

What about getting rid of the word 'champion'?  Seems like there are two
roles: the Member(s) which backed the proposal to enter the incubator, and
a Coordinator.

Scott

On Mon, Nov 21, 2011 at 9:06 AM, Ross Gardler rgard...@opendirective.comwrote:

 On 21 November 2011 16:47, Joe Schaefer joe_schae...@yahoo.com wrote:
  Personally I am against the idea of picking a chair
  for a podling early.

 That's not the proposal, although it was suggested and I believe
 rejected (for reasons similar to the ones you gave), at least I've not
 seen any support for it.

 The proposal is as the subject says an informal chair. The name
 seems to have moved to champion in order to avoid any impression of
 leadership.

 The responsibilities would be to the Incubator PMC to ensure that the
 project is progressing rather than struggling with busy elsewhere or
 inactive mentors.

 Does your concern extend to this role?

 Ross

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

Re: [VOTE] Accept OpenOffice.org for incubation

[Scott Deboy]

+1 (binding)

On Fri, Jun 10, 2011 at 11:13 AM, Roman H. Gelbort ro...@piensalibre.com.ar
 wrote:

 El 10/06/11 14:17, Roman H. Gelbort escribió:
  +1 Accept OpenOffice.org for incubation
 
 and binding

 --

 ---
 Prof. Román H. Gelbort
 No busquemos aplicaciones que reemplacen aplicaciones,
 sino aplicaciones que resuelvan problemas específicos...

 http://www.piensalibre.com.ar

 ---


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

Real-time communication (was [VOTE] ALOIS to enter the incubator)

[Scott Deboy]

I understand the concern raised by the use of real-time communication for
Apache projects - that decisions may be made off-list, and that folks who
aren't a party to the real-time communication do not have the opportunity to
benefit from or impact the decisions that result from the real-time
communication.

The proposal does offer what seems to be a reasonable compromise: 'we would
send the logs daily to the mailing list.'

Daily chat logs posted to the dev list, coupled with good mentoring and
guidance that decisions need to be made on the mailing list, would seem to
minimize the risk.

I'm interested in what others think of their proposal for supporting
real-time communication, and curious what others are doing, if anything, to
support the growing interest in real-time communication between project
participants.

Scott


On Thu, Sep 16, 2010 at 10:49 AM, Craig L Russell
craig.russ...@oracle.comwrote:

 Hi Urs,

 My only concern is the request to have a chat channel. There's wide use of
 chat channels in Apache (the periodic board and members' meetings make use
 of them, and infrastructure uses channels to advantage).

 But for an incubating project, I'd strongly discourage use of chat as a
 communication channel.

 +1

 Craig


 On Aug 26, 2010, at 9:09 AM, Urs Lerch wrote:

  Hi,

 I would like to call a vote for accepting ALOIS for incubation in
 the Apache Incubator. The full proposal is available below and on the
 proposal wiki page (http://wiki.apache.org/incubator/AloisProposal).  We
 ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as
 Champion and Mentor. Additional mentors are warmly welcome.

 Please cast your vote:

 [ ] +1, bring ALOIS into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring ALOIS into Incubator, because...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

 Thanks,
 Urs


 


 = Preface =

 ALOIS is a log collection and correlation software with reporting and
 alarming functionalities. It has been implemented by the Swiss company
 IMSEC for a customer about five years ago. GPL-licenced, implemented in
 Ruby and completely based on other OSS-licensed components, it was
 designed for the open source community right from the start. Now that
 the software has shown its functioning over several years in production
 with the one customer and one IMSEC-internal installation, it seems to
 be the right time to open it to a wider community.


 = Abstract =

 ALOIS stands for „Advanced Logging and Intrusion Detection System“ and
 is meant to be a fully implemented open source SIEM (security
 information and event management) system.


 = Proposal =

 While almost all other SIEM software, be it closed or open source,
 concentrate on the technological part of security monitoring, ALOIS is
 aimed to monitor the security of the content. It intends to be
 pro-active in the detection of potential loss, theft, mistaken
 modification or unauthorized access. ALOIS works on log messages and
 thus contains all the basic functionality of a conventional SIEM, as
 centralized collecting, normalizing, aggregation, analyzing and
 correlating of all log messages, as well as reporting all security
 related events. Therefore it can be used as any other SIEM.

 ALOIS consists of five modules interacting to ensure a scaleable
 functionality of a SIEM:

  * Insink is the message sink, which is the receiving entry point for
 all the different log messages into ALOIS. It is partly based on the
 syslog-ng software. Insink listens for messages (UDP), waits for
 messages (TCP), receives message collections (files, emails) and
 pre-filters them to prevent from message flow overload.

  * Pumpy is the incoming FIFO buffer, implemented as a relational
 database tables. which contain the incoming original messages (in raw
 format). In a complex system setup, there may be several insink
 instances, e.g. for a group of hosts, for specific types of messages, or
 for high-avaliablity.

  * Prisma contains logic to split up the text of log messages into
 separate fields, based on regular expressions. Actually, prisma is a
 set of prismi, each one prisma for one type of log message (apache,
 cisco etc. Several prismi can be applied to the same message. This
 allows for stacked messages, i.e. forwarded log messages contained in
 compressed files contained in e-mail messages. The data retrieved form
 the log messages is stored in a database called Dobby. Due to prisma
 being written in Ruby, prismi can be applied interactively (when having
 system access).

  * Dobby is the central log database. It should be separated from the
 Pumpy database for availability and performance reasons. The current
 implementation is based on MySQL.

  * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard
 is the analysis engine and user interface of ALOIS, implemented in Ruby
 on Rails using AJAX. It allows

Re: [VOTE] ALOIS to enter the incubator

[Scott Deboy]

, a lot of the internal communication happens in
  a chat. Thus, opening a new chat channel for the community is scheduled.
  (To document the discussions for all those who were off-line, we would
  send the logs daily to the mailing list.)
 
 
  = Initial Source =
 
  Although the initial source comes from a project for a customer. it has
  an open source licence since the beginning. Therefore it doesn't have
  any propriatary code in it. A thorough revision before releasing it to a
  public repository is recommend and is also in planning.
 
  The initial source will be a snapshot of the version control system,
  accompanied by a related debian package.
 
 
  = Source and Intellectual Property Submission Plan =
 
  ALOIS is currently under a GPL licence. Since there are only two
  contributors so far, both from the same company, there is no problem to
  re-licence the code and contribute it to Apache. The commitment of the
  company's owner has been granted.
 
 
  = External Dependencies =
 
  So far, no external dependencies are known. As mentioned before, a
  thorough revision of the codebase is in planning. There it can be
  controlled, that no other licence is affected by the code.
 
 
  = Cryptography =
 
  ALOIS does not involve cryptographic code.
 
 
  = Required Resources =
 
  == Mailing lists ==
 
  The following mailing lists will be required:
 
   * alois-private
   * alois-dev
   * alois-commits
   * alois-users
 
  == Subversion Directory ==
 
  https://svn.apache.org/repos/asf/incubator/alois
 
  == Issue Tracking ==
 
  JIRA ALOIS (ALOIS)
 
  == Other Resources ==
 
  We would like to open a chat channel. If this isn't possible within the
  infrastructure of Apache, we would love to do this in our own already
  existing infrastructure.
 
 
  = Initial Commiters =
 
   * NAME EMAIL  AFFILIATION  CLA
   * Flavio Pellanda  flavio.pellanda at logintas dot ch IMSECno
   * Urs Lerchmail at ulerch dot net IMSECyes
   * Daniel Lutz  daniel.lutz at logintas dot ch IMSECno
   * Marcus Holthaus  marcus.holthaus at imsec dot chIMSECno
 
 
  = Sponsors =
 
  == Champion ==
 
   * Scott Deboy sdeboy at apache dot org
 
  == Nominated Mentors ==
 
   * Scott Deboy sdeboy at apache dot org
   * Christian Grobmeier grobmeier at apache dot org
 
  == Sponsoring Entity ==
 
  The Incubator PMC (requested)
 

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

Re: [VOTE] ALOIS to enter the incubator

[Scott Deboy]

+1

On Thu, Aug 26, 2010 at 9:54 AM, Mohammad Nour El-Din 
nour.moham...@gmail.com wrote:

 +1 notbinding

 On Thu, Aug 26, 2010 at 4:30 PM, Benson Margulies bimargul...@gmail.com
 wrote:
  OK, I read the syntax of this sideways.
 
  +1, binding, from me.
 
  On Thu, Aug 26, 2010 at 12:26 PM, Urs Lerch m...@ulerch.net wrote:
  Hi
 
  There is, at least in my opinion, a very clear statement regarding the
  licencing:
 
   = Source and Intellectual Property Submission Plan =
 
   ALOIS is currently under a GPL licence. Since there are only two
   contributors so far, both from the same company, there is no problem
   to re-licence the code and contribute it to Apache. The commitment of
   the company's owner has been granted.
 
  The names of the two contributors are listed elsewhere in the proposal.
  Do you think that ain't enough?
 
  Best
  Urs
 
 
  Am Donnerstag, den 26.08.2010, 12:17 -0400 schrieb Benson Margulies:
  I don't see anything explicit in here about relicensing from GPL to
  ASL. Perhaps that was hashed out before I joined the PMC?
 
  I'm +0 tending toward -1 without an explicit statement that the
  copyright owners are known and on board with the license change.
 
  On Thu, Aug 26, 2010 at 12:09 PM, Urs Lerch m...@ulerch.net wrote:
   Hi,
  
   I would like to call a vote for accepting ALOIS for incubation in
   the Apache Incubator. The full proposal is available below and on the
   proposal wiki page (http://wiki.apache.org/incubator/AloisProposal).
  We
   ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as
   Champion and Mentor. Additional mentors are warmly welcome.
  
   Please cast your vote:
  
   [ ] +1, bring ALOIS into Incubator
   [ ] +0, I don't care either way,
   [ ] -1, do not bring ALOIS into Incubator, because...
  
   This vote will be open for 72 hours and only votes from the Incubator
   PMC are binding.
  
   Thanks,
   Urs
  
  
   
  
  
   = Preface =
  
   ALOIS is a log collection and correlation software with reporting and
   alarming functionalities. It has been implemented by the Swiss
 company
   IMSEC for a customer about five years ago. GPL-licenced, implemented
 in
   Ruby and completely based on other OSS-licensed components, it was
   designed for the open source community right from the start. Now that
   the software has shown its functioning over several years in
 production
   with the one customer and one IMSEC-internal installation, it seems
 to
   be the right time to open it to a wider community.
  
  
   = Abstract =
  
   ALOIS stands for „Advanced Logging and Intrusion Detection System“
 and
   is meant to be a fully implemented open source SIEM (security
   information and event management) system.
  
  
   = Proposal =
  
   While almost all other SIEM software, be it closed or open source,
   concentrate on the technological part of security monitoring, ALOIS
 is
   aimed to monitor the security of the content. It intends to be
   pro-active in the detection of potential loss, theft, mistaken
   modification or unauthorized access. ALOIS works on log messages and
   thus contains all the basic functionality of a conventional SIEM, as
   centralized collecting, normalizing, aggregation, analyzing and
   correlating of all log messages, as well as reporting all security
   related events. Therefore it can be used as any other SIEM.
  
   ALOIS consists of five modules interacting to ensure a scaleable
   functionality of a SIEM:
  
* Insink is the message sink, which is the receiving entry point for
   all the different log messages into ALOIS. It is partly based on the
   syslog-ng software. Insink listens for messages (UDP), waits for
   messages (TCP), receives message collections (files, emails) and
   pre-filters them to prevent from message flow overload.
  
* Pumpy is the incoming FIFO buffer, implemented as a relational
   database tables. which contain the incoming original messages (in raw
   format). In a complex system setup, there may be several insink
   instances, e.g. for a group of hosts, for specific types of messages,
 or
   for high-avaliablity.
  
* Prisma contains logic to split up the text of log messages into
   separate fields, based on regular expressions. Actually, prisma is
 a
   set of prismi, each one prisma for one type of log message (apache,
   cisco etc. Several prismi can be applied to the same message. This
   allows for stacked messages, i.e. forwarded log messages contained in
   compressed files contained in e-mail messages. The data retrieved
 form
   the log messages is stored in a database called Dobby. Due to prisma
   being written in Ruby, prismi can be applied interactively (when
 having
   system access).
  
* Dobby is the central log database. It should be separated from the
   Pumpy database for availability and performance reasons. The current
   implementation is based on MySQL.
  
* The Analyzer contains

RE: Statements from Qpid mentors would help me decide... [WAS Re: [VOTE] Apache Qpid Graduation as TLP]

[Scott Deboy]

I would expect to see proof of qpid's ability to grow their committership and 
build a user community before leaving the incubator.  There's no track record 
of either at the moment.

According to incubator-general mail archives, qpid voted in 4 committers since 
April of 2007.  Additionally, those folks don't appear active on the qpid 
developer list.

The 'diversity' question was partially answered, but it's still a concern for 
me.  

I imagine it'll be hard to attract new folks to qpid when they're mostly 
corporate-sponsored, and some of those sponsorships -can't- be transparent to 
the ASF.  They'll probably be able to attract committers, but the new 
committers will probably come from other corporate sponsors.




Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:  503.224.7496
Cell:   503.997.1367
Fax:503.222.0185

[EMAIL PROTECTED]

www.comotivsystems.com



-Original Message-
From: [EMAIL PROTECTED] on behalf of Yoav Shapira
Sent: Fri 3/21/2008 4:52 AM
To: general@incubator.apache.org
Subject: Re: Statements from Qpid mentors would help me decide... [WAS Re: 
[VOTE] Apache Qpid Graduation as TLP]
 
On Fri, Mar 21, 2008 at 4:19 AM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
 On Thu, Mar 20, 2008 at 6:55 PM, Carl Trieloff [EMAIL PROTECTED] wrote:
At this point the Apache Qpid community with support from its mentors 
 feels that
it is ready to graduate to an official top level project at Apache

  but another voice asks: are they really ready today? has the IPMC
  fully equipped them for the chanlleges ahead? do they really
  understand how to mentor new independent developers into committers
  and PMCers? is the diversity sufficient to have learnt how to have
  disagreements on technical matters whilst retaining community spirit?

It's a hard call for me as well.  The technical bits are all there,
processes followed, paperwork filed, etc.  More importantly, the qpid
community has been open, receptive to feedback from everyone inside
and outside their group, welcoming to new opinions from new people,
and respectful of ASF spirit, not just its letter.  There are
disagreements and debates on various technical matters without hurting
the community.  That's why I support their graduation.

It would have been really nice if one or two more committers from new
organizations had been added during the previous few months, but that
didn't happen.  But I don't think the fact the committers come from a
small set of organizations necessarily means there's no diversity.
And I don't want to introduce artificial requirements.  The are they
really ready question is subjective by definition, and it's a good
one, but I still vote +1 ;)

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: FW: (qpid) Diversity

[Scott Deboy]

For the qpid folks who don't want to divulge their employer: are they
working on the project as part of their employment?  If so, it would
appear we need a CCLA, correct?

If we don't know the committer's employer (and they're working on the
project as an employee), we can't determine if a CCLA is on file.

From http://www.apache.org/licenses/

---
For a corporation that has assigned employees to work on an Apache
project, a Corporate CLA (CCLA) is available for contributing
intellectual property via the corporation, that may have been assigned
as part of an employment agreement. Note that a Corporate CLA does not
remove the need for every developer to sign their own CLA as an
individual, to cover any of their contributions which are not owned by
the corporation signing the CCLA.



Scott Deboy


-Original Message-
From: Rajith Attapattu [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 06, 2008 10:48 AM
To: general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity

On Thu, Mar 6, 2008 at 8:23 AM, Martin Ritchie [EMAIL PROTECTED]
wrote:

 On 06/03/2008, Noel J. Bergman [EMAIL PROTECTED] wrote:
  Daniel Kulp write:
a quick svn log on their SVN repo for all commits since Jan 1
 [suggests
   that]
 
   all but 4 commits since Jan 1 can easily be contributed to RedHat
   employees.
 
 
   I think the above should provide enough information about the
health
 and
diversity of the community that actually working on the code.
 
 
  What is the Qpid community's response to these findings?
 
 
  --- Noel


I believe if a committer has signed the required legal documents then
thats
all what matters.
If they are uncomfortable disclosing their employer then perhaps we
should
respect that.
What is important is that these folks are contributing to the project in
a
legal manner.
The last thing we want is to discourage people from contributing.

As martin has pointed out, looking at the last 6 months and just the
trunk
is not a fair evaluation of diversity.
We should also not forget the significant contributions made by the
following folks in the last year or two.
Off the top of my head.

Colin Crist - Hermes JMS integration
Kevin Smith - SSL patch for the java broker.
Steve Vinoski - Maven build system
Tomas Restrepo - .NET client.
There was also a few individuals who made patches for the python client
to
get it interoperating with other open source implementations.

I am very optimistic that our community will continue to grow with more
contributions as we increase our visibility and efforts to integrate
with
other projects like Synapse, Axis2, Tuscany, CXF etc..

Regards,

Rajith Attapattu
Red Hat
blog: http://rajith.2rlabs.com/



 Ok I have a few comments in response to the findings:

 - Firstly not all work is done on trunk so purely looking at trunk is
 not a good metric

 - Looking at the last two months especially as that includes the start
 of the year which is typically a quite period also will show poor
 commit numbers.

 - We are preparing for an M2.1 release so a lot of effort is being
 expended on that branch.

 My take would be to look at the last 6 months, which admittedly
 includes a number of holiday periods so the count of commits may be a
 little low. Since 2007-09 for the commits on the qpid repository
 shows:

 aconway 272
 aidan 54
 arnaudsimon 230
 astitcher 16
 cctrieloff 45
 gsim 201
 kpvdr 11
 nsantos 8
 rajith 169
 rgodfrey 99
 rgreig 98
 rhs 151
 ritchiem 593
 rupertlssmith 468

 1103RedHat
 1312Non-Aligned

 So Redhat have less than half the commits to Qpid so I don't think
 this is something we should worry about. Keeping an eye on for sure,
 but over analysing the alignment of those people that don't want to or
 are not allowed to say who they work for is not something that Apache
 requires nor would it be beneficial. Saying that we are not diverse
 because a lot of work on trunk has been done by a small set of people
 over a two month period is not helpful to the discussion.

 It is also worth noting that volume of commits does not in anyway
 correspond to the quantity of code changed and even looking at lines
 changes cannot say anything for the quality. I think the fact that we
 have an active project that has matured to the point that where we
 feel as though we can self regulate in the Apache Way speaks far more
 to the community of the project than identifying who is paying the
 bills.

 The whole project worked very hard to pull together two servers and
 five client libraries for the M2 release all talking AMQP 0-8. We are
 again working as a community to provide a M2.1 release that will inter
 operate at AMQP 0-9 with other AMQP products outside the Apache world.
 I for one am looking forward to our future releases where we can again
 move the entire project on to the wholly different AMQP 0-10.

 --
 Martin Ritchie

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED

RE: FW: (qpid) Diversity

[Scott Deboy]

Does ASF need proof that a transfer of intellectual property ownership
occurred?

Scott Deboy


-Original Message-
From: Robert Greig [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 06, 2008 3:10 PM
To: [EMAIL PROTECTED]; general@incubator.apache.org
Subject: Re: FW: (qpid) Diversity

On 06/03/2008, Scott Deboy [EMAIL PROTECTED] wrote:
 For the qpid folks who don't want to divulge their employer: are they
 working on the project as part of their employment?  If so, it would
 appear we need a CCLA, correct?

I do not believe so since those employees have signed legal documents
with the employer where the employer has transferred the intellectual
property ownership to the employee.

Therefore those committers are effectively working as private
individuals.

RG

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]