Re: [DISCUSS] Druid incubation proposal

[Brian McCallister]

+1 - glad to see Druid finally (hopefully) landing here!

On Wed, Feb 21, 2018 at 10:57 PM, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> Woot!
>
> +1 for druid incubation.
>
> -h
>
>
>
> On Fri, Feb 16, 2018 at 12:15 PM, Gian Merlino  wrote:
>
> > Hi all,
> >
> > I would like to open up a discussion about incubating Druid at Apache.
> I've
> > included a proposal in this mail and have also posted a draft at
> > https://wiki.apache.org/incubator/DruidProposal. More information about
> > Druid is also available on our project web site at: http://druid.io/
> >
> > Thanks for your consideration!
> >
> > Gian
> >
> > = Druid Proposal =
> >
> > == Abstract ==
> >
> > Druid is a high-performance, column-oriented, distributed data store.
> >
> > == Proposal ==
> >
> > Druid is an open source data store designed for real-time exploratory
> > analytics on large data sets. Druid's key features are a column-oriented
> > storage layout, a distributed shared-nothing architecture, and ability to
> > generate and leverage indexing and caching structures. Druid is typically
> > deployed in clusters of tens to hundreds of nodes, and has the ability to
> > load data from Apache Kafka and Apache Hadoop, among other data sources.
> > Druid offers two query languages: a SQL dialect (powered by Apache
> Calcite)
> > and a JSON-over-HTTP API.
> >
> > Druid was originally developed to power a slice-and-dice analytical UI
> > built on top of large event streams. The original use case for Druid
> > targeted ingest rates of millions of records/sec, retention of over a
> year
> > of data, and query latencies of sub-second to a few seconds. Many people
> > can benefit from such capability, and many already have (see
> > http://druid.io/druid-powered.html). In addition, new use cases have
> > emerged since Druid's original development, such as OLAP acceleration of
> > data warehouse tables and more highly concurrent applications operating
> > with relatively narrower queries.
> >
> > == Background ==
> >
> > Druid is a data store designed for fast analytics. It would typically be
> > used in lieu of more general purpose query systems like Hadoop !MapReduce
> > or Spark when query latency is of the utmost importance. Druid is often
> > used as a data store for powering GUI analytical applications.
> >
> > The buzzwordy description of Druid is a high-performance,
> column-oriented,
> > distributed data store. What we mean by this is:
> >
> >  * "high performance": Druid aims to provide low query latency and high
> > ingest rates possible.
> >  * "column-oriented": Druid stores data in a column-oriented format, like
> > most other systems designed for analytics. It can also store indexes
> along
> > with the columns.
> >  * "distributed": Druid is deployed in clusters, typically of tens to
> > hundreds of nodes.
> >  * "data store": Druid loads your data and stores a copy of it on the
> > cluster's local disks (and may cache it in memory). It doesn't query your
> > data from some other storage system.
> >
> > == Rationale ==
> >
> > Druid is a mature, active project with a large number of production
> > installations, dozens of contributors to each release, and multiple
> vendors
> > offering professional support. Given Druid's strong community, its close
> > integration with many other Apache projects (such as Kafka, Hadoop, and
> > Calcite), and its pre-existing Apache-inspired governance structure, we
> > feel that Apache is the best home for the project on a long-term basis.
> >
> > == Current Status ==
> >
> > === Meritocracy ===
> > Since Druid was first open sourced the original developers have solicited
> > contributions from others, including through our blog, the project
> mailing
> > lists, and through accepting !GitHub pull requests. We have an
> > Apache-inspired governance structure with a PMC and committers, and our
> > committer ranks include a good number of people from outside the original
> > development team.
> >
> > === Community ===
> >
> > The Druid core developers have sought to nurture a community throughout
> the
> > life of the project. We use !GitHub as the focal point for bug reports
> and
> > code contributions, and the mailing lists for most other discussion. To
> try
> > to make people feel welcome, we've also spelled this out on a
> "CONTRIBUTE"
> > link from the project page: http://druid.io/community/. Today we have an
> > active contributor base (a typical release has ~40 contributors) and
> > mailing list.
> >
> > === Core Developers ===
> >
> > Druid enjoys good diversity of committer affiliation. The most active
> > developers over the past year are affiliated with four different
> companies:
> > Imply, Metamarkets, Yahoo, and Hortonworks. Many Druid committers are
> also
> > committers on other ASF projects as well, including Apache Airflow,
> Apache
> > Curator, and Apache Calcite. The original developers of Druid remain
> > involved in the project.
> >
> > === 

Re: [DISCUSS] RocketMQ Incubation Proposal

[Brian McCallister]

+1 !

On Fri, Nov 4, 2016 at 8:37 AM, Jim Jagielski  wrote:

> Cool.
>
> +1
>
> > On Nov 3, 2016, at 6:10 PM, Bruce Snyder  wrote:
> >
> > Please find below a proposal for a new Incubator podling named Apache
> > RocketMQ, a fast, low latency, reliable, scalable, distributed, easy to
> use
> > message-oriented middleware, especially for processing large amounts of
> > streaming data.
> >
> > The draft proposal can be found in the wiki at the following URL:
> >
> > https://wiki.apache.org/incubator/RocketMQProposal
> >
> > Below, please find the text for the proposal below.
> >
> > Thanks,
> >
> > Bruce
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Annotator

[Brian McCallister]

+1 from me!

On Thu, Aug 11, 2016 at 11:23 AM Daniel Gruno  wrote:

> Obviously a binding +1 from me :)
>
> With regards,
> Daniel.
>
> On 08/08/2016 09:41 PM, Benjamin Young wrote:
> > Hi all!
> >
> > Thanks for everyone who's contributed to the discussion around the
> Apache Annotator proposal:
> > https://wiki.apache.org/incubator/AnnotatorProposal
> >
> > From what our Champion tells me, we're now ready to go to a vote!
> >
> > We have a long and eager list of contributors, a key focus around
> existing code and completed W3C standards for annotation, and a growing
> world of annotation-centric tools on and off the Web (including NLP and
> machine learning).
> >
> > I'd also like to say a quick "thanks" to our Champion to our Mentors for
> their input and help along the way.
> >
> > Cheers!
> > Benjamin
> > --
> > http://bigbluehat.com/
> > http://linkedin.com/in/benjaminyoung
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Apache Annotator needs you to mentor! ;)

[Brian McCallister]

On Tue, Jul 5, 2016 at 1:39 PM, Benjamin Young 
wrote:

> Hi all!
>
> I'd very much like to un-log-jam the Annotator Proposal which I submitted
> back in late May-hence the new thread. ;)
>
> AFAIK, we only need one more Mentor to get things rolling. Two of our
> committers are from the Apache CouchDB community and have been doing The
> Apache Way for > 5+ years each, so it should be a fairly easy mentoring
> time as you'll have help. ;)
>
> Please give our proposal a read through and sign-up as our last Mentor:
> https://wiki.apache.org/incubator/AnnotatorProposal


I've not mentored in quite a few years, so am kind of rusty, but this is a
project I wish I knew existed prior to seeing this email, and now will use
the bejoobers out of, so... I'll volunteer if you need me :-)

-Brian

/me wanders off to read the current expectations of mentors :-)


>
> The future of commentary on all the things needs you!
> Benjamin
>
> P.S.: The original thread starts here (for the curious):
>
> https://lists.apache.org/thread.html/92ecfbc40a1feb4db345e4210b0f68afd31a31ff96dfb618c214ee84@1464702385@%3Cgeneral.incubator.apache.org%3E
> --
> http://bigbluehat.com/
> http://linkedin.com/in/benjaminyoung
>
>

Re: [VOTE]: Graduate Apache jclouds as an Apache Top Level Project

[Brian McCallister]

And a belated +1, not that it needs the extra vote, but jclouds functions
great!


On Tue, Sep 24, 2013 at 3:56 AM, Suresh Marru sma...@apache.org wrote:

 On Sep 23, 2013, at 2:57 PM, Andrew Bayer andrew.ba...@gmail.com wrote:

  Reminder - it'd be great to get more eyes and make sure we're not missing
  anything for graduation. Thanks!

 + 1 (already voted on PPMC list, just cheer leading for others to look
 over)

 Andrew,

 Since 5 IPMC member/mentors already voted on the Podling dev list, I do
 not think any further votes are needed. But as you put it rightly, more
 eyes and reviews will be better. I would just put a end time to close the
 vote. Since the next board meeting is 3 weeks away, no hurry though.

 Suresh

 
  A.
 
 
  On Fri, Sep 20, 2013 at 5:00 PM, Andrew Bayer andrew.ba...@gmail.com
 wrote:
 
  argh, line breaks all vanished in weird ways. Here's a better format:
 
  The Apache jclouds project entered incubation in April of 2013, and
 since
  then has shipped two releases, added a committer, and transitioned
  thoroughly into the Apache Way for decision-making, development process,
  etc. Our website[1] conforms, so far as we can tell, with Apache's
  standards, the existing jclouds registered trademark has been
 transferred
  to the ASF[2], we've decided on a set of project bylaws[4], and now
 we've
  held a vote[5] on a graduation resolution[6, and below] to be added to
 the
  agenda for the next ASF board meeting.
  The vote has passed[7] with 7 binding PPMC +1s and 4 binding mentor +1s,
  so on behalf of the Apache jclouds project, I'd like to request the
 IPMC's
  approval for our graduation. Thanks!
 
  Please cast your vote:
 
  [ ] +1 Graduate the Apache jclouds podling from Apache Incubator as a
 TLP
  [ ] +0 Indifferent to the graduation status of Apache jclouds podling
  [ ] -1 Reject graduation of Apache jclouds podling from Apache Incubator
  because ...
 
  The vote will be open for 72 hours, until 5pm PDT on Monday, September
  23rd.
 
  [1]: http://jclouds.incubator.apache.org/
  [2]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-37
  [3]: http://apache.markmail.org/thread/q6sqwspp55sjtk2v
  [4]: https://wiki.apache.org/jclouds/Bylaws
  [5]: http://markmail.org/thread/vnnvej3q7sla3btl
  [6]: https://wiki.apache.org/jclouds/GraduationCharter
  [7]: http://apache.markmail.org/thread/55d6vle5be43gwtv
 
  Thanks again -
  The Apache jclouds 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
  providing a cloud agnostic library for the JVM that enables
  developers to access a variety of supported cloud providers using
  one API, for distribution at no charge to the public.
 
  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
  Committee (PMC), to be known as the The Apache jclouds Project,
  be and hereby is established pursuant to Bylaws of the
  Foundation; and be it further
 
  RESOLVED, that The Apache jclouds Project be and hereby is
  responsible for the creation and maintenance of a software
  project related to providing a cloud agnostic library for the JVM
  that enables developers to access a variety of supported cloud
  providers using one API; and be it further
 
  RESOLVED, that the office of Vice President, jclouds 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
  jclouds Project, and to have primary responsibility for
  management of the projects within the scope of responsibility of
  The Apache jclouds 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 jclouds Project:
 
  * Adrian Cole (adrianc...@apache.org)
  * Andrew Bayer(aba...@apache.org)
  * Andrew Gaul (g...@apache.org)
  * Andrew Phillips (andr...@apache.org)
  * Becca Wood  (silky...@apache.org)
  * Everett Toews   (ever...@apache.org)
  * David Nalley(ke4...@apache.org)
  * Ignasi Barrera  (n...@apache.org)
  * Ioannis Canellos(ioca...@apache.org)
  * Matt Stephenson (matts...@apache.org)
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrew Bayer be and
  hereby is appointed to the office of Vice President, jclouds, 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 jclouds Project be and hereby
  is tasked with the migration and rationalization of the Apache
  Incubator jclouds podling; and be it further
 
  RESOLVED, that all responsibility pertaining to the 

Re: [PROPOSAL] Aurora for Incubation

[Brian McCallister]

Aurora is aimed at long-running stateless services (like app servers)?

-Brian


On Mon, Aug 26, 2013 at 3:27 PM, Dave Lester d...@ischool.berkeley.eduwrote:

 Hi All,

 We're pleased to share a draft ASF incubation proposal for Aurora, a
 service scheduler used to schedule jobs onto Apache Mesos that we've
 developed at Twitter. Aurora provides all of the primitives necessary to
 quickly deploy and scale stateless and fault tolerant services in a
 datacenter. The complete proposal can be found:
 https://wiki.apache.org/incubator/AuroraProposal, and also pasted below.

 In particular, we'd love to add additional mentors to the project. Your
 feedback is appreciated.

 Dave

 = Abstract =

 Aurora is a service scheduler used to schedule jobs onto Apache Mesos.

 = Proposal =

 Aurora is a scheduler that provides all of the primitives necessary to
 quickly deploy and scale stateless and fault tolerant services in a
 datacenter.

 Aurora builds on top of Apache Mesos and provides common features that
 allow any site to run large scale production applications. While the
 project is currently used in production at Twitter, we wish to develop a
 community to increase contributions and see it thrive in the future.

 = Background =

 The initial development of Aurora was done at Twitter, and is planned to be
 open sourced. This proposal is for Aurora to join the Apache Incubator.

 = Rationale =

 While the Apache Mesos core focuses on distributing individual tasks across
 nodes in a cluster, typical services consist of dozens or hundreds of
 replicas of tasks. As a service scheduler, Aurora provides the abstraction
 of a job to bundle and manage these tasks. Aurora provides many key
 functionalities centered around a job, including: definition, the concept
 of an instance and the serverset, deployment and scheduling, health
 checking, and introspection. It also allows cross-cutting concerns to be
 handled like observability and log collection.

 = Current Status =

 == Meritocracy ==

 By submitting this incubator proposal, we’re expressing our intent to build
 a diverse developer community around Aurora that will conduct itself
 according to The Apache Way and use meritocratic means of accepting
 contributions. Several members of the Aurora team overlap with Apache
 Mesos, which successfully graduated from the Incubator and has embraced a
 meritocratic model of governance; we plan to follow a similar path forward
 with Aurora and believe that a synergy between both projects will make this
 even easier.

 == Community ==

 Aurora is currently being used internally at Twitter. By open sourcing the
 project, we hope to extend our contributor base significantly and create a
 vibrant community around the project.

 == Core Developers ==

 Aurora is currently being developed by a team of seven engineers at
 Twitter.

 == Alignment ==

 The ASF is a natural choice to host the Aurora project, given the goal of
 open sourcing the project and fostering a community to grow and support the
 software. Additionally, Aurora integrates with Apache Mesos, and Apache
 ZooKeeper for service discovery.

 We believe that inclusion within Apache will build stronger ties between
 these projects, and create further alignment between their goals and
 communities.

 = Known Risks =

 == Orphaned Products ==

 The core developers plan to continue working full time on the project, and
 there is very little risk of Aurora being abandoned since it is running
 hundreds of services as part of Twitter’s infrastructure. Additionally,
 members of the Mesos community beyond Twitter have expressed interest in an
 advanced scheduler like Aurora (see “Interested Parties” section); we
 believe that need will drive some of the community involvement necessary
 for the project to incubate successfully.

 == Inexperience with Open Source ==

 Initial Aurora committers have varying levels of experience using and
 contributing to Open Source projects, however by working with our mentors
 and the Apache community we believe we will be able to conduct ourselves in
 accordance with Apache Incubator guidelines. The close relationship between
 the Aurora team and Apache Mesos means there is an awareness of the
 incubation process and a willingness to embrace The Apache Way.

 == Homogenous Developers ==

 The initial set of committers are from a single organization, however we
 expect that once approved for incubation the project will attract
 contributors from more organizations. We have already had conversations
 with other companies who have expressed an interest in Aurora.

 == Reliance on Salaried Developers ==

 Initial Aurora committers are salaried developers at Twitter, however
 shortly after open sourcing the code we plan to diversify the project’s
 core committers and contributors.

 == Relationships with Other Apache Products ==

 Initially, Aurora has been developed as a scheduler for Apache Mesos.
 Additionally, it relies on ZooKeeper for service 

Re: [VOTE] Accept jclouds into the Apache Incubator

