Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of cliffschmidt@gmail.com
 designates 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z5yBQTXDHYneIajQlHpPbEIHZT6apKOb20t58TSHRc9fznX+KyhC3JOVnGPaV010wa1wK2sKNF1OWc117V1WDtd8fKT9qdslxBzAa1wqOIJYLZ0LhxUA65Pat7YJ9NHmeZazmlIK2syyTBZy6RHIJzXmfLGcLYlLnCk0u1tD2uc=
Message-ID: <c5e632550608101632ldc2a03ck462b7cf8e22c3f9f@mail.gmail.com>
Date: Thu, 10 Aug 2006 16:32:02 -0700
From: "Cliff Schmidt" <cliffschmidt@gmail.com>
To: general@incubator.apache.org
Subject: Re: [VOTE] Accept Glasgow into Incubator
In-Reply-To: <c5e632550608030952y40db6ebeu216cfe8564e93fe3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c5e632550608030952y40db6ebeu216cfe8564e93fe3@mail.gmail.com>

The official vote closed three days ago, but I didn't want to close it
out while discussions were still going, especially when there were
binding -1s involved.  While a -1 does not veto a proposal, it is
important to make sure that anyone who has a concern has had a chance
to make it heard or clarify it.

The vote currently stands at: (6) +1s, (1) +/-0, and (2) -1s.

With these results, the proposal would be accepted for incubation.
However, since there has been quite a bit of discussion during the
voting and two standing -1s, I'd like to give one last call for any
additional votes or changed votes, and extend the voting period just
another 24 hours to Saturday, August 12th 00:00 UTC / Friday, August
11th 17:00 PDT (see
http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=12&year=2006&hour=00&min=0&sec=0&p1=0).

Please submit any last votes now, and I will send out the final
results shortly after the new closing time.  Also, for those
interested in a summary of who voted what so far, see below.

Thanks,
Cliff

Binding +1
Dims, Jason, Jim, JAaron, Susan, Robert
Paul stated support for the project and offered to mentor, but did not
officially vote.

Binding +/-0
Bill

Binding -1s:
Garrett, Brian

----

Non-binding +1:
Matthias, Craig Russell, Coach, Kim, Adi

Spec process concerns (without voting):
Mads, Leo

Name concerns:
Danny (non-binding -1), Rich (no vote)


