[VOTE] Accept Glasgow into Incubator

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

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

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

Cliff, so it is not lost (I switched subjects to a discussion forum that,
oddly, you have not responded to) ...

I'm sorry, but respectfully -1 this proposal as written.  My specific objection
is to the language below, I don't see anything otherwise objectionable in the
proposal.

[c.f. the Re: Accept Glasgow into Incubator - Spec Terms thread which only
Carl has partly responded to.]

which is my vote on your call for acceptance.

Bill

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

Re: [VOTE] Accept Glasgow into Incubator

[Craig L Russell <Cr...@Sun.COM>]

+1 (non-binding) from me.

Craig

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

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: [VOTE] Accept Glasgow into Incubator

[Matthias Wessendorf <ma...@apache.org>]

+1 (non-binding) from me too

On 8/3/06, Davanum Srinivas <da...@gmail.com> wrote:
> +1 from me.
>
> 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
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

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

Re: [VOTE] Accept Glasgow into Incubator

[Davanum Srinivas <da...@gmail.com>]

+1 from me.

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


-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

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

Re: [VOTE] Accept Glasgow into Incubator

[Adinarayana Sakala <ad...@gmail.com>]

+1 (non-binding).

-Adi

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


-- 
Adi Sakala
http://celtix.objectweb.org

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

Re: [VOTE] Accept Glasgow into Incubator

[Kim van der Riet <ki...@redhat.com>]

+1 (non-binding)

On Thu, 2006-08-03 at 09:52 -0700, 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=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
> 

Re: Accept Glasgow into Incubator - Spec Terms

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