[Brian McCallister]

 as a build tool with the jclouds API.

 jclouds includes support for the Apache CloudStack API and is used as a
 compatibility test tool for its EC2 interface. jclouds can also be used to
 test Apache Deltacloud EC2 portability.

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

 jclouds recognizes the fortitude of the Apache brand, but the motivation
 for becoming an Apache project is to strengthen and expand the jclouds
 community and its user base. While the jclouds community has seen steady
 growth over the past several years, association with the ASF is expected to
 expedite this pattern of growth. Development is expected to continue on
 jclouds under the Apache license whether or not it is supported by the ASF.

 == Documentation ==

 The [[http://www.jclouds.org/|jclouds]] project documentation is publicly
 available at the following sites:

   * http://jclouds.org: installation guide, user guides, development
 resources, news, resources to get started
   * https://github.com/jclouds/jclouds: current source, source code
 issues log
   * https://github.com/jclouds/jclouds.github.com: static content for
 jclouds.org, documentation issues log
   * https://twitter.com/jclouds: jclouds on Twitter
   * https://groups.google.com/forum/?fromgroups#!forum/jclouds-dev: the
 jclouds development forum on Google Groups
   * https://groups.google.com/forum/?fromgroups#!forum/jclouds: the
 jclouds community forum on Google Groups

 == Initial Source ==

 The initial source is located on GitHub in the following repositories:

  * git://github.com/jclouds/jclouds.git
  * git://github.com/jclouds/jclouds-labs.git
  * git://github.com/jclouds/jclouds.github.com.git
  * git://github.com/jclouds/jclouds-chef.git
  * git://github.com/jclouds/jclouds-cli.git
  * git://github.com/jclouds/jclouds-karaf.git
  * git://github.com/jclouds/jclouds-examples.git

 == Source and Intellectual Property Submission Plan ==

 jclouds's initial source is licensed under the Apache License, Version
 2.0. https://github.com/jclouds/jclouds/blob/master/resources/LICENSE.txt

 == External Dependencies ==

 This is a listing of Maven coordinates for all of the external
 dependencies jclouds uses. All of the dependencies are in Sonatype and
 their licenses should be accessible.

  * aopalliance:aopalliance:jar:1.0:compile
  * com.google.code.gson:gson:jar:2.2.2:compile
  * com.google.guava:guava:jar:14.0.1:compile
  * com.google.inject.extensions:guice-assistedinject:jar:3.0:compile
  * com.google.inject:guice:jar:3.0:compile
  * javax.annotation:jsr250-api:jar:1.0:compile
  * javax.inject:javax.inject:jar:1:compile
  * javax.ws.rs:jsr311-api:jar:1.1.1:compile
  * org.99soft.guice:rocoto:jar:6.2:compile

 == Cryptography ==

 jclouds contains no cryptographic algorithms, but it does provide the
 ability for people to plug in various cryptographic libraries.

 == Required Resources ==

 === Mailing lists ===

  * jclouds-dev: for development discussions
  * jclouds-user: for community discussions
  * jclouds-private: for PPMC discussions
  * jclouds-commits: for code changes

 === Apache git repository ===

 The jclouds team is experienced in git and requests the following
 allocation on the Apache git server:

 git://git.apache.org/incubator-jclouds.git

 === Issue Tracking ===

 jclouds currently uses GitHub for issue tracking. The intent is to request
 an allocation for Jira upon acceptance into the Incubator. Proposed project
 name: jclouds

 == Initial Committers ==

  * Ignasi Barrera, ignasi dot barrera at gmail dot com
  * Andrew Bayer, abayer at apache dot org
  * Ioannis Canellos, iocanel at gmail dot com
  * Adrian Cole, adrianc at netflix dot com
  * Andrew Gaul, gaul at maginatics dot com
  * Andrew Phillips, aphillips at qrmedia dot com
  * Matt Stephenson, mattstep at mattstep dot net
  * Everett Toews, everett dot toews at rackspace dot com
  * Becca Wood, silkysun at silkysun dot net

 == Affiliations ==

  * Ignasi Barrera, Abiquo
  * Andrew Bayer, Cloudera
  * Ioannis Canellos, Red Hat
  * Adrian Cole, Netflix
  * Andrew Gaul, Maginatics
  * Matt Stephenson, Google
  * Everett Toews, Rackspace

 == Sponsors ==
 === Champion ===

  * Brian McCallister, Apache Software Foundation

 === Mentors ===

  * Brian McCallister, Apache Software Foundation
  * Tom White, Apache Software Foundation
  * Henning Schmiedehausen, Apache Software Foundation
  * David Nalley, Apache Software Foundation
  * Jean-Baptiste Onofré, Apache Software Foundation
  * Mohammad Nour El-Din, Apache Software Foundation
  * Olivier Lamy, Apache Software Foundation
  * Tomaz Muraus, Apache Software Foundation
  * Suresh Marru, Apache Software Foundation
  * Carlos Sanchez, Apache Software Foundation

 === Sponsoring Entity ===

 The jclouds contributors and community request sponsorship from the
 Incubator.

Might I have permission to edit the wiki (add a page)?

[Brian McCallister]

BrianMcCallister

Thanks!

-Brian

Re: [VOTE] Release Apache Mesos 0.10.0-incubating (RC2)

[Brian McCallister]

+1


On Tue, Dec 11, 2012 at 12:56 PM, Benjamin Hindman b...@berkeley.eduwrote:

 Please vote on releasing the following candidate as Apache Mesos
 (incubating) version 0.10.0. This will be the second incubator release for
 Mesos in Apache.

 The candidate for Mesos 0.10.0-incubating release is available at:


 http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz

 The tag to be voted on:


 https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.10.0-incubating-RC2

 The MD5 checksum of the tarball can be found at:


 http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz.md5

 The signature of the tarball can be found at:


 http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz.asc

 Mesos' KEYS file, containing the PGP keys used to sign the release:
   http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS

 Please vote on releasing this package as Apache Mesos 0.10.0-incubating!

 The vote is open until Friday, December 14th at 5:00 pm (PST) and passes if
 a majority of at least 3 +1 IPMC votes are cast.

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

 To learn more about Apache Mesos, please see http://www.mesosproject.org.

Re: [VOTE] Release Apache Mesos 0.9.0-incubating (RC5)

[Brian McCallister]

+1 swept for licensing and general organization of everything :-)

On Thu, Apr 19, 2012 at 5:54 PM, Matei Zaharia ma...@eecs.berkeley.edu wrote:
 +1

 Tested it on Mac OS X, seems to work fine.

 Matei

 On Apr 19, 2012, at 12:53 PM, Benjamin Hindman wrote:

 Please vote on releasing the following candidate as Apache Mesos
 (incubating) version 0.9.0. This will be the first incubator release for
 Mesos in Apache, but the sixth release candidate.

 Changes since RC4:
  * Updated NOTICE to include project name and copyright date as well as to
 include third-party licences.
  * Changed one of our third-party components to be included as an archive
 of it's source rather than a binary bundle (Python egg).
  * Added DISCLAIMER.

 The candidate for Mesos 0.9.0-incubating release is available at:

 http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz

 The tag to be voted on:

 https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.9.0-incubating-RC5

 The MD5 checksum of the tarball can be found at:

 http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.md5

 The signature of the tarball can be found at:

 http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.asc

 Mesos' KEYS file, containing the PGP keys used to sign the release:
  http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS

 Please vote on releasing this package as Apache Mesos 0.9.0-incubating!

 The vote is open until Monday, April 23rd at 8 pm (a bit more than 72 hours
 since it's over the weekend) and passes if a majority of at least 3 +1 IPMC
 votes are cast.

 [ ] +1 Release this package as Apache Mesos 0.9.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


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

CloudStack?

[Brian McCallister]

I don't remember seeing anything about a CloudStack project, is there
something I missed?

http://www.citrix.com/English/NE/news/news.asp?newsID=2323072

-Brian

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

Re: [PROPOSAL] Propose Howl as an Apache Incubator project

[Brian McCallister]

The proposal looks fine, but the name collides with http://howl.ow2.org/

-Brian

On Thu, Feb 10, 2011 at 1:37 PM, Alan Gates ga...@yahoo-inc.com wrote:
 I would like to propose Howl as an Apache Incubator project.  Howl is a
 table and storage management service for data created using Apache Hadoop.
  The proposal is on the Incubator wiki at
 http://wiki.apache.org/incubator/HowlProposal and is pasted below.  Thanks.

 Alan.

 == Abstract ==
 Howl is a table and storage management service for data created using Apache
 Hadoop.

 == Proposal ==
 The vision of Howl is to provide table management and storage management
 layers for Apache Hadoop.  This includes:
  * Providing a shared schema and data type mechanism.
  * Providing a table abstraction so that users need not be concerned with
 where or how their data is stored.
  * Providing interoperability across data processing tools such as Pig, Map
 Reduce, Streaming, and Hive.

 == Background ==
 Data processors using Apache Hadoop have a common need for table management
 services.  The goal of a table management service is to track data that
 exists in a Hadoop grid and present that data to users in a tabular format.
  Such a table management service needs to provide a single input and output
 format to users so that individual users need not be concerned with the
 storage formats that are chosen for particular data sets.  As part of having
 a single format, the data will need to be described by one type of schema
 and have a single datatype system.

 Additionally, users should be free to choose the best tools for their use
 cases.  The Hadoop project includes Map Reduce, Streaming, Pig, and Hive,
 and additional tools exist such as Cascading.  Each of these tools has users
 who prefer it, and there are use cases best addressed by each of these
 tools.  Two users on the same grid who need to share data should not be
 constrained to use the same tool but rather should be free to choose the
 best tool for their use case.  A table management service that presents data
 in the same way to all of the tools can alleviate this problem by providing
 interfaces to each of the data processing tools.

 There are also a few other features a table management service should
 provide, such as notification of when data arrives.

 A couple of developers at Yahoo! started the project. It is based on the
 Hive !MetaStore component. There is good amount of interest in such a
 service expressed from Yahoo!, Facebook, !LinkedIn, and, others. We are
 therefore proposing to place Howl in the Apache incubator and to build an
 open source community around it.


 == Rationale ==
 There is a strong need for a table management service, especially for large
 grids with petabytes of data, and where the data volume is increasing by the
 day. Hadoop users need to find data to read and have a place to store their
 data.  Currently users must understand the location of data to read, the
 storage format, compression techniques used, etc.  To write data they need
 to understand where on HDFS their data belongs, the best compression format
 to use, how their data should be serialized, etc.

 Most users do not want to be concerned with these issues.  They want these
 managed for them.

 Having it as an Apache Open Source project will highly benefit Howl from the
 point of view of getting a large community that currently uses Hadoop and
 the other products built around Hadoop (like Pig, Hive, etc.). Users of the
 Hadoop ecosystem can influence Howl’s roadmap, and contribute to it. Looking
 at it in another way, we believe having Howl as part of the Hadoop ecosystem
 will be a great benefit to the current Hadoop/Pig/Hive community too.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Howl following the Apache meritocracy model. We
 have wanted to make the project open source and encourage contributors from
 multiple organizations from the start. We plan to provide plenty of support
 to new developers and to quickly recruit those who make solid contributions
 to committer status.

 === Community ===
 Howl is currently being used by developers at Yahoo! and there has been an
 expressed interest from !LinkedIn and Facebook. Yahoo! also plans to deploy
 the current version of Howl in production soon. We hope to extend the user
 and developer base further in the future. The current developers and users
 are all interested in building a solid open source community around Howl.

 To work towards an open source community, we have started using the !GitHub
 issue tracker and mailing lists at Yahoo! for development discussions within
 our group.

 === Core Developers ===
 Howl is currently being developed by four engineers from Yahoo! - Devaraj
 Das, Ashutosh Chauhan, Sushanth Sowmyan, and Mac Yang. All the engineers
 have deep expertise in Hadoop and the Hadoop Ecosystem in general.

 === Alignment ===
 The 

Re: [PROPOSAL] Mesos Project

[Brian McCallister]

 =

 Not applicable.



 = Required Resources =

 == Mailing Lists ==

  * mesos-private for private PMC discussions (with moderated subscriptions)
  * mesos-dev
  * mesos-commits
  * mesos-user



 == Subversion Directory ==

 https://svn.apache.org/repos/asf/incubator/mesos



 == Issue Tracking ==

 JIRA Mesos (MESOS)



 == Other Resources ==

 The existing code already has unit tests, so we would like a Hudson instance
 to run them whenever a new patch is submitted. This can be added after project
 creation.



 = Initial Committers =

  * Ali Ghodsi (ali at sics dot se)
  * Benjamin Hindman (benh at eecs dot berkeley dot edu)
  * Andy Konwinski (andyk at eecs dot berkeley dot edu)
  * Matei Zaharia (matei at apache dot org)

 A CLA is already on file for Matei Zaharia.


 = Affiliations =

  * Ali Ghodsi (UC Berkeley / Swedish Institute of Computer Science)
  * Benjamin Hindman (UC Berkeley)
  * Andy Konwinski (UC Berkeley)
  * Matei Zaharia (UC Berkeley)



 = Sponsors =

 == Champion ==

 Tom White

 == Nominated Mentors ==

  * Dhruba Borthakur
  * Brian McCallister
  * Tom White

 == Sponsoring Entity ==

 Incubator PMC



 -
 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][PROPOSAL] Amber incubator

[Brian McCallister]

+1

On Wed, May 5, 2010 at 11:59 PM, Matthias Wessendorf mat...@apache.org wrote:
 +1 (binding )

 sent from my Android phone

 Am 06.05.2010 07:57 schrieb Gurkan Erdogdu gurkanerdo...@yahoo.com:

 +1

 --Gurkan




 
 From: Simone Gianni simo...@apache.org
 To: general@incubator.apache.org
 Sent: Wed, May 5, 2010 1:48:46 AM
 Subject: [VOTE][PROPOSAL] Amber incubator


 I would like to present for a vote the following proposal to be sponsored by
 the Shindig PMC for a ...


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

Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

[Brian McCallister]

+1 (slightly late, but I have a great excuse!)

On Mon, Feb 1, 2010 at 9:24 AM, Kevan Miller kevan.mil...@gmail.com wrote:
 +1 (binding)

 Good luck.

 --kevan

 On Jan 28, 2010, at 2:59 PM, Eric Evans wrote:


 Greetings,

 We took the feedback from the earlier discussion[1] here and added our
 active mentors to the proposed PMC, (for a total of 7 people), then ran
 that through a new community vote[2].

 [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
 [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157

 There didn't seem to be any other feedback, so I'd like to start an
 official vote to recommend graduation of Apache Cassandra to a top-level
 project.

 Please cast your vote:
 [ ] +1 to recommend Cassandra's graduation
 [ ]  0 don't care
 [ ] -1 no, don't recommend yet, (because...)

 The vote will be open for 72 hours.

 Thanks,

 --
 Eric Evans
 eev...@rackspace.com
 cassandra-resolution.txt
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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



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

Re: [Discuss] Apache Shindig as a TLP

[Brian McCallister]

Big +1

On Tue, Jan 12, 2010 at 10:04 AM, Vincent Siveton vsive...@apache.org wrote:
 Hi folks

 FYI, the Shindig community has successfully voted for graduation [1].
 If no objection on the charter or other, I will start a formal
 acceptance vote soon.

 Cheers,

 Vincent

 [1] http://shindig-dev.markmail.org/message/c47amdxjtntkjij5


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

Re: [Proposal][Vote] Traffic Server

[Brian McCallister]

+1

On Thu, Jul 2, 2009 at 4:03 PM, Leif Hedstroml...@yahoo-inc.com wrote:
 Good evening,

 As you know, we've been preparing our proposal to submit Traffic Server to
 the Incubator for a few weeks now. With the help from our champion (thanks
 Doug!), and the entire Incubator community, it's my pleasure to submit a
 request for Traffic Server to be accepted into the Incubator. The proposal
 is attached below, and is also available on the Wiki:

  http://wiki.apache.org/incubator/TrafficServerProposal


 Since our first draft, we've added a number of mentors and contributors, and
 also added and improved on the proposal. I would like this to be considered
 our official application, and that the Incubator votes (+ or -) on our
 acceptance as a podling.

 Sincerely,

 -- leif


 Traffic Server

 


     Abstract

 Traffic Server is fast, scalable and extensible HTTP/1.1 compliant caching
 proxy server.


     Proposal

 The goal is to create an Apache top level project to Open Source the
 existing Yahoo! Traffic Server code. Traffic Server (TS for short) is used
 in-house to deliver significant amount of HTTP traffic to millions of users.

 Key Features:

   *

     HTTP/1.1 caching proxy server

   *

     Scalable on SMP (TS is a hybrid thread + event processor)

   *

     Extensible: TS has a feature rich plugin API

   *

     Fast


     Background

 Traffic Server is a piece of software initially acquired by Yahoo! from
 Inktomi. The software has been actively developed and used at Yahoo for the
 last three years, and we're now getting ready to Open Source this project.


     Rationale

 Traffic Server fills a need for a fast, extensible and scalable HTTP proxy
 and caching. We have a production proven piece of software that can deliver
 HTTP traffic at high rates, and can scale well on modern SMP hardware. We
 have benchmarked Traffic Server to handle in excess of 35,000 RPS on a
 single box. Traffic Server has a rich feature set, implementing most of
 HTTP/1.1 to the RFC specifications.


     Initial goals

 The initial goal is to build a community of developers and users of the
 Traffic Server software. Longer term goal is to address a few feature
 additions that we think are beneficial:

   *

     Full 64-bit support

   *

     Porting to more Unix flavors (currently we only support Linux)

   *

     Add missing features, e.g., CARP, HTCP, ESI and native IPv6

   *

     Incremental improvements to existing features, and performance


     Current Status


       Meritocracy

 Building our developer community using the meritocracy is important to the
 success of Traffic Server. We know there are many developers out there
 interested in the technology, and the meritocracy system is a great way to
 encourage participation.


       Community

 Our hope is that our existing code, features and capabilities will attract a
 large community of both developers and users. We know that several
 developers who have previously worked on the code, are looking forward to
 participating in the Open Source efforts. We also believe that other
 organizations will find this project interesting and relevant, and
 contribute resources.

 The user community of Traffic Server would be similar to that of the Apache
 HTTP server, and in many cases they would overlap.


       Core Developers

   *

     Leif Hedstrom leif at yahoo-inc.com

   *

     Bryan Call bcall at yahoo-inc.com

   *

     Vijaya Bhaskar Mamidi vmamidi at yahoo-inc.com

   *

     Steve Jiang sjiang at yahoo-inc.com

   *

     Dima Ruban dima at yahoo-inc.com

   *

     Anirban Kundu akundu at yahoo-inc.com

   *

     Andrew Hsu andrewhs at yahoo-inc.com

   *

     Eric Balsa eric at ericbalsa.com

   *

     BalaKrishna http://wiki.apache.org/incubator/BalaKrishna JD
     balakrishnajd at yahoo.com


       Alignment

 Yahoo! is already a contributor to the Apache Foundation. We are already
 familiar with the ASF process, and we know it provides everything we need
 and require to be successful. We also feel there is a natural symbiotic
 relationship between Traffic Server and the Apache HTTP server, which is how
 TS is generally used at Yahoo!. The Traffic Server team is also in the same
 organization as the Yahoo! Hadoop developers, which is already an Apache
 TLP.


     Known Risks


       Orphaned Products

 Traffic Server is widely used and deployed inside of Yahoo!. It's not going
 away anytime soon; in fact, it's growing fast.


       Inexperience with Open Source

 All Yahoo! participants are active users and contributors to Open Source
 projects. Leif is a committer at Mozilla (although no longer active),
 creator of PerLDAP, as well as creator of a Yahoo! search API (pYsearch).
 Bryan Call is the creator of cksfv, and contributor to lmsensor. Dima Ruban
 has been an active developer in the FreeBSD project.


       Homogeneous Developers

 The current list 

Etch?

[Brian McCallister]

What ever happened to Etch?

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

Re: [VOTE] Accept Cassandra into the Incubator

[Brian McCallister]

 mailto:cassandra-u...@incubator.apache.org

 == Subversion Directory ==

  *[WWW] https://svn.apache.org/repos/asf/incubator/cassandra== Issue
 Tracking ==

 * JIRA Cassandra

 = Sponsors =

 == Champion ==
 * Brian McCallister== Mentors ==
 * Torsten Curdt* Brian McCallister
 * Matthieu Riou
 * Ian Holsman

 == Sponsoring Entity ==
 * Incubator




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



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

Re: [VOTE] Accept Cassandra into the Incubator

[Brian McCallister]

On Sat, Dec 27, 2008 at 11:26 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 I'd like to see some plan on dealing with the fork/community stuff. We
 *know* it is a problem, and I'd like to see how this is being
 addressed in the proposal. In my opinion that is the crux to this
 proposal. Just going Apache is not going to solve problems. The
 feather is not a magic wand you can wave around and make problems
 disappear.

 What will happen when the original coders won't come with the project?
 What when they do and then disappear *again*? How will you get the
 folks on board that don't want to come over?

The fork was something proposed by Ian because there was no clear
path for folks to become involved with Cassandra. The folks working on
it at Facebook didn't want to see a fork, and proposed entering
incubation in order to structure opening up development. Avinash and
the others on the proposal *are* the core contributors, there is no
fork, and hopefully there will be no need to.

No one expects to wave a feather over the code and have a vibrant
developer community appear, but you *can* wave a wand and have a set
of expectations appear, which is what Cassandra is trying to do.

The plan: follow the normal apache process. Folks contribute good
stuff, the folks involved recognize this and make the contributor a
committer, useful code continues to come into existence, rinse-repeat.

The plan is no different than any apache project.

-Brian


 Martijn

 On Sat, Dec 27, 2008 at 6:13 PM, Brian McCallister bri...@skife.org wrote:
 I consider this to be a high-risk project, and agree with Martjin's
 concerns, but do not consider this a bar to entering incubation. The
 *reason* Cassandra wants to enter incubation is to address these
 weaknesses.

 +1

 -Brian

 On Tue, Dec 23, 2008 at 2:01 PM, Ian Holsman li...@holsman.net wrote:

 Dear Incubator PMC,

 There has been some discussion around the Cassandra proposal,
 and we would now like to officially propose Cassandra to the Incubator
 for consideration..

 Please vote on accepting Cassandra project for incubation. The full
 Cassandra proposal is available at the end of this message and as a wiki
 page at http://wiki.apache.org/incubator/Cassandra. We ask the
 Incubator PMC to sponsor the Cassandra podling, with Brian as the Champion,
 and Torsten, Matthieu, and Ian volunteering to mentor as well.

 The vote is open for the next 72 hours and only votes from the
 Incubator PMC are binding.

 [ ] +1 Accept Cassandra as a new podling
 [ ] -1 Do not accept the new podling (provide reason, please)

 
 = Abstract =

 Cassandra is a distributed storage system for managing
 structured/unstructured data while providing reliability at a massive scale.

 = Background =

 Development of Cassandra started in Facebook in June 2007. It started of a
 system to solve the Inbox Search problem and since then has
 matured to solve various storage problems associated with
 structured/unstructured data.

 = Rationale =

 Cassandra is a distributed storage system for managing structured data that
 is designed to scale to a very large size across many commodity servers,
 with no single point of failure.
 The philosophy behind the design of the storage portion of Cassandra is that
 it be able to satisfy the requirements of applications that demand storage
 of large amounts of structured data. Reliability at massive scale is a very
 big challenge. Outages in the service can have significant negative impact.
 Hence Cassandra aims to run on top of an infrastructure of hundreds of nodes
  (possibly spread across different datacenters). At this scale, small and
 large components fail continuously; the way Cassandra manages the persistent
 state in the face of these failures drives the reliability and scalability
 of the software systems relying on this service.

 = Initial Source =

 Intial Source can be obtained from the following site -
 http://the-cassandra-project.googlecode.com/svn/branches/development/. The
 mailing list is currently maintained at the same site.
 We will move it over to Apache once this proposal has been accepted.

 = Source and Intellectual Property Submission Plan =

 = External Dependencies =
 * All dependencies have Apache compatible licenses. Dependencies are log4j,
 Thrift, Apache Commons.

 = Cryptography =
 * None
 = Committers =

 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan
 * Jiansheng Huang
 * Dan Dumitriu

 = Current Status =
 == Meritocracy ==

 * Though initial development was done at Facebook, Cassandra was intended to
 be released as an open source project from its inception. Environment will
 lend itself to support meritocracy at all times.

 == Community ==
 * Folks who are actively considering deploying/prototyping Cassandra in
 their respective organizations.

 == Core Developers ==
 * Avinash Lakshman
 * Prashant Malik
 * Kannan Muthukkaruppan

 == License ==
 * The Cassandra codebase is Apache 2.0 licensed

Re: [VOTE] Accept Cassandra into the Incubator

[Brian McCallister]

On Sat, Dec 27, 2008 at 11:26 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 I'd like to see some plan on dealing with the fork/community stuff. We
 *know* it is a problem, and I'd like to see how this is being
 addressed in the proposal. In my opinion that is the crux to this
 proposal. Just going Apache is not going to solve problems.

Actually, it is a huge first step. Right now there is no path for
non-FB employees to contribute.

Second step is to encourage non-FB (or other FB folks) folks to contribute.

Third step is to make them committers.

Fourth step is to have the whole crowd get beers together at the next apachecon.

Fifth step is GOTO 2.

:-)

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

Re: Cassandra Incubator Proposal

[Brian McCallister]

I am expecting to be a mentor.

On Sat, Dec 13, 2008 at 1:45 PM, Matthieu Riou matthieu.r...@gmail.com wrote:
 If you need one more, you can count me in.

 Cheers,
 Matthieu

 On Fri, Dec 12, 2008 at 11:38 PM, William A. Rowe, Jr.
 wr...@rowe-clan.netwrote:

 Ian Holsman wrote:
  I'll be a mentor. do we need 2 or 3?

 That would be nice, yes.

 3 mentors == 3 binding votes.

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




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

Re: [VOTE] Graduate CouchDB as TLP (Was: Re: Asking for Feedback: CouchDB Graduation)

[Brian McCallister]

+1

On Sat, Nov 8, 2008 at 6:17 AM, Jan Lehnardt [EMAIL PROTECTED] wrote:
 Dear Incubator General List, dear IPMC,

 thank you all for your comments on whether CouchDB should graduate
 from the Incubator to a top level project. I think we have your support.
 On behalf of the Apache CouchDB PPMC I am now calling a vote:

 [ ] Yes, CouchDB is ready to become a top lavel project at the ASF and the
IPMC will recommend the proposed resolution quoted below to the Board.

 [ ] No, CouchDB is not yet ready, it should stay in the Incubator.

 Thank you.


 Cheers
 Jan
 --

 On Nov 3, 2008, at 18:19, Jan Lehnardt wrote:

 Dear Incubator General List,

 The community and developers of Apache CouchDB deem
 the project ready for graduation to a top level Apache project.

 [EMAIL PROTECTED] vote summary:


  
 http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200810.mbox/[EMAIL
  PROTECTED]

 Message IDs for informal(*) PPMC vote to appoint Damien Katz to become
 Vice President, CouchDB:

  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]

 (* Sorry we didn't to a formal vote and hence no formal [RESULT] message)

 --

 We would like to ask the IPMC to discuss the following Board resolution to
 be
 recommended to the Board. Once your feedback is collected and integrated,
 we will ask you to vote on the final resolution. Thank you!

 --

 Proposed Board Resolution:

 Establish the Apache CouchDB 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 implementing a distributed, fault-
 tolerant and schema-free document-oriented database 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 CouchDB Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache CouchDB Project be and hereby is
 responsible for the creation and maintenance of software
 related to implementing a distributed, fault-tolerant and
 schema-free document-oriented database; and be it further

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

 * J Chris Anderson ([EMAIL PROTECTED])
 * Damien Katz  ([EMAIL PROTECTED])
 * Christopher Lenz ([EMAIL PROTECTED])
 * Jan Lehnardt ([EMAIL PROTECTED])
 * Noah Slater  ([EMAIL PROTECTED])

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Damien
 Katz be appointed to the office of Vice President, CouchDB, 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 CouchDB Project be and hereby
 is tasked with the creation of a set of bylaws intended to
 encourage open development and increased participation in the
 CouchDB Project; and be it further

 RESOLVED, that the initial Apache CouchDB Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator CouchDB podling; and be it further

 RESOLVED, that all responsibility pertaining to the Apache
 Incubator CouchDB podling encumbered upon the Apache Incubator
 PMC are hereafter discharged.

 --

 Again, thanks for your cooperation!


 For the Apache CouchDB PPMC,
 Jan
 --
 PS: Thanks to Noah Slater for proofreading.


 -
 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: [PROPOSAL] ESME - The Enterprise Social Messaging Experiment

[Brian McCallister]

Sweet, I'll +1 it and probably use it :-)

On Mon, Nov 3, 2008 at 5:22 PM, Darren Hague [EMAIL PROTECTED] wrote:
 I would like to propose ESME as a project for the Apache Incubator.

 Enterprise Social Messaging Experiment (ESME) is a secure and highly
 scalable microsharing and micromessaging platform that allows people to
 discover and meet one another and get controlled access to other sources of
 information, all in a business process context. ESME is written in Scala and
 uses the Lift web framework.

 Please see http://wiki.apache.org/incubator/ESMEProposal for details.

 Since this is my first Apache project, any and all feedback is welcome - I
 will call for a vote a few days after relevant messages on the list reduce
 to a trickle and people seem happy with the proposal.

 Best regards,
 Darren Hague


 -
 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: Apache Shindig Board Reports ?

[Brian McCallister]

Good catch, thank you!

I just added us to the third group (ie, the March group). We'll need to be
good incubatorlings and probably do our first three months of reporting a
bit late :-)

-Brian

On Fri, Feb 22, 2008 at 8:57 PM, Luciano Resende [EMAIL PROTECTED]
wrote:

 Just trying to help with the Apache way of doing things for new
 podlings. I was looking for Board Reports from Shindig and could not
 find it, are they available somewhere ? Also, looks like the Board
 Report Schedule [1] is still not listing Shindig.

 [1] http://wiki.apache.org/incubator/ReportingSchedule
 [2] http://incubator.apache.org/guides/ppmc.html

 --
 Luciano Resende
 Apache Tuscany Committer
 http://people.apache.org/~lresende http://people.apache.org/%7Elresende
 http://lresende.blogspot.com/

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

Re: Subversion vs other source control systems

[Brian McCallister]

FWIW, I quite like both git and mercurial, both give me a better workflow
than subversion for a lot of things I work on. Offline commits, local
branches, and sane merging are *huge*. The approach to distributed repos is
also very nice for folks who do want to maintain a fork elsewhere (forking
isn't evil, it is a very good reaction to needing something slightly
different which the majority (or the powerful) in the base project doesn't
want).

Looking forward to  trying svn 1.5 branch management, though :-) Being able
to repeatedly merge from a branch I didn't branch from will be *huge* (ie,
pull bug fixes from release branches without pulling cruft from trunk from
whence I branched).