On 8/3/06, Cliff Schmidt <cliffschmidt@gmail.com> 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=8&day=7&year=2006&hour=17&min=0&sec=0&p1=0)
>
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=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 protocols are a unique contributor to the success of
> Apache's project communities and we are eager to learn from our
> Incubator mentors so that we can evolve Glasgow into a healthy and
> sustainable community.
> === Core Developers: ===
> Most of the initial committers are members of Red Hat, IONA, and JP
> Morgan Chase's (JPMC) development teams. Additional developers will be
> added through the Apache community process.
> === Alignment: ===
> An initial implementation has been written in Java and C++, which will
> be refactored into this project to form the initial code base.  We
> have had a few exploratory conversations about integration with
> individuals of other communties such as Apache Geronimo, Tuscany,
> ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards
> future collaboration with these communities. Our current
> implementation makes extensive use of projects from the Apache Jakata
> Commons, Mina and other Apache infrastructure projects. A
> compatibility binding for JMS also exists. It is however important to
> note that this is NOT a JMS project and aims to solve a different
> problem space, providing language and platform independent and
> interoperable messaging, driven by a protocol specification which may
> ultimately be commoditized in hardware.
>
> The scope of the project is broader than just Java and C++ as the
> project will also look at providing bindings in other languages such
> as PHP and Python.Additionally, bindings have already been created for
> test automation.
> As Glasgow's broad goal is to create a standardized, widely available,
> and  interoperable messaging solution based on the AMQP protocol,
> there are numerous potential collaboration opportunities with many
> other Apache projects including:
>  * Transport support for Geronimo
>  * Interoperability integration with ActiveMQ(JMS)
>  * Integration with Axis for SOAP messaging over an asynchronous transport
>  * Language/platform neutral interoperable messaging for projects
> like Synapse and ServiceMix
>
> == AVOIDING THE WARNING SIGNS ==
> === Orphaned products: ===
> The initial code submission is based on active code developed and we
> believe that through its continued evolution in an open community will
> lead to a stronger, more widely accepted foundation for development of
> middleware and be valuable to many other Apache and community
> projects.
> === Inexperience with open source: ===
> Many of the initial committers have experience working on open source
> projects and several are committers on other Apache projects. Each of
> the companies involved in the initial submission has prior success
> building or contributing to open source projects. Moreover, some of
> the initial companies involved focus exclusively on developing open
> source software.  This depth and diversity of experience fosters a
> deep understanding of managing and running open source projects.
> === Homogenous developers: ===
> The current list of committers includes developers from several
> different companies who are geographically distributed across the U.S.
> and Europe. They are experienced with working in a distributed
> environment and with resolving technical differences outside the scope
> of a common employer.
> === Reliance on salaried developers: ===
> Most of the initial developers are paid by their employers to
> contribute to this project; however, this submission includes
> employers with track records for ongoing investment in open source
> communities (including Apache, Eclipse, ObjectWeb and Fedora).
> === No ties to other Apache products: ===
> As described in the Alignment section,this framework already leverages
> existing Apache projects. by making use of  other Apache projects for
> infrastructure building blocks. The initial codebase will be licensed
> under the Apache License 2.0.
> === A fascination with the Apache brand: ===
> The committers are intent on developing a strong open source community
> around what we hope will be a best-in-class, enterprise-grade high
> performance messaging framework.  We believe that the Apache Software
> Foundation's emphasis on community open development makes it the most
> suitable choice for such a project. We understand that the Apache
> brand has become synonymous with the values of quality, meritocracy,
> and community, and we endeavor to make our project worthy of such an
> affiliation. We also commit to working proactively with the Public
> Relations Committee to ensure that any marketing or promotional
> activities we pursue are in compliance with the ASF's policies.
>
> == SCOPE OF SUBPROJECTS ==
> The initial contributors envision an active community of related
> projects sharing a common of commodity and interoperable middleware
> but targeting specific technical areas:
> Glasgow will be seeded with several projects based on donated material
> (see the next section):
>  * a Java implementation of the wire level framing
>  * a C++ implementation of the wire level framing
>  * a Java implementation of a broker
>  * a Java implementation of a JMS interface
>  * a C++ implementation of a portability layer, which will be
> refactored to be pluggable
>  * an implementation of the broker with will be refactrored into C++,
> for existing work and possible use of GCJ
> To assist in community building, the committers have identified
> several key technology areas that will allow new contributors points
> of entry to actively engage in the project. These include:
>  * integration with other Apache projects (Tuscany, ActiveMQ,
> ServiceMix, Apache Axis)
>  * integration with security and both local and distributed transactions (XA)
>  * support heterogeneous API bindings in C, C++, Java, PHP, Python and BPEL
>  * support for cross memory or RDMA transports
>  * support for in process IPC clients or IPC transport bindings
>  * support for broadcast and relay from PGM <--> AMQP
>  * integration with payload marshilling toolkits
>  * Declarative policy based API's
> These initial projects are intended merely as starting points and
> should not be taken as bounding the scope of the Glasgow project as a
> whole. Some other potential projects may include:
>  * Integration with rich middleware frameworks (such as Celtix or ServiceMix).
>  * Support and integration of Security.
>  * Management tools.
>  * Support for additional class frames such as tunneling
>
> == INITIAL SOURCE ==
> A group of companies are developing a set of specifications relating
> to the creation of commodity enterprise class messaging, collectively
> called Advanced Message Queuing Protocol (AMQP). In progress versions
> are available at:
>  * http://www.envoytech.org/spec/amqp/
>  * http://www.iona.com/opensource/amqp/
>  * http://www.redhat.com/solutions/specifications/amqp/
>  * http://www.twiststandards.org/tiki-index.php?page=AMQ
>  * http://www.faqs.org/rfcs/rfc3208.html
>
>
> The initial contributors have been developing Java and C++ code bases
> (licensed under the Apache License 2.0) which implement aspects of
> these specifications, and intend to donate it to Apache. The current
> working svn is available at:
> https://etp.108.redhat.com/source/browse/etp/trunk/blaze
>
> Although the Glasgow project expects to bootstrap using these
> materials and in the case of specifications, to provide feedback that
> will be incorporated into their ongoing development, we expect and
> encourage the open source community to take the project in new
> directions not envisioned by them to create a world class
> implementation of the AMQP specification and related technologies.
>
> == Interactions with the specifications ==
> The specification is being developed by group of companies, under a
> contract that requires the resulting work to be published to a
> standards body. This model has been chosen to assure that anyone that
> contributes to the specification grants a copyright and patient
> license to all contributions made to the specification on every
> publication (draft or final). This ensures that the specification will
> always be open and implementable by anyone without royalties or
> commercial limitations. We feel that this is a very strong model for
> keeping this work entirely open and will fit well with the Apache
> project enabling innovations to pass in both directions across the
> extended community.
>
> Dealing with feedback from the Glasgow project to specifications
> It is key that the best implementation and specifications be created
> based on technical merit and practicalities for adoption by both the
> parties developing the specification and the committers within the
> Apache community. Given this, one of the important aspects is how
> issues discovered during the development of this implementation are
> incorporated back into the specifications.  The following feedback
> loop exists to ensure that any specification input incuding the
> Glasgow community can have their feedback incorporated into the
> specifications.
> === MECHANISMS FOR FEEDBACK ===
> a.) In the same way anyone can issue a JIRA on any Apache project
> having signed the Apache CLA, anyone can issue a "JIRA" to the
> specification working group through the RLA (Reviewer License
> Agreement). This agreement provides a license to that IP so that the
> specification team can incorporate it and the specifaction as they
> like and the specifications can remain entirely open and royalty free.
> b.) In the same spirit of Apache, if an individual has shown
> understanding of the project and substantive contribution to the
> specification, a vote based on technical merit and understanding of
> the goals of the work can be initiated to have that parties Employer
> join the specification working group. On such acceptance the employer
> is required to sign an agreement to make sure that employer also
> grants the ongoing and consistent licenses to the work as posted in
> specifications.
>
> The Reviewer License Agreement (RLA) can be viewed from the AMQP
> specification page of any of the members as listed above.
>
> == ASF resources to be created ==
> mailing list(s)
>  * glasgow-dev
>  * glasgow-commits
> Subversion repository
>  * https://svn.apache.org/repos/asf/incubator/glasgow
> Jira
>  * Glasgow (GLASGOW)
>
> === INITIAL COMMITTERS ===
>  * Rajith Attapattu (Red Hat)
>  * Mark Atwell (JPMC)
>  * Bela Ban (Red Hat)
>  * Bhupendra Bardwaj (JPMC)
>  * Alan Conway (Red Hat)
>  * Tejeswar Das (IONA)
>  * Ovidiu Feodorov  (Red Hat)
>  * Tim Fox (Red Hat)
>  * Paul Fremantle (WSO2)
>  * Eoghan Glynn (IONA)
>  * Robert Greig (JPMC)
>  * Chamikara Jayalath (WSO2)
>  * Sam Joyce (IONA)
>  * John O'Hara (JPMC)
>  * Frank Lynch (IONA)
>  * Marnie McCormack (JPMC)
>  * Martin Ritchie (JPMC)
>  * Rafael Schloming (Red Hat)
>  * Archit Shah (Red Hat)
>  * Stephen Shaw (JPMC)
>  * Gordon Sim (Red Hat)
>  * James Strachan (LogicBlaze)
>  * Manik Surtani (Red Hat)
>  * Paul Taylor (IONA)
>  * Carl Trieloff (Red Hat)
>  * Kim van der Riet (Red Hat)
>  * Steve Vinoski (IONA)
>  * Sergey Yedrikov (IONA)
>
> === APACHE SPONSOR ===
> The Glasgow team will make the submission to the incubator as the
> sponsor for incubation.
>
> Champion
>  * Cliff Schmidt (consultant to Red Hat)
> Mentors:
>  * James Strachan
>  * Cliff Schmidt (consultant to Red Hat)
>  * Paul Fremantle
>

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