[RESULT] [VOTE] Glasgow accepted for incubation

[Cliff Schmidt <cl...@gmail.com>]

The Glasgow proposal vote has passed with:
6  binding +1s, 2 binding 0s, and 2  binding -1s.

There were also 5 non-binding +1s and 2 non-binding -1s.

It looks as though the committers are reaching consensus in a separate
thread on changing the project name, in response to some proper-name
concerns.  I suggest they hold off on requesting project resources if
the currently-proposed name appears to be getting traction; otherwise,
just pick anything without a registered software trademark to get the
project started and debate the name during incubation.

Cliff

On 8/10/06, Cliff Schmidt <cl...@gmail.com> wrote:
> 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 <cl...@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

RE: [RESULT] [VOTE] Glasgow accepted for incubation

["Noel J. Bergman" <no...@devtech.com>]

Cliff,

> The Glasgow proposal vote has passed with:
> 6  binding +1s, 2 binding 0s, and 2  binding -1s.
> There were also 5 non-binding +1s and 2 non-binding -1s.

So 11 +1 and 4 -1.  That passes by a fairly large majority, BUT the concerns
of the dissenters should be addressed.  The major one appears to be the
handling of the IP.  I've separately started a thread on specification
projects, which I hope could be a solution.

	--- Noel



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