I quite accept the practical side of saying svn only as long as no one
steps up to manage git or mercurial. Saying though shalt use svn because it
is the blessed end-all is BS. Subversion is great, and all, but it also
sucks. Some things suck less for different workflows, some things suck more.
For one-branch development, svn is awesome.

Saying we can have only one because is very weak. Can anyone cite specific
problems FreeBSD or Perl have had?

-Brian

Re: [VOTE] Accept CouchDB for incubation

[Brian McCallister]

+1

On Sat, Feb 9, 2008 at 8:09 AM, Sam Ruby [EMAIL PROTECTED] wrote:

 We've had an initial discussion, which attracted a number of messages
 of encouragement, and identified no issues or concerns.  Then we
 proceeded onto a proposal, which attracted three excellent mentors.
 Now it is time to vote on the proposal which can be found on the
 Apache Wiki, and reproduced below.

 I would like to proudly start this off with my +1.

 - Sam Ruby

 http://wiki.apache.org/incubator/CouchDBProposal

Re: [VOTE] as to Thrift Proposal

[Brian McCallister]

+1

-Brian

On Thu, Feb 7, 2008 at 5:59 PM, Yonik Seeley [EMAIL PROTECTED] wrote:

  On Jan 23, 2008 9:07 PM, Mark Slee [EMAIL PROTECTED] wrote:
   We've just posted the Apache Incubator proposal for Thrift onto the
   Wiki:
   http://wiki.apache.org/incubator/ThriftProposal

 +1

 -Yonik

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

Re: [DISCUSS] CouchDB incubator project

[Brian McCallister]

+1 -- I am very excited to see this and think it will be good for CouchDB.

-Brian