William A. Rowe, Jr. wrote:
> I'm sorry, but respectfully -1 this proposal as written.  My specific objection
> is to the language below, I don't see anything otherwise objectionable in the
> proposal.
> 
> The ASF does not recognize corporate members; all of our contributions are
> measured on an individual basis and individual merit.
> 
> This proposal under the "Mechanisms for Feedback" and ultimate participation
> by the appropriate parties sends us down entirely the wrong track and conveys
> the wrong message for an ASF project.
> 
> I have no objection to that standards committee growing more corporate members.
> But to the extent that ASF contributors offer productive growth and formative
> input into the specification, the way this section is phrased is not acceptable.
> If the contributor wish, and if under these terms their contributions merits
> participation, that contributor should either lead the ASF's direct involvement
> as the ASF spec liason (much as we've done within the JCP) or as an individual
> contributor.
> 
> The specific statement "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."
> 
> is an Oxymoron.
> 
> This section of the proposal below is entirely corporate-oriented, and that
> is not what the ASF does.  If this can be addressed, my opinion of this effort
> is otherwise without issues.  One alternative is to modify this as I hint at
> above.  The other alternative is to determine the specific standards body first
> and vote participation up or down based on the body selected.
> 
> Bill
> 
> 
> 
> 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.
> 
> "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."
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 
> 

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

Re: Accept Glasgow into Incubator - Spec Terms

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Carl Trieloff wrote:
> (Correction)
> Looking, at this further the the CCLA is just concerned about IP, I might have
> miss-read and miss-stated. No need to start a thread based on my miss-read.

Right.  The CCLA exists to *protect* that very same individual-contributor
orientation of the ASF.  No matter how we protest, some people's contributions
will always be work-product, and unless they negotiate their contracts to
clearly provide for outside contributions to open source, the CCLA is our
vehicle to facilitate the company's employees' contributions to the ASF.

Bill

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

Re: Accept Glasgow into Incubator - Spec Terms

[Carl Trieloff <cc...@redhat.com>]

(Correction)
Looking, at this further the the CCLA is just concerned about IP, I 
might have
miss-read and miss-stated. No need to start a thread based on my miss-read.

and to

If the contributor wish, and if under these terms their contributions 
merits
participation, that contributor should either lead the ASF's direct 
involvement
as the ASF spec liason (much as we've done within the JCP) or as an 
individual
contributor.

I would love this.

Regards
Carl.


Carl Trieloff wrote:
> The ASF does not recognize corporate members;
>
>
> Incorrect - Apace has a CCLA, and requires your employer to sign it
>
> From icla "
>
> For the purposes of this definition,
>   "control" means (i) the power, direct or indirect, to cause the
>   direction or management of such entity, whether by contract or
>   otherwise, or (ii) ownership of fifty percent (50%) or more of the
>   outstanding shares, or (iii) beneficial ownership of such entity."
>
> and from ccla "
> This version of the Agreement allows an entity (the "Corporation") to
>   submit Contributions to the Foundation, to authorize Contributions   
> submitted by its designated employees to the Foundation, and to grant 
>   copyright and patent licenses thereto."
>
>
> ...
>
> all of our contributions are
> measured on an individual basis and individual merit
>
> correct.
>
> This mail seems to imply that Apache does not require employer to sign
> the CCLA, however I have first had experience that the ASF does 
> require this.
> It seems that the objection is that I chose to be up-front write this 
> down, even
> though the practice is the same at Apache. Without the CCLA there 
> would no patient and
> copyright grants if you are not self employed and just about every 
> employer
> would have claims on Apache code. Thus from a IP perspective, you have to
> recognize the employer. Key point - contributions - individual ICLA. 
> IP - need employer
> CCLA.
>
> Hope that clears it up, regards
> Carl.
>
>
>
> William A. Rowe, Jr. wrote:
>> I'm sorry, but respectfully -1 this proposal as written.  My specific 
>> objection
>> is to the language below, I don't see anything otherwise 
>> objectionable in the
>> proposal.
>>
>> The ASF does not recognize corporate members; all of our 
>> contributions are
>> measured on an individual basis and individual merit.
>>
>> This proposal under the "Mechanisms for Feedback" and ultimate 
>> participation
>> by the appropriate parties sends us down entirely the wrong track and 
>> conveys
>> the wrong message for an ASF project.
>>
>> I have no objection to that standards committee growing more 
>> corporate members.
>> But to the extent that ASF contributors offer productive growth and 
>> formative
>> input into the specification, the way this section is phrased is not 
>> acceptable.
>> If the contributor wish, and if under these terms their contributions 
>> merits
>> participation, that contributor should either lead the ASF's direct 
>> involvement
>> as the ASF spec liason (much as we've done within the JCP) or as an 
>> individual
>> contributor.
>>
>> The specific statement "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."
>>
>> is an Oxymoron.
>>
>> This section of the proposal below is entirely corporate-oriented, 
>> and that
>> is not what the ASF does.  If this can be addressed, my opinion of 
>> this effort
>> is otherwise without issues.  One alternative is to modify this as I 
>> hint at
>> above.  The other alternative is to determine the specific standards 
>> body first
>> and vote participation up or down based on the body selected.
>>
>> Bill
>>
>>
>>
>> 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.
>>>     
>>
>> "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."
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>   
>
>


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

Re: Accept Glasgow into Incubator - Spec Terms

[Carl Trieloff <cc...@redhat.com>]

The ASF does not recognize corporate members;


Incorrect - Apace has a CCLA, and requires your employer to sign it

 From icla "

For the purposes of this definition,
   "control" means (i) the power, direct or indirect, to cause the
   direction or management of such entity, whether by contract or
   otherwise, or (ii) ownership of fifty percent (50%) or more of the
   outstanding shares, or (iii) beneficial ownership of such entity."

and from ccla "
This version of the Agreement allows an entity (the "Corporation") to
   submit Contributions to the Foundation, to authorize Contributions 
   submitted by its designated employees to the Foundation, and to grant 
   copyright and patent licenses thereto."


...

 all of our contributions are
measured on an individual basis and individual merit

correct.

This mail seems to imply that Apache does not require employer to sign
the CCLA, however I have first had experience that the ASF does require 
this.
It seems that the objection is that I chose to be up-front write this 
down, even
though the practice is the same at Apache. Without the CCLA there would 
no patient and
copyright grants if you are not self employed and just about every employer
would have claims on Apache code. Thus from a IP perspective, you have to
recognize the employer. Key point - contributions - individual ICLA. IP 
- need employer
CCLA.

Hope that clears it up, regards
Carl.



William A. Rowe, Jr. wrote:
> I'm sorry, but respectfully -1 this proposal as written.  My specific objection
> is to the language below, I don't see anything otherwise objectionable in the
> proposal.
>
> The ASF does not recognize corporate members; all of our contributions are
> measured on an individual basis and individual merit.
>
> This proposal under the "Mechanisms for Feedback" and ultimate participation
> by the appropriate parties sends us down entirely the wrong track and conveys
> the wrong message for an ASF project.
>
> I have no objection to that standards committee growing more corporate members.
> But to the extent that ASF contributors offer productive growth and formative
> input into the specification, the way this section is phrased is not acceptable.
> If the contributor wish, and if under these terms their contributions merits
> participation, that contributor should either lead the ASF's direct involvement
> as the ASF spec liason (much as we've done within the JCP) or as an individual
> contributor.
>
> The specific statement "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."
>
> is an Oxymoron.
>
> This section of the proposal below is entirely corporate-oriented, and that
> is not what the ASF does.  If this can be addressed, my opinion of this effort
> is otherwise without issues.  One alternative is to modify this as I hint at
> above.  The other alternative is to determine the specific standards body first
> and vote participation up or down based on the body selected.
>
> Bill
>
>
>
> 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.
>>     
>
> "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."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   

Re: Accept Glasgow into Incubator - Spec Terms

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

I'm sorry, but respectfully -1 this proposal as written.  My specific objection
is to the language below, I don't see anything otherwise objectionable in the
proposal.

The ASF does not recognize corporate members; all of our contributions are
measured on an individual basis and individual merit.

This proposal under the "Mechanisms for Feedback" and ultimate participation
by the appropriate parties sends us down entirely the wrong track and conveys
the wrong message for an ASF project.

I have no objection to that standards committee growing more corporate members.
But to the extent that ASF contributors offer productive growth and formative
input into the specification, the way this section is phrased is not acceptable.
If the contributor wish, and if under these terms their contributions merits
participation, that contributor should either lead the ASF's direct involvement
as the ASF spec liason (much as we've done within the JCP) or as an individual
contributor.

The specific statement "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."

is an Oxymoron.

This section of the proposal below is entirely corporate-oriented, and that
is not what the ASF does.  If this can be addressed, my opinion of this effort
is otherwise without issues.  One alternative is to modify this as I hint at
above.  The other alternative is to determine the specific standards body first
and vote participation up or down based on the body selected.

Bill



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.

"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."

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

Re: [VOTE] Accept Glasgow into Incubator

[Leo Simons <ma...@leosimons.com>]

On Thu, Aug 10, 2006 at 04:32:02PM -0700, Cliff Schmidt wrote:
> Spec process concerns (without voting):
> Mads, Leo

Let the record show the concerns are more broad than about a "spec
process". But, as my later rant hints at, I don't see a real reason
to cause any more stir about any of this *now*; rather it is something
we should "soulsearch" more. In the meantime I do wish glasgow or
whatever it will be called all the best.

If you want a vote from me you could record it as -/+0.

LSD

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

Re: [VOTE] Accept Glasgow into Incubator

[Mads Toftum <ma...@toftum.dk>]

On Thu, Aug 10, 2006 at 04:32:02PM -0700, Cliff Schmidt wrote:
> Spec process concerns (without voting):
> Mads, Leo
> 
Mine would be a -1 if I was on the incubator PMC (but no thanks, I'd
rather not).
I don't find the excuse that a mistake has been made in the past
sufficient to repeat it. I'm also far from convinced that we should use
the ASF name to promote this specific spec - I'd much rather give them a
while longer to prove that it is the right choice.
But, not my call - and kind of useless to object anyway because they
seem to have aquired plenty of support already.

vh

Mads Toftum
-- 
`Darn it, who spiked my coffee with water?!' - lwall


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

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt <cl...@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 <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: [VOTE] Accept Glasgow into Incubator

[Jason van Zyl <ja...@maven.org>]

+1

On 3 Aug 06, at 12:52 PM 3 Aug 06, 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=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
>
>

Jason van Zyl
jason@maven.org




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

Re: [VOTE] Accept Glasgow into Incubator

[ro...@jpmorgan.com]

So it would be fine if development had been funded by the public sector (in
the form of Glasgow City Council) but since it was funded by a private
organisation it's not ok?

Robert


|---------+---------------------------->
|         |           "Danny Angus"    |
|         |           <danny.angus@gmai|
|         |           l.com>           |
|         |                            |
|         |           04/08/2006 14:47 |
|         |           Please respond to|
|         |           general          |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                |
  |       To:       general@incubator.apache.org                                                                                   |
  |       cc:                                                                                                                      |
  |       Subject:  Re: [VOTE] Accept Glasgow into Incubator                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------|




On 04/08/06, Gordon Sim <go...@virgin.net> wrote:
> Danny Angus wrote:
> > I think it is about time that we grew up and introduced a rule which
> > prevents words already used as proper nouns from being proposed as
> > project names unless there is some real and relevant on-topic
> > connection.
> Just by way of explanation, this name was proposed as (a) it is where
> the project began and (b) it is a port, which was felt to have a loose
> association with messaging. As a connection (a) is certainly real,
> though I can understand that the relevance of (b) might be viewed as
> rather tenuous.

If pressed I wouldn't think that those were good reasons, a) is just a
coincidence and b) is a pun.

A good reason would be that it had been funded by the city, or had
become associated with one if the city's institutions. like the GHC
and JAF.

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





This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
 

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

Re: [VOTE] Accept Glasgow into Incubator

[Danny Angus <da...@gmail.com>]

On 04/08/06, Gordon Sim <go...@virgin.net> wrote:
> Danny Angus wrote:
> > I think it is about time that we grew up and introduced a rule which
> > prevents words already used as proper nouns from being proposed as
> > project names unless there is some real and relevant on-topic
> > connection.
> Just by way of explanation, this name was proposed as (a) it is where
> the project began and (b) it is a port, which was felt to have a loose
> association with messaging. As a connection (a) is certainly real,
> though I can understand that the relevance of (b) might be viewed as
> rather tenuous.

If pressed I wouldn't think that those were good reasons, a) is just a
coincidence and b) is a pun.

A good reason would be that it had been funded by the city, or had
become associated with one if the city's institutions. like the GHC
and JAF.

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

Re: [VOTE] Accept Glasgow into Incubator

[Danny Angus <da...@gmail.com>]

On 04/08/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:

> Note that these reasons would have been obvious if the discussion on
> what to change the name to had happened in public...

Quite.

d.

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

Re: [VOTE] Accept Glasgow into Incubator

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/4/06, Gordon Sim <go...@virgin.net> wrote:
> Danny Angus wrote:
> > I think it is about time that we grew up and introduced a rule which
> > prevents words already used as proper nouns from being proposed as
> > project names unless there is some real and relevant on-topic
> > connection.
> Just by way of explanation, this name was proposed as (a) it is where
> the project began and (b) it is a port, which was felt to have a loose
> association with messaging. As a connection (a) is certainly real,
> though I can understand that the relevance of (b) might be viewed as
> rather tenuous.

Note that these reasons would have been obvious if the discussion on
what to change the name to had happened in public...

-garrett

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

Re: [VOTE] Accept Glasgow into Incubator

[Gordon Sim <go...@virgin.net>]

Danny Angus wrote:
> I think it is about time that we grew up and introduced a rule which
> prevents words already used as proper nouns from being proposed as
> project names unless there is some real and relevant on-topic
> connection. 
Just by way of explanation, this name was proposed as (a) it is where 
the project began and (b) it is a port, which was felt to have a loose 
association with messaging. As a connection (a) is certainly real, 
though I can understand that the relevance of (b) might be viewed as 
rather tenuous.

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

Re: [VOTE] Accept Glasgow into Incubator

[Rich Bowen <rb...@rcbowen.com>]

On Aug 4, 2006, at 08:31, Danny Angus wrote:

> Hi everybody,
>
> I don't have a binding vote here, but..
>
> -1
>
> I strongly object to the name, in some sense I object to this name
> because it is also the name of the city in which I work, and
> conversations about "Glasgow" will be a bit wierd.
>
> But very much more importantly I would also like to publicly stand up
> and say that I think it is ridiculous that time after time we
> misappropriate proper nouns to name our projects with. Stop it. Stop
> it now.
>
> It is misguided to think that it can be done without making a cultural
> reference, and it is naieve to think that all such references will be
> appropriate or well received by those whose culture is being
> misrepresented. The fact that Glasgow is not an impoverished and
> exploited region of Africa or Asia doesn't make it any less
> inappropriate to use it as a project name.
>
> I think it is about time that we grew up and introduced a rule which
> prevents words already used as proper nouns from being proposed as
> project names unless there is some real and relevant on-topic
> connection. Don't be lazy, if trademarks and IP make it difficult to
> pick an apropriate name straight away don't just revert to sticking a
> pin in the map, get out a thesaurus.
>
> With the notable and highly significant exceptions of "Apache" and
> "Jakarta" (both of which raise difficult questions) it seems as if it
> has only really become common practice since the incubator with Derby,
> Geronimo, Tuscany, & Woden to name some that I know about. You guys
> have the chance to stop it by rejecting this project on the basis of
> its name.

Danny has stated something here that I have also begun to feel rather  
strongly about. Consider, for a moment, how it would feel if we  
called a project Canada, or perhaps Russia. Yet we have Trinidad and  
Tobago. Someone on IRC mentioned that they hear of Jakarta in two  
contexts - one, the Apache project, and the other, when something  
unpleasant is happening in that part of the world.

While I wouldn't necessarily vote to reject the proposal solely on  
this one point (although I do agree with all of the points so  
eloquently stated by Garrett - but I'm not a member of the Incubator  
PMC) I would strongly request that the changing of the name be a  
prerequisite for graduation, if this proposal is indeed accepted.

--
http://feathercast.org/




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

Re: [VOTE] Accept Glasgow into Incubator

[Danny Angus <da...@gmail.com>]

Hi everybody,

I don't have a binding vote here, but..

-1

I strongly object to the name, in some sense I object to this name
because it is also the name of the city in which I work, and
conversations about "Glasgow" will be a bit wierd.

But very much more importantly I would also like to publicly stand up
and say that I think it is ridiculous that time after time we
misappropriate proper nouns to name our projects with. Stop it. Stop
it now.

It is misguided to think that it can be done without making a cultural
reference, and it is naieve to think that all such references will be
appropriate or well received by those whose culture is being
misrepresented. The fact that Glasgow is not an impoverished and
exploited region of Africa or Asia doesn't make it any less
inappropriate to use it as a project name.

I think it is about time that we grew up and introduced a rule which
prevents words already used as proper nouns from being proposed as
project names unless there is some real and relevant on-topic
connection. Don't be lazy, if trademarks and IP make it difficult to
pick an apropriate name straight away don't just revert to sticking a
pin in the map, get out a thesaurus.

With the notable and highly significant exceptions of "Apache" and
"Jakarta" (both of which raise difficult questions) it seems as if it
has only really become common practice since the incubator with Derby,
Geronimo, Tuscany, & Woden to name some that I know about. You guys
have the chance to stop it by rejecting this project on the basis of
its name.

Please take this opportunity to stop the rot.

d.

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

Re: [VOTE] Accept Glasgow into Incubator

[Gordon Sim <go...@virgin.net>]

Garrett Rooney wrote:
> Finally, and I hate to say this because it may very well be just a
> cultural difference between projects the Glasgow developers have
> worked on and the way things work in ASF projects I'm familiar with, I
> think it's disturbing that all answers to questions concerning this
> proposal have been discussed in private and fed back to us through a
> single person.  I don't see a community of individuals here, I see a
> collection of companies working to bring a new project to the ASF
> because they can benefit from the brand, and while that can certainly
> change with time its combination with the other problems means I can't
> vote in favor of the proposal.
One reason for this may be that many of the issues & questions raised
have been about the ownership and control of the specification and not
the glasgow project itself.  I accept that a project whose goal is the
implementation of a specification must necessarily be judged with
reference to that specification.  However, that not all the developers
of a particular implementation of a specification feel qualified to
comment on legal issues relating to that specification, or to the
processes that govern it, should not be taken as implying that they do
not participate as individuals within their project.

Questions for the protocol group may well require discussion and
agreement amongst the members of that group and as those members do
not correspond to the members of the glasgow proposal this list would
not be an appropriate place for that discussion.


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

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Alan Conway wrote:
> Idiotic question from complete Apache newbie: is the proposal that
> Apache should start hosting specs but would still host projects
> implementing foreign specs, or that Apache should stop hosting projects
> implementing non-Apache specs?

Twofold answer IMHO...

if we host a spec, it shouldn't be the same as the implementation project,
but an independent 'project' that is implementation neutral.

and there is no reason to expect to host every spec.  Many have very logical
umbrellas today that are acceptable.  There are some spec umbrellas that are
not acceptable due to the control / nda / ip considerations and those sorts
of implementations wouldn't be appropriate for the open dialog of an ASF
hosted project.  Open/transparent/freely licenseable specs are really not
an issue for the ASF to host one implementation, no matter what umbrella
hosts such a spec.

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

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

[Craig L Russell <Cr...@Sun.COM>]

On Aug 15, 2006, at 6:57 AM, Alan Conway wrote:

> Idiotic question from complete Apache newbie: is the proposal that
> Apache should start hosting specs but would still host projects
> implementing foreign specs, or that Apache should stop hosting  
> projects
> implementing non-Apache specs?

I haven't read anything as meaning that Apache would stop hosting  
projects implementing external specs. We would have to cancel most of  
the existing projects.

And we're circling around the idea of hosting spec-writing projects  
but haven't come close to understanding the implications. And it's  
not clear to me that the project that stimulated the discussion even  
wants to have a spec-writing component.

Craig
>
> On Mon, 2006-08-14 at 08:34 +0100, James Strachan wrote:
>> On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
>>> Carl Trieloff wrote:
>>>
>>>> -> Is Apache in the business of writing and publishing  
>>>> specifications? <-
>>>
>>>> As long as Apache is not in the business of also creating
>>>> specifications, there will be by definition some separation
>>>> between code and spec processes, and I would like to work
>>>> with the ASF to try improve this.
>>>
>>> Wait ... why can't a specification be a releasable, just like a  
>>> codebase?  The only issue, as I see it, would be enforcement of  
>>> compliance.  And Roy even put forward a proposed license  
>>> amendment for such things.
>>>
>>> As you saying that if the ASF would host the specification, that  
>>> you and the rest of the AMQP IP holders would be willing to  
>>> contribute and manage the specification here under ASF practices?
>>>
>>> I would be in favor of such an approach.  Honestly, I would  
>>> vastly prefer to have Open Specifications managed under ASF  
>>> processes than under the JCP, OASIS, etc.
>>
>> +1
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

[Alan Conway <ac...@redhat.com>]

Idiotic question from complete Apache newbie: is the proposal that
Apache should start hosting specs but would still host projects
implementing foreign specs, or that Apache should stop hosting projects
implementing non-Apache specs?

On Mon, 2006-08-14 at 08:34 +0100, James Strachan wrote:
> On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
> > Carl Trieloff wrote:
> >
> > > -> Is Apache in the business of writing and publishing specifications? <-
> >
> > > As long as Apache is not in the business of also creating
> > > specifications, there will be by definition some separation
> > > between code and spec processes, and I would like to work
> > > with the ASF to try improve this.
> >
> > Wait ... why can't a specification be a releasable, just like a codebase?  The only issue, as I see it, would be enforcement of compliance.  And Roy even put forward a proposed license amendment for such things.
> >
> > As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?
> >
> > I would be in favor of such an approach.  Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.
> 
> +1
> 


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

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

[James Strachan <ja...@gmail.com>]

On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
> Carl Trieloff wrote:
>
> > -> Is Apache in the business of writing and publishing specifications? <-
>
> > As long as Apache is not in the business of also creating
> > specifications, there will be by definition some separation
> > between code and spec processes, and I would like to work
> > with the ASF to try improve this.
>
> Wait ... why can't a specification be a releasable, just like a codebase?  The only issue, as I see it, would be enforcement of compliance.  And Roy even put forward a proposed license amendment for such things.
>
> As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?
>
> I would be in favor of such an approach.  Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.

+1

-- 

James
-------
http://radio.weblogs.com/0112098/

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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> SOP effective when?  http://wiki.apache.org/incubator/WicketProposal surely
> doesn't.  Citations please, or are you just being inventive ;-?

Look at most of the prior proposals - they have affiliations listed.
It's especially more important when they are originating from a
corporate sponsor (or rather a 'coalition') instead of another
open-source community.  -- justin

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

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Justin Erenkrantz wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> It's not complicated, folks.  ASF projects consist of individuals. 
>> Adding company affiliations after each of the initial committers names
>> suggests, to some, that the day they move on to another company their 
>> contribution to the project ends.
> 
> No, including the affiliations is standard practice.  

SOP effective when?  http://wiki.apache.org/incubator/WicketProposal surely
doesn't.  Citations please, or are you just being inventive ;-?

> This is the only
> way we can judge the diversity of the proposal.  If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project.  -- justin

Quit worrying about sense-of-community and diversity on entry into incubation.
Incubation is about growing community.  Our only goal at this phase is to
determine that community and meritocracy can be established, moving forwards,
with the group of initial contributors, and that the project's appeal would
increase the diversity.

But, once again, nobody's answering the crux of the question, only blowing
more wind.  Can the proposal be modified to be less employer-centric, or
does it need a different home to achieve the goals of the contributors?
Do the initial contributors/participants understand they are participating
on behalf of the project before their employer?  Do they plan to be around
when they move on?  If so they will make great participants in the project's
PMC.  For those that don't, ethical considerations suggest they should plan
to remain committer / contributors.

Bill


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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

I placed company names after names, as the last proposal to get voted on 
did not
have company names on it and was requested to add company names. Nothing
more than that.

Carl.


Justin Erenkrantz wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> It's not complicated, folks.  ASF projects consist of individuals.  
>> Adding
>> company affiliations after each of the initial committers names 
>> suggests, to
>> some, that the day they move on to another company their contribution 
>> to the
>> project ends.  We understand why Cliff did so for himself (so that 
>> there would
>> be no misunderstanding that he has a vested interest, bravo), but 
>> that this
>> was propagated to the entire initial list of committers is very 
>> troubling.
>
> No, including the affiliations is standard practice.  This is the only
> way we can judge the diversity of the proposal.  If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project.  -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


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

Re: Re: Too many licenses? Was: [vote] Accept Glasgow

[robert burrell donkin <ro...@gmail.com>]

On 8/7/06, Cliff Schmidt <cl...@gmail.com> wrote:

<snip>

> Yep -- it's been fun for me to watch us go back and forth on this as I
> try to advise people outside the ASF on what the best thing to do is
> (since every proposer I've run into really actually wants to do the
> most acceptable thing).

not so much herding cats as ballet dancing with a hurd of rogue elephants ;-)

> Robert actually touched on this issue here:
> http://incubator.apache.org/guides/proposal.html#template-affiliations,
> which ends with, "It's probably best to do this in a separate section
> away from the committers list."

just to let every one know that it's just a draft. my plan is to try
to edit the drafts until they seem ready (to those working on the
documentation) and then put them up for community review. if anyone
wants to lend a hand, they'd be more than welcome :-)

- robert

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

Re: Too many licenses? Was: [vote] Accept Glasgow

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

On 8/7/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > It's not complicated, folks.  ASF projects consist of individuals.  Adding
> > company affiliations after each of the initial committers names suggests, to
> > some, that the day they move on to another company their contribution to the
> > project ends.  We understand why Cliff did so for himself (so that there would
> > be no misunderstanding that he has a vested interest, bravo), but that this
> > was propagated to the entire initial list of committers is very troubling.
>
> No, including the affiliations is standard practice.  This is the only
> way we can judge the diversity of the proposal.  If it's just names of
> folks off the street and everyone works at the same company (and that
> isn't disclosed), we have no way of estimating the true diversity of
> the project.  -- justin

Yep -- it's been fun for me to watch us go back and forth on this as I
try to advise people outside the ASF on what the best thing to do is
(since every proposer I've run into really actually wants to do the
most acceptable thing).

Robert actually touched on this issue here:
http://incubator.apache.org/guides/proposal.html#template-affiliations,
which ends with, "It's probably best to do this in a separate section
away from the committers list."

The funny thing is that I thought that was a good approach too, until
Justin and Yoav asked for the more explicit version (the way these
folks did things) in
http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/%3c5c902b9e0606210718k1cd8f394idf424dc085c0ff2e@mail.gmail.com%3e.

I understand as much as anyone that we have lots of different opinions
on these kinds of things and sometimes, some of us (including me)
think that there has been a consensus...and it's on our side.  All
that is fine, but let's all try to be a little more careful with
making value juidgements against new folks who show up and think that
one of the options used in the past is a reasonable approach.

Cliff

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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 8/7/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> It's not complicated, folks.  ASF projects consist of individuals.  Adding
> company affiliations after each of the initial committers names suggests, to
> some, that the day they move on to another company their contribution to the
> project ends.  We understand why Cliff did so for himself (so that there would
> be no misunderstanding that he has a vested interest, bravo), but that this
> was propagated to the entire initial list of committers is very troubling.

No, including the affiliations is standard practice.  This is the only
way we can judge the diversity of the proposal.  If it's just names of
folks off the street and everyone works at the same company (and that
isn't disclosed), we have no way of estimating the true diversity of
the project.  -- justin

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

Re: [vote] Accept Glasgow (revised vote)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Carl Trieloff wrote:
> William A. Rowe, Jr. wrote:
>> Last and final objection, I want to make sure I am not missing
>> something...
>> the contract between the spec participants is or is not public?  If
>> public,
>> was there a link I missed?  If so, can it be added to the proposal for
>> completeness sake?
> 
> I have to say partially public.

With your very detailed explanation, I grok the dynamics at work.  Although
I can't support the proposal until I understand all of the NDA's at work,
the extent to which the project will be 'controlled' by private traffic, and
by traffic they may or may not successfully influence ...

... I'm very pleased with all of the efforts to resolve entirely reasonable
confusion on the part of the submittors, and fully believe the project can
succeed as it addresses the remaining issues ...

... my vote is retracted, count me +/- 0 until we determine the rules by which
the spec committee is playing, at which point I would likely support the
proposal.  But please don't let my earlier negative vote impede your progress
if there's sufficient support for the proposal as-is, the -1 is reverted.

Bill

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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

William A. Rowe, Jr. wrote:
> Last and final objection, I want to make sure I am not missing something...
> the contract between the spec participants is or is not public?  If public,
> was there a link I missed?  If so, can it be added to the proposal for
> completeness sake?
>
> Bill
>
>
>   
William, to this last point that has not been covered in a previous posting

I have to say partially public.

Short explanation, about two weeks ago a similar question was asked and 
based on
what was asked, I had requested from the working group to be able to publish
the "joint objectives" and the license that the working group will 
provide to the standards
body once selected and submitted to. This has been added to the wiki. 
The 'Joint Objectives'
is copied below.

The agreement is a non-NDA document, and the working group provides it 
to anyone
who requests it that said I would prefer to discuss any publication of 
the agreement on open
web sites or mailing lists with the working group prior to doing so. As 
this group is
is new, it is still working out many policies internally. Out of respect 
for those members
of the group who are out on summer vacations it seems best to wait for 
the majority of the
other members to have returned before I make such a request.

I think it is good to clarify that I have two hats, one as a proposer of 
project to incubator
and one as a part of the spec working group, and the hat I have to wear 
for this issue
is as a representative of the working group and not as a committer on 
this proposal

Regards
Carl.


Joint Objectives (from AMQP Participant agreement)

A. Members wish to work together to collectively create a Specification 
for an open and interoperable messaging protocol, to enable the
development and industry-wide use and for widespread deployment.
B. The goal is to have the protocol generally used for messaging, 
capable of servicing the industries' most complex and demanding
environments. However, it is intended to be simple to use and relatively 
easy to implement.
C. It is not the first objective of this group to drive the creation of 
middleware APIs complimentary to the AMQ Protocol even though an API
might be specified along with protocol for the express purpose to 
understand and test the protocol itself. This is important as the
protocol will be general purpose and usable from any language, and any 
platform without prejudice and bindings for many languages and platforms
will need to exist once the protocol is specified.
D. Members are encouraged to provide open (OSI) licensed implementations 
of the AMQP Specification. Prototype implementations of Draft revisions
of the AMQP Specification may also be produced by a member for 
demonstration, proof-of-concept, or market development purposes provided
prior approval to such a prototype implementation has been given. The 
aim being that the unity and cohesion of the AMQP Specification is not
weakened by forking or manipulation of the market by early release of 
non-conformant implementations.
E. The group will promote the use of the protocol and conformance with 
the published AMQP Specification.
F. The protocol will not specify payload formats, but rather concentrate 
on interoperability of the messaging "envelope" and all the related 
components including but not limited to areas such as 
security,transactions, persistence, synchrony, bridging, tunneling, 
queuing semantics, reliable multicast and distribution optimizations to 
name a few.

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

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>> William,
>>
>> I have made some edits to the wiki on the Mechanisms for feedback[...]
> 
> Although the objectionable language still appears on the spec parties' web
> sites[...]

Whoa - my bad; I got this wrong and the web sites beat us both...

> I have one last suggestion on your choice of words...
> 
>>>From the proposal, "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."
> 
> could be more simply put "On such acceptance, the employer must also sign
> the [RLA? ] agreement [or is this Specifications Party Contract?] to ensure
> that all necessary licenses are clearly granted." - which makes perfect sense.

"In the same spirit of an Apache-style process, if an individual has shown
understanding of the project and substantive contribution to the specification,
based on technical merit and understanding of the goals of the work an
invitation may be extended to have that member join the specification Working
Group. On such acceptance the Party is required to sign an agreement that makes
sure they also grant ongoing and consistent licenses to the work."

Done.  The language on the sites is perfect.  The Party in this case is the
individual, and anyone else who lays claim to the IP they produce, so I don't
see any reason not to use the web site language off Envoy & IONA (the two I
just reread.)

Still looking for just the answer to my very last question about the Spec
participation contract, public or private status.

Bill

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

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Carl Trieloff wrote:
> 
> William,
> 
> I have made some edits to the wiki on the Mechanisms for feedback
> section to clean up the language, based on some of the misunderstanding 
> and to reflect the discussion from the list onto the wiki. Tried to keep
> it short, but can edit more in if required.

Although the objectionable language still appears on the spec parties' web
sites, and I still consider it an abuse of the phrase "In the same spirit
of an Apache-style process" until the rest of the language changes...
I have one last suggestion on your choice of words...

>From the proposal, "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."

could be more simply put "On such acceptance, the employer must also sign
the [RLA? ] agreement [or is this Specifications Party Contract?] to ensure
that all necessary licenses are clearly granted." - which makes perfect sense.

I still find two points in the RLA (which, w.r.t. employment *wasn't* at all
objectionable(!) and entirely contributor-focused, individual or corporate)
to be odd;

"for the purpose of developing and promoting the Specification and in connection
with any product that implements and complies with the Specification"

which is a bit too fuzzy for many to agree too (usually it would be constrained
to "necessary to implement the proposed Feedback to the Specification" or some
similarly narrow language - but if this works for all involved), and...

"information shall be considered “Confidential Information” when, [...] (ii)
non-tangible disclosures are identified as confidential prior to disclosure and
reduced to writing, marked as provided above, and delivered to the receiving
party within thirty (30) days of the original date of disclosure."

which from a mailing-list centered activity is entirely a cat out of the bag
scenario.  It's important that the project understand that the infra team
has a -strict- policy about not redacting project mailing list history for
any purpose whatsoever.

I am confident that at least three of the initial committers are clear
in their company hat / project hat deliniation and that any confusion
about this, in practice, will be cleared up in the project pre-committee.

Last and final objection, I want to make sure I am not missing something...
the contract between the spec participants is or is not public?  If public,
was there a link I missed?  If so, can it be added to the proposal for
completeness sake?

Bill

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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

William,

I have made some edits to the wiki on the Mechanisms for feedback 
section to clean up the
language, based on some of the misunderstanding and to reflect the 
discussion from the list
onto the wiki. Tried to keep it short, but can edit more in if required.

Carl.

William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>   
>>> But to the extent that ASF contributors offer productive growth and
>>> formative input into the specification, the way this section is phrased
>>> is not acceptable.  If the contributor wish[es], and if under these terms
>>> their contributions merits participation, that contributor should either
>>> lead the ASF's direct involvement as the ASF spec liason (much as we've
>>> done within the JCP) or as an individual contributor.
>>>
>>>       
>> I would love this.
>>     
>
> Glad to hear that, but until the proposal is revised it is simply a platitude.
>
> I phrased that as an either-or or both, but we need to know from the spec
> committee what would be acceptable.
>
> I'm very concerned, though, that not one mentor has spoken up and added any
> feedback on this objection...
>
>
> Carl Trieloff wrote:
>   
>>> My question came down to this; if someone offers a patch, which then suggests
>>> an improvement to the spec, does the ASL (which covers -everything- that is
>>> offered to the ASF) adequately correspond to the RLA terms to satisfy the
>>> spec committee?  If so there's no issue; in fact it would be sufficient to
>>> continue to accept contributions from ASF committers who have signed a CLA
>>> to the effect that everything they offer is covered.
>>>       
>> Now that I understand what you are getting at - I really like the idea.
>> no idea if it is possible, but worth looking into - seems like it might work. 
>> We can work this with Cliff and see what we can come up during incubator
>>     
>
> I'm a bit concerned about the project's apparent attitude "accept us and then
> we'll work out the wrinkles, or not".  Even copyrights are already assigned
> as Apache Software Foundation when they are, in fact, not the ASF's yet.  And
> FWIW - copyright will become much simpler under the new practice; no more
> individual file copyright notices, one collective NOTICE, one LICENSE file.
>
> Most important, so I'll say this for the third time;
>
>   
>>> The specific statement "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."
>>>       
>
> has put off this effort on the wrong foot.  I hope this is addressed now, and
> not put off with some fuzzy "then we'll work out the details during incubation".
>
> It's not complicated, folks.  ASF projects consist of individuals.  Adding
> company affiliations after each of the initial committers names suggests, to
> some, that the day they move on to another company their contribution to the
> project ends.  We understand why Cliff did so for himself (so that there would
> be no misunderstanding that he has a vested interest, bravo), but that this
> was propagated to the entire initial list of committers is very troubling.
>
> The effort seems entirely too eager to brand the project as Apache, entirely
> ready to defend the status quo or try to cite ASF policy back at any objectors,
> and entirely uninterested in addressing a couple of things; how to start off
> on the right foot as a collaboration of willing developers (not employers)
> at the ASF.  That's the sense of what I'm reading - I'm not saying it's so.
> The enthusiasm is admirable, but the core issues need to be addressed before
> incubation begins.
>
> Address the crux of this please, the language of the spec feedback cycle and
> the spec body, and then let's all move *forward* to incubating the effort?
> The silence of the mentors on this makea me very concerned about their ability
> to adequately shape the evolution of this community.
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Carl Trieloff wrote:
>
>> But to the extent that ASF contributors offer productive growth and
>> formative input into the specification, the way this section is phrased
>> is not acceptable.  If the contributor wish[es], and if under these terms
>> their contributions merits participation, that contributor should either
>> lead the ASF's direct involvement as the ASF spec liason (much as we've
>> done within the JCP) or as an individual contributor.
>>
> I would love this.

Glad to hear that, but until the proposal is revised it is simply a platitude.

I phrased that as an either-or or both, but we need to know from the spec
committee what would be acceptable.

I'm very concerned, though, that not one mentor has spoken up and added any
feedback on this objection...


Carl Trieloff wrote:
> 
>> My question came down to this; if someone offers a patch, which then suggests
>> an improvement to the spec, does the ASL (which covers -everything- that is
>> offered to the ASF) adequately correspond to the RLA terms to satisfy the
>> spec committee?  If so there's no issue; in fact it would be sufficient to
>> continue to accept contributions from ASF committers who have signed a CLA
>> to the effect that everything they offer is covered.
> 
> Now that I understand what you are getting at - I really like the idea.
> no idea if it is possible, but worth looking into - seems like it might work. 
> We can work this with Cliff and see what we can come up during incubator

I'm a bit concerned about the project's apparent attitude "accept us and then
we'll work out the wrinkles, or not".  Even copyrights are already assigned
as Apache Software Foundation when they are, in fact, not the ASF's yet.  And
FWIW - copyright will become much simpler under the new practice; no more
individual file copyright notices, one collective NOTICE, one LICENSE file.

Most important, so I'll say this for the third time;

>> The specific statement "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."

has put off this effort on the wrong foot.  I hope this is addressed now, and
not put off with some fuzzy "then we'll work out the details during incubation".

It's not complicated, folks.  ASF projects consist of individuals.  Adding
company affiliations after each of the initial committers names suggests, to
some, that the day they move on to another company their contribution to the
project ends.  We understand why Cliff did so for himself (so that there would
be no misunderstanding that he has a vested interest, bravo), but that this
was propagated to the entire initial list of committers is very troubling.

The effort seems entirely too eager to brand the project as Apache, entirely
ready to defend the status quo or try to cite ASF policy back at any objectors,
and entirely uninterested in addressing a couple of things; how to start off
on the right foot as a collaboration of willing developers (not employers)
at the ASF.  That's the sense of what I'm reading - I'm not saying it's so.
The enthusiasm is admirable, but the core issues need to be addressed before
incubation begins.

Address the crux of this please, the language of the spec feedback cycle and
the spec body, and then let's all move *forward* to incubating the effort?
The silence of the mentors on this makea me very concerned about their ability
to adequately shape the evolution of this community.

Bill


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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

y question came down to this; if someone offers a patch, which then suggests
an improvement to the spec, does the ASL (which covers -everything- that is
offered to the ASF) adequately correspond to the RLA terms to satisfy the
spec committee?  If so there's no issue; in fact it would be sufficient to
continue to accept contributions from ASF committers who have signed a CLA
to the effect that everything they offer is covered.

Now that I understand what you are getting at - I really like the idea. 
no idea if it
is possible, but worth looking into - seems like it might work. We can 
work this with
Cliff and see what we can come up during incubator

Carl


William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
>   
>> William A. Rowe, Jr. wrote:
>>     
>>> I have a question, can anyone summarize how contributions under the ASL
>>> would be weaker or stronger than contributions under this RLA?
>>>   
>>>       
>> Legally they are most likely much the same - I think the questions you
>> ask implies something
>> which should be the question to ask....
>> -> Is Apache in the business of writing and publishing specifications? <-
>> From precedence and from what I know it is not.
>>     
>
> Actually, no, that doesn't follow from my question.
>
> My question came down to this; if someone offers a patch, which then suggests
> an improvement to the spec, does the ASL (which covers -everything- that is
> offered to the ASF) adequately correspond to the RLA terms to satisfy the
> spec committee?  If so there's no issue; in fact it would be sufficient to
> continue to accept contributions from ASF committers who have signed a CLA
> to the effect that everything they offer is covered.
>
> This is slightly distinct from a non-committer without a CLA which is also
> contributing under the ASL, but without quite as strong a paper trail that
> they contributed knowingly under that license.
>
>   
>> As long as Apache is not in the business of also creating specifications,
>> there will be by definition some separation between code and spec processes
>>     
>
> This would generally be true even if they were both under the ASF umbrella,
> I don't necessarily think they have to be one.  E.g. even if the spec
> committee were an ASF committee, they would answer to all implementors, not
> only one implementation by the ASF...
>
>   
>> and I would like to work with the ASF to
>> try improve this. The way the group is setup I believe the ASF can have
>> a strong influence while
>> we are in incubator, and the ASF can "keep" us in incubator until the
>> spec meets ASF standards as
>> Brian said before we went to vote. Thus being in incubator seems the
>> perfect place to work this.
>>     
>
> Sure, that sounds like a good thing, although it still doesn't go to the
> questions
>
>  * project contributors must all sign two agreements?
>  * the spec committee is or isn't sufficently protected by the ASL terms?
>
>   
>> I think this is one of the options we can look at to have any member of
>> the project provide feedback to the spec working group - however it seems
>> presumptuous to use the ASL or work out details like this before we are
>> accepted in incubator.
>>     
>
> Well the ASL is the binding license of ASF work, so if that's a presumptuous
> assertion, perhaps this project belongs elsewhere?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>   
>> Carl Trieloff wrote:
>>
>>     
>>> I think this is one of the options we can look at to have any member of
>>> the project provide feedback to the spec working group - however it seems
>>> presumptuous to use the ASL or work out details like this before we are
>>> accepted in incubator.
>>>       
>> Well the ASL is the binding license of ASF work, so if that's a presumpesuesume tuous
>> assertion, perhaps this project belongs elsewhere?
>>     
The code is already under ASL, no issues with that. comment was to spec 
feedback, sorry if that
was not clear.

>
> Oh - to the first half of your statement, I don't think it's a bad idea to
> filter the suggestions through a few key mentors who can track proposals
> through the spec committee.  The bottom line is that the fruits of these
> ideas come from an ASL licensed code base by 'some member' who contributed
> to the implementation.  So ... it's very important to know that dev@ spec
> discussion will be usable by the spec committee when pushed that direction
> by the spec liasons, from the ASF or any participating company.
>
> That's not necessarily something to postpone until incubation; from the day
> the dev@ list is created, you will begin to collect ideas on the dev@ list.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

William A. Rowe, Jr. wrote:
> Carl Trieloff wrote:
> 
>> I think this is one of the options we can look at to have any member of
>> the project provide feedback to the spec working group - however it seems
>> presumptuous to use the ASL or work out details like this before we are
>> accepted in incubator.
> 
> Well the ASL is the binding license of ASF work, so if that's a presumptuous
> assertion, perhaps this project belongs elsewhere?

Oh - to the first half of your statement, I don't think it's a bad idea to
filter the suggestions through a few key mentors who can track proposals
through the spec committee.  The bottom line is that the fruits of these
ideas come from an ASL licensed code base by 'some member' who contributed
to the implementation.  So ... it's very important to know that dev@ spec
discussion will be usable by the spec committee when pushed that direction
by the spec liasons, from the ASF or any participating company.

That's not necessarily something to postpone until incubation; from the day
the dev@ list is created, you will begin to collect ideas on the dev@ list.

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

Re: Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Carl Trieloff wrote:
> William A. Rowe, Jr. wrote:
>>
>> I have a question, can anyone summarize how contributions under the ASL
>> would be weaker or stronger than contributions under this RLA?
>>   
> Legally they are most likely much the same - I think the questions you
> ask implies something
> which should be the question to ask....
> -> Is Apache in the business of writing and publishing specifications? <-
> From precedence and from what I know it is not.

Actually, no, that doesn't follow from my question.

My question came down to this; if someone offers a patch, which then suggests
an improvement to the spec, does the ASL (which covers -everything- that is
offered to the ASF) adequately correspond to the RLA terms to satisfy the
spec committee?  If so there's no issue; in fact it would be sufficient to
continue to accept contributions from ASF committers who have signed a CLA
to the effect that everything they offer is covered.

This is slightly distinct from a non-committer without a CLA which is also
contributing under the ASL, but without quite as strong a paper trail that
they contributed knowingly under that license.

> As long as Apache is not in the business of also creating specifications,
> there will be by definition some separation between code and spec processes

This would generally be true even if they were both under the ASF umbrella,
I don't necessarily think they have to be one.  E.g. even if the spec
committee were an ASF committee, they would answer to all implementors, not
only one implementation by the ASF...

> and I would like to work with the ASF to
> try improve this. The way the group is setup I believe the ASF can have
> a strong influence while
> we are in incubator, and the ASF can "keep" us in incubator until the
> spec meets ASF standards as
> Brian said before we went to vote. Thus being in incubator seems the
> perfect place to work this.

Sure, that sounds like a good thing, although it still doesn't go to the
questions

 * project contributors must all sign two agreements?
 * the spec committee is or isn't sufficently protected by the ASL terms?

> I think this is one of the options we can look at to have any member of
> the project provide feedback to the spec working group - however it seems
> presumptuous to use the ASL or work out details like this before we are
> accepted in incubator.

Well the ASL is the binding license of ASF work, so if that's a presumptuous
assertion, perhaps this project belongs elsewhere?


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

RE: Specifications as (part of) ASF projects

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

Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Geir Magnusson Jr wrote:
>>> Noel J. Bergman wrote:
>>>> Wait ... why can't a specification be a releasable, just like a
>>>> codebase?  The only issue, as I see it, would be enforcement of
>>>> compliance.  And Roy even put forward a proposed license amendment
>>>> for such things.
>>> Which license amendment?  The license amendment that I'm thinking of was
>>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>>> compatibility - it had nothing to do w/ enforcement of compliance with a
>>> spec.

> <grrr mail client changed?>

Not for the past 6 years.  Would love the chance, and still waiting for someone to get clueful about migrating Outlook in its entirety, and not just a piece here and there.  I've got >4.5GB of mail to migrate, plus 1000s of contact and calendar entries.

> > The JSR licemse, not the TCK license.  

> I don't remember a JSR license.

I was referring to http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt, which could be adapted for the purpose.

> > what else would you call the clauses forbidding the use of the
> > trademark names, references to the specification, and restricted 
> > name space unless the code passed the TCK?

> Dunno, but different than enforced compliance.

Denying implementers the ability to use the specification's restricted name space, which effects the use of the API; make any reference to the specification; or use the trademark(s) is probably about right when dealing with Open Source.

	--- Noel



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

Re: Specifications as (part of) ASF projects

[Geir Magnusson Jr <ge...@pobox.com>]

Noel J. Bergman wrote:
> Geir Magnusson Jr wrote:
>> Noel J. Bergman wrote:
>>> Wait ... why can't a specification be a releasable, just like a
>>> codebase?  The only issue, as I see it, would be enforcement of
>>> compliance.  And Roy even put forward a proposed license amendment
>>> for such things.
>> Which license amendment?  The license amendment that I'm thinking of was
>> specific to JCP TCKs and how derivative works of a TCK can't be used for
>> compatibility - it had nothing to do w/ enforcement of compliance with a
>> spec.
> 
<grrr mail client changed?>

> The JSR licemse, not the TCK license.  

I don't remember a JSR license.  I remember an addendum for an RI, and
an addendum for a TCK.

> Not that it can't be modified,
> but what else would you call the clauses forbidding the use of the
> trademark names, references to the specification, and restricted 
> name space unless the code passed the TCK?

Dunno, but different than enforced compliance.

geir


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

RE: Specifications as (part of) ASF projects

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

Geir Magnusson Jr wrote:
> Noel J. Bergman wrote:
>> Wait ... why can't a specification be a releasable, just like a
>> codebase?  The only issue, as I see it, would be enforcement of
>> compliance.  And Roy even put forward a proposed license amendment
>> for such things.
> Which license amendment?  The license amendment that I'm thinking of was
> specific to JCP TCKs and how derivative works of a TCK can't be used for
> compatibility - it had nothing to do w/ enforcement of compliance with a
> spec.

The JSR licemse, not the TCK license.  Not that it can't be modified, but what else would you call the clauses forbidding the use of the trademark names, references to the specification, and restricted name space unless the code passed the TCK?

	--- Noel



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

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

[Geir Magnusson Jr <ge...@pobox.com>]

What broken mail client are you using?

inline...

Noel J. Bergman wrote:
> Carl Trieloff wrote:
> 
>> -> Is Apache in the business of writing and publishing specifications? <-
> 
>> As long as Apache is not in the business of also creating 
>> specifications, there will be by definition some separation
>> between code and spec processes, and I would like to work
>> with the ASF to try improve this.
> 
> Wait ... why can't a specification be a releasable, just like a codebase?  The only issue, as I see it, would be enforcement of compliance.  And Roy even put forward a proposed license amendment for such things.

Which license amendment?  The license amendment that I'm thinking of was
specific to JCP TCKs and how derivative works of a TCK can't be used for
compatibility - it had nothing to do w/ enforcement of compliance with a
spec.

geir

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

Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

[Brian McCallister <br...@apache.org>]

On Aug 13, 2006, at 10:49 AM, Noel J. Bergman wrote:

> Carl Trieloff wrote:
>
>> -> Is Apache in the business of writing and publishing  
>> specifications? <-
>
>> As long as Apache is not in the business of also creating
>> specifications, there will be by definition some separation
>> between code and spec processes, and I would like to work
>> with the ASF to try improve this.
>
> Wait ... why can't a specification be a releasable, just like a  
> codebase?  The only issue, as I see it, would be enforcement of  
> compliance.  And Roy even put forward a proposed license amendment  
> for such things.
>
> As you saying that if the ASF would host the specification, that  
> you and the rest of the AMQP IP holders would be willing to  
> contribute and manage the specification here under ASF practices?
>
> I would be in favor of such an approach.  Honestly, I would vastly  
> prefer to have Open Specifications managed under ASF processes than  
> under the JCP, OASIS, etc.

I very much agree.

-Brian

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


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

Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)

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

Carl Trieloff wrote:

> -> Is Apache in the business of writing and publishing specifications? <-

> As long as Apache is not in the business of also creating 
> specifications, there will be by definition some separation
> between code and spec processes, and I would like to work
> with the ASF to try improve this.

Wait ... why can't a specification be a releasable, just like a codebase?  The only issue, as I see it, would be enforcement of compliance.  And Roy even put forward a proposed license amendment for such things.

As you saying that if the ASF would host the specification, that you and the rest of the AMQP IP holders would be willing to contribute and manage the specification here under ASF practices?

I would be in favor of such an approach.  Honestly, I would vastly prefer to have Open Specifications managed under ASF processes than under the JCP, OASIS, etc.

	--- Noel



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

Re: Too many licenses? Was: [vote] Accept Glasgow

[Carl Trieloff <cc...@redhat.com>]

William A. Rowe, Jr. wrote:
> Garrett Rooney wrote:
>   
>> AMQP seems to be moving in this
>> direction, they've got some sort of agreement you can sign in order to
>> provide them feedback
>>     
>
> I have a question, can anyone summarize how contributions under the ASL
> would be weaker or stronger than contributions under this RLA?
>   
Legally they are most likely much the same - I think the questions you 
ask implies something
which should be the question to ask....
 -> Is Apache in the business of writing and publishing specifications? <-
 From precedence and from what I know it is not.

As long as Apache is not in the business of also creating 
specifications, there will be by definition
some separation between code and spec processes, and I would like to 
work with the ASF to
try improve this. The way the group is setup I believe the ASF can have 
a strong influence while
we are in incubator, and the ASF can "keep" us in incubator until the 
spec meets ASF standards as
Brian said before we went to vote. Thus being in incubator seems the 
perfect place to work this.


> I'd like to have those quantified.  If there's no difference, and the spec
> implementors are requesting this become an ASF project, then why not accept
> spec feedback/contributions under the ASL?  These may be relicensed under
> the RLA for their publishing purposes, the ASL doesn't inhibit that, IIUC.
>
>   
I think this is one of the options we can look at to have any member of 
the project
 provide feedback to the spec working group - however it seems 
presumptuous to use the
ASL or work out details like this before we are accepted in incubator.

Regards
Carl.

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

Too many licenses? Was: [vote] Accept Glasgow

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Garrett Rooney wrote:
> AMQP seems to be moving in this
> direction, they've got some sort of agreement you can sign in order to
> provide them feedback

I have a question, can anyone summarize how contributions under the ASL
would be weaker or stronger than contributions under this RLA?

I'd like to have those quantified.  If there's no difference, and the spec
implementors are requesting this become an ASF project, then why not accept
spec feedback/contributions under the ASL?  These may be relicensed under
the RLA for their publishing purposes, the ASL doesn't inhibit that, IIUC.

Clarifications welcomed.

Bill


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

Re: horses and carts; was: Accept Glasgow into Incubator

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/3/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Mads, I'm not sure if you meant to vote, but it raises a dialog so I'm
> forking the subject.
>
> Mads Toftum wrote:
> > I very much agree with Garretts concerns - and would be much in favor of
> > not bringing the project into incubation before they have proven an
> > actual community and that they can work the standard the "apache way".
>
> Which is the cart and which is the horse?  Code like stdcxx, derby, etc
> don't come from "apache way" communities.  Working in an OSS community
> is a learned skill.  These projects come to us with good code, and they
> come asking to learn how to operate as a community, rather than the
> traditional commercial development models.
>
> And what's the role of the incubator if not to teach those skills?

FWIW, I don't have any problem with people showing up at the incubator
with some code and wanting to build a community around it, that's just
fine.  I just want it to actually feel like that's the goal, and in
this case that wasn't the feeling I was getting.  Now it's perfectly
possible that I was just getting the wrong impression, I could
certainly be wrong, and it's quite hard to tell for sure when
everything the people bringing this proposal to us says is behind
closed doors except their conclusions.

-garrett

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

horses and carts; was: Accept Glasgow into Incubator

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mads, I'm not sure if you meant to vote, but it raises a dialog so I'm
forking the subject.

Mads Toftum wrote:
> I very much agree with Garretts concerns - and would be much in favor of
> not bringing the project into incubation before they have proven an
> actual community and that they can work the standard the "apache way".

Which is the cart and which is the horse?  Code like stdcxx, derby, etc
don't come from "apache way" communities.  Working in an OSS community
is a learned skill.  These projects come to us with good code, and they
come asking to learn how to operate as a community, rather than the
traditional commercial development models.

And what's the role of the incubator if not to teach those skills?

Bill

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

Re: Glasgow - community? specs? other issues?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Eelco Hillenius wrote:
> [...]
> I did not write that actually. I'm sorry I hijacked the VOTE thread.
> It's one of the (hopefully) few things to get used to over at Apache,
> as at Wicket we aren't that formal about it.

First, I generally agreed with this (which was what you said in an earlier
post... my reply was

>Some folks have expressed concerns about community, etc; things I don't
>think are so important entering the incubator - they are mandatory before
>the effort would graduate, of course  :)

I think the rest of this post quotes your post of 0300gmt so I haven't
read it again - as I say I think they are good thoughts to be thunk after
we resolve immediate issues at hand, for incoming future projects.

But the hijaak comment wasn't directed at you - it's a bad habit here.  At
20+ posts a day, some days easily 50 posts, using decent message subjects
would be very productive.

I'm still waiting for any feedback on "specs?", but community doesn't seem
to be an insurmountable obstacle.


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

Re: Glasgow - community? specs? other issues?

[Eelco Hillenius <ee...@gmail.com>]

On 8/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Eelco Hillenius wrote:
> >> I understand that there are some specific circumstances in this case,
> >> but in general I believe this sort of criteria is why we get
> >> complaints that it's impossible to "innovate" at Apache any more.  We
> >> require all the grunt work of innovation to occur outside of Apache.

I did not write that actually. I'm sorry I hijacked the VOTE thread.
It's one of the (hopefully) few things to get used to over at Apache,
as at Wicket we aren't that formal about it.

Here is the blurp that attracted my attention, followed by my thoughts:

> I understand that there are some specific circumstances in this case,
> but in general I believe this sort of criteria is why we get
> complaints that it's impossible to "innovate" at Apache any more.  We
> require all the grunt work of innovation to occur outside of Apache.
>
> The issues of an open specification is one thing.  But aren't "proven
> an actual community" and "work the standard 'apache way'" graduation
> requirements, not entry requirements?  If we expect something coming
> into the incubator to already have a fully functioning, health
> Apache-style community, then the only point of the Incubator is for
> handling licensing issues.

This is quite interesting...

Over at Wicket we have been operating 'the Apache way' from a very
early stage in the project (about two years). We have mail archives,
commit logs, releases, and history of letting new committers in to
prove all that if people are willing to spend an hour looking for it.
But we feel we have to prove ourselves all over again as the
incubation process expects it's podlings to prove themselves within
the confines of the incubation process.

The incubation process might benefit from having a categorization of
projects that want to enter. Such categorization basically answers:
* How old are these projects, how many committers, how large is the
community of developers and users?
* Has the project been working apache style for a certain time (the
time being a categorization in itself). If it has, there is no
question about prove - it'll be there as that is one of the key
factors of working the apache way (mailing lists, committers etc.)?

This categorization would then be the starting point for answering two
things that I think are currently missing in the whole incubation
process (please do tell me if I am wrong/ missed something):
* To what extend can information about the project's readiness be
gathered based on the (outside) history of the project, and how much
information needs to be gathered additionally during incubation? The
availability of such history could get some load of the backs of the
involved parties and might mean a shorter incubation time.
* What would be the proposed time estimate for the whole incubation?
Factor time currently seems to be non existent in the incubation
process. But 'it takes how long it takes' imo does not cut it. I
believe the incubation process would benefit from formalizing
timelines and milestones so that both parties keep focussed on making
progress. Having a schedule for incubation would also mean that
involved parties could use that schedule for any other plans they
might be making. For example, we (Wicket) would like to have our 2.0
version to be released at Apache, after (if) we're done with
incubation. There is currently no way to even remotely predict when
that might happen. This is inconvenient for our users, but also is a
problem as we are writing a book on that version and our publisher
*does* want to know when that book will be ready for publishing.
Having a code base that is release-ready but that's just waiting for
months for the incubation process to move on for some unknown time is
unacceptable to us. The kind of schedule I am thinking of would be
semi-binding. If we meet the requirements for the milestone in time,
we go on to the next stage, unless there is absolute consensus we
shouldn't based on something other that the milestone requirements. If
we don't meet the requirements in time, incubation may be terminated
for that reason alone.

I couldn't find any previous discussions on these topics, but if I
missed them, my apologies and please reply with an URL. Otherwise, I'd
be very interested to hear what others think of this. Also, I am not
specifically proposing anything concrete for Wicket's incubation at
this time; I wouldn't want to get in the way of our mentors :)

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

Re: Glasgow - community? specs? other issues?

[ro...@jpmorgan.com]

Let me try to address your concerns.

> And as far as the openness of the spec itself - this is, too, an issue.
> I will continue voting -1 until we really determine that - unlike JCP -
> we can have a no-NDA scenario with respect to TCKs etc.  And that,
> unlike Oasis, the implementation is covered by the grants, not strictly
> the spec.  And, ideally, that IP grants under the ASL will cover those
> participating in the spec from future problems; that the spec itself will
> not be entirely corp-based; and worse yet, that horridly offensive
> language is modified in the project proposal/charter.

There is no NDA with respect to TCKs. What made you think there was? In
fact, there is currently no TCK, which is something the AMQP group needs to
address and I am sure they will address. The AMQP group is only a few
months old and has many things to address.

I am not sure what you mean by "the implementation is covered by the
grants"? Are you referring to the TCK?

I am also not sure what you mean by "IP grants under the ASL will cover
those participating in the spec from future problems". Can you expand on
that please?

Anyone can join the specification group, you just have to demonstrate
merit. There is a legal issue that people need to get their employer to
sign a declaration that basically says they are not going to sue other
members of specification group. The reason for this is that most people
work under a contract that states that everything they produce belongs to
their employer - even if they do it in their own time. If an individual can
demonstrate that they do not work under such a contract then I am pretty
sure there would be no requirement for them to approach their employer.

I believe that the language you objected to in the proposal was simply
poorly worded rather than deliberately offensive and that it will be
modified.

Robert



This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
 

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

Glasgow - community? specs? other issues?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Eelco Hillenius wrote:
>> I understand that there are some specific circumstances in this case,
>> but in general I believe this sort of criteria is why we get
>> complaints that it's impossible to "innovate" at Apache any more.  We
>> require all the grunt work of innovation to occur outside of Apache.

Well, the criticism I've seen was essentially, incubator folk make one
specific objection, committee 'huddles' to come up with the "right answer"
and keep presenting it through one person.  That's not the way ASF projects
operate.  So the effort was rightly criticized - although we don't really
expect everything to flow in an 'asf way' quite so early in the process.

Some folks have expressed concerns about community, etc; things I don't
think are so important entering the incubator - they are mandatory before
the effort would graduate, of course :)

>> The issues of an open specification is one thing.  But aren't "proven
>> an actual community" and "work the standard 'apache way'" graduation
>> requirements, not entry requirements?

Yes.  My concerns relate to the specification.  Some others voted -1 for
some other reasons that don't concern me nearly as much.

But some of the specs issues really have got to be worked out before one
peep of specs related suggestions pollute the minds of the developers in
their dev@ list.  I think I've finally clarified these sufficiently, please
correct me if I'm wrong.

And as far as the openness of the spec itself - this is, too, an issue.
I will continue voting -1 until we really determine that - unlike JCP -
we can have a no-NDA scenario with respect to TCKs etc.  And that,
unlike Oasis, the implementation is covered by the grants, not strictly
the spec.  And, ideally, that IP grants under the ASL will cover those
participating in the spec from future problems; that the spec itself will
not be entirely corp-based; and worse yet, that horridly offensive
language is modified in the project proposal/charter.

Yes - I totally understand that the contributors are coming at this from
an entirely corporate perspective, and I'm really not 'dissing' that.
One of the projects I mentor, stdcxx, started the same way.  I'm only
pointing out that we need to put the right foot forward before voting
this project up and in.  Missteps are expected and excusable :)

Finding a home before the collation of the willing says "hey!
here's a project!" would have been one alternative.  Spelling out where
they plan to land would be another viable alternative.  Leaving this in
limbo leaves some of us understandably wary.

Tweaking the language to sound less corporate, but leaving the ASF and
new project vulnerable to corporate dictatates is no more palatable than
the current language :)  I know your mentor totally understands what I
mean, so I don't doubt this can be corrected, through discussion -here-
on this list, the name question resolved, and the incubation accepted
unanimously.

You really had some great things to add, and I totally agree with you
we should consider adding those qualifications - after we are done
pondering the incubation of this new project.

Oh - and you replied on the primary vote thread - we really need to
focus the s/n ratio for the counters to track the outcome :)

Yours,

Bill


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

Re: [VOTE] Accept Glasgow into Incubator

[Eelco Hillenius <ee...@gmail.com>]

> I understand that there are some specific circumstances in this case,
> but in general I believe this sort of criteria is why we get
> complaints that it's impossible to "innovate" at Apache any more.  We
> require all the grunt work of innovation to occur outside of Apache.
>
> The issues of an open specification is one thing.  But aren't "proven
> an actual community" and "work the standard 'apache way'" graduation
> requirements, not entry requirements?  If we expect something coming
> into the incubator to already have a fully functioning, health
> Apache-style community, then the only point of the Incubator is for
> handling licensing issues.

This is quite interesting...

Over at Wicket we have been operating 'the Apache way' from a very
early stage in the project (about two years). We have mail archives,
commit logs, releases, and history of letting new committers in to
prove all that if people are willing to spend an hour looking for it.
But we feel we have to prove ourselves all over again as the
incubation process expects it's podlings to prove themselves within
the confines of the incubation process.

The incubation process might benefit from having a categorization of
projects that want to enter. Such categorization basically answers:
* How old are these projects, how many committers, how large is the
community of developers and users?
* Has the project been working apache style for a certain time (the
time being a categorization in itself). If it has, there is no
question about prove - it'll be there as that is one of the key
factors of working the apache way (mailing lists, committers etc.)?

This categorization would then be the starting point for answering two
things that I think are currently missing in the whole incubation
process (please do tell me if I am wrong/ missed something):
* To what extend can information about the project's readiness be
gathered based on the (outside) history of the project, and how much
information needs to be gathered additionally during incubation? The
availability of such history could get some load of the backs of the
involved parties and might mean a shorter incubation time.
* What would be the proposed time estimate for the whole incubation?
Factor time currently seems to be non existent in the incubation
process. But 'it takes how long it takes' imo does not cut it. I
believe the incubation process would benefit from formalizing
timelines and milestones so that both parties keep focussed on making
progress. Having a schedule for incubation would also mean that
involved parties could use that schedule for any other plans they
might be making. For example, we (Wicket) would like to have our 2.0
version to be released at Apache, after (if) we're done with
incubation. There is currently no way to even remotely predict when
that might happen. This is inconvenient for our users, but also is a
problem as we are writing a book on that version and our publisher
*does* want to know when that book will be ready for publishing.
Having a code base that is release-ready but that's just waiting for
months for the incubation process to move on for some unknown time is
unacceptable to us. The kind of schedule I am thinking of would be
semi-binding. If we meet the requirements for the milestone in time,
we go on to the next stage, unless there is absolute consensus we
shouldn't based on something other that the milestone requirements. If
we don't meet the requirements in time, incubation may be terminated
for that reason alone.

I couldn't find any previous discussions on these topics, but if I
missed them, my apologies and please reply with an URL. Otherwise, I'd
be very interested to hear what others think of this. Also, I am not
specifically proposing anything concrete for Wicket's incubation at
this time; I wouldn't want to get in the way of our mentors :)

Eelco

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

Re: [VOTE] Accept Glasgow into Incubator

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

On 8/4/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 8/4/06, Cliff Schmidt <cl...@gmail.com> wrote:
> > nor would I, as a mentor, ever allow any project to move through
> > incubation without actively working to create such a community.
>
> I have no doubt that this is the case, and if I said anything that
> implies otherwise I'm sorry.  I have a great deal of faith in Cliff as
> a mentor, and I trust him to do the right thing with regard to
> building communities at the ASF.

Oh I definitely didn't take any offense, but I appreciate your comment.

My point was just to remind folks that these proposals come with
mentors who are there to ensure the critical community-building aspect
(which was the concern of yours I was responding to) of the project
gets the needed attention...or the project will eventually get booted
out.  I would hate to ever be associated with a project that failed
incubation, but I have no problem with voting to kick out a project
that isn't trying to make things work.

I think the difference in our opinions may come down to trust in the
incubation process.  We've firmly established over the years that we
want to have a relatively low bar for entry into incubation (usually
some sort of initial code, committers to go with it, and an
understanding and willingness to  adopt/apply our community
principles).  This approach is supposed to welcome all those who want
to try to make this work with us.  We've never required that the
project is already operating like an Apache project; instead, we
ensure they are doing so before graduation.  And, if it's not working
out, we "retire" the project before it ever gets the full ASF
endorsement.

I only agreed to mentor this project after talking to, literally,
every single committer to make sure they understood how we do things,
that they were willing to commit to the required community work, and
that they understood that people like me will intervene if things
aren't going well.  I do this, because, otherwise, I'd just be setting
myself up for a really frustrating 6-24 months.

I completely respect your opinion, but I don't think that a proposal
thread is a representative environment for determining the expected
degree of transparency in future development work, nor do I think that
the spec this project wants to implement is less open than several
others being implemented at Apache today (including ones at "official"
standards orgs)...but you'll have to read my very long post if you
care to know more of my thoughts on that:
http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3cc5e632550607200133u7db769e9h241c6b2a381b5242@mail.gmail.com%3e.

Cliff

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

Re: [VOTE] Accept Glasgow into Incubator

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/4/06, Cliff Schmidt <cl...@gmail.com> wrote:

> Of course everyone should make their own minds about this after a
> careful reading of the threads  (and may see things differently),
> but....
>
> I wouldn't have agreed to champion the proposal if I had the sense
> there was not a commitment to create an open/transparent/meritocratic
> community around the project;

I'm certainly not going to argue with Cliff on this point, I'm sure he
has seen that commitment and thus can say that's what the people
bringing this proposal to us want to do, but personally, I don't have
that sort of insight into the situation at hand, I haven't had the
sort of interaction with the people involved that Cliff has, so all I
can base my opinion on is what's happened on this mailing list.

In any event, any questions I have about intentions regarding forming
open, meritocratic communities are only being raised because of the
relationship they have with the ability of new contributors to
participate in driving this specification.  The issues are
interconnected.

> nor would I, as a mentor, ever allow any project to move through
> incubation without actively working to create such a community.

I have no doubt that this is the case, and if I said anything that
implies otherwise I'm sorry.  I have a great deal of faith in Cliff as
a mentor, and I trust him to do the right thing with regard to
building communities at the ASF.

-garrett

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

Re: [VOTE] Accept Glasgow into Incubator

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

On 8/4/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 8/4/06, J Aaron Farr <fa...@apache.org> wrote:
> > On 8/3/06, Mads Toftum <ma...@toftum.dk> wrote:
> > > On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote:
> > > > I'm sorry, but I have to vote -1 (binding).
> > > >
> > > I very much agree with Garretts concerns - and would be much in favor of
> > > not bringing the project into incubation before they have proven an
> > > actual community and that they can work the standard the "apache way".
> > > I feel it would look very much as an ASF endorsement of a standard that
> > > we may not have any influence on at all - maybe things will look
> > > different in a few months time, but right now I'm far from convinced.
> >
> > I understand that there are some specific circumstances in this case,
> > but in general I believe this sort of criteria is why we get
> > complaints that it's impossible to "innovate" at Apache any more.  We
> > require all the grunt work of innovation to occur outside of Apache.
> >
> > The issues of an open specification is one thing.  But aren't "proven
> > an actual community" and "work the standard 'apache way'" graduation
> > requirements, not entry requirements?  If we expect something coming
> > into the incubator to already have a fully functioning, health
> > Apache-style community, then the only point of the Incubator is for
> > handling licensing issues.
>
> For what it's worth, I don't have any intrinsic problem with a group
> bringing some code to the ASF in an attempt to start a community
> around it, as long as that's what's actually happening.  The general
> feeling I got from reading the mail around this proposal wasn't
> leaning in that direction, now that could just be a missunderstanding
> on my part, but it is part of what convinced me to vote -1.

Of course everyone should make their own minds about this after a
careful reading of the threads  (and may see things differently),
but....

I wouldn't have agreed to champion the proposal if I had the sense
there was not a commitment to create an open/transparent/meritocratic
community around the project;

nor would I, as a mentor, ever allow any project to move through
incubation without actively working to create such a community.

Cliff

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

Re: [VOTE] Accept Glasgow into Incubator

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/4/06, J Aaron Farr <fa...@apache.org> wrote:
> On 8/3/06, Mads Toftum <ma...@toftum.dk> wrote:
> > On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote:
> > > I'm sorry, but I have to vote -1 (binding).
> > >
> > I very much agree with Garretts concerns - and would be much in favor of
> > not bringing the project into incubation before they have proven an
> > actual community and that they can work the standard the "apache way".
> > I feel it would look very much as an ASF endorsement of a standard that
> > we may not have any influence on at all - maybe things will look
> > different in a few months time, but right now I'm far from convinced.
>
> I understand that there are some specific circumstances in this case,
> but in general I believe this sort of criteria is why we get
> complaints that it's impossible to "innovate" at Apache any more.  We
> require all the grunt work of innovation to occur outside of Apache.
>
> The issues of an open specification is one thing.  But aren't "proven
> an actual community" and "work the standard 'apache way'" graduation
> requirements, not entry requirements?  If we expect something coming
> into the incubator to already have a fully functioning, health
> Apache-style community, then the only point of the Incubator is for
> handling licensing issues.

For what it's worth, I don't have any intrinsic problem with a group
bringing some code to the ASF in an attempt to start a community
around it, as long as that's what's actually happening.  The general
feeling I got from reading the mail around this proposal wasn't
leaning in that direction, now that could just be a missunderstanding
on my part, but it is part of what convinced me to vote -1.

-garrett

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

Re: [VOTE] Accept Glasgow into Incubator

[J Aaron Farr <fa...@apache.org>]

On 8/3/06, Mads Toftum <ma...@toftum.dk> wrote:
> On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote:
> > I'm sorry, but I have to vote -1 (binding).
> >
> I very much agree with Garretts concerns - and would be much in favor of
> not bringing the project into incubation before they have proven an
> actual community and that they can work the standard the "apache way".
> I feel it would look very much as an ASF endorsement of a standard that
> we may not have any influence on at all - maybe things will look
> different in a few months time, but right now I'm far from convinced.

I understand that there are some specific circumstances in this case,
but in general I believe this sort of criteria is why we get
complaints that it's impossible to "innovate" at Apache any more.  We
require all the grunt work of innovation to occur outside of Apache.

The issues of an open specification is one thing.  But aren't "proven
an actual community" and "work the standard 'apache way'" graduation
requirements, not entry requirements?  If we expect something coming
into the incubator to already have a fully functioning, health
Apache-style community, then the only point of the Incubator is for
handling licensing issues.

-- 
  jaaron

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

Re: [VOTE] Accept Glasgow into Incubator

[Mads Toftum <ma...@toftum.dk>]

On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote:
> I'm sorry, but I have to vote -1 (binding).
> 
I very much agree with Garretts concerns - and would be much in favor of
not bringing the project into incubation before they have proven an
actual community and that they can work the standard the "apache way".
I feel it would look very much as an ASF endorsement of a standard that
we may not have any influence on at all - maybe things will look
different in a few months time, but right now I'm far from convinced.

vh

Mads Toftum
-- 
`Darn it, who spiked my coffee with water?!' - lwall


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

Re: [VOTE] Accept Glasgow into Incubator

[Leo Simons <ma...@leosimons.com>]

On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote:
> I'm sorry, but I have to vote -1 (binding).

I'm not voting since I feel I haven't investigated this proposal in
enough detail, but I did have a general feeling of uneasyness, and now
Garrett has put some of that feeling into words which I strongly agree
with.

LSD

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

Re: [VOTE] Accept Glasgow into Incubator

[Garrett Rooney <ro...@electricjellyfish.net>]

I'm sorry, but I have to vote -1 (binding).

I'm not in favor of the ASF endorsing a specification that seems to be
completely under the control of a small number of companies with no
way for new developers to participate in its development.  The fact
that we have done this in the past is unfortunate, but it doesn't
change things in my opinion.  AMQP seems to be moving in this
direction, they've got some sort of agreement you can sign in order to
provide them feedback, that's a step, but I don't see any mailing
lists, I don't see any way for someone who doesn't work for one of the
companies in question to join as an equal member, and in general I
think it's premature for the ASF to get involved, and accepting an
incubator project is getting involved.

Additionally, since we've already decided that we need to do
"something" about the open/closed specification question with regard
to incubator projects, I think it's unfair to bring a new project into
the incubator when it's possible that our decision could result in
that project not being able to graduate.  If we know we're going to
have that debate eventually we should do so now, to wait until after
the project is in incubation seems unfair to them.

Finally, and I hate to say this because it may very well be just a
cultural difference between projects the Glasgow developers have
worked on and the way things work in ASF projects I'm familiar with, I
think it's disturbing that all answers to questions concerning this
proposal have been discussed in private and fed back to us through a
single person.  I don't see a community of individuals here, I see a
collection of companies working to bring a new project to the ASF
because they can benefit from the brand, and while that can certainly
change with time its combination with the other problems means I can't
vote in favor of the proposal.

-garrett

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

Re: [VOTE] Accept Glasgow into Incubator

[robert burrell donkin <ro...@gmail.com>]

On 8/3/06, Cliff Schmidt <cl...@gmail.com> wrote:

<snip>

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

+1

i do have a few comments

i agree with the substance of a couple of important points which have
led some people to vote -1 but i disagree about the right way to
proceed.

upon reflection, the use of proper nouns to name projects is a habit
that we need to break. however, IMHO this is something that does not
need to be addressed immediately for this project.

i also definitely agree with the importance of open standards.
however, apache has already achieved a great deal of good by engaging
with creators of standards. there seems to me to be a willingness to
move towards an open standards process. i think that we should (at
this stage of the process and given that the body is still
bootstrapping) be willing to give them the benefit of the doubt.

we can (and should) revisit the issue of standards later (perhaps at
the time of the first board report). we should know more then.

- robert

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

Re: [VOTE] Accept Glasgow into Incubator

[Brian McCallister <br...@apache.org>]

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


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

Re: [VOTE] Accept Glasgow into Incubator

[Jim Jagielski <ji...@jaguNET.com>]

+1

On Aug 3, 2006, at 12:52 PM, 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=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
>


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

Re: [VOTE] Accept Glasgow into Incubator

[sophitia que <so...@gmail.com>]

+1

Re: [VOTE] Accept Glasgow into Incubator

[J Aaron Farr <fa...@apache.org>]

+1

-- 
  jaaron

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

Re: SUBJECT NAMES

[Eelco Hillenius <ee...@gmail.com>]

I just realized I did that (too). My excuses for that, and I'll resend
my offending message with a proper subject name.

Eelco


On 8/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Everyone...
>
> Cliff Schmidt wrote:
> > Coach,
> >
> > If you don't view your question as related to the vote, would you mind
> > reposting it to a separate or an existing thread about Glasgow?
> >
> > Maybe it's just my personal preference, but I like to keep vote threads
> > to just votes and critical questions that were missed in the prior discussion
> > (which, I admit, often doesn't happen).
>
> Cliff - Amen.
>
> The general@i.a.o is already one of the broadest possible lists in the ASF.
>
> The fact that message subjects continue to be hijaaked
> is INCREDIBLY COUNTERPRODUCTIVE!!!
>
> if you want to fork the discussion, please please please, invent a new
> subject name.  Threaded mailreaders will note the fork from it's parent
> message - and the rest of us can sort out the dozens of conversations that
> happen each week and participate in those that are significant to us.
>
> I thank you who already do, and TIA to those who start ;-)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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

SUBJECT NAMES

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Everyone...

Cliff Schmidt wrote:
> Coach, 
> 
> If you don't view your question as related to the vote, would you mind
> reposting it to a separate or an existing thread about Glasgow?
> 
> Maybe it's just my personal preference, but I like to keep vote threads
> to just votes and critical questions that were missed in the prior discussion
> (which, I admit, often doesn't happen).

Cliff - Amen.

The general@i.a.o is already one of the broadest possible lists in the ASF.

The fact that message subjects continue to be hijaaked
is INCREDIBLY COUNTERPRODUCTIVE!!!

if you want to fork the discussion, please please please, invent a new
subject name.  Threaded mailreaders will note the fork from it's parent
message - and the rest of us can sort out the dozens of conversations that
happen each week and participate in those that are significant to us.

I thank you who already do, and TIA to those who start ;-)



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

Re: [VOTE] Accept Glasgow into Incubator

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

Coach, 

If you don't view your question as related to the vote, would you mind reposting it to a separate or an existing thread about Glasgow?

Maybe it's just my personal preference, but I like to keep vote threads to just votes and critical questions that were missed in the prior discussion (which, I admit, often doesn't happen). 

Thanks,
Cliff
  
  

-----Original Message-----
From: "Coach Wei" <co...@nexaweb.com>
Date: Thu, 3 Aug 2006 11:32:14 
To:<ge...@incubator.apache.org>
Subject: RE: [VOTE] Accept Glasgow into Incubator

+1 (non binding) from me.

A question unrelated to voting: What is the possible (estimated) minimum
implementation footprint (in term of kilobytes or megabytes) to support
AMQP network wire-level protocol? I am asking this thinking of the
possibility of using AMQP protocol in mobile applications such as J2ME. 

---Coach Wei

> -----Original Message-----
> From: Cliff Schmidt [mailto:cliffschmidt@gmail.com]
> Sent: Thursday, August 03, 2006 12:52 PM
> To: general@incubator.apache.org
> Subject: [VOTE] Accept Glasgow into Incubator
> 
> 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=
20
> 06&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


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

RE: [VOTE] Accept Glasgow into Incubator

[Coach Wei <co...@nexaweb.com>]

+1 (non binding) from me.

A question unrelated to voting: What is the possible (estimated) minimum
implementation footprint (in term of kilobytes or megabytes) to support
AMQP network wire-level protocol? I am asking this thinking of the
possibility of using AMQP protocol in mobile applications such as J2ME. 

---Coach Wei

> -----Original Message-----
> From: Cliff Schmidt [mailto:cliffschmidt@gmail.com]
> Sent: Thursday, August 03, 2006 12:52 PM
> To: general@incubator.apache.org
> Subject: [VOTE] Accept Glasgow into Incubator
> 
> 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=
20
> 06&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


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