On Thu, Jan 31, 2008 at 7:40 AM, Sam Ruby [EMAIL PROTECTED] wrote:

 The original source for this proposal can be found at

 http://www.couchdbwiki.com/index.php?title=Apache_Incubator_Proposal

 and a current snapshot is attached below.  Once we have established that
 there is interest, my plan is to move this content over to
 wiki.apache.org/incubator as a [PROPOSAL].

 I've been watching CouchDB since September, and believe that it would
 fit well in the ASF.  My preference is that it exits as a top level
 project, mainly due to my experience with umbrella PMCs, but I would
 otherwise not be adverse to it joining the DB project.  We certainly do
 not need to decide this now.

 - Sam Ruby

 Project Name: CouchDB
 -

 ==Proposal==
 The goal is to create either an Apache top level project, or a db
 subproject, around the existing CouchDB open source project.

 Key Features:
 * a REST API using JSON for data transport,
 * a JavaScript view engine based on Mozilla Spidermonkey,
 * a GNU Autotools build system supporting most POSIX systems
 * a built-in administration interface
 * experimental fulltext search with Lucene

 ===Rationale===
 The goals of the project are aligned with the goals of the ASF, namely
 there is interest in (continuing to) foster a collaborative, consensus
 based development process, using an open and pragmatic software license,
 and a desire to create high quality software that leads the way in its
 field.

 ===Initial goals===
 * Features for next release
 **  Incremental reduce support, for full map/reduce support.
 ** Document validation model (validate live and replicated changes)
 ** Documentation, Documentation, Documentation
 ** Fulltext Search
 * Priority feature work
 ** Live compaction
 ** Extensible security model
 ** LDAP authentication
 ** More query capabilities exposed to HTTP, e.g. multi-key view lookups
 * Future feature work
 ** Server storage partioning
 ** Server failover clustering
 * Requested Features
 ** hierarchical structure in documents

 ==Current Status==

 ===Meritocracy===
 The project has recently transformed from being primarily a single
 person led (and funded) project to one with a number of diverse
 participants.  Development has been coordinated primarily through a
 mailing list, with some IRC.

 ===Community===
 The community consists of a set of independent developers, one of which
 recently joined IBM

 ===Initial Developers===
 * William Beh
 * Damien Katz
 * Jan Lehnardt
 * Christopher Lenz
 * Dirk Schalge
 * Noah Slater

 ===Alignment===
 A database server with a strong focus on HTTP and REST principles.

 ===Known Risks===
 * Dependency on Erlang
 ** Including some modifications to the HTTP server stack.  The plan is
 to convert over to [http://code.google.com/p/mochiweb/ MochiWeb] (MIT
 licenced)
 * Dependency on Mozilla SpiderMonkey
 ** Including small modifications, to be sent back to Mozilla

 ===Orphaned Products===
 * This is a new effort, and is far from being orphaned.

 ===Inexperience with Open Source===
 All participants are active users and contributors to open source. One
 of them (Christopher Lenz) has experience as committer on other Apache
 projects.

 ===Homogenous Developers===
 The exiting committers are spread over a number of countries and
 employers.

 ===Reliance on Salaried Developers===
 Only one developer is being paid to work on CouchDB.  Read
 [http://damienkatz.net/2008/01/faq_about_couch.html his views] on the
 relationship he has with his employer.

 ===Relationships with Other Apache Products===
 Experimental usage of Lucene

 ===An excessive fascination with the Apache brand===
 This product started out independent of Apache and under a GPL license.
  After discussions with a number of people within IBM, Damien Katz
 agreed to pursue both incubation at the ASF, and employment at IBM

 ==Documentation==

 ===Initial Source===
 Resides on [http://code.google.com/p/couchdb/ Google Code].  The code
 has been recently relicensed from GPL to the Apache License, Version
 2.0, in anticipation of this submission.

 ===Source and Intellectual Property Submission Plan===
 The bulk of the core code was written by Damien Katz.  Major
 contributions include: a GNU Autotools build system supporting most
 POSIX systems contributed by Noah Slater,  a built-in administration
 interface provided by Christopher Lenz, and experimental fulltext search
 with Lucene by Jan Lehnardt.  ICLAs either have been, or are in the
 process of being, submitted for all code involved in this submission.

 ICLA's are already on file for:
 * Jan Lehnardt
 * Christopher Lenz
 ICLA's in progress:
 * William Beh
 * Damien Katz
 * Dirk Schalge
 * Noah Slater

 There are a few (as in single digit) number of files that we are
 continuing to sort through the licenses.  These include Public Domain, X
 Consortium, and MITish licenses.

 

Re: [RESULT] [VOTE] Accept Shindig for Incubation

[Brian McCallister]

I've filed infra tickets for Shindig tuff to be set up :-)

On Dec 3, 2007, at 1:33 PM, Brian McCallister wrote:


+1: 25
0: 1
-1: 0

Looks like it passed! Woo hoo!

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an  
excellent

implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
  http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
  http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

  Andy Smith  (Google)
  Brian McCallister   (Ning)
  Brian Stoler(Google)
  Cassie Doll (Google)
  Dan Bentley (Google)
  Dan Farino  (MySpace)
  David Glazer(Google)
  David Harkness  (Google)
  David Sklar (Ning)
  Doug Coker  (Google)
  Evan Gilbert(Google)
  Graham Spencer  (Google)
  Jeffrey Regan   (Google)
  John Hjelmstad  (Google)
  John Panzer (Google)
  Jun Yang(Google

[RESULT] [VOTE] Accept Shindig for Incubation

[Brian McCallister]

+1: 25
 0: 1
-1: 0

Looks like it passed! Woo hoo!

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Andy Smith  (Google)
   Brian McCallister   (Ning)
   Brian Stoler(Google)
   Cassie Doll (Google)
   Dan Bentley (Google)
   Dan Farino  (MySpace)
   David Glazer(Google)
   David Harkness  (Google)
   David Sklar (Ning)
   Doug Coker  (Google)
   Evan Gilbert(Google)
   Graham Spencer  (Google)
   Jeffrey Regan   (Google)
   John Hjelmstad  (Google)
   John Panzer (Google)
   Jun Yang(Google)
   Jussi Myllymaki (Google)
   Kevin Brown (Google)
   Martin Traverso (Ning)
   Paul

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Okay, am about to submit a VOTE email with the revised proposal.

There are a couple major changes on the proposal. The biggest is the  
initial contributors and codebase. Google asked to be involved and  
offered to submit the initial implementation, which is a whole lot  
better than the one I pulled out of Ning so I think it is a great  
change. Additionally, folks from Hi5 and MySpace have been added to  
the proposal.


-Brian

On Nov 27, 2007, at 11:40 PM, Otis Gospodnetic wrote:


+1 -- my simpy.com might become a client soon. :)

Otis

--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

- Original Message 
From: Brian McCallister [EMAIL PROTECTED]
To: general@incubator.apache.org
Sent: Friday, November 9, 2007 1:03:49 PM
Subject: [PROPOSAL] Shindig, an OpenSocial Container

Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community-
developed
implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing

[VOTE] Accept Shindig for Incubation

[Brian McCallister]

This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial applications.

= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is a  
high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential consumers
of the project. Remedying this is a large part of why we want to bring  
the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

Andy Smith  (Google)
Brian McCallister   (Ning)
Brian Stoler(Google)
Cassie Doll (Google)
Dan Bentley (Google)
Dan Farino  (MySpace)
David Glazer(Google)
David Harkness  (Google)
David Sklar (Ning)
Doug Coker  (Google)
Evan Gilbert(Google)
Graham Spencer  (Google)
Jeffrey Regan   (Google)
John Hjelmstad  (Google)
John Panzer (Google)
Jun Yang(Google)
Jussi Myllymaki (Google)
Kevin Brown (Google)
Martin Traverso (Ning)
Paul Lindner(Hi5)
Ramkumar Ramani (Google)
Thomas Baker(Ning

Re: [VOTE] Accept Shindig for Incubation

[Brian McCallister]

+1 from me as well :-)

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Andy Smith  (Google)
   Brian McCallister   (Ning)
   Brian Stoler(Google)
   Cassie Doll (Google)
   Dan Bentley (Google)
   Dan Farino  (MySpace)
   David Glazer(Google)
   David Harkness  (Google)
   David Sklar (Ning)
   Doug Coker  (Google)
   Evan Gilbert(Google)
   Graham Spencer  (Google)
   Jeffrey Regan   (Google)
   John Hjelmstad  (Google)
   John Panzer (Google)
   Jun Yang(Google)
   Jussi Myllymaki (Google)
   Kevin Brown (Google)
   Martin Traverso (Ning)
   Paul Lindner(Hi5

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Wow, really happy at the positive response.

I'm on my way to ATL in the morning, and am halfway healthy again, so  
will try to pull out some code during hackathon.


-Brian

On Nov 9, 2007, at 10:03 AM, Brian McCallister wrote:


Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.



= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Thomas Baker[EMAIL PROTECTED]
   Tim Williamson  [EMAIL PROTECTED]
   Brian McCallister   [EMAIL PROTECTED]
   Thomas Dudziak  [EMAIL PROTECTED]
   Martin Traverso [EMAIL PROTECTED]

= Sponsors =

== Champion ==

   Brian McCallister   [EMAIL PROTECTED]

== Nominated Mentors ==

   Brian McCallister   [EMAIL PROTECTED]
   Thomas Dudziak  [EMAIL PROTECTED]
   Santiago Gala   [EMAIL PROTECTED]
   Upayavira   [EMAIL PROTECTED]

== Sponsoring Entity

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

On Nov 9, 2007, at 1:34 PM, Sylvain Wallez wrote:


Brian McCallister wrote:

Shindig Proposal


A big +1, and I'd happily be a mentor.


Thank you! We'll take you up on that :-)

-Brian




Sylvain

--
Sylvain Wallez - http://bluxte.net


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

[PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client-side
composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

Thomas Baker[EMAIL PROTECTED]
Tim Williamson  [EMAIL PROTECTED]
Brian McCallister   [EMAIL PROTECTED]
Thomas Dudziak  [EMAIL PROTECTED]
Martin Traverso [EMAIL PROTECTED]

= Sponsors =

== Champion ==

Brian McCallister   [EMAIL PROTECTED]

== Nominated Mentors ==

Brian McCallister   [EMAIL PROTECTED]
Thomas Dudziak  [EMAIL PROTECTED]
Santiago Gala   [EMAIL PROTECTED]
Upayavira   [EMAIL PROTECTED]

== Sponsoring Entity ==

The Apache Incubator.


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

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

On Nov 9, 2007, at 11:47 AM, Leo Simons wrote:


Can we see a code dump of the stuff you'll be donating?


As soon as possible :-) I am home with a nasty fever today so...  
blech. We should have the ning-specific stuff gutted out by ApacheCon  
at least!


-Brian

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

Re: [VOTE] accept Pig into Incubator

[Brian McCallister]

+1

-Brian

On Sep 25, 2007, at 10:20 AM, Doug Cutting wrote:

I would like to call the Incubator PMC to vote to incubate the  
proposed Pig project.  Discussion on this list evidenced broad  
interest in this project, which bodes well for its ability to build  
a diverse developer community.


http://wiki.apache.org/incubator/PigProposal

+1

Doug

---

= Proposal for Pig Project =

== Abstract ==

Pig is a platform for analyzing large data sets.

== Proposal ==

The Pig project consists of high-level languages for expressing  
data analysis programs, coupled with infrastructure for evaluating  
these programs. The salient property of Pig programs is that their  
structure is amenable to substantial parallelization, which in  
turns enables them to handle very large data sets.


At the present time, Pig's infrastructure layer consists of a  
compiler that produces sequences of Map-Reduce programs, for which  
large-scale parallel implementations already exist (e.g., the  
Hadoop subproject). Pig's language layer currently consists of a  
textual language called Pig Latin, which has the following key  
properties:


 1. ''Ease of programming''. It is trivial to achieve parallel  
execution of simple, embarrassingly parallel data analysis tasks.  
Complex tasks comprised of multiple interrelated data  
transformations are explicitly encoded as data flow sequences,  
making them easy to write, understand, and maintain.
 2. ''Optimization opportunities''. The way in which tasks are  
encoded permits the system to optimize their execution  
automatically, allowing the user to focus on semantics rather than  
efficiency.
 3. ''Extensibility''. Users can create their own functions to do  
special-purpose processing.


== Background ==

Pig started as a research project at Yahoo! in May of 2006 to  
combine ideas in parallel databases and distributed computing. The  
first internal release took place in July 2006. The first release  
was a simple front-end to the Hadoop Map/Reduce framework. The  
following releases added new features and evolved the language  
based on user feedback. In July 2007, pig was taken over by a  
development team and the first production version is due to be  
released on 9/28/07.


Since its inception, we had observed a steady growth of the user  
community within Yahoo!.  In April 2007, Pig was released under a  
BSD-type license.  Several external parties are using this version  
and have expressed interest in collaborating on its development.


== Rationale ==

In an information-centric world, innovation is driven by ad-hoc  
analysis of large data sets. For example, search engine companies  
routinely deploy and refine services based on analyzing the  
recorded behavior of users, publishers, and advertisers. The rate  
of innovation depends on the efficiency with which data can be

analyzed.

To analyze large data sets efficiently, one needs parallelism. The  
cheapest and most scalable form of parallelism is cluster  
computing. Unfortunately, programming for a cluster computing  
environment is difficult and time-consuming. Pig makes it easy to  
harness the power of cluster computing for ad-hoc data analysis.


While other language exist that try to achieve the same goals, we  
believe that Pig provides more flexibility and gives more control  
to the end user.


SQL typically requires (1) importing data from a user's preferred  
format into a database system's internal format (2) well- 
structured, normalized data with a declared schema, and (3)  
programs expressed in declarative SELECT-FROM-WHERE blocks. In  
contrast, Pig Latin facilitates (1) interoperability, i.e. data may  
be read/written in a format accepted by other applications such as  
text editors or graph generators (2) flexibility, i.e. data may be  
loosely structured or have structure that is
defined operationally, and (3) adoption by programmers who find  
procedural programming more natural than declarative programming.


Sawzall is a scripting language used at Google on top of Map- 
Reduce. A sawzall program has a fairly rigid structure consisting  
of a filtering phase (the map step) followed by an aggregation  
phase (the reduce step). Furthermore, only the filtering phase can  
be written by the user, and only a pre-built set of aggregations  
are available (new ones are non-trivial to add). While Pig Latin  
has similar higher level primitives like filtering and aggregation,  
an arbitrary number of them can be flexibly chained together in a  
Pig Latin program, and all primitives can use user-defined  
functions with equal ease. Further, Pig Latin has additional  
primitives such as cogrouping, that allow operations such as joins  
(which require multiple programs in Sawzall) to be written in a  
single line in Pig Latin. Further, Pig Latin is designed
to be embedded into other languages, and can use functions written  
in other languages. Thus, 

Re: Incubator Proposal: SPL

[Brian McCallister]

On Sep 17, 2007, at 5:57 AM, David L Kaminsky wrote:

Tomcat
-

We're open to suggestions regarding the order in which we add  
bindings to

APIs, and doing such bindings isn't terribly hard.  If Tomcat is
particularly critical as an early demonstration, we can add that to  
the
proposal.  And, of course, the code is (suppose to be) modular, so  
others

could at it at any time.


Lot more people deploy and manage large number of Tomcat instances  
than Geronimo instances.


-Brian

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

Re: Incubator Proposal: Pig

[Brian McCallister]

+1 -- I'd offer to help as much as I can, but I know how little that  
is right now :-(


Definitely support (and will probably use at least ;-)

-Brian

On Sep 18, 2007, at 12:52 PM, Olga Natkovich wrote:


Hi,

Yahoo! research and development teams have developed a proposal  
below. The

proposal is also available on wiki at
http://wiki.apache.org/incubator/PigProposal
http://wiki.apache.org/incubator/PigProposal.
We would like to ask that the ASF consider forming a podling  
according to

the proposal.

Thanks,

Olga Natkovich
 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]

-- 
--

-

= Pig Open Source Proposal =

== Abstract ==

Pig is a platform for analyzing large data sets.

== Proposal ==

The Pig project consists of high-level languages for expressing data
analysis programs, coupled with infrastructure for evaluating these
programs. The salient property of Pig programs is that their  
structure is
amenable to substantial parallelization, which in turns enables  
them to

handle very large data sets.

At the present time, Pig's infrastructure layer consists of a  
compiler that
produces sequences of Map-Reduce programs, for which large-scale  
parallel
implementations already exist (e.g., the Hadoop subproject). Pig's  
language
layer currently consists of a textual language called Pig Latin,  
which has

the following key properties:

 1. ''Ease of programming''. It is trivial to achieve parallel  
execution of

simple, embarrassingly parallel data analysis tasks. Complex tasks
comprised of multiple interrelated data transformations are explicitly
encoded as data flow sequences, making them easy to write,  
understand, and

maintain.
 2. ''Optimization opportunities''. The way in which tasks are encoded
permits the system to optimize their execution automatically,  
allowing the

user to focus on semantics rather than efficiency.
 3. ''Extensibility''. Users can create their own functions to do
special-purpose processing.

== Background ==

Pig started as a research project at Yahoo! in May of 2006 to  
combine ideas
in parallel databases and distributed computing. The first internal  
release
took place in July 2006. The first release was a simple front-end  
to the
Hadoop Map/Reduce framework. The following releases added new  
features and
evolved the language based on user feedback. In July 2007, pig was  
taken
over by a development team and the first production version is due  
to be

released on 9/28/07.

Since its inception, we had observed a steady growth of the user  
community
within Yahoo!.  In April 2007, Pig was released under a BSD-type  
license.
Several external parties are using this version and have expressed  
interest

in collaborating on its development.

== Rationale ==

In an information-centric world, innovation is driven by ad-hoc  
analysis of
large data sets. For example, search engine companies routinely  
deploy and

refine services based on analyzing the recorded behavior of users,
publishers, and advertisers. The rate of innovation depends on the
efficiency with which data can be
analyzed.

To analyze large data sets efficiently, one needs parallelism. The  
cheapest
and most scalable form of parallelism is cluster computing.  
Unfortunately,

programming for a cluster computing environment is difficult and
time-consuming. Pig makes it easy to harness the power of cluster  
computing

for ad-hoc data analysis.

While other language exist that try to achieve the same goals, we  
believe
that Pig provides more flexibility and gives more control to the  
end user.


SQL typically requires (1) importing data from a user's preferred  
format
into a database system's internal format (2) well-structured,  
normalized

data with a declared schema, and (3) programs expressed in declarative
SELECT-FROM-WHERE blocks. In contrast, Pig Latin facilitates (1)
interoperability, i.e. data may be read/written in a format  
accepted by
other applications such as text editors or graph generators (2)  
flexibility,

i.e. data may be loosely structured or have structure that is
defined operationally, and (3) adoption by programmers who find  
procedural

programming more natural than declarative programming.

Sawzall is a scripting language used at Google on top of Map-Reduce. A
sawzall program has a fairly rigid structure consisting of a  
filtering phase

(the map step) followed by an aggregation phase (the reduce step).
Furthermore, only the filtering phase can be written by the user,  
and only a
pre-built set of aggregations are available (new ones are non- 
trivial to
add). While Pig Latin has similar higher level primitives like  
filtering and
aggregation, an arbitrary number of them can be flexibly chained  
together in
a Pig Latin program, and all primitives can use user-defined  
functions with
equal ease. Further, Pig Latin has additional primitives such as  
cogrouping,
that allow operations such 

Re: [VOTE] Retire Heraldry from incubation

[Brian McCallister]

+1

-Brian

On Jun 1, 2007, at 2:15 AM, J Aaron Farr wrote:



This is a vote to move the Heraldry project from active incubation to
'retired' status.

Earlier this year the Heraldry project was reorganized in order to
make another attempt at incubating an OpenID project.  Unfortunately,
the reconstituted podling has been unable to reboot and the remaining
committers agree that termination at this time is in the best interest
of all involved.  Details of these matters can be found on the public
Heraldry dev list, in particular the Recharter and SVN thread in May
[1].

I want to thank all the committers and mentors, both past and present,
for their efforts in the Heraldry project and I especially wish the
committers success in their furture efforts.  As with any retired or
domant open source project here at Apache, should a future team of
developers be interested in picking where others left off, they may do
so by forming a proposal and emailing the Incubator PMC.

Please vote for the Heraldry Podling Termination:

 [ ]  +1, terminate the Heraldry podling and move to 'retired'
 [ ]  -1, do not terminate the podling at this time


--  
  J Aaron Farr jadetower.com[US] +1 724-964-4515

馮傑仁  cubiclemuses.com [HK] +852 8123-7905

[1] http://mail-archives.apache.org/mod_mbox/incubator-heraldry-dev/ 
200705.mbox/thread


-
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: [VOTE] Graduate OpenJPA to a Top Level Project

[Brian McCallister]

+1 Good folks, good community, good code!

-Brian

On May 8, 2007, at 10:45 PM, Craig L Russell wrote:


Dear Incubator,

The OpenJPA podling respectfully requests the Incubator to consider  
its graduation to a Top Level Project. Please vote on recommending  
the attached draft board resolution.


The vote will end in 72 hours, 2300 hours PDT Friday 11-May-2007.

[ ] +1 Recommend to the board to establish Apache OpenJPA
[ ] -1 Do not recommend establishing Apache OpenJPA because...

Over the past several months the OpenJPA community has grown from a  
single large donation to a diverse community of contributors and  
users. OpenJPA meets the technical requirements for diversity, with  
committers from three and PPMC members from four independent  
organizations.


Committers from other Apache projects have not only used the  
incubating releases as dependencies in their projects but provided  
patches to OpenJPA as well.


The OpenJPA community prepared and voted out two releases performed  
by different release managers.


The community readily agreed on the bike-shed issues of code  
formatting and indentation, and there has been no resurrection of  
these issues. The community had issues with commit-then-review  
versus review-then-commit and resolved them win-win. Most recently,  
a public issue regarding the proposed charter of the TLP was resolved.


During the process of incubation, the PPMC learned how to govern  
itself, voting in new committers and PPMC members.


Mentors offered invaluable advice and assistance in getting the  
project set up and organized.


The status file for OpenJPA can be found at: http://svn.apache.org/ 
repos/asf/incubator/openjpa/STATUS


The incubator checklist web page for OpenJPA can be found at:  
http://incubator.apache.org/projects/openjpa.html



Establish the Apache OpenJPA 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, to be known as
   Apache OpenJPA, related to the implementation of
   object persistence, including, but not limited to,
   Java Persistence API, for distribution at no charge to the  
public;


   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), be and hereby is established pursuant to  
Bylaws

   of the Foundation; and be it further

   RESOLVED, that the OpenJPA PMC be and hereby is charged with
   the creation and maintenance of Apache OpenJPA;
   and be it further

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

   PMC; and be it further

   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   OpenJPA PMC:

   Geir Magnusson Jr.  [EMAIL PROTECTED]
   Patrick Linskey [EMAIL PROTECTED]
   Craig Russell   [EMAIL PROTECTED]
   Kevin Sutter[EMAIL PROTECTED]
   Abe White   [EMAIL PROTECTED]
   Marc Prud'hommeaux  [EMAIL PROTECTED]

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

   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator OpenJPA podling and encumbered upon the Apache  
Incubator

   PMC are hereafter discharged.

Craig Russell
DB PMC, OpenJPA PPMC
[EMAIL PROTECTED] http://db.apache.org/jdo





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

Re: Status of the Wadi project?

[Brian McCallister]

I think wadi withdrew from incubation. It seems alive here: http:// 
wadi.codehaus.org/


?

-Brian

On Apr 15, 2007, at 2:09 AM, Jukka Zitting wrote:


Hi,

I cross-referenced http://wiki.apache.org/incubator/ReportingSchedule
against http://incubator.apache.org/projects/ and noticed that the
Wadi project is not included in the reporting schedule.

There doesn't seem to have been any activity on the project in over  
a year.


BR,

Jukka Zitting

-
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: WANTED: Another Mentor for QPid

[Brian McCallister]

On Apr 10, 2007, at 10:58 PM, Brian McCallister wrote:


If someone can step up to help OpenJPA I will trade off :-)

I haven't been a fantastic mentor for OpenJPA, anyway :-(


(Not trying to ditch OpenJPA, just trying to open up options :-)

-Brian



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

Re: WANTED: Another Mentor for QPid

[Brian McCallister]

If someone can step up to help OpenJPA I will trade off :-)

I haven't been a fantastic mentor for OpenJPA, anyway :-(

-Brian

On Apr 10, 2007, at 7:46 PM, Noel J. Bergman wrote:

I am informed that QPid has two Mentors.  Would someone please  
volunteer to

act as a third?  QPid is an technology in the MQ/JMS messaging problem
domain, seeking to provide a vendor neutral protocol for interoperable
messaging.

--- Noel



-
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: [vote] mod_wombat ip clearance

[Brian McCallister]

On Feb 15, 2007, at 6:54 PM, Brian McCallister wrote:


search for if applicable


Using the search available here ( http://www.uspto.gov/main/ 
trademarks.htm ) I found nothing which looks infringing. There are  
a number of wombat trademarks around, but the only one related to  
software is marked DEAD. The closest live one is for some folks who  
make keyboards.


For completeness, here are all the live marks associated with wombat  
and registered with the USPTO:


Word MarkWOMBAT PACK
Goods and Services 	IC 025. US 022 039. G  S: jackets, parkas, hats,  
caps, gloves, sweaters, sweatshirts, t-shirts, pants, shorts, ski  
overalls, coats, shirts, swim wear, scarves, boots, shoes, sandals,


Word MarkWOMBAT
Goods and Services 	IC 009. US 021 023 026 036 038. G  S:  
sunglasses, cases for glasses, frames for glasses, parts and fittings  
for glasses
IC 014. US 002 027 028 050. G  S: watches, watch straps and parts  
and fittings therefor; and jewelry
IC 025. US 022 039. G  S: Clothing, namely, shirts, pants, jackets;  
footwear and headgear, namely, tennis shoes and hats


Word MarkSILKY WOMBAT
Goods and Services  IC 033. US 047 049. G  S: Wines

Word MarkWOMBAT PACK
Goods and Services 	IC 018. US 001 002 003 022 041. G  S: Backpacks  
and luggage


Word MarkWARMBAT AUSTRALIA
Goods and Services 	IC 025. US 022 039. G  S: Clothing and footwear,  
namely boots, shoes, sandals, slippers, t-shirts, sweatshirts, hats,  
stocking caps, jeans, and jackets. FIRST USE: 20040120. FIRST USE IN  
COMMERCE: 20040120


Word MarkWOMBAT
Goods and Services 	IC 010. US 026 039 044. G  S: Adjustable  
activity support chairs and seats for medical use for use by patients  
and the disabled and parts and accessories for the aforementioned goods


Word MarkWOMBAT HILL
Goods and Services 	IC 033. US 047 049. G  S: WINES AND FORTIFIED  
WINES. FIRST USE: 20020816. FIRST USE IN COMMERCE: 20030707


Word MarkWOMBAT
Goods and Services 	IC 008. US 023 028 044. G  S: Rakes. FIRST USE:  
20031009. FIRST USE IN COMMERCE: 20031009


Word MarkWELLNESS WOMBATS
Goods and Services 	IC 016. US 002 005 022 023 029 037 038 050. G   
S: Educational books in the field of children's literature. FIRST  
USE: 20060112. FIRST USE IN COMMERCE: 20060112


Word MarkWOMBAT
Goods and Services 	IC 028. US 022 023 038 050. G  S: sports fishing  
equipment, namely, fishing rods and poles; fishing reels; items of  
terminal tackle, namely, leaders, artificial lures, artificial baits,  
artificial flies, fishing hooks, bobbers, sinkers, snaps, and  
swivels; fishing supplies and accessories, namely, fish stringers,  
creels, tackle boxes, bags, baskets, and other containers designed to  
hold fish, portable bait containers, landing nets, gaff hooks,  
fishing hook disgorgers, dressing for fishing lines and artificial  
flies; fishing rod belts; fishing rodholders; fishing harnesses; fish  
fighting chairs; fishing outriggers, fishing downriggers. FIRST USE:  
19860401. FIRST USE IN COMMERCE: 19860401


Word MarkWOMBAT WARE
Goods and Services 	IC 021. US 002 013 023 029 030 033 040 050. G   
S: plastic drinking glasses and plastic serving pitchers. FIRST USE:  
19990630. FIRST USE IN COMMERCE: 19990630


Word MarkWOMBAT WIZARD
Goods and Services 	IC 009. US 021 023 026 036 038. G  S: wireless  
keyboards for computers. FIRST USE: 19970800. FIRST USE IN COMMERCE:  
19970800


Word MarkWOMBAT XING
Goods and Services 	IC 041. US 100 101 107. G  S: video production  
services, namely, music videos, video yearbooks, instructional  
videos, home movie editing, feature films, and film shorts. FIRST  
USE: 19940700. FIRST USE IN COMMERCE: 19940700


Word MarkWOMBAT
Goods and Services 	IC 009. US 021 023 026 036 038. G  S: computer  
keyboards. FIRST USE: 19940505. FIRST USE IN COMMERCE: 19940505


Word MarkVIVA LA WOMBAT!
Translations 	THE SPANISH WORD VIVA IS TRANSLATED IN ENGLISH AS  
LONG LIVE.
Goods and Services 	IC 025. US 039. G  S: MEN'S, LADIES' AND  
CHILDREN'S CLOTHING, NAMELY, JUMPERS, SWEATERS, SHIRTS, SKIRTS,  
TROUSERS, DRESSES, SWIMWEAR AND HATS. FIRST USE: 19830628. FIRST USE  
IN COMMERCE: 19861006


-Brian

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

IP Clearance and Lazy Consensus

[Brian McCallister]

On Feb 14, 2007, at 6:00 AM, Jim Jagielski wrote:

This is a lazy-consensus approval vote.


Huh? These types of things should require activing
voting, not lazy-consensus. Otherwise the Incubator
is worthless.


I am just quoting from the IP Clearance docs:

Fourth paragraph (if you count the text box as a paragraph), Note  
that only lazy concensus is required.


http://incubator.apache.org/ip-clearance/index.html

In the case of IP Clearance, another PMC has already voted to accept  
the code, and it is supposed to be a crossing of t's and dotting of  
i's which is actively managed by a member or officer (per the  
template). Presumably we trust a member or officer to not cheat.


Considering the possible legal implications of getting IP wrong, it  
may be a good thing to require the formal approval just to force more  
eyes to look at things. That said, I hesitate to increase the  
incubator workload when the work amounts to covering another PMC's  
butt for them :-)



Yours in Waffles,
-Brian

[vote] mod_wombat ip clearance

[Brian McCallister]

The last code grant for the mod_wombat codebase ( http:// 
incubator.apache.org/ip-clearance/httpd-wombat.html ) has been  
recorded and I would like to move forward with the import.


Code grants and CLA's have been recorded from each person who has  
contributed code.


This is a lazy-consensus approval vote.

-Brian

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

Re: [vote] mod_wombat ip clearance

[Brian McCallister]

+1 From me :-)

-Brian

On Feb 13, 2007, at 3:00 PM, Brian McCallister wrote:

The last code grant for the mod_wombat codebase ( http:// 
incubator.apache.org/ip-clearance/httpd-wombat.html ) has been  
recorded and I would like to move forward with the import.


Code grants and CLA's have been recorded from each person who has  
contributed code.


This is a lazy-consensus approval vote.

-Brian

-
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: [VOTE] Roller graduation

[Brian McCallister]

+1 and about time :-)

-Brian


On Feb 6, 2007, at 7:07 AM, Dave wrote:


OK, let's try this again.

The Roller community believes that Roller is ready for graduation, as
evidenced by this vote:
http://mail-archives.apache.org/mod_mbox/incubator-roller-dev/ 
200702.mbox/browser


We would like to initiate a vote to graduate to a top level project.
We would like the resolution attached to this email to be presented to
the board for consideration at the next possible board meeting.

For additional information, the Roller status file is here:
http://incubator.apache.org/projects/roller.html


Thanks for your consideration. Please commence voting...

- Dave

Here is the resolution:
https://svn.apache.org/repos/asf/incubator/roller/trunk/tlp- 
resolution.txt



Establish the Apache Roller 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 the Roller blog server,
  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 Roller Project,
  be and hereby is established pursuant to Bylaws of the
  Foundation; and be it further

  RESOLVED, that the Apache Roller Project be and hereby is
  responsible for the creation and maintenance of open-source
  software related to the Roller blog server; and be it further

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

* Anil Gangolli   [EMAIL PROTECTED]
* Allen Gilliland [EMAIL PROTECTED]
* Dave Johnson[EMAIL PROTECTED]
* Matt Raible [EMAIL PROTECTED]
* Craig Russell   [EMAIL PROTECTED]
* Matthew Schmidt [EMAIL PROTECTED]
* Elias Torres[EMAIL PROTECTED]
* Henri Yandell   [EMAIL PROTECTED]

  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dave Johnson
  be appointed to the office of Vice President, Roller, 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 Roller Project be and hereby
  is tasked with the creation of a set of bylaws intended to
  encourage open development and increased participation in the
  Roller Project; and be it further

  RESOLVED, that the initial Apache Roller Project be and hereby
  is tasked with the migration and rationalization of the Apache
  Incubator Roller podling; and be it further

  RESOLVED, that all responsibility pertaining to the Apache
  Incubator Roller podling encumbered upon the Apache Incubator
  PMC are hereafter discharged.

-
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: [VOTE] Felix Graduation

[Brian McCallister]

+1

-Brian

On Jan 16, 2007, at 12:02 PM, Richard S. Hall wrote:

The Felix community feels that we are ready for graduation, as  
indicated by the following community vote to request graduation:


http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/ 
200612.mbox/[EMAIL PROTECTED]


We would like to initiate a vote to graduate to a top level  
project. We would like the resolution attached to this email to be  
presented to the board for consideration at the next possible board  
meeting.


For additional information, the Felix status file is here: http:// 
incubator.apache.org/projects/felix.html


Thank you in advance for your time and consideration.

- richard
## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix 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 implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform 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 Felix Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache Felix Project be and hereby is
   responsible for the creation and maintenance of
   open-source software implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform; and be it further

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

 * Alex Karasulu [EMAIL PROTECTED]
 * Berin Loritsch [EMAIL PROTECTED]
 * Carsten Ziegeler [EMAIL PROTECTED]
 * Matteo Demuru [EMAIL PROTECTED]
 * Enrique Rodriguez [EMAIL PROTECTED]
 * Francesco Furfari [EMAIL PROTECTED]
 * Stefano Lenzi [EMAIL PROTECTED]
 * Marcel Offermans [EMAIL PROTECTED]
 * Noel Bergman [EMAIL PROTECTED]
 * Karl Pauls [EMAIL PROTECTED]
 * Richard Hall [EMAIL PROTECTED]
 * Sylvain Wallez [EMAIL PROTECTED]
 * Timothy Bennett [EMAIL PROTECTED]
 * Trustin Lee [EMAIL PROTECTED]
 * Rob Walker [EMAIL PROTECTED]

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

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator Felix podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.

  Special Order 6E, Establishing the Apache Felix Project, was
  approved by Unanimous Vote.

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

[result] ActiveMQ Graduation

[Brian McCallister]

Vote passes!

I'll forward the resolution to the board :-)

+1: [
Henri Yandell
Alex Karasulu
James Strachan
Davanum Srinivas
Paul Fremantle
Dain Sundstrom
Brian McCallister
Robert Burrell Donkin
David Blevins
Jason van Zyl
]

0: []

-1: []

-Brian

On Jan 8, 2007, at 5:20 PM, Brian McCallister wrote:

ActiveMQ would like to move to graduate to a top level project, and  
that the proposal at the end of this email be presented to the  
board for consideration at the next meeting.


Status File: http://incubator.apache.org/projects/activemq.html

I will plan on tallying the vote on 1/15/07 (one week from today)  
in order to allow plenty of time for folks to catch up from the  
holidays.


Thank you,

-Brian


---
-- Proposal to the Board --
---
Establish the Apache ActiveMQ 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 implementing a distributed
messaging system, 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 ActiveMQ PMC, be and hereby
is established pursuant to Bylaws of the Foundation; and be it
further

RESOLVED, that the Apache ActiveMQ PMC be and hereby is responsible
for the creation and maintenance of open-source software and
documentation for a distributed messaging system, based on software
licensed to the Foundation; and be it further


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

Alan Cabrera [EMAIL PROTECTED]
Hiram Chirino [EMAIL PROTECTED]
Rob Davies [EMAIL PROTECTED]
Matt Hogstrom [EMAIL PROTECTED]
David Jencks [EMAIL PROTECTED]
Brian McCallister [EMAIL PROTECTED]
Aaron Mulder [EMAIL PROTECTED]
Guillaume Nodet [EMAIL PROTECTED]
John Sisson [EMAIL PROTECTED]
Bruce Snyder [EMAIL PROTECTED]
James Strachan [EMAIL PROTECTED]
Dain Sundstrom [EMAIL PROTECTED]

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister be
appointed to the office of Vice President, ActiveMQ, 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 ActiveMQ 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 ActiveMQ Project; and be
it further

RESOLVED, that the Apache Incubator PMC shall, upon deciding that
the ActiveMQ incubating project has graduated, transfer all oversight
and responsibility for the ActiveMQ incubating project and its
artifacts to the Apache ActiveMQ PMC.


-
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: [vote] ActiveMQ Graduation

[Brian McCallister]

On Jan 9, 2007, at 8:21 AM, Henri Yandell wrote:


On 1/9/07, Justin Erenkrantz [EMAIL PROTECTED] wrote:


1) The Board meeting is on the 17th, so this will likely be too late
to add to this month's agenda.  (You can see if we're willing to hold
a spot open for ActiveMQ, but it's iffy if you were to submit it on
Tuesday.)


No worries, we can wait until the following if need be, there is no  
race I know :-) If it gets in, great, if not, so be it.


2) The resolution has the dreaded PMC virus.  Where did you get  
this

template from?  It's bogus.  Please fix.  Harmony's template is here:

http://www.apache.org/foundation/records/minutes/2006/ 
board_minutes_2006_10_25.txt


or:

https://svn.apache.org/repos/private/committers/board/templates/ 
podling-tlp-resolution.txt


Please consider the proposed resolution changed to (using the podling- 
tlp-resolution):


Establish the Apache ActiveMQ 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
   implementing a distributed messaging system, 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 ActiveMQ Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache ActiveMQ Project be and hereby is
   responsible for the creation and maintenance of open-source
   software and documentation for a distributed messaging system,
   based on software licensed to the Foundation; and be it
   further

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

   * Alan Cabrera [EMAIL PROTECTED]
   * Hiram Chirino [EMAIL PROTECTED]
   * Rob Davies [EMAIL PROTECTED]
   * Matt Hogstrom [EMAIL PROTECTED]
   * David Jencks [EMAIL PROTECTED]
   * Brian McCallister [EMAIL PROTECTED]
   * Aaron Mulder [EMAIL PROTECTED]
   * Guillaume Nodet [EMAIL PROTECTED]
   * John Sisson [EMAIL PROTECTED]
   * Bruce Snyder [EMAIL PROTECTED]
   * James Strachan [EMAIL PROTECTED]
   * Dain Sundstrom [EMAIL PROTECTED]

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister
   be appointed to the office of Vice President, ActiveMQ, 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 ActiveMQ Project be and hereby
   is tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   ActiveMQ Project; and be it further

   RESOLVED, that the initial Apache ActiveMQ Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator ActiveMQ podling; and be it further

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator ActiveMQ podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.




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

Re: [vote] ActiveMQ Graduation

[Brian McCallister]

+1

-Brian

On Jan 8, 2007, at 5:20 PM, Brian McCallister wrote:

ActiveMQ would like to move to graduate to a top level project, and  
that the proposal at the end of this email be presented to the  
board for consideration at the next meeting.


Status File: http://incubator.apache.org/projects/activemq.html

I will plan on tallying the vote on 1/15/07 (one week from today)  
in order to allow plenty of time for folks to catch up from the  
holidays.


Thank you,

-Brian


---
-- Proposal to the Board --
---
Establish the Apache ActiveMQ 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 implementing a distributed
messaging system, 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 ActiveMQ PMC, be and hereby
is established pursuant to Bylaws of the Foundation; and be it
further

RESOLVED, that the Apache ActiveMQ PMC be and hereby is responsible
for the creation and maintenance of open-source software and
documentation for a distributed messaging system, based on software
licensed to the Foundation; and be it further


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

Alan Cabrera [EMAIL PROTECTED]
Hiram Chirino [EMAIL PROTECTED]
Rob Davies [EMAIL PROTECTED]
Matt Hogstrom [EMAIL PROTECTED]
David Jencks [EMAIL PROTECTED]
Brian McCallister [EMAIL PROTECTED]
Aaron Mulder [EMAIL PROTECTED]
Guillaume Nodet [EMAIL PROTECTED]
John Sisson [EMAIL PROTECTED]
Bruce Snyder [EMAIL PROTECTED]
James Strachan [EMAIL PROTECTED]
Dain Sundstrom [EMAIL PROTECTED]

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister be
appointed to the office of Vice President, ActiveMQ, 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 ActiveMQ 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 ActiveMQ Project; and be
it further

RESOLVED, that the Apache Incubator PMC shall, upon deciding that
the ActiveMQ incubating project has graduated, transfer all oversight
and responsibility for the ActiveMQ incubating project and its
artifacts to the Apache ActiveMQ PMC.


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

[vote] ActiveMQ Graduation

[Brian McCallister]

ActiveMQ would like to move to graduate to a top level project, and  
that the proposal at the end of this email be presented to the board  
for consideration at the next meeting.


Status File: http://incubator.apache.org/projects/activemq.html

I will plan on tallying the vote on 1/15/07 (one week from today) in  
order to allow plenty of time for folks to catch up from the holidays.


Thank you,

-Brian


---
-- Proposal to the Board --
---
Establish the Apache ActiveMQ 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 implementing a distributed
messaging system, 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 ActiveMQ PMC, be and hereby
is established pursuant to Bylaws of the Foundation; and be it
further

RESOLVED, that the Apache ActiveMQ PMC be and hereby is responsible
for the creation and maintenance of open-source software and
documentation for a distributed messaging system, based on software
licensed to the Foundation; and be it further


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

Alan Cabrera [EMAIL PROTECTED]
Hiram Chirino [EMAIL PROTECTED]
Rob Davies [EMAIL PROTECTED]
Matt Hogstrom [EMAIL PROTECTED]
David Jencks [EMAIL PROTECTED]
Brian McCallister [EMAIL PROTECTED]
Aaron Mulder [EMAIL PROTECTED]
Guillaume Nodet [EMAIL PROTECTED]
John Sisson [EMAIL PROTECTED]
Bruce Snyder [EMAIL PROTECTED]
James Strachan [EMAIL PROTECTED]
Dain Sundstrom [EMAIL PROTECTED]

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister be
appointed to the office of Vice President, ActiveMQ, 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 ActiveMQ 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 ActiveMQ Project; and be
it further

RESOLVED, that the Apache Incubator PMC shall, upon deciding that
the ActiveMQ incubating project has graduated, transfer all oversight
and responsibility for the ActiveMQ incubating project and its
artifacts to the Apache ActiveMQ PMC.


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

Wombat IP Clearance

[Brian McCallister]

The Apache HTTPD project has decided (1) to import the wombat  
codebase (2) and I have filled out all but one part of the ip  
clearance form. The remaining part is the actual transfer of  
copyright/assignment/etc. What form is correct for filling this out?


-Brian

1) https://svn.i-want-a-pony.com/repos/wombat/trunk
2) http://marc.theaimsgroup.com/?l=apache-httpd- 
devm=116525513728295w=2


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

Re: [VOTE] Release Qpid M1

[Brian McCallister]

On Dec 11, 2006, at 2:27 AM, Cliff Schmidt wrote:


On 12/6/06, Brian McCallister [EMAIL PROTECTED] wrote:

Concern:
Was there any resolution on the AMQP licensing terms (1) in relation
to making releases? I think it is okay, but how it fits into the
current draft guidelines (2) I am unsure. I think Cliff voted for
this, so I suspect it is okay. Just want to make sure :-)


Yes, before I gave my +1 I made sure the AMQP spec license allowed for
distribution (which got corrected from the earlier version of the
license).  I also personally did a review to ensure that all
third-party licenses are acceptable (mainly BSD-like, Apache, CPL, and
MPL) and that the required notices for these components are covered by
the NOTICE file.


Thanks!

+1 from me, things look in order.

-Brian

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

Re: [VOTE] Release Qpid M1

[Brian McCallister]

Concern:
Was there any resolution on the AMQP licensing terms (1) in relation  
to making releases? I think it is okay, but how it fits into the  
current draft guidelines (2) I am unsure. I think Cliff voted for  
this, so I suspect it is okay. Just want to make sure :-)


Nit:
I am unable to verify the gpg signature on the source tarball. I  
couldn't find the key ( 76DDB16818806464 ) on a keyserver, nor is  
there a KEYS file with it.


-Brian

(1) https://svn.apache.org/repos/asf/incubator/qpid/branches/M1/specs/ 
license.amqp.txt


(2) http://people.apache.org/~cliffs/3party.html
On Dec 6, 2006, at 7:46 PM, Carl Trieloff wrote:

The Qpid community voted on and almost approved to release qpid- 
java-1.0-incubator-M1, we are a vote short.


I would thus like to request the Incubator PMC to review the  
release and if someone could help us get this remaining vote to be  
able to request to publish the release.


You can preview the release at:
   http://people.apache.org/~rajith/qpid-release/M1/
which includes the links to the binary and sources releases.


The svn branch used for the M1 release is located at:
   https://svn.apache.org/repos/asf/incubator/qpid/branches/M1/
The results of the vote held on the Qpid dev list where as follows

Vote Summary

0   -1 or 0 votes
2   +1 Mentors 12   +1 PPMC
4   +1 Others

Mentors
---
Cliff Schmitt
Paul Fremantle

PPMC

Alan Conway
Kim van der Riet
Martin Ritche
Marnie McCormack
Steve Vinoski
Gordon Sim
Robert Grieg
Rajith Attapatta
John O'Hara
Bhupendra Bhardwaj
Rafael Schloming
Carl Trieloff

Others
--
Suresh Kodichath Frank Lynch
Sam Joyce
Tejeswar Das

 Regards
Carl


-
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: [VOTE] Graduate Cayenne to TLP status (pending board approval)

[Brian McCallister]

+1 I have been watching the Cayenne goings-ons and am very impressed.

-Brian

On Dec 1, 2006, at 7:24 AM, Andrus Adamchik wrote:

Apache Cayenne community just voted to request graduation from the  
Incubator as a TLP [1]. The text of the proposed board resolution  
(adopted from iBatis graduation resolution) is included below.  
Other project related links are also shown below - [2], [3]. The  
following people cast +1 votes:


  Andrus Adamchik (PPMC)
  Craig Russell
  Malcolm Edgar (committer)
  Matt Kerr
  Tore Halset (PPMC)
  Ari Maniatis
  Bill Dudney (PPMC)
  Michael Gentry (PPMC)
  Mike Kienenberger (PPMC)
  Jean T. Anderson (PPMC / Incubator PMC)
  Kevin Menard (committer)
  Jason Dwyer


I am asking for a vote of the Incubator PMC on graduation of  
Cayenne that is conditional on the board's approval of a TLP for  
that purpose. Please cast your votes.


[1] http://mail-archives.apache.org/mod_mbox/incubator-cayenne-dev/ 
200612.mbox/[EMAIL PROTECTED]

[2] http://incubator.apache.org/cayenne/
[3] http://incubator.apache.org/projects/cayenne.html

Andrus

-
Apache Cayenne developers have voted to request the ASF Board to  
establish
Cayenne as a Top Level Project at the ASF. Here is the text of the  
suggested

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 related to object-relational mapping (ORM)
   and remoting services, 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 Cayenne PMC, be  
and

   hereby is established pursuant to Bylaws of the Foundation; and
   be it further

   RESOLVED, that the Apache Cayenne PMC be and hereby is
   responsible for the creation and maintenance of software
   related to the Cayenne Object Relational Framework and tools,
   based on software licensed to the Foundation; and be it further

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

 Andrus Adamchik ([EMAIL PROTECTED])
 Bill Dudney ([EMAIL PROTECTED])
 Michael Gentry ([EMAIL PROTECTED])
 Tore Halset ([EMAIL PROTECTED])
 Mike Kienenberger  ([EMAIL PROTECTED])

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrus Adamchik be
   and hereby is appointed to the office of Vice President, Apache
   Cayenne, 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 Cayenne PMC be and hereby is
   tasked with the migration and rationalization of the incubating
   Apache Cayenne project; and be it further

   RESOLVED, that all responsibility pertaining to the incubating
   Apache Cayenne project encumbered upon the incubator PMC be
   hereafter discharged.


-
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: [VOTE] Release ActiveMQ CPP 1.0

[Brian McCallister]

+1 though I'd consider making the configure script +x in the future.

-Brian

On Nov 14, 2006, at 6:30 PM, Nathan Mittler wrote:

The ActiveMQ community has voted on the release of ActiveMQ CPP 1.0  
with a

total of 6 +1's.

The source bundle for the release candidate can be found here:
http://people.apache.org/~tabish/activemq-cpp-1.0.zip

And here's the wiki page for the release:
http://www.activemq.org/site/activemq-cpp-10-release.html

Please cast your votes:

[ ] +1 Release the source as Apache ActiveMQ  CPP 1.0
[ ] -1 Veto the release (provide specific comments)

Regards,
Nate



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

Re: [VOTE] Approve the 2.0.1 release of Cayenne

[Brian McCallister]

+1

-Brian

On Sep 30, 2006, at 9:09 AM, Andrus Adamchik wrote:

Cayenne community has voted and approved 2.0.1 release of Cayenne.  
This release marks a major milestone in Cayenne incubation as we've  
fully resolved all IP issues and got rid of incompatible license  
dependencies. Now we would like to request the approval of the  
Incubator PMC to perform the release.



There were 6 +1 votes (including 3 from PPMC members) and no  
other votes:


Andrus Adamchik +1
Michael Gentry +1
Tore Halset +1
Mike Kienenberger +1
Kevin Menard +1
Jim Jagielski +1 (cast on the PPMC list)

Vote thread:

http://mail-archives.apache.org/mod_mbox/incubator-cayenne-dev/ 
200609.mbox/[EMAIL PROTECTED]


Release artifacts can be found here:

http://people.apache.org/~aadamchik/release/2.0.1/


And here is my +1 (non-binding)

Andrus

-
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: Proposal for a new incubation project: Unstructured Information Management Architecture - UIMA

[Brian McCallister]

On Aug 25, 2006, at 4:07 AM, Leo Simons wrote:


What does it *do*?


I believe it is basically a big, pluggable, harness for analyzing and  
annotating streams of arbitrary data, if this is the same thing I  
talked with a bunch of folks about (including Martin, I believe) a  
couple years ago at Hawthorne.


I think it actually grew out of a real need in the research community  
- lots of cool tools were being built to do unstructured information  
analysis and none of them could be used together.


-Brian

ps: I may also be totally wrong. My guesstimate is based on a couple  
hours of conversations a few years ago.


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

Re: Proposal for a new incubation project: Unstructured Information Management Architecture - UIMA

[Brian McCallister]

On Aug 25, 2006, at 11:11 AM, Brian McCallister wrote:


(including Martin, I believe)


s/Martin/Marshall/g

Doh! Sorry :-)

-Brian

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

Re: [VOTE] approve the 4.0.2 release of ActiveMQ

[Brian McCallister]

+1 (again) :-)

On Aug 17, 2006, at 3:58 PM, Hiram Chirino wrote:


In accordance with the incubator release procedure (see below) the
Apache ActiveMQ community has voted on and approved the 4.0.2 release
binary.

We would now like to request the permission of the Incubator PMC to
perform the release.

Release notes:
http://incubator.apache.org/activemq/activemq-402-release.html

Vote thread:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200608.mbox/% 
[EMAIL PROTECTED]


Vote result:
The VOTE has passed with 7 ppmc +1's and no -1s.

+1 Hiram Chirino
+1 James Strachan
+1 Rob Davies
+1 Guillaume Nodet
+1 Alan D. Cabrera
+1 Aaron Mulder
+1 Brian McCallister

We also had 1 non ppmc +1:
+1 Kevan Miller

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/ 
maven1/incubator-activemq/distributions/


Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Here's my non binding +1

--
Regards,
Hiram

Blog: http://hiramchirino.com

-
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: Forming an ActiveMQ PPMC

[Brian McCallister]

On Aug 16, 2006, at 12:32 AM, James Strachan wrote:


On 8/16/06, Brian McCallister [EMAIL PROTECTED] wrote:

The ActiveMQ committers have decided to aim for TLP status (1), as
such we need to get a PPMC in place. Thus far we have been working
under a committer votes all count style (really, everyone's vote
counts, it is on a public list without any of the mine is binding
stuff that has become popular), so I would like to open the
discussion of formalizing the PPMC as all current committers on
ActiveMQ.


FWIW we've had a PPMC in place for some time ;) which was mostly the
committers plus anyone from Incubator/Geronimo PMCs who wanted to help
too. (Brian search your mailbox for activemq-ppmc or activemq-private
which is the latest name of the mailing list - I've seen at least 2
posts from you :)


Hah, you are right! Okay, I feel stupid.

/me is going to find a *lot* more coffee

:-)

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

Re: Glasgow - new name proposal

[Brian McCallister]

AMQPD

-Brian

On Aug 9, 2006, at 1:06 PM, Rafael Schloming wrote:

How about Qpid? It could mean Queuing Protocol for Information  
Delivery or something like that.


Carl Trieloff wrote:

+1 for Kyma  easy to say, read and use in code.
Archit Shah wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

 
-

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]


-
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: [VOTE] Accept Glasgow into Incubator

[Brian McCallister]

-1

I think that this project is premature until the spec is in an open,
inclusive process or at an acceptable standards body with compatible
licensing terms. I would embrace this project were it so.

The project is supposed to be implementations of a standard protocol
but the protocol in question is proprietary and is under the control of
a group of companies whose employees make up the initial committer list.
It is impossible for individuals to join the protocol specification
body, and even then the means of decision making is not specified.

While it is a proprietary, closed-group protocol it cannot be called a
standard, and the project is, in fact, implementing a protocol under
the control of a subset of the employers of the contributors to the
project.

If the protocol were being developed under an open, inclusive process
which was compatible with how Apache works in general (which includes
processes in standards bodies which conduct business in that way, or
which have established sufficient reputation to allay these worries) I
would be very much in favor of this proposal.

-Brian


On Aug 3, 2006, at 9:52 AM, Cliff Schmidt wrote:


I believe all open questions about the Glasgow proposal (originally
submitted as Blaze) have now been addressed enough to call a vote
for accepting the project for incubation.

Therefore, as the champion of this project, I am calling a vote.  As
usual, the binding votes will be those case by Incubator PMC members
(since the project is requesting sponsorship from the Incubator PMC);
however all participants on this list are encouraged to vote if they
have a strong feeling one way or another.

The traditional 72-hour voting period would end during a weekend for
most timezones; so I propose extending that by an additional day, with
the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
http://www.timeanddate.com/worldclock/fixedtime.html? 
month=8day=7year=2006hour=17min=0sec=0p1=0)


Please vote on the Glasgow proposal, as described below, which can
also be found at:
http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1.

Note the old wiki page (with the full history of changes since the
original proposal) can be found here:
http://wiki.apache.org/incubator/Blaze

Cliff


= Glasgow Proposal (renamed from Blaze) =

== RATIONALE ==
Glasgow provides multiple language implementations of the Advanced
Messaged Queuing Protocol (AMQP) specification and related
technologies including PGM, transaction management, queuing,
distribution, security, management and heterogeneous multi-platform
support for messaging (links to these specifications are in the
Initial Source section of this proposal.)
Glasgow's overall goal is to create an open and interoperable
implementation for messaging which implements the emerging AMQP
specification, in keeping with the philosophy of the Foundation. This
implementation will provide a messaging solution that will be language
and platform agnostic by using a well defined wire specification.
Providing both libraries for the framing and protocol in addition to
brokers in both Java and C/C++ allows for integration with Apache and
non-Apache projects in a manner that facilitates heterogeneous
deployment with full interoperability for SOA  distributed systems.
The seed code for the project will consist of in-progress C/C++ and
Java implementations of the AMQP specification that we intend to
continue development on in conjunction with other Apache communities.
More information on the scope of the seed code can be found in
subsequent sections of this proposal.

== CRITERIA ==
=== Meritocracy: ===
The Glasgow committers recognize the desirability and necessity of
running this project as a full meritocracy; indeed, the scope of the
project's technical aspects are so varied that we find it hard to
envision success any other way. One of the most important lessons that
can be derived from the historic evolution of middleware is that
specifications architected in isolation from real usable code that has
been developed to solve tangible, real world problems or amongst a
narrowly restricted list of contributors often do not see widespread
adoption. Our goal in crafting this implementation and providing our
learning to the specification team is to develop the best possible
language agnostic advanced message queuing platform.  We understand
that in order to do so, we will need to engage all interested  members
of the community and operate to the standard of meritocracy that
characterizes successful Apache projects.

=== Community: ===
The project's primary objective is to build a vibrant community of
users and active contributors.  Although Glasgow is not based on an
existing open source community, many of the initial contributors have
experience participating in and building other open source
communities.  Several of the contributors have previously participated
in Apache communities. We understand that Apache's community
governance 

Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)

[Brian McCallister]

On Aug 1, 2006, at 1:47 AM, Gordon Sim wrote:

The current working group is open to new members and is eager for  
feedback from anyone.


Where are the archives of the discussions that have gotten it this  
far so I can understand what is driving the process and be able to  
contribute? What mailing list do I subscribe to in order to join the  
discussion?


-Brian



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

Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)

[Brian McCallister]

On Aug 1, 2006, at 9:36 AM, Carl Trieloff wrote:


Brian,

Just as in JCP, OASIS or W3C the real work happens on private  
channels, that said we are in
the process of creating public pages, from which to link user and  
feedback lists for anyone to

read, access and interact with the working group.


Great! Is it the intention of the spec group members to switch the  
primary discussion and real work to the public list?


Also, the question from my email before last is still unanswered: can  
the spec be forked if the process becomes an insurmountable obstacle  
for the Glasgow project? I realize this is really based on the terms  
in the license, but not being a lawyer, can you at least clarify the  
intentions of the group regarding this?


-Brian

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

Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)

[Brian McCallister]

On Aug 1, 2006, at 10:44 AM, Cliff Schmidt wrote:


Could you clarify whether you are asking if the Glasgow project could
continue in a different direction from the spec, or whether the spec,
itself, could be changed/forked and distributed by the ASF?


If something were to happen to cause development to stop on the spec,  
the licensing terms were to change, etc, could folks (including  
Glasgow) basically use the last released version as a starting point  
for continued protocol development, or would the licensing terms (and  
grants of rights specifically tied to use of this protocol based on  
this document) force the project and existing users to throw things  
away and develop something new which would not infringe.


-Brian


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

Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)

[Brian McCallister]

On Jul 29, 2006, at 4:45 PM, Cliff Schmidt wrote:


Does anyone have any further concerns about this proposal?


snip /


- There was also the question about how the AMQP specification will be
handled and licensed.  I started this thread with my feelings about
that aspect (short version: it looks better than some other currently
incubating projects, but I'd like us to come up with guidelines about
what is acceptable at Apache, and then make sure this project adheres
to those guidelines before graduating from the incubator).


I am still uncomfortable with the AMQP spec ownership and process for  
two reasons.


1) The pessimistic and defensive one: Entering incubation at Apache  
implies Apache's endorsement. This is not what we mean, but it is how  
the world will react. This endorsement is partly the point of the  
proposal -- getting the ASF behind AMQP will give it a boost, and  
incubation is still not well understood, even inside the ASF :-(


2) The go conquer the world one: If the goal is to create a  
standard protocol for messaging stuff, this requires a lot of buy in  
from a wide range of parties. Keeping the protocol behind closed  
doors and with a mysterious future sabotages this. Transparency is, I  
believe, a major requirement for accomplishing this goal, and the  
process is anything but transparent at the moment.


Both of these points would be lightened if the folks presently  
involved with the specification process seemed to recognize them as  
issues. To my reading, they are not recognized as issues, and there  
has been no public discussion by the folks actually involved with the  
protocol spec about this. The extent of it has been to say, more or  
less, that they doesn't think there is a problem. Lots of uninvolved  
people have chimed in with thoughts, but we (as I am one) are the  
peanut gallery and have no say in the current specification system.


Finally, is the specification forkable if it becomes an  
insurmountable problem?


If I weren't already committed to other incubating projects I would  
offer to help mentor as I really want this to succeed, meaning AMQP  
to become a de facto standard and the Apache implementations to be  
the best. Hope folk don't mind if I do stick in thoughts at least :-)


-Brian


ps: Tuscany being even more closed is not a justification for this  
getting it wrong. Tuscany's spec relationship is, in my opinion, a  
mistake, and one we have, hopefully, learned from.




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

Re: [PROPOSAL] Incubate Wicket

[Brian McCallister]

+0 (I'd love to see it happen, but don't expect to be able to  
contribute).


Nice folks, and anything with Upayavira, Sylvain, and Alex involved  
is destined to conquer the world anyway :-)


-Brian

On Jul 26, 2006, at 8:54 AM, Upayavira wrote:


The Wicket developers (http://wicket.sourceforge.net) have expressed a
desire to incubate their project within the ASF.

I personally think that Wicket would fit very well at Apache with its
flavour of innovation and its strong, meritocracy based community.

The proposal follows (which can also be found at:
http://wiki.apache.org/incubator/WicketProposal)

Regards, Upayavira

= Wicket Proposal =

This proposal outlines the creation of a new top-level Wicket project
within the Apache Software Foundation.

== Rationale ==

Wicket is a unique web application framework that focusses on bringing
plain object oriented Java programming to the web tier. It is  
unique in

it's focus amongst the (many) web frameworks that exist today. Due to
it's unmanaged nature and reliance on plain Java, it is a very good
match for frameworks like OSGi and Eclipse RSP. Wicket has been  
gaining
a very steady increase in popularity, and with two books coming out  
and
vastly improved new releases we are working on, we expect this  
trend to
continue. We consider moving to Apache being an additional boost,  
and we

hope it will open the way for possible future cooperation with other
Apache projects.

The maintainers of Wicket are interested in joining the Apache  
Software

Foundation for several reasons:

 * Apache has a widely recognized name, which will help Wicket get an
increased visibility and acceptance.

 * We'd like to enjoy the benefits of utilizing Apache's  
infrastructure

and legal protection.

 * Most team members have been enthusiastic users of Apache  
software for

many years and would like to be part of the family with it's get
togethers etc.

 * It might open the door for cooperation with other projects, such as
Felix or Jetspeed.

 * Apache seems to attract great communities around its projects, we
hope joining Apache will help as make our growing community even  
bigger.


 * We hope to contribute to Apache's ongoing success by delivering an
innovative, dynamic project with an enthusiastic user base.

== Criteria ==

=== Community ===

Wicket has striven to foster a diverse community that is open to
everyone. It is released
under a non-reciprocal license (Apache License 2.0) to encourage the
maximum possible adoption by all
potential users and developers. The Wicket community encourages
suggestions and
contributions from any potential user, and more developers have joined
as contributors
since the project's inception in 2004.

=== Meritocracy ===

Wicket was originally created by Jonathan Locke in April 2004. Then it
was taken over in September 2004 by Eelco Hilenius, Johan Compagner  
and

Martijn Dashorst. Chris Turner and Juergen Donnerstag were invited to
join that same week based on their contributions and discussions. The
project now has committers and users from around the world, and  
Jonathan

Locke is back with the project again. The newer committers of the
project joined in subsequent years by initially submitting patches,  
then

having commit privileges for some of the applications (wicket-stuff),
and then privileges over a larger range of applications. The project
members understand the importance of letting motivated individuals
contribute to the project after they have proven themselves.

== Scope of Sub projects ==

Wicket is distributed as one large subversion tree, but contains  
several
distinct parts: the core framework, a couple of extensions project  
that
are endorsed by the core developers, an examples project (which  
includes

a component reference), a quick start project and a developer sandbox.
One of the extensions projects, called wicket-extensions, has a dual
purpose. The first is to ensure the core project does not get too  
large,

while still having a place to put interesting components and utility
classes. The second purpose of that project is to provide a place  
where

components can prove themselves before potentially graduating to the
core project.

Whilst Wicket has these various subprojects, access to the subversion
tree is maintained with a single ACL. Once voted in as a committer, an
individual will have access to the entire tree, and trust is used to
ensure that they only touch the parts of the tree that they are
knowledgeable enough to change.

== Features ==

Wicket is a Java web application framework that takes simplicity,
separation of concerns and ease of development to a whole new level.
Wicket pages can be mocked up, previewed and later revised using
standard WYSIWYG HTML design tools. Dynamic content processing and  
form
handling is all handled in Java code using a first-class component  
model

backed by POJO data beans that can easily be persisted using your
favorite technology.

== Initial Source ==

The 

Re: [Proposal] Blaze

[Brian McCallister]

On Jul 20, 2006, at 7:12 AM, Sanjiva Weerawarana wrote:


On Wed, 2006-07-19 at 22:33 -0400, Carl Trieloff wrote:

Carl Trieloff wrote:


Sahan,

Thank you for your interest, do you mind if we do a brief call
(or email...or discuss right here on the list -- whatever your  
preference)

to understand
what your interest is and what or where you are wanting to  
contribute.


Please keep the conversation to the list .. its part of the process of
building openness and community.

In general, you should not have to ask what someone who's already  
an ASF

committer what his/her interest is in joining an incubator project. In
this particular case isn't the relationship/interest abundantly clear?


That said I want to be a committer shouldn't be a free pass either :-)

-Brian

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

Re: [Proposal] Blaze

[Brian McCallister]

On Jul 18, 2006, at 8:41 PM, Noel J. Bergman wrote:


Ian Holsman wrote:


if blaze's goal is to create a standardized widely available and
interoperable messaging solution (you forgot enterprise class)
why is it creating a new one, and not using JMS ?


Blaze's goal (AMQP) is to provide multple language implementations  
of a
language-neutral, wire-level, protocol with a ton of detailed  
semantics for

interoperable messaging.  JMS is a a Java API.


I am wholly behind the goal of establishing an open standard protocol  
for async messaging. Heck, I helped spec one out (which I would be  
happy to see supplanted by something better!), but I fear the way the  
protocol spec works here probably won't work well for an Apache project.


Blaze seems to be about about providing implementations of a  
proprietary protocol controlled by a group of vendors and one major  
customer. The protocol is specified behind closed doors with good  
intentioned but legally nebulous licensing. Participation in the  
protocol specification process by folks outside the initial group is  
by submitting suggestions to a private channel. The protocol is  
specifically controlled by a group of companies, with no provision  
for individual participation. On the other hand, Apache is  
specifically made up of individuals, not companies, and merit is  
based on the actions of the individual.


The protocol being implemented is pretty much controlled by a  
separate, closed body. There is presently no way for Apache  
contributors to participate in, or even observe, the protocol  
specification process. The eventual standards body to which it is to  
be submitted is unknown, and there are definitely standards bodies  
which are incompatible with Apache (any pay-to-play, or any barring  
individual participation, tend to be difficult) style development.


So basically, if the project's goal is to provide a couple reference  
implementations and various client libraries for an in-development  
closed protocol (with well intentioned licensing) which is being  
developed via a process which precludes participation by folks  
working on the Apache project unless their employer (who may not even  
be aware of their participation) signs an IP agreement? Even then,  
the path to joining the protocol specification group is by submitting  
suggestions to private discussion in which you are not included.


If the protocol came with the project, the protocol lived in a  
standards body such as the IETF, or even if the protocol was being  
developed in the open using an apache-style meritocracy, I would be  
100% for this. As it stands, I worry that it is incompatible with  
Apache.


-Brian




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

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Brian McCallister]

On Jul 11, 2006, at 12:46 PM, Cliff Schmidt wrote:


IRC can be used by a podling to bring new people up to speed (e.g.
QA between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process.


Just to call a spade a spade...

Perhaps things like members' and board meetings should also avoid IRC  
if a blanket statement that making decisions, even implicit ones, in  
IRC is bad?


-Brian

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

Re: Renaming Heraldry

[Brian McCallister]

Just my 2 cents: I rather liked the name Heraldry as well -- thought  
it was one of the more appropriate, and evocative, around =)


-Brian

On Jul 1, 2006, at 5:07 PM, Justin Erenkrantz wrote:


On 6/30/06, Matt Pelletier [EMAIL PROTECTED] wrote:

For what it's worth, I don't have an issue with 'Heraldry', and I
think 'Ibid' might be too confusing.


I also don't see any particular reason why Heraldry is a bad name -
actually, it sort of sums up the critical purpose of what the project
is doing.

*shrug*  -- justin

-
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: [VOTE] approve the 4.0.1 release of ActiveMQ

[Brian McCallister]

+1 with incubator hat on

-Brian

On Jun 20, 2006, at 6:09 AM, Davanum Srinivas wrote:


+1 (binding) from me,.

-- dims

On 6/20/06, James Strachan [EMAIL PROTECTED] wrote:

In accordance with the incubator release procedure (see below) the
ActiveMQ community has voted on and approved the 4.0.1 release  
binary.


We would now like to request the permission of the Incubator PMC to
perform the release.

Release notes:
http://incubator.apache.org/activemq/activemq-401-release.html

Vote thread:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200606.mbox/% 
[EMAIL PROTECTED]


Vote result:
The VOTE has passed with 9 ppmc +1's and no -1s.

+1 Hiram Chirino
+1 Alan D. Cabrera
+1 Adrian Co
+1 Brian McCallister
+1 Jonas Lim
+1 Bruce Snyder
+1 Fritz Oconer
+1 James Strachan
+1 Rob Davies

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0.1-RC1/ 
maven1/incubator-activemq/distributions/


Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/ 
Incubation_Policy.html#Releases


Here's my +1

--

James
---
http://radio.weblogs.com/0112098/

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





--
Davanum Srinivas : http://wso2.com/blogs/

-
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: [Proposal] Jini Project

[Brian McCallister]

On Jun 19, 2006, at 7:15 AM, Jim Hurley wrote:


This proposal seeks to create a project within the Apache Software
Foundation to continue the development and advancement of Jini
technology. It has broad backing from the Jini Community, and
includes core developers from Sun Microsystems (original developer
of the technology) as well as Community technical leaders.


This is very cool. Who controls the Jini spec, out of curiosity?

-Brian



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

Re: [VOTE] Incubator PMC to approve ActiveMQ 4.0 Release (new binary)

[Brian McCallister]

+1

-Brian

On Jun 5, 2006, at 7:46 AM, James Strachan wrote:


We ended up recutting the binary of the 4.0 release of ActiveMQ to
address a few issues brought up in the Incubator PMC vote; I'd just
like to call another vote to explicitly approve the new binary distro
to avoid confusion (as most Incubator PMC folks voted on the previous
binary).

Can I ask the Incubator PMC to please approve the new binary for the
ActiveMQ 4.0 release.

Release notes:
http://incubator.apache.org/activemq/activemq-40-release.html

Vote threads:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200605.mbox/% 
[EMAIL PROTECTED]
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200605.mbox/% 
[EMAIL PROTECTED]


Vote result:
The latest vote was 7 +1s and no -1s.

+1 Hiram Chirino
+1 Guillaume Nodet
+1 Bruce Snyder
+1 Adrian Co
+1 Jonas Lim
+1 James Strachan
+1 Fritz Oconer

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/ 
incubator-activemq/distributions/


Here's my +1
--

James
---
http://radio.weblogs.com/0112098/

-
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: [VOTE] Incubator PMC to approve ActiveMQ 4.0 Release

[Brian McCallister]

+1

-Brian

On May 26, 2006, at 5:11 AM, James Strachan wrote:


In accordance with the incubator release procedure (see below) the
ActiveMQ community has voted on and approved the 4.0 release binary.

We would now like to request the permission of the Incubator PMC to
perform the release.

Release notes:
http://incubator.apache.org/activemq/activemq-40-release.html

Vote thread:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200605.mbox/% 
[EMAIL PROTECTED]


Vote result:
The VOTE has passed with 10 committer +1's and 1 non-committer +1  
and no -1s.


+1 James Strachan
+1 Hiram Chirino
+1 Rob Davies
+1 Guillaume Nodet
+1 Jonas Lim
+1 Bruce Snyder
+1 John Sisson
+1 Dain Sundstrom
+1 Fritz Oconer
+1 Adrian Co
+1 Alan D. Cabrera

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/ 
incubator-activemq/distributions/


Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Here's my +1
--

James
---
http://radio.weblogs.com/0112098/

-
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: XAP (Extensible Ajax Platform) Proposal

[Brian McCallister]

On May 9, 2006, at 8:56 PM, Coach Wei wrote:

Has anyone had a chance to look at this proposal?  I realize there  
have

been a few other threads on this list in the last week, but I'd really
be interested in getting any feedback.


Off topic of the proposal -- how is scripting a UI in XML easier or  
more powerful than in JavaScript? It seems the opposite would be true.


-Brian

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

Re: [VOTE] Accept OpenJPA as an Incubator Podling

[Brian McCallister]

+1

-Brian

On Mar 19, 2006, at 5:33 AM, Geir Magnusson Jr wrote:



What follows is the official proposal for OpenJPA.  The unofficial
version can be found here

  http://wiki.apache.org/incubator/OpenJPAProposal

Please vote on acceptance of this proposal.  The vote will run 1  
week until Sunday, March 26, 2006 or until all Incubator PMC  
members have voted.


[ ] +1 Accept the OpenJPA proposal
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


== 
=



OpenJPA Project Proposal
=
OpenJPA will be an ASL-licensed implementation of the Java Persistence
API (JPA) which is defined as part of JSR-220.

Rationale
=
We think that Open JPA is something that will benefit from wide  
collaboration, being able to build a community of developers and  
committers that outlive the founders, and that will be embraced by  
other

Apache efforts, such as the Geronimo project as part of an EJB 3.0
container. Given the existing momentum forming behind JPA even at this
early stage, we are confident that an industrial-grade ASL
implementation of JSR220 will attract a diverse community.
Criteria

Meritocracy
===
The Open JPA committers recognize the desirability of building  
software

as a meritocracy and look forward to growing a healthy community of
developers to enhance the JPA APIs.

Community
=
The proposed committer community is includes members of the BEA JPA  
team

and several individuals from the Apache community.

Core Developers
===
Fourteen of the initial committers are BEA employees. One of those  
is a

committer on the Apache JDO project. We anticipate that five of these
fourteen will be involved in the core code development, and the other
nine will be involved in documentation and ongoing QA for the project.

Three of the initial committers are committers on the Geronimo  
project.

Two are IBM employees involved in the WebSphere product team. One is
from Intel.

Alignment
=
Open JPA will be a candidate for use in Geronimo as the default JPA
implementation. Other projects that have general-purpose JPA needs may
be users of the Open JPA project.

Open JPA has some level of alignment with the Apache DB project. In
particular, the Open JPA codebase already includes support for Derby
databases.

JPA is for use in any Java application, not just J2EE. Therefore, any
application that needs to do data persistence in the object/relational
style (including any application that currently uses Hibernate) will
benefit from Open JPA.

License
===
The existing codebase is owned by BEA and is subject to a proprietary
license. The applicable code will be relicensed under the Apache
Software License 2.0.


Avoiding the Warning Signs
==

Orphaned products
-
Open JPA is a derivative of the basis of the BEA WebLogic Server (WLS)
EJB3 JPA implementation, and so is an important piece of the BEA  
code base.


As this is a very eagerly anticipated specification for the Java
community, we expect that this project will continue to grow and  
develop
within its own community, and be embraced by other open source  
projects

(such as Geronimo) as well.

Inexperience with open source
-
The authors of the existing code (who will be part of the initial
committer list) have experience with open source development  
already, in

both professional and personal contexts. Examples: serp ([WWW]
http://serp.sourceforge.net) (used in Kodo currently), sqlline and  
jline

([WWW] http://sqlline.sourceforge.net and [WWW]
http://jline.sourceforge.net) (used by the Kodo development team, and
used by the Apache JDO team), Growl ([WWW] http://growl.info).

Four of the initial committers have extensive experience within the
Geronimo project, among other open-source projects.

Homogeneous developers
--
The members of the initial committer list have been working in a
distributed, multi-national, asynchronous environment for the last  
five

years, while working at SolarMetric. We had a team of up to 7 people
working from 6 different locations over the course of the last five  
years.


Reliance on Salaried Developers
---
Most of the developers are paid by their employer to contribute to  
this

project, but given the anticipation from the Java community for the a
JPA implementation and the committers' sense of ownership for the  
code,

the project would continue without issue if no salaried developers
contributed to the project.

No ties to other Apache products

Open JPA will likely be used by Geronimo, requires some Apache  
products
(regexp, commons collections, commons lang, commons pool), and  
supports

Apache commons logging.

A fascination with the Apache brand
---
We think that Open JPA is something that will benefit 

Re: Incubation Process and PPMCs

[Brian McCallister]

On Mar 14, 2006, at 9:51 AM, Yoav Shapira wrote:


And continuning the discussion from the OpenJPA proposal thread, do
the other 27 - 15 = 12 people on the proposal get moved into
non-committer status?


Speaking as one of those twelve, I'd greatly appreciate not being  
removed just because I am maintaining part of the codebase which  
works quite well at the moment (the dirt easy, platform neutral,  
wire protocol part).


-Brian



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

Re: [VOTE] accept Cayenne into incubator

[Brian McCallister]

On Mar 2, 2006, at 6:24 AM, Andrus Adamchik wrote:



Sorry, this is confusion on my end. I will change the Sponsor to  
DB, but is this consistent with the fact that we have no final  
decision on how Cayenne will graduate from the incubator (as TLP or  
DB subproject)?


You cannot actually do that unless the DB PMC votes to sponsor  
Cayenne, which we haven't done. If Thomas wants to introduce such a  
motion I'm happy to consider it, but as of yet, it hasn't happened.  
If that is the path Cayenne wants to take, let us know and we'll chat  
about it =)


-Brian


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

Re: Cayenne ASF Proposal

[Brian McCallister]

On Feb 28, 2006, at 4:02 PM, Thomas Dudziak wrote:

Though it wasn't posted to the PMC list (I only saw it because of  
the announcement on the incubator list).


Erg, could have sworn I CC'ed the pmc list once discussions heated  
up. My apologies!


-Brian


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

Re: Cayenne ASF Proposal

[Brian McCallister]

Andrus and Bill initially opened discussion on [EMAIL PROTECTED] I  
suggested they aim for a top level project status for a few reasons:


* Cayenne already has an mature ASF-style structure and community  
(reportedly =)
* There are ~subprojects (the gui tool, etc) in Cayenne, and sub-sub- 
projects seem to be frowned upon

* DB is getting kind of umbrella shaped already

That said, I am very willing to broach the subject of sponsorship  
with the DB PMC, I just figure the discussion of the best way to  
proceed makes more sense here. I think that Cayenne would prefer to  
be a top level project, in the end, and I agree with that goal. The  
best way to help that happen... well, we're discussing all that =)


-Brian

On Feb 25, 2006, at 12:40 PM, Andrus Adamchik wrote:


Hi Yoav,

We've actually looked at the DB option (and are still open to it as  
a second choice). The reasoning behind the TLP proposal is that  
Cayenne has quite some history as an open source project and we  
have a number of subprojects that may not fit into the DB community  
scope as there is no database involved.


Cayenne is all these things:

* An object relational mapping framework (ORM). This part similar  
in functionality to OJB.
* A framework for remote objects persistence (user API similar to  
ORM, but no DB on the backend). I am not even sure how to classify  
that ... persistence through web services (??)

* UI tools (ORM tools and tools for object to UI binding)
* [still in the early stages] JPA implementation (JSR-220) - this  
is another ORM API, but IMO within Apache it has most synergy with  
Geronimo.


In fact we've already presented our proposal to the DB community,  
and the consensus seems to be that TLP is a better option:


http://www.mail-archive.com/general@db.apache.org/msg00247.html

Andrus


On Feb 25, 2006, at 11:17 PM, Yoav Shapira wrote:


Hola,
db.apache.org might be a better place for Cayenne than a TLP, no?
It's similar to OJB...

Yoav

On 2/25/06, Andrus Adamchik [EMAIL PROTECTED] wrote:

Hi folks,

We at Cayenne project (http://objectstyle.org/cayenne) would like to
join Apache. We wrote a proposal draft that can be viewed here:

http://objectstyle.org/confluence/display/CAY/ASF+Proposal

Brian McCallister volunteered to help us as a mentor. And now we  
need

a Sponsor. I understand that for TLP a sponsor must be either
Incubator PMC or the ASF Board. I am asking for advice on how we can
go about that.

Thanks
Andrus



--
Andrei (aka Andrus) Adamchik
Cayenne Persistence Framework
Lead Architect
http://objectstyle.org/cayenne/



 
-

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





--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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




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

Re: [VOTE] Incubator PMC to approve the 4.0-M4 release of ActiveMQ

[Brian McCallister]

+1

-Brian

On Feb 17, 2006, at 10:09 AM, James Strachan wrote:

In accordance with the incubator release procedure (see below) the  
ActiveMQ community has voted on and approved a proposal to release  
the 2nd candidate of the 4.0-M4 release.
We would now like to request the permission of the Incubator PMC to  
perform the release.


Thanks
James

Proposal:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200602.mbox/[EMAIL PROTECTED] 
%3e


Vote result:
8 +1s, no -1

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0-M4/ 
distributions/


Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Here's my +1

James
---
http://radio.weblogs.com/0112098/


-
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: [VOTE] approve a milestone release of ActiveMQ?

[Brian McCallister]

+1

On Jan 30, 2006, at 12:06 AM, James Strachan wrote:

On the developer list the committers voted to create a milestone  
release of ActiveMQ...
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200512.mbox/[EMAIL PROTECTED]


then the committers voted to approve the distro
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200601.mbox/[EMAIL PROTECTED] 
%3e


the results were 8 +1s and no -1s.

You can download and review the distro here
http://people.apache.org/~chirino/incubator-activemq-4.0-M4/

So based on the incubation guidelines
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

I'd like to ask the Incubator PMC to approve the release
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

[ ] +1 Release the binary as 4.0-M4
[ ] -1 Veto the milestone release (provide specific comments)

Incidentally those interested in the incubation status can view the  
status here

http://wiki.apache.org/geronimo/ActiveMQ_Incubation


Here's my +1

James
---
http://radio.weblogs.com/0112098/


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

Removing Axion Resources

[Brian McCallister]

The DB PMC would like to ask that the Axion incubation resources be  
removed and that Axion no longer be considered in incubation.


-Brian McCallister

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

Re: [VOTE] Changes to Incubator process(es)

[Brian McCallister]

On Jan 11, 2006, at 6:28 AM, Davanum Srinivas wrote:

[ -1 ] - Any proposal should hit [EMAIL PROTECTED] first, No PR  
before that.


[ -1 ] - Any PR should be vetted by PRC, No Excuses.


If this includes blogging about it (which recently was an issue) then  
it won't work, regardless of what we want. This is addressing a real  
problem, but is not an enforceable option unless we know what PR  
means, and No Excuses is insufficient as it implies any  
communication with the public, which simply won't work.


A bad solution to a problem is not a solution and creates barriers to  
a good solution.


[ -0 ] - Any new proposal should have 3 ASF Members / Officers as  
mentors

(without regard to affiliation)


Current ASF projects which have less than that now. A mentor who  
isn't a contributor is probably a bad idea, so what does it say if  
current projects fail incubator requirements?



[ -1 ] - Any new proposal should list at least one person as a
infrastructure volunteer.


Nice in theory, not doable in practice. Should be strongly encouraged  
to help with infrastructure, but no way it should be a requirement.


[ -1 ] - A sponsoring PMC should hold their VOTE to sponsor a  
proposal or

IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED]


PMC sponsors projects to the incubator. Let the PMC talk it over  
ahead of time and decide on a course of action.


[ -0 ] - Any existing committer from any Apache project should be  
able to

volunteer to work on the proposed project within the 72 hours. Any
later, it would be through regular karma process. (To promote
inclusion/diversification from day one)


I think this is a bad solution to a real problem. I don't have a  
better solution at the moment.



[ -1 ] - IP Clearance needs to be preceded by a proposal posted to
[EMAIL PROTECTED] as well


A PMC isn't allowed to discuss wanting to bring code in?

[ +1 ] - IP Clearance has to be OK'ed by Incubator PMC VOTE (before  
code

gets checked in to a sponsoring project's SVN)


Isn't this required now?


[ -1 ] - Petition the Board to require Incubator PMC VOTE to begin
incubation process even for projects that other PMC's want to sponsor.


This removes the ability for PMC's to bring code in. Where do we draw  
the line between code donations and patches?




[ -1 ] - Within 72 hours of a new project hitting the  
[EMAIL PROTECTED]

mailing list, that any incubator PMC member can call for an advisory
vote and comment period if they see issues with what's been presented
by the sponsoring PMC.


They can do this now, how is it a change?

-Brian

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

Re: [VOTE] accept Solr into incubator

[Brian McCallister]

+0 (would be +1 but I am trying not to +1 anything which I cannot  
commit time to help with)


I will use it, though =)

-Brian


On Jan 10, 2006, at 1:38 PM, Yoav Shapira wrote:


Hi,
+1 from me.

Yoav

On 1/10/06, Otis Gospodnetic [EMAIL PROTECTED] wrote:

This is as clear as day: +1.

Otis


- Original Message 
From: Doug Cutting [EMAIL PROTECTED]
To: general@incubator.apache.org
Sent: Tue 10 Jan 2006 12:21:49 PM EST
Subject: [VOTE] accept Solr into incubator

I propose that we accept the CNET's Solr project into the incubator.

Discussion on this list evidenced broad interest in this project,  
which

bodes well for its ability to build a developer community.

The Lucene PMC would be happy to accept Solr as a Lucene sub-project
once it graduates from the incubator.

The proposal is at:

http://wiki.apache.org/incubator/SolrProposal

+1

Doug


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





--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

-
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: [PROPOSAL] Solr

[Brian McCallister]

I know of at least half a dozen private implementations of exactly  
this. I definitely would like to see some common cause oon it.


Will read proposal in more detail tomorrow morning!

-Brian

On Jan 3, 2006, at 7:19 AM, Yonik Seeley wrote:


Hello Incubator PMC folks,

I would like to propose a new Apache project named Solr.
http://wiki.apache.org/incubator/SolrProposal
The project is being proposed as a sub-project of Lucene, and the
Lucene PMC has agreed to be the sponsor.

-Yonik


'''Proposal for new project Solr '''

Yonik Seeley -- yonik at apache dot org


'''(0) rationale'''

Solr is a search server based on Apache Lucene and focused on
full-text search, relevancy, and performance.

Some of the server features include:
   * Query and update interfaces over HTTP and XML.
   * Replication based on index snapshots and rsync.
   * A schema allowing declarative specification of fields and their
types, including specification of text analysis filter chains.
   * External configuration for Lucene parameters, stopword lists, and
synonym lists.
   * A web based admin interface with statistics and debugging.
   * An extensive caching framework for filters, queries, documents,
and user caches.
   * Plugins for customizing query handling, caching and many other
server aspects.

Solr is currently an internal CNET project, and is used to power
search and faceted browsing in a number of CNET sites.

'''(0.1) criteria'''

''Meritocracy: ''

Solr's developers are comfortable operating as a meritocracy.

''Community: ''

Establishing an active open source community will be the top priority.

''Core Developers:''

Solr starts with three committers.

''Alignment:''

Solr currently uses the following Apache projects: Ant, Lucene.

'''(0.2) warning signs'''

''Orphaned products: ''

Solr is not an orphan, use within CNET is growing rapidly.

''Inexperience with open source:''

Solr's committers are experienced with open source and have made
contributions to other open source projects.

''Homogenous developers:''

Solr's initial committers are all CNET employees since it's currently
an internal project.

''Reliance on salaried developers:''

Some committers are currently paid to make contributions to Solr.

''No ties to other Apache products:''

Solr has strong ties to Lucene.

''A fascination with the Apache brand:''

The committers respect the Apache brand and feel that Apache is the
right place to generate a strong open source community.

'''(1) scope of the subprojects'''

The scope of the project is to provide a stand-alone full-text  
search server.
The proposal is that this project become a sub-project of Apache  
Lucene.


'''(2) identify the initial source from which the subproject is to be
populated'''

CNET will donate the initial source code for this project.

'''(3) identify the ASF resources to be created '''


'''(3.1) mailing list(s) '''

 * solr-dev
 * solr-user

'''(3.2) Subversion or CVS repositories'''

 * https://svn.apache.org/repos/asf/incubator/solr

'''(3.3) Jira '''

 * Solr (SOLR)

'''(4) identify the initial set of committers '''

 * Yonik Seeley, CNET (Lucene committer)
 * Bill Au, CNET
 * Chris Hostetter, CNET

'''(5) identify apache sponsoring individual '''
 * Doug Cutting, Champion
 * Lucene PMC, Sponsor
 (as defined in
http://incubator.apache.org/incubation/ 
Roles_and_Responsibilities.html)


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

JDO2 Snapshots

[Brian McCallister]

Is it okay for the (incubating) jdo project to post snapshots to the  
maven repository at ibiblio via the cvs.apache.org repo?


The only catch is figuring a good way to label it as in incubation.  
One option is to include it the artifact id, so it would be something  
like:


jdo2-incubating-2.0-SNAPSHOT

Any thoughts?

-Brian

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

Re: [RESULT] [VOTE] Graduate Derby as sub-project of Apache DB

[Brian McCallister]

On Jul 26, 2005, at 11:21 AM, Jeremy Boynes wrote:


So what happens now? :-)

Logistical details that come to mind are:
* adding Derby committers to the DB PMC - I assume a vote on who to  
add

  takes place on the DB PMC list, is this in progess?


yes.

Cannot comment on the rest =)

* moving the SVN root under the DB project and granting Derby  
committers

  karma to the appropriate trees there
* updating the project pages in Incubator to reflect graduation
* updating the project web site to reflect the move under DB
* updating the DB website to reflect the new subproject
* change the JIRA category from Incubator to DB
* no change to the mailing lists as they already point to  
db.apache.org


I'm sure I've missed some stuff - anyone else?
Volunteers?

--
Jeremy

Daniel John Debrunner wrote:


Daniel John Debrunner wrote:


So please vote on graduating Derby to a sub-project of Apache DB.


Passed with eleven (11) +1 votes (including one ++1 vote :-)
Three (3) members of the Incubator PMC voted +1 (Noel, Geir, Roy)
Three (3) members of the DB-PMC voted +1 (Brian, Geir, Henning).
Thanks,
Dan.



-
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: [VOTE] Graduate Derby as sub-project of Apache DB

[Brian McCallister]

+1 (derby ppmc and db pmc hats on)

-Brian

On Jul 20, 2005, at 8:40 PM, Daniel John Debrunner wrote:


Noel said that rather than hassling the Incubator PMC members for
release approval, we should just graduate!

So please vote on graduating Derby to a sub-project of Apache DB.

The developer community continues get the Apache Way and its diversity
has increased since the last graduation vote (where it got good  
reports).


We've added five new committers during incubation based upon their
contributions, which gives us committers from three independent  
entities.


We've performed two releases (though the latest is waiting approval  
from

the incubator PMC :-)

DB-PMC has discussed the inclusion of a sub-set of Derby PPMC members.

DB-PMC has voted to accept the project (see status file)
http://incubator.apache.org/projects/derby.html

-

My vote +1.

Thanks!
Dan.


-
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: [VOTE] Derby 10.1 incubating release

[Brian McCallister]

+1 (non-binding)

-Brian

On Jul 16, 2005, at 9:39 AM, Andrew McIntyre wrote:


Hello Incubator,

On behalf of the Derby development community, I'd like to request
permission to post the files you can find here:

http://people.apache.org/~fuzzylogic/derby_10.1/

as an incubating release on the Derby website. The big news for this
release is the contribution of the network client driver for Derby to
Apache.

Here is a link to the vote on derby-dev:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/% 
[EMAIL PROTECTED]


and the final result:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/% 
[EMAIL PROTECTED]


Please vote with your approval if you find the release archives  
satisfy the guidelines for incubating releases as described here:


http://incubator.apache.org/incubation/ 
Incubation_Policy.html#Releases%0D


and that no other potential issues as regards incubating releases  
are discovered.


Many thanks,
Andrew McIntyre


-
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: Proposal for STDCXX

[Brian McCallister]

Big +1 (non-binding)
-Brian
On May 13, 2005, at 5:27 PM, Heidi Buelow wrote:
Proposal for an Apache-run version of the C++ Standard Library
Submission date: 12 May 2005, Tim Triemstra, Heidi Buelow (TimT @  
RogueWave
dot-com, Buelow @ RogueWave dot-com)

(0) rationale
The goal of the Apache C++ Standard Library project is to provide a  
free
implementation of the ISO/EIC 14882 international standard, often  
called the
STL or stdlib, which is consistent and portable across all major
platforms and compilers. For the sake of this proposal, the project  
will be
called STDCXX to blend in with other Apache names.

Currently, C++ developers spend considerable effort porting code among
platforms, as compiler vendors are focused on backward  
compatibility rather
than cross-platform portability. There are other free  
implementations, but
none have the quality, license flexibility, or platform support  
necessary to
serve as a universal foundation for the C++ language.

Rogue Wave Software will jump start this project by contributing the
commercial C++ Standard Library it has been shipping for over a  
decade. This
is a new, enhanced version of the OEM library provided by many  
vendors,
including ARM, Sun Microsystems, HP and others. Unique attributes  
include:

Complete compliance with the C++ standard
Complete implementation of locale library (not OS dependant)
User control over strict or loose standards compliance
Largest test suite of any major implementation
High performance
Reference counted basic_string using atomic locking
Thread-safety, including iostream and locale objects
Fast compiles and extremely small executable file sizes
Proven, portable, and fully tested on each platform
Many platforms (Windows, Linux, Solaris, HP-UX, AIX, etc.)
Platform-specific compilers (eg: MSVC, Sun Forte, HP aCC, GCC)
Fully configurable and documented build control
Ten years of deployment in the world's most critical systems
Highly respected documentation, well maintained and up to date
The day the project is launched, it will already provide the strongest
foundation library for the C++ language available, both in terms of  
platform
and standards support.

(0.1) criteria
Meritocracy: The STDCXX project should adhere to the same open,  
merit-based
community standards as other Apache projects, while also closely  
tracking
the relevant C++ standards.

Contributions and Core Developers: The initial code contribution  
will be a
fully-functional implementation of the ISO/EIC 14882 international  
standard,
including the Standard Template Library (STL), locales, and iostreams
libraries. As each platform's build system is packaged, additional  
ports
will be contributed.

As a side note, Rogue Wave Software intends to continue  
distributing the
library as part of its SourcePro/C++ product well into the future.  
This
means that significant effort will continue, especially in porting,  
and that
effort will directly benefit the open source community since even code
developed to meet commercial requirements will be contributed back  
into the
community.

Community: We estimate there are over 300,000 developers using the  
original
commercial code, and several have already expressed interest in  
becoming
contributors. This established, loose-knit group of users exposed  
to the
existing code base via OEM or as direct customers should ensure a  
vibrant
community once the open source project is started.

It is likely that the Apache C++ Standard Library would be a desirable
project to be used by other Apache projects as a foundation to ensure
excellent performance and easy portability across platforms. It can  
serve
many of the same goals as the existing APR project, but directly  
address the
needs of C++ developers. Those other projects will be encouraged to  
actively
participate in the library's community as well.

Apache Alignment: With the success of open/free software, C/C++ has  
seen a
bit of a revival as a popular language for its portability, power, and
performance. In fact, Apache has a considerable number of key  
projects based
on these languages. These projects and the entire developer  
community at
large would benefit from a C++ standard implementation from a  
trusted source
such as Apache. Without such a respected organization behind the  
project,
developers will have to constantly choose a less-portable solution,  
or a
solution more risky due to a small user community.

(0.2) known risks
Orphaned Products: One of the first questions when a commercial entity
offers code to the public is will this code be abandoned? To be  
clear,
Rogue Wave decided to initiate this process due to its own desire to
stabilize the C++ market, making the creation of higher-level products
easier and more portable. For a long time the contributed code has  
served
primarily as a foundation for other commercial products, not as  
revenue
producer on its own. Regardless of Apache's interested in the  
project, Rogue
Wave 

[OT] Re: [VOTE] Graduate Derby from the incubator

[Brian McCallister]

On Apr 22, 2005, at 2:16 PM, Daniel John Debrunner wrote:
Pity my Derby internals proposal was rejected by Apachecon Europe :-)
Would you consider doing it as a BOF if you will be there? I would like 
to attend it!

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

Re: [VOTE] Graduate Derby from the incubator

[Brian McCallister]

To clarify my statement on project dependencies:
I think that Derby has already grown a large and diverse community 
around itself, and that is important to consider as well. Projects 
dependent upon derby, be they ASF or otherwise, have a significant 
second-order effect on the project's truck number. Other ASF projects 
dependent on Derby are a useful metric here as we are familiar with 
those projects, to a greater or lesser degree.

Things Derby depends on (except from the licensing and technical points 
of view) are not particularly relevant to estimating Derby's viability 
(1), but things dependent upon Derby are quite relevant to estimating 
Derby's viability. If you throw away good will and solely base 
motivation on need, projects which have healthy communities which rely 
on Derby are strongly motivated to help maintain Derby -- if the 
current maintainers are incapable of doing so (otherwise most people 
are happy to work on their own stuff).

That is the point I was awkwardly wandering towards. It is *not* a 
substitute for the contributor/committer pool on the project itself, 
but it is a relevant measure of the developer community invested in 
Derby.

-Brian
On Apr 3, 2005, at 11:51 AM, Brian McCallister wrote:
On Apr 3, 2005, at 11:02 AM, Rodent of Unusual Size wrote:
At least one person from the DB PMC has voted in favour of graduation,
which I hope means that the project understands the issues of
assuming oversight and feels comfortable doing so.  Having more
people from the DB PMC/project weigh in on the vote would be
nice. :-)
DB PMC hat on:
The only thing weighing on me about graduating Derby is that all the 
committers, but one, work for the same employer. There are a number of 
other folks under consideration, but they aren't committers (yet, 
hopefully).

Ken makes a good point about it not being a TLP, and the DB PMC 
prodding the developer community growth. I have to agree with this 
argument, especially when I put it next to the DdlUtils project 
(commons-sql) with, er, two committers.

Derby depends on nothing else at Apache (except ant for its build), 
and is depended on by nothing else at Apache. This is *good* from a 
technical point of view, but is a weakness from a community health 
point of view.

To use DdlUtils as an example again, despite that project having only 
two (active) committers on the project, another Db project, OJB is 
dependent on the project (which is a big chunk of the reason we want 
to get it out of the commons sandbox), and has a strong motivation 
therefore to keep it going. OJB has a pretty good sized committer 
base, and has already pushed past the ~retirement of the initial 
project leader (who still pokes his head in on big design issues, but 
is otherwise pretty much inactive). So, despite DdlUtils having a 
small committer base when aiming for the same level in the ASF 
hierarchy (subproject), it has a much larger developer community 
strongly motivated to maintain it, even if they are not committers on 
it now.

Derby has a much larger committer base, but that committer base is 
rather homogenous by ASF standards. No other ASF projects I am aware 
of (except maybe Geronimo?) actually use Derby right now, or use it in 
such a way that swapping out to HSQLDB isn't trivial. This lack of 
dependency is good, technically, but does not build a strong community 
support system (if all the BeanUtils committers were hit by trucks, 
there is no real doubt that other Struts folks would step in 
immediately).

DB PMC hat off:
I don't doubt the long-term viability of Derby. It is a great project 
which works well, and has a responsive and growing developer 
community. Even if the IBM committers were to be informed they were no 
longer allowed to contribute under terms of their employment, I am 
confident that despite the slowdown that would occur, the developer 
community would step up (the db pmc would just need to do more work in 
the interim).

I don't know official ASF policy on subproject acceptance (if there 
even is such a thing), so have timeboxed my voting decision so that I 
can learn more before having to chime in =)

-Brian
-
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]