July 2006 Incubator Board Report

[Noel J. Bergman]

This has been a busy month for the Incubator PMC, considering a number of
new submissions, such as:

  CeltixFire - a multiple vendor submission for a SOA platform
  Blaze - a proposed standard and set of implementations for messaging
  middleware interop
  Heraldry - an identity project

The Incubator continues to grow, and I have approached Dave Reid about
helping us to send out reminders to all of the Incubator projects, just as
he does for the rest of the ASF.

The Incubator PMC is reviewing our practices regarding Mentoring, and
revising our documentation in general.  Many thanks to Robert Burrell
Donkin, Noirin Plunkett, Justin Erenkrantz, Jean T. Anderson, and others for
their gratefully received contributions.

One good discussion has been on branding of projects in the Incubator.
Another good discussion was about the use of IRC, incorporated experiences
from multiple projects that use IRC, and effected the plans of at least one
Incubator project to use IRC.

Another topic that we are starting to discuss with an eye towards execution
is a policy on project dormancy, and what exactly to do to effect such a
project status.

Lastly, Cliff Schmidt raised the issue of disclosure regarding people being
contracted to act as Mentors, and the Incubator PMC agreed on a disclosure
policy that provides disclosure without appearing to be advertising.


-

=== Abdera ===

 1. Continued work on the code, working towards a 0.1.0 release
 1. Added two new committers to the project (Stephen Duncan and Garrett
Rooney). Stephen is still in discussions with his employer regarding his
CLA.
 1. Rob Yates' ICLA has been received and account set up
 1. Jira has been set up

=== Agila ===

The interest around the BPEL implementation in Agila has mostly moved to Ode
and the workflow part isn't evolving so declaring the project as dormant
sounds fair enough.

=== AltRMI ===

Nothing happening.  Incubator PMC likely to declare this project as dormant
as soon as we establish the mechanics.


=== Felix ===

Upayavira says "Felix progresses well as a community, increasing in
maturity, and I believe that Felix is nearly ready to graduate. In
preparation for that we have been going over the relevant issues:
auditing licensing of code and libraries, porting non-ASF services onto
ASF hardware (a Confluence wiki) and improving our public website."

Other details:

Community:
  * Stephane Frenot was added as a committer.
  * Defined and accepted Felix community roles and processes document.
  * Working with Maven community to get OSGi packaging features into the
Maven core with the involvement of Jason van Zyl and Peter Kriens.
  * Announced "Felix Commons" initiative for bundling common libraries for
use in the OSGi framework.
  * Working on and nearing completion of various graduation tasks, such as
license verification.

Code:
  * iPOJO project contribution which uses byte code instrumentation to
enable POJOs to be used in an OSGi environment and to simplify OSGi
development.
  * Event Admin standard OSGi R4 service implementation committed along with
bridges for UPnP, Wire Admin, and User Admin.
  * Managed OSGi framework using JMX committed.
  * Committed major updates to the OSGi Maven plugin to simplify bundle
packaging by auto-generating bundle metadata with the involvement of Peter
Kriens.
  * Many improvements to core Felix OSGi framework, such as auto-detecting
which core packages to export based on the current execution environment.
  * Several OSGi-related presentations at ApacheCon EU from Felix community
members.

Licensing:
  * Migrated Service Binder to kxml2 to avoid licensing issues with kxml1,
thanks to community member Jan Rellermeyer.
  * Need further investigation of MX4J licensing; it appears to be a
derivative of the Apache license.
  * Need further investigation of javax.microedition licensing.
  * Ensured that all source code has appropriate license headers

=== FtpServer ===

Nothing happening.  Incubator PMC likely to declare this project as dormant
as soon as we establish the mechanics.

=== Graffito ===

Raphael Luta is currently the only mentor for the Graffito project
that has been under incubation for nearly 2 years now.

Graffito is a CMS system now built on top of Jackrabbit and providing
a portlet based user interface. As such it is mostly suited to integrate
with portal containers like Jetspeed but some of the services provided
(like JCR mapping) can be useful outside of portal context.

While we've managed to slowly build a community around the initial
2 men codebase, we're still very far from having a sustainable
independant community around Graffito.

Due to his numerous other activities, Raphael feels he cannot provide alone
the adequate mentoring required by this project and so we are looking for
additionnal mentors to help grow the Graffito community and graduate it.

=== Harmony ===

The Harmony project c

Re: [Proposal] Blaze

[Gordon Sim]

James Strachan wrote:

On 7/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Ian Holsman wrote:
Blaze is about only AMQP, a proposed standard for interoperable 
messaging.
ActiveMQ implements multiple protocols.  There is some disagreement 
between

AMQP proponents and the ActiveMQ team regarding the desirability of
balkanizing messaging protocols.


I'd maybe rephrase that a little; AMQP proponents see AMQP as 'the one
protocol to bind them all' whereas the ActiveMQ team are pretty
flexible on protocols, we prefer to let users decide to use whatever
protocol makes sense for their requirements so we support several
(REST, Ajax, XML, WS-Notififaction, Jabber (never quite finished that
one), Stomp, OpenWire) and hopefully one day AMQP too.

Responding here as an individual, rather than on behalf of all AMQP 
proponents (and I don't think I would describe myself with that label!), 
I certainly don't see AMQP as the one protocol to bind them all. I agree 
with you entirely that the protocol should be selected based on the 
needs of the system being built. AMQP aims to add a protocol designed 
for message-oriented-middleware to the set from which that choice can be 
made, where currently all too often it is a product that dictates the 
protocol.


It is useful to hide various protocols behind a common API, but it is 
also useful to be able to implement various APIs using a common 
protocol. Both approaches give the user more freedom in their choice and 
more options for integration and interoperability.



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

Re: [Proposal] Blaze

[James Strachan]

On 7/19/06, Gordon Sim <[EMAIL PROTECTED]> wrote:

James Strachan wrote:
> On 7/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> Ian Holsman wrote:
>> Blaze is about only AMQP, a proposed standard for interoperable
>> messaging.
>> ActiveMQ implements multiple protocols.  There is some disagreement
>> between
>> AMQP proponents and the ActiveMQ team regarding the desirability of
>> balkanizing messaging protocols.
>
> I'd maybe rephrase that a little; AMQP proponents see AMQP as 'the one
> protocol to bind them all' whereas the ActiveMQ team are pretty
> flexible on protocols, we prefer to let users decide to use whatever
> protocol makes sense for their requirements so we support several
> (REST, Ajax, XML, WS-Notififaction, Jabber (never quite finished that
> one), Stomp, OpenWire) and hopefully one day AMQP too.
>
Responding here as an individual, rather than on behalf of all AMQP
proponents (and I don't think I would describe myself with that label!),
I certainly don't see AMQP as the one protocol to bind them all. I agree
with you entirely that the protocol should be selected based on the
needs of the system being built. AMQP aims to add a protocol designed
for message-oriented-middleware to the set from which that choice can be
made, where currently all too often it is a product that dictates the
protocol.

It is useful to hide various protocols behind a common API, but it is
also useful to be able to implement various APIs using a common
protocol. Both approaches give the user more freedom in their choice and
more options for integration and interoperability.


Agreed. BTW even with my ActiveMQ hat and blinkers firmly on, I
welcome AMQP and hope that one day it can be used as a way to
interoperate among different messaging providers - not just one or two
open source ones at Apache :) but maybe some of the commercial
products in this space too. (Today the JMS API is the only realistic
way to bridge them).

Incidentally I think Blaze totally deserves its own podling; its a
completely different community with different goals and a completely
different code base - but I hope to see some collaboration further
down the line so that code can be reused across ActiveMQ and Blaze.

e.g. already ActiveMQ should be able to reuse Blaze's AMQP marshalling
Java code so that we can add AMQP support to ActiveMQ too. We could
maybe merge Blaze's JMS client code with ActiveMQ's so users have a
single JMS client to work with across different broker implementations
and Blaze would then be able to reuse ActiveMQ's Resource Adapter code
for J2EE 1.4 compliance.

Currently ActiveMQ has several C/C++ clients (with another client
library waiting to get through the  donator's lawyers), so it might
make sense at some point to try unify the C++ clients together too so
users have a single C++ API for their messaging client and then a
number of implentations/transports/protocols to use at deployment
time. i.e. making a JMS for C++ API. (We've got a good start called
CMS in ActiveMQ...)

http://incubator.apache.org/activemq/activemq-cpp-client.html

--

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

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

Re: [Proposal] Blaze

[Paul Fremantle]

Currently ActiveMQ has several C/C++ clients (with another client
library waiting to get through the  donator's lawyers), so it might
make sense at some point to try unify the C++ clients together too so
users have a single C++ API for their messaging client and then a
number of implentations/transports/protocols to use at deployment
time. i.e. making a JMS for C++ API. (We've got a good start called
CMS in ActiveMQ...)


I agree that a C++ (and also C) rendering of a JMS like API is going
to be a very useful thing.

James - do you have any idea how CMS matches or differs from IBM's XMS
(http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html)?
XMS is also a rendering of JMS into C/C#/C++.

I think it would be interesting to see a confluence of the APIs and
protocols between ActiveMQ and Blaze giving interoperability in both
code and on the wire.

Paul



http://incubator.apache.org/activemq/activemq-cpp-client.html

--

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

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [Proposal] Blaze

[Gordon Sim]

James Strachan wrote:

I hope to see some collaboration further
down the line so that code can be reused across ActiveMQ and Blaze.


Agreed!

Paul Fremantle wrote:

I think it would be interesting to see a confluence of the APIs and
protocols between ActiveMQ and Blaze giving interoperability in both
code and on the wire.
Again, I agree. One point to add here though is that inevitably the API 
and protocol are not entirely orthogonal (as an example, in AMQP there 
are separate 'exchange' and 'queue' concepts from which, it is intended, 
different messaging patterns can be built). The challenge will therefore 
be to allow access to all features a protocol through a standard API. 
Perhaps a layered approach will be the simplest. Regardless, I look 
forward to more collaboration on this!


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

Re: [Proposal] Blaze

[Paul Fremantle]

By the way I support this proposal and am volunteering to join the
project and mentor. I've added my name to the wiki.

Paul

On 7/19/06, Gordon Sim <[EMAIL PROTECTED]> wrote:

James Strachan wrote:
> I hope to see some collaboration further
> down the line so that code can be reused across ActiveMQ and Blaze.

Agreed!

Paul Fremantle wrote:
> I think it would be interesting to see a confluence of the APIs and
> protocols between ActiveMQ and Blaze giving interoperability in both
> code and on the wire.
Again, I agree. One point to add here though is that inevitably the API
and protocol are not entirely orthogonal (as an example, in AMQP there
are separate 'exchange' and 'queue' concepts from which, it is intended,
different messaging patterns can be built). The challenge will therefore
be to allow access to all features a protocol through a standard API.
Perhaps a layered approach will be the simplest. Regardless, I look
forward to more collaboration on this!

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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [pre-proposal] AsyncWeb

[Paul Fremantle]

+1 to this (pre-)proposal.

Paul

On 7/18/06, Bill Stoddard <[EMAIL PROTECTED]> wrote:

Justin Erenkrantz wrote:
> On 7/15/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>> Everyone else that has been working with Dave is already an ASF
>> committer with a CLA on file at the ASF:
>>
>> Trustin Lee
>> Dan Diephouse
>> Alex Karasulu
>>
>> Yes let's get that software grant and a CLA from you Dave.  Considering
>> the constituents of the project at safehaus we might be able to take up
>> Justin's earlier suggestion to possibly import the project: moving the
>> source, doco (confluence) and jira issues all at once to the ASF.
>
> I think then a software grant and iCLA/CCLA plus a completed IP
> Clearance form from an ASF Officer or Member is sufficient (see the IP
> clearance template for the instructions on submission).
>
> Depending upon how substantial the contributions were from the 3
> ASFers, we might need Trustin, Dan, and Alex to also sign the software
> grant too for AsyncWeb.  The official policy is that we need software
> grants signed from all developers - but if you guys just submitted
> minor patches, that's probably not necessary - but if you developed
> large chunks of AsyncWeb too, then a grant should be filed too even
> though you have iCLAs on file.
>
>> Also note that there are no dependencies except on MINA.
>
> Good.
>
>> Why don't we start the process of importing the project into Directory
>> for now as a MINA protocol example and get the MINA TLP proposal before
>> the board. With the move of MINA (and AsyncWeb) out of Directory,
>> AsyncWeb will be under a MINA TLP.
>
> Honestly, I'd recommend flipping it: get MINA to be TLP first and then
> move in AsyncWeb.  There's no reason that AsyncWeb should land in the
> Directory TLP and then move again in short-order.  Ensure that the
> submitted charter of MINA can incorporate AsyncWeb sufficiently.  If
> you submit the resolution ASAP, it'll make it into this month's Board
> meeting (which is likely to be Wednesday, but that's not confirmed
> yet).  You can add Dave to the initial MINA PMC roster even though his
> project isn't in just yet, too.  Or, you can add him after the IP
> paperwork is filed too - whatever works best.
>
>> Or do you still see incubation as being necessary for AsyncWeb even
>> after getting a Grant and CLA from Dave?
>
> I personally don't think so.  We're talking about one committer
> joining an already existing ASF project and that individual has
> already worked with at least three other ASFers.  If the legal
> paperwork is filed (i.e. grant and iCLA/CCLA), I don't see the point
> of 'full' Incubation.  MINA's getting a chunk of code...the Incubator
> PMC just needs to ensure that the legal paperwork is received first.

+1.

Very interesting project BTW. Hope I can find time to participate ;-)

Bill


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





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [pre-proposal] AsyncWeb

[Afkham Azeez]

+1 to this proposal. I've also added my name to the list at
http://wiki.apache.org/incubator/AsyncWebProposal

Regards
Azeez

On 7/12/06, peter royal <[EMAIL PROTECTED]> wrote:

I have been talking with Dave Irving who is the principal developer
behind AsyncWeb, , an HTTP engine built
upon MINA , on
bringing the project to the ASF.

I've started a proposal at , assistance from others would be appreciated in
helping flesh it out.

I think this would be a good addition to the ASF, as there are many
projects that can benefit from a Java-based non-blocking HTTP server,
and I would also like to see some collaboration with the
HttpComponents project on their HttpNIO efforts.


thanks!

-pete

--
[EMAIL PROTECTED] - http://fotap.org/~osi










--
Thanks
Afkham Azeez

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

Re: [pre-proposal] AsyncWeb

[Saminda Abeyruwan]

+1.

Interesting project. I would really like to participate.

Saminda

On 7/19/06, Afkham Azeez <[EMAIL PROTECTED]> wrote:


+1 to this proposal. I've also added my name to the list at
http://wiki.apache.org/incubator/AsyncWebProposal

Regards
Azeez

On 7/12/06, peter royal <[EMAIL PROTECTED]> wrote:
> I have been talking with Dave Irving who is the principal developer
> behind AsyncWeb, , an HTTP engine built
> upon MINA , on
> bringing the project to the ASF.
>
> I've started a proposal at  AsyncWebProposal>, assistance from others would be appreciated in
> helping flesh it out.
>
> I think this would be a good addition to the ASF, as there are many
> projects that can benefit from a Java-based non-blocking HTTP server,
> and I would also like to see some collaboration with the
> HttpComponents project on their HttpNIO efforts.
>
>
> thanks!
>
> -pete
>
> --
> [EMAIL PROTECTED] - http://fotap.org/~osi
>
>
>
>
>
>
>


--
Thanks
Afkham Azeez

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

Please review Tuscany C++ M1 release candidate

[Pete Robbins]

I have initiated a vote on tuscany-dev@ws.apache.org to publish a release of
the Tuscany C++ implementation.
The vote email thread is available here:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05134.html

As this is the first time that we are attempting a C++  incubation
release so I would appreciate if you could take a look at the
distributions ( http://people.apache.org/~robbinspg/RC-3b) and give us
feedback and let us know if we need to fix anything.

If the vote on tuscany-dev is successful, we will send a summary of that
vote to the Incubator's general list to formally request the Incubator
PMC to approve the release.

Cheers,

--
Pete

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Jason van Zyl]

On 18 Jul 06, at 9:38 PM 18 Jul 06, Noel J. Bergman wrote:


Jason,

I am +1 for the project, overall.

I do suggest that we start out with the PPMC of you and the other  
Mentors,
have you bring Dan and other appropriate people onto the PMC as  
your first
order of business, and them go about selecting Committers.  From  
what I
recall at ApacheCon, there was some uncertaintly about the current  
roster,

so let's allow the PPMC to review and address as appropriate.


Sure, once the vote is formally complete and we move on the next  
phase I'll get that rolling.




As was discussed at ApacheCon EU, I hope that the project will  
continue
efforts to collaborate with the rest of the Web Services community  
at the
ASF, because I hate to see wasted, redundant, effort when  
collaboration is
possible.  And it certainly appears from discussion that they are  
willing to

explore any number of options.


I think Dan has shown from past efforts that he's always worked well  
with the WS efforts and has a good relationship with them and will  
continue that trend. The rest of us will follow Dan's example there  
so I think we'll be fine.




So give it your best effort, and good luck.  :-)



Thanks, much appreciated.


--- Noel


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




Jason van Zyl
[EMAIL PROTECTED]




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

Re: [Proposal] Blaze

[Carl Trieloff]

This worries me - accepting an implementation whose specification does
not yet have a defined license or containing standards body. Maybe
we've done it before though.

This is not true - AMQP has a well defined license and it is posted in 
the spec, and you can implement

the specification freely - without strings.

On the topic of  - at which standards body it will land at, why is that 
a concern, as the license of

the specification is well defined no matter where it goes

Regards
Carl.


Henri Yandell wrote:

On 7/18/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:


Thanks for the comments - I will be brief and then we can have follow up
exchange as required. comments in-line.


Brian McCallister wrote:
> Comments in line:
>
> On Jul 17, 2006, at 12:10 PM, Carl Trieloff wrote:
>
>> == 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.
>
> Which standards body? What licensing terms apply to the spec?

The body has not been selected yet, this will be decided by the group
working on the Spec. It will be one of the common suspects. This
group is set up very similar to Tuscany / SCA setup with some key
differences which I will highlight a few in the other answers.


This worries me - accepting an implementation whose specification does
not yet have a defined license or containing standards body. Maybe
we've done it before though.

Afaik, and I know little, I thought there were bodies whose rules were
such that we didn't want to work with them. Does that stop us wanting
to do implementations?

Hen



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

Re: [Proposal] Blaze

[Davanum Srinivas]

Carl,

Please bear with me. As a mentor for Tuscany, i am struggling with
same kind of issues with SCA. Namely access to the spec, access to
influence the spec and moving the spec to an external
organizationSo let's see if we can derive any lessons learned from
our experience.

IANAL, Is there an assurance in the license that all *future* revs to
the spec will have the same license? If not how can an Apache project
be sure that it can track the spec?

Let's say it goes to OASIS, then the spec is "donated" to OASIS and
goes under the current IP regime for OASIS which has no guarantee that
the future revs to the spec will be implementable in open source. Do
you see it differently?

thanks,
dims

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:


This worries me - accepting an implementation whose specification does
not yet have a defined license or containing standards body. Maybe
we've done it before though.

This is not true - AMQP has a well defined license and it is posted in
the spec, and you can implement
the specification freely - without strings.

On the topic of  - at which standards body it will land at, why is that
a concern, as the license of
the specification is well defined no matter where it goes

Regards
Carl.


Henri Yandell wrote:
> On 7/18/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>>
>> Thanks for the comments - I will be brief and then we can have follow up
>> exchange as required. comments in-line.
>>
>>
>> Brian McCallister wrote:
>> > Comments in line:
>> >
>> > On Jul 17, 2006, at 12:10 PM, Carl Trieloff wrote:
>> >
>> >> == 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.
>> >
>> > Which standards body? What licensing terms apply to the spec?
>>
>> The body has not been selected yet, this will be decided by the group
>> working on the Spec. It will be one of the common suspects. This
>> group is set up very similar to Tuscany / SCA setup with some key
>> differences which I will highlight a few in the other answers.
>
> This worries me - accepting an implementation whose specification does
> not yet have a defined license or containing standards body. Maybe
> we've done it before though.
>
> Afaik, and I know little, I thought there were bodies whose rules were
> such that we didn't want to work with them. Does that stop us wanting
> to do implementations?
>
> Hen


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





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

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

Re: [Proposal] Blaze

[Carl Trieloff]

Niclas Hedhman wrote:

On Wednesday 19 July 2006 03:07, Carl Trieloff wrote:
  

 I have provided a direct link to one of the docs on our site
http://www.redhat.com/f/pdf/amqp/amqp_0-8_specification.pdf



The license is for the specification, which is far from an obvious one, so I 
would suggest to run this via [EMAIL PROTECTED]


The main questions for me would be;

 1. Does the specification allows ASF to develop an Apache licensed 
implementation?
  

yes.
 2. Are there parts of the specification that must be included in any 
distribution that limits the down-stream rights (the spec mentions that the 
spec itself is non-transferable)?
  

If I understand correctly what you are asking  - no, no limitations.

I will add this to be clear. anyone may copy, distribute, implement the 
spec as long as they include the license - they can

do so in whole or any part there of


Further,
Are there any TCK associated with this work that are part of the specification 
work, and if so what are the licensing requirements at this end?
  

no.


If we need to I will be glad to do additional follow-up with Apache 
legal on any issues that
requires that. We spend many hours well more like months looking at the 
issues, so I am glad

to provide information as required.

Regards
Carl.


Cheers
Niclas

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

  

Re: [Proposal] Blaze

[Paul Fremantle]

Carl

I think some of the team have a good point on the IP and licensing
issues. One issue that is very frustrating from an Apache perspective
is if there are some committers involved in the spec process, and
other committers not involved.

This is frustrating for both halves: the committers who (by dint of
which employer they work for) have access to information and knowledge
about future unpublished spec changes have to be very careful: they
might donate IP to Apache that is under NDA and they don't have the
right to use in code.

The committers who are NOT part of the spec body have the opposite
issue - they are "in the dark" which is also frustrating.

A second concern I have is to do with the patent status of this work.
I know from personal experience that there are a number of patents on
reliable messaging held by major companies such as IBM, Microsoft,
Tibco, who are not part of the AMQP effort. To what extent have the
AMQP team evaluated the spec and codebase for patent infringement?

Paul



On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:

Niclas Hedhman wrote:
> On Wednesday 19 July 2006 03:07, Carl Trieloff wrote:
>
>>  I have provided a direct link to one of the docs on our site
>> http://www.redhat.com/f/pdf/amqp/amqp_0-8_specification.pdf
>>
>
> The license is for the specification, which is far from an obvious one, so I
> would suggest to run this via [EMAIL PROTECTED]
>
> The main questions for me would be;
>
>  1. Does the specification allows ASF to develop an Apache licensed
> implementation?
>
yes.
>  2. Are there parts of the specification that must be included in any
> distribution that limits the down-stream rights (the spec mentions that the
> spec itself is non-transferable)?
>
If I understand correctly what you are asking  - no, no limitations.

I will add this to be clear. anyone may copy, distribute, implement the
spec as long as they include the license - they can
do so in whole or any part there of
>
> Further,
> Are there any TCK associated with this work that are part of the specification
> work, and if so what are the licensing requirements at this end?
>
no.


If we need to I will be glad to do additional follow-up with Apache
legal on any issues that
requires that. We spend many hours well more like months looking at the
issues, so I am glad
to provide information as required.

Regards
Carl.
>
> Cheers
> Niclas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>






--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Re: [Proposal] Blaze

[Brian McCallister]

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


Ian Holsman wrote:


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


Blaze's goal (AMQP) is to provide multple language implementations  
of a
language-neutral, wire-level, protocol with a ton of detailed  
semantics for

interoperable messaging.  JMS is a a Java API.


I am wholly behind the goal of establishing an open standard protocol  
for async messaging. Heck, I helped spec one out (which I would be  
happy to see supplanted by something better!), but I fear the way the  
protocol spec works here probably won't work well for an Apache project.


Blaze seems to be about about providing implementations of a  
proprietary protocol controlled by a group of vendors and one major  
customer. The protocol is specified behind closed doors with good  
intentioned but legally nebulous licensing. Participation in the  
protocol specification process by folks outside the initial group is  
by submitting suggestions to a private channel. The protocol is  
specifically controlled by a group of companies, with no provision  
for individual participation. On the other hand, Apache is  
specifically made up of individuals, not companies, and merit is  
based on the actions of the individual.


The protocol being implemented is pretty much controlled by a  
separate, closed body. There is presently no way for Apache  
contributors to participate in, or even observe, the protocol  
specification process. The eventual standards body to which it is to  
be submitted is unknown, and there are definitely standards bodies  
which are incompatible with Apache (any pay-to-play, or any barring  
individual participation, tend to be difficult) style development.


So basically, if the project's goal is to provide a couple reference  
implementations and various client libraries for an in-development  
closed protocol (with well intentioned licensing) which is being  
developed via a process which precludes participation by folks  
working on the Apache project unless their employer (who may not even  
be aware of their participation) signs an IP agreement? Even then,  
the path to joining the protocol specification group is by submitting  
suggestions to private discussion in which you are not included.


If the protocol came with the project, the protocol lived in a  
standards body such as the IETF, or even if the protocol was being  
developed in the open using an apache-style meritocracy, I would be  
100% for this. As it stands, I worry that it is incompatible with  
Apache.


-Brian




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

[jira] Created: (INCUBATOR-29) Wording change to policy document (Entry To Incubator Section)

[Robert Burrell Donkin (JIRA)]

Wording change to policy document (Entry To Incubator Section)
--

 Key: INCUBATOR-29
 URL: http://issues.apache.org/jira/browse/INCUBATOR-29
 Project: Incubator
  Issue Type: Improvement
  Components: site
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


This change does not alter policy. At the moment, the policy document contains 
a large quantity of discursive material in addition to policy. Not only does 
this mean that documentation has to be maintained in two places but also the 
discursive material cannot be changes without a VOTE. This change replaces 
discursive material with a link to a guide.

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -214,7 +214,8 @@
 
   Entry to Incubation
 
-  Entry to Incubation requires a number of hurdles be passed.
+  Please read the guide to the process
+  in conjunction with this policy.
 
   
 Proposal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [Proposal] Blaze

[Carl Trieloff]

Davanum Srinivas wrote:

Carl,

Please bear with me. As a mentor for Tuscany, i am struggling with
same kind of issues with SCA. Namely access to the spec, access to
influence the spec and moving the spec to an external
organizationSo let's see if we can derive any lessons learned from
our experience.

IANAL, Is there an assurance in the license that all *future* revs to
the spec will have the same license?

yes

If not how can an Apache project
be sure that it can track the spec?

project goal is to implement published versions, but I see no reason why 
Apache

could not look at joining the working group.

Let's say it goes to OASIS, then the spec is "donated" to OASIS and
goes under the current IP regime for OASIS which has no guarantee that
the future revs to the spec will be implementable in open source. Do
you see it differently?

I see it differently, the Working Groups contracts address this
issue - state how the spec will be licensed. Under OASIS, AMQP license
should map to "RF on Limited Terms".


thanks,
dims

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:


This worries me - accepting an implementation whose specification does
not yet have a defined license or containing standards body. Maybe
we've done it before though.

This is not true - AMQP has a well defined license and it is posted in
the spec, and you can implement
the specification freely - without strings.

On the topic of  - at which standards body it will land at, why is that
a concern, as the license of
the specification is well defined no matter where it goes

Regards
Carl.


Henri Yandell wrote:
> On 7/18/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>>
>> Thanks for the comments - I will be brief and then we can have 
follow up

>> exchange as required. comments in-line.
>>
>>
>> Brian McCallister wrote:
>> > Comments in line:
>> >
>> > On Jul 17, 2006, at 12:10 PM, Carl Trieloff wrote:
>> >
>> >> == 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.
>> >
>> > Which standards body? What licensing terms apply to the spec?
>>
>> The body has not been selected yet, this will be decided by the group
>> working on the Spec. It will be one of the common suspects. This
>> group is set up very similar to Tuscany / SCA setup with some key
>> differences which I will highlight a few in the other answers.
>
> This worries me - accepting an implementation whose specification does
> not yet have a defined license or containing standards body. Maybe
> we've done it before though.
>
> Afaik, and I know little, I thought there were bodies whose rules were
> such that we didn't want to work with them. Does that stop us wanting
> to do implementations?
>
> Hen


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








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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[William A. Rowe, Jr.]

Noel J. Bergman wrote:


Some would be highly offended, and a few would bother to look for the
signal embedded in the noise.  But when one tries to become an active
participant in a community, the dynamic changes, and so must one's
interactions with others.  My point to Mladen, and I believe the point
that Jim and others have made, too, is that this is a normal social
process that can benefit both the community and the individual.> 


+1; I like the way you put this all.  I had mentioned in my last post (in case
it didn't stand out)...

"they would be asked to move on if they can't come to terms with that concept."

That's key - participating in open source is evolutionary for the software,
and should be evolutionary for the participants ... Software learns new
facilities, features, optimizations.  Participants learn more coding and
architecture/design skills.  But we hope participants also learn community
skills, from the way things happen within the ASF :)

Caution is normal/expected here.  But we should also exercise some faith
that the problems identified will be resolved, if the team or individuals
we raise the problems with are willing to solve them.  After all, most all
of us are here & members of our projects or the ASF because some other
members had faith that we would make good participants.




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

Re: [Proposal] Blaze

[Carl Trieloff]

Paul Fremantle wrote:

Carl

I think some of the team have a good point on the IP and licensing
issues. One issue that is very frustrating from an Apache perspective
is if there are some committers involved in the spec process, and
other committers not involved.

This is frustrating for both halves: the committers who (by dint of
which employer they work for) have access to information and knowledge
about future unpublished spec changes have to be very careful: they
might donate IP to Apache that is under NDA and they don't have the
right to use in code.

The work in AMQP is not under NDA, however IPR rights are only granted
on each version of the spec as it is published. This is true for just 
about all of the
standards process, so the group can deal with issues if they want. So I 
don't see that it
is meaning-full to commit draft work into an OSS project, but it might 
make sense for
the team at large to see updates that could help out in the project 
knowing how things may

change.

I see two options:
a.) The project requests of the Working Group to review drafts
b.) Apache looks at joining the Working Group.

Both should resolve this issue.



The committers who are NOT part of the spec body have the opposite
issue - they are "in the dark" which is also frustrating.

covered above


A second concern I have is to do with the patent status of this work.
I know from personal experience that there are a number of patents on
reliable messaging held by major companies such as IBM, Microsoft,
Tibco, who are not part of the AMQP effort. To what extent have the
AMQP team evaluated the spec and codebase for patent infringement?


The code is original work using common patterns that are widely used,
will cover details in the submission of the CCLA and code grant with
Apache legal.


Good questions, thanks
Carl.



Paul



On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:

Niclas Hedhman wrote:
> On Wednesday 19 July 2006 03:07, Carl Trieloff wrote:
>
>>  I have provided a direct link to one of the docs on our site
>> http://www.redhat.com/f/pdf/amqp/amqp_0-8_specification.pdf
>>
>
> The license is for the specification, which is far from an obvious 
one, so I

> would suggest to run this via [EMAIL PROTECTED]
>
> The main questions for me would be;
>
>  1. Does the specification allows ASF to develop an Apache licensed
> implementation?
>
yes.
>  2. Are there parts of the specification that must be included in any
> distribution that limits the down-stream rights (the spec mentions 
that the

> spec itself is non-transferable)?
>
If I understand correctly what you are asking  - no, no limitations.

I will add this to be clear. anyone may copy, distribute, implement the
spec as long as they include the license - they can
do so in whole or any part there of
>
> Further,
> Are there any TCK associated with this work that are part of the 
specification

> work, and if so what are the licensing requirements at this end?
>
no.


If we need to I will be glad to do additional follow-up with Apache
legal on any issues that
requires that. We spend many hours well more like months looking at the
issues, so I am glad
to provide information as required.

Regards
Carl.
>
> Cheers
> Niclas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>









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

RE: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Sanjiva Weerawarana]

On Tue, 2006-07-18 at 21:38 -0400, Noel J. Bergman wrote:
> Jason,
> 
> I am +1 for the project, overall.
> 
> I do suggest that we start out with the PPMC of you and the other Mentors,
> have you bring Dan and other appropriate people onto the PMC as your first
> order of business, and them go about selecting Committers.  From what I
> recall at ApacheCon, there was some uncertaintly about the current roster,
> so let's allow the PPMC to review and address as appropriate.
> 
> As was discussed at ApacheCon EU, I hope that the project will continue
> efforts to collaborate with the rest of the Web Services community at the
> ASF, because I hate to see wasted, redundant, effort when collaboration is
> possible.  And it certainly appears from discussion that they are willing to
> explore any number of options.
> 
> So give it your best effort, and good luck.  :-)

+1 Noel. I'd like to join the PPMC too as an interested party observer.
I will poke my nose in as a mentor when possible but don't have the
cycles to commit to it.

Sanjiva.


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Sanjiva Weerawarana]

On Tue, 2006-07-18 at 23:02 +0100, robert burrell donkin wrote:
> now hani's becoming a somewhat important and certainly famous figure in the
> java ecosystem i hope that he'd start to realize that some people are hurt
> by his offensive posts and lay off the personal stuff with those folks who
> don't appreciate his humour.

Personally speaking I wasn't hurt buy the crap he writes on his blog.

However, I will not tolerate any personal attacks on ASF lists and if
any of that spills over to the blog I will not tolerate it either. Hurt?
No. Tolerate? No either.

Sanjiva.



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

Re: [Proposal] Blaze

[James Strachan]

On 7/19/06, Gordon Sim <[EMAIL PROTECTED]> wrote:

James Strachan wrote:
> I hope to see some collaboration further
> down the line so that code can be reused across ActiveMQ and Blaze.

Agreed!

Paul Fremantle wrote:
> I think it would be interesting to see a confluence of the APIs and
> protocols between ActiveMQ and Blaze giving interoperability in both
> code and on the wire.
Again, I agree. One point to add here though is that inevitably the API
and protocol are not entirely orthogonal (as an example, in AMQP there
are separate 'exchange' and 'queue' concepts from which, it is intended,
different messaging patterns can be built). The challenge will therefore
be to allow access to all features a protocol through a standard API.
Perhaps a layered approach will be the simplest. Regardless, I look
forward to more collaboration on this!


Agreed! For something so apparently simple (sending messages from
producers to consumers) messaging can be amazingly complicated :)

But I'm sure we will be able to come up with some levels of reuse
across various protocols. e.g. I've already seen some quite good
layering in the soon-to-be-contributed C++ client for ActiveMQ (e.g. a
single threaded C++ layer first, then a multi threaded layer, then a
JMS-like abstraction etc).

I'm sure we'll be able to add most semantics behind a standard API and
layer added features above it where need be.
--

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

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

[jira] Created: (INCUBATOR-30) Remove commented out material from policy document

[Robert Burrell Donkin (JIRA)]

Remove commented out material from policy document
--

 Key: INCUBATOR-30
 URL: http://issues.apache.org/jira/browse/INCUBATOR-30
 Project: Incubator
  Issue Type: Improvement
  Components: site
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


A policy document using RTC should not contain commented out content. This 
change is not semantically significant.

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -13,26 +13,6 @@
 http://purl.org/DC/elements/1.0/"; rel="schema.DC"/>
   
   
-  
 
  Incubation Policy: Table of Contents
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [Proposal] Blaze

[James Strachan]

On 7/19/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:

> Currently ActiveMQ has several C/C++ clients (with another client
> library waiting to get through the  donator's lawyers), so it might
> make sense at some point to try unify the C++ clients together too so
> users have a single C++ API for their messaging client and then a
> number of implentations/transports/protocols to use at deployment
> time. i.e. making a JMS for C++ API. (We've got a good start called
> CMS in ActiveMQ...)

I agree that a C++ (and also C) rendering of a JMS like API is going
to be a very useful thing.

James - do you have any idea how CMS matches or differs from IBM's XMS
(http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html)?
XMS is also a rendering of JMS into C/C#/C++.


Thanks for the link! I've had a quick look and it looks remarkably
close to the current CMS client. Hardly surprising I guess since they
are both kinda clones of the JMS API but in C++ and using JMS 1.1 and
mostly ignoring the crappy bits of JMS 1.0.2b :)

I couldn't see the C# client so not sure if we differ a bit there - we
ended up changing the C# client a little from JMS to make use of C#
coding conventions and features (like delegates and events etc) - and
we followed that sucky C# practice of naming interfaces IConnection
etc :). Not sure if the XMS in C# does the same. (We imaginatively
called the C# client NMS for .Net Messaging System).

I wonder if IBM and the XMS folks would be interested in donating the
*API* code for XMS to Apache and working with other folks at Apache so
we can merge some of the C/C++/C# clients together into a single
reuable client API with pluggable providers (and maybe even some
resuable optional implementation code different implementations could
choose to reuse)?

There's clearly a delta between AMQP and the features of JMS, but even
if we just get the core JMS semantics reusable across the clients it'd
be a big win IMHO.



I think it would be interesting to see a confluence of the APIs and
protocols between ActiveMQ and Blaze giving interoperability in both
code and on the wire.


Agreed.
--

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

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

[jira] Created: (INCUBATOR-31) Change wording to more cleanly separate the roles document from the policy one

[Robert Burrell Donkin (JIRA)]

Change wording to more cleanly separate the roles document from the policy one
--

 Key: INCUBATOR-31
 URL: http://issues.apache.org/jira/browse/INCUBATOR-31
 Project: Incubator
  Issue Type: Improvement
  Components: site
Reporter: Robert Burrell Donkin


Descriptions and definitions are split between two documents: policy and roles. 
I think it cleaner to move leave just definitions in the policy and link to the 
appropriate discursive material in roles.

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -79,7 +79,7 @@
 Post-Graduation Check 
List
   
 
-Roles in the Incubation 
Process
+Roles Defined
   
 Incubator
Project Management Committee (PMC)
@@ -826,9 +826,9 @@
   
 
 
-  Roles in the Incubation Process
+  Roles Defined
 
-  This section describes the roles involved in the Incubation process.
+  Definitions of the roles involved in the Incubation process.
 
   
 Incubator Project Management Committee (PMC)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (INCUBATOR-31) Change wording to more cleanly separate the roles document from the policy one

[Robert Burrell Donkin (JIRA)]

 [ http://issues.apache.org/jira/browse/INCUBATOR-31?page=all ]

Robert Burrell Donkin reassigned INCUBATOR-31:
--

Assignee: Robert Burrell Donkin

> Change wording to more cleanly separate the roles document from the policy one
> --
>
> Key: INCUBATOR-31
> URL: http://issues.apache.org/jira/browse/INCUBATOR-31
> Project: Incubator
>  Issue Type: Improvement
>  Components: site
>Reporter: Robert Burrell Donkin
> Assigned To: Robert Burrell Donkin
>
> Descriptions and definitions are split between two documents: policy and 
> roles. I think it cleaner to move leave just definitions in the policy and 
> link to the appropriate discursive material in roles.
> Index: site-author/incubation/Incubation_Policy.xml
> ===
> --- site-author/incubation/Incubation_Policy.xml(revision 423542)
> +++ site-author/incubation/Incubation_Policy.xml(working copy)
> @@ -79,7 +79,7 @@
>  Post-Graduation Check 
> List
>
>  
> -Roles in the Incubation 
> Process
> +Roles Defined
>
>  Incubator
> Project Management Committee (PMC)
> @@ -826,9 +826,9 @@
>
>  
>  
> -  Roles in the Incubation Process
> +  Roles Defined
>  
> -  This section describes the roles involved in the Incubation process.
> +  Definitions of the roles involved in the Incubation process.
>  
>
>  Incubator Project Management Committee (PMC)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (INCUBATOR-32) Add links from policy into roles and vice verses

[Robert Burrell Donkin (JIRA)]

Add links from policy into roles and vice verses


 Key: INCUBATOR-32
 URL: http://issues.apache.org/jira/browse/INCUBATOR-32
 Project: Incubator
  Issue Type: Improvement
  Components: site
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


Links role <-> policy for candidate

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -877,7 +877,8 @@
   
 Candidate
 
-A project that is proposed for incubation.
+A proposal for incubation. Described in detail 
+here.
 
   
   
Index: site-author/incubation/Roles_and_Responsibilities.xml
===
--- site-author/incubation/Roles_and_Responsibilities.xml   (revision 
423542)
+++ site-author/incubation/Roles_and_Responsibilities.xml   (working copy)
@@ -86,7 +86,8 @@
   
 Candidate
 
-A Candidate is a project that is proposed for incubation. A 
Candidate
+A Candidate [definition] is a project proposed 
for 
+incubation. A Candidate
 shall meet the following minimum criteria:
 
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [Proposal] Blaze

[Henri Yandell]

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:



Henri said:
This worries me - accepting an implementation whose specification does
not yet have a defined license or containing standards body. Maybe
we've done it before though.


This is not true - AMQP has a well defined license and it is posted in
the spec, and you can implement
the specification freely - without strings.


Bad wording on my part. I mean the license once it is at the standards body.


On the topic of  - at which standards body it will land at, why is that
a concern, as the license of
the specification is well defined no matter where it goes


I was assuming that standard bodies dictate the license to a large
extent, and given that those have caused trouble in the past the idea
of a new project with that still undefined is a worry. The term
"standards body" is a mental flag :)

I asked Cliff as champion about this bit and he said he'd reply here
in a few hours.

Hen

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

[jira] Created: (INCUBATOR-33) Clarify Role of Champion And Consolidate Policy

[Robert Burrell Donkin (JIRA)]

Clarify Role of Champion And Consolidate Policy
---

 Key: INCUBATOR-33
 URL: http://issues.apache.org/jira/browse/INCUBATOR-33
 Project: Incubator
  Issue Type: Improvement
  Components: policy
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


The currently document is contradictory. 
http://incubator.apache.org/incubation/Incubation_Policy.html#Champion includes 
a little discussion of the role and implies that only champions can be members. 
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion 
uses declarative language and allows members and champions. This isn't good and 
needs resolving one way or another.

Elections championed by Officers have succeeded in the past and I see no reason 
why Champions should not be officers though this may - or may not - prevent 
then acting as mentors. So, this patch consolidates the documentation in that 
direction. I'm willing to create a similar patch if the converse opinion is in 
the majority.

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -883,10 +883,16 @@
   
 Champion
 
-A Member of the Apache Software Foundation who supports a 
Candidate's
-application for Incubation and who supports and assists the Podling
-through the Incubation process.
+The Champion who nominates the proposal SHALL support and assist 
+the Candidate's application through the Incubation Process. Described in 
detail 
+here.
 
+The Champion MUST be an
+  http://www.apache.org/foundation/index.html";>Officer
+or
+  http://www.apache.org/foundation/members.html";>Member
+of the Foundation.
+
   
   
 Sponsor
Index: site-author/incubation/Roles_and_Responsibilities.xml
===
--- site-author/incubation/Roles_and_Responsibilities.xml   (revision 
423542)
+++ site-author/incubation/Roles_and_Responsibilities.xml   (working copy)
@@ -123,13 +123,9 @@
   
 Champion
 
-A candidate project shall be sponsored by an
-
-  http://www.apache.org/foundation/index.html";>Officer
-or
-
-  http://www.apache.org/foundation/members.html";>Member
-of the Foundation. The Champion assists the candidate on their
+A candidate must have a Champion 
+[definition]. 
+The Champion assists the candidate on their
 initial submission to a Sponsor. While private conversations are not
 generally encouraged within the Apache community, the Champion's
 relationship with the Candidate should allow for this in order to

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (INCUBATOR-34) Clarify Role of Champion And Consolidate Policy [ALTERNATIVE]

[Robert Burrell Donkin (JIRA)]

Clarify Role of Champion And Consolidate Policy [ALTERNATIVE]
-

 Key: INCUBATOR-34
 URL: http://issues.apache.org/jira/browse/INCUBATOR-34
 Project: Incubator
  Issue Type: Improvement
  Components: policy
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


Alternative clarification: only members

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -883,10 +883,14 @@
   
 Champion
 
-A Member of the Apache Software Foundation who supports a 
Candidate's
-application for Incubation and who supports and assists the Podling
-through the Incubation process.
+The Champion who nominates the proposal SHALL support and assist 
+the Candidate's application through the Incubation Process. Described in 
detail 
+here.
 
+The Champion MUST be an
+  http://www.apache.org/foundation/members.html";>Member
+of the Foundation.
+
   
   
 Sponsor
Index: site-author/incubation/Roles_and_Responsibilities.xml
===
--- site-author/incubation/Roles_and_Responsibilities.xml   (revision 
423542)
+++ site-author/incubation/Roles_and_Responsibilities.xml   (working copy)
@@ -123,13 +123,9 @@
   
 Champion
 
-A candidate project shall be sponsored by an
-
-  http://www.apache.org/foundation/index.html";>Officer
-or
-
-  http://www.apache.org/foundation/members.html";>Member
-of the Foundation. The Champion assists the candidate on their
+A candidate must have a Champion 
+[definition]. 
+The Champion assists the candidate on their
 initial submission to a Sponsor. While private conversations are not
 generally encouraged within the Apache community, the Champion's
 relationship with the Candidate should allow for this in order to

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Champions: policy clarification required

[robert burrell donkin]

i've been analysing the current policy document: cross referencing and
drawing up policy-neutral rationalisations in JIRA (planning to use a single
VOTE thread for all these changes since require prior PMC approval is
required before commit).

i've run into a problem.
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Championis
not consistent with
http://incubator.apache.org/incubation/Incubation_Policy.html#Champion.
roles states champions can be officers or members whereas policy implies
only members. so, i can't consolidate in a policy-neutral fashion.

i've create two alternative patches in JIRA (
https://issues.apache.org/jira/browse/INCUBATOR-33 and
https://issues.apache.org/jira/browse/INCUBATOR-34). i plan to put both to a
VOTE to let the PMC clarify their intent but thought it best to allow people
to jump in and start a discussion thread first.

anyone have strong opinions as to whether Champions should be only members?

- robert

[jira] Created: (INCUBATOR-35) Move discursive material about PMC from policy to roles and responsibilities

[Robert Burrell Donkin (JIRA)]

Move discursive material about PMC from policy to roles and responsibilities


 Key: INCUBATOR-35
 URL: http://issues.apache.org/jira/browse/INCUBATOR-35
 Project: Incubator
  Issue Type: Improvement
  Components: site
Reporter: Robert Burrell Donkin
 Assigned To: Robert Burrell Donkin


Consolidate discursive material onto roles and responsibilities. Added cross 
links.

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 423542)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -833,38 +833,14 @@
   
 Incubator Project Management Committee (PMC)
 
-(From the resolution that created the Incubator Project - see
-http://incubator.apache.org/resolution.html)
+The Project Management Committee is responsible to the Board for 
administering 
+the Incubator Project in the manner specified in the founding
+resolution.
 
-The Incubator PMC is responsible for :
+
+The roles and responsibilities of the PMC are described and discussed 
+here.
 
-
-  acceptance and oversight of candidate projects submitted or 
proposed
-to become part of the Foundation;
-
-  providing guidance and ensuring that sub-projects under it's 
purview
-develop products according to the Foundation's philosophy and
-guidelines for collaborative development;
-
-  providing a repository for the storage of incubation history and
-information;
-
-  assisting a Podling's Mentor in discharging her/his duties;
-
-  regularly evaluating projects under its purview for the purposes 
of
-recommending to the Sponsor whether the project should:
-
-  
-
-  successfully exit incubation;
-
-  continue to receive guidance and support within the 
Incubator; or
-
-  be terminated.
-
-
-  
-
   
   
 Chair of the Incubator PMC
Index: site-author/incubation/Roles_and_Responsibilities.xml
===
--- site-author/incubation/Roles_and_Responsibilities.xml   (revision 
423542)
+++ site-author/incubation/Roles_and_Responsibilities.xml   (working copy)
@@ -23,11 +23,10 @@
   
 Incubator Project Management Committee (PMC)
 
-(From the resolution that created the Incubator Project - see
-http://incubator.apache.org/resolution.html)
+The Incubator PMC 
+[definition]
 
+is responsible for :
 
-The Incubator PMC is responsible for :
-
 
   acceptance and oversight of candidate projects submitted or 
proposed
 to become part of the Foundation;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

RE: Champions: policy clarification required

[Noel J. Bergman]

Robert Burrell Donkin wrote:

> i've run into a problem. [Roles_and_Responsibilities.html] is not
> consistent with [Incubation_Policy.html]
> roles states champions can be officers or members whereas policy
> implies only members.

>From my perspective, these are all vestiges of early Incubator policy
discussions with an overemphasis on P&P language and concern over whom could
bring a project into the Incubator.

What is a Champion?  Let's see what the docs say:

 roles:

  A candidate project shall be sponsored by an Officer or Member of
  the Foundation

  the Champion has no formal responsibility within the Incubation process

 policy:

  A Member of the Apache Software Foundation who supports a Candidate's
  application for Incubation and who supports and assists the Podling
  through the Incubation process

In other words, the Champion is someone who helps support a project's entry
into the Incubator.  But what is the reality?  How does a project get
accepted?  A PMC votes to accept it.  So is there really any need for a
Champion to be either a Member or an Officer?  If so, what?  And who
supports and assists the project through the Incubation Process?  Mentors.
All of which begs the question of whether we should simply discard the
Champion role entirely.

Let's tie this into more of the project lifecycle.  My view is that the
project startup would be:

  - acceptance
  - bootstrap the PPMC from the PMC (assigning Mentors)
  - election by the PPMC of project contributors to the PPMC
  - election by the PPMC of Committers

We have the outstanding thread on Mentors still to complete, but if the
current proposal is adopted to clarify matters, each PPMC would have at
least one ASF Member plus any number of other interested Incubator PMC
members (all equally known as Mentors and having binding votes by virtue of
being PMC members), and such others as the PPMC elects (having non-binding
votes).

So let us continue to simplify, clean out anachronisms, and align our
processes with ASF ideals.  We're years into the Incubator now, and we have
ways of both delegating and controlling the process without over-specifying
in response to FUD.  When it comes down to it, the Incubator PMC holds all
of the binding votes.

--- Noel


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

piling on

[Roy T. Fielding]

I believe that it is a bad idea to allow people to add themselves
to a proposal as committers without first obtaining the consent of
the person(s) making the proposal.  Being a committer in the incubator
is giving a person the right to veto code changes based on whatever
technical reason they deem significant.  We should not hand out that
right like candy to anyone who happens to edit a wiki page.

Podlings must be open to new contributors and should add contributors
to the list of committers fairly quickly, at least when compared to
more established Apache projects.  However, the core team must be
allowed to select other core members based on mutual consensus,
since consensus is how code changes are approved.  How a community
exercises that consensus is one of the primary determinants for
graduation.

In contrast, letting anyone "pile on" to a podling while it is at
the proposal stage is placing an unequal burden on a new podling
that we would never place on a full project.  If the community is
not cohesive, no consensus will be possible and we effectively
hamstring the podling before it is even started.

Roy

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

Re: piling on

[Garrett Rooney]

On 7/19/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

I believe that it is a bad idea to allow people to add themselves
to a proposal as committers without first obtaining the consent of
the person(s) making the proposal.  Being a committer in the incubator
is giving a person the right to veto code changes based on whatever
technical reason they deem significant.  We should not hand out that
right like candy to anyone who happens to edit a wiki page.

Podlings must be open to new contributors and should add contributors
to the list of committers fairly quickly, at least when compared to
more established Apache projects.  However, the core team must be
allowed to select other core members based on mutual consensus,
since consensus is how code changes are approved.  How a community
exercises that consensus is one of the primary determinants for
graduation.

In contrast, letting anyone "pile on" to a podling while it is at
the proposal stage is placing an unequal burden on a new podling
that we would never place on a full project.  If the community is
not cohesive, no consensus will be possible and we effectively
hamstring the podling before it is even started.


+1, I would much prefer to see interested parties starting to
contribute in the usual way (patches sent to a development mailing
list) and get their commit access once the project has decided they
are ready for it.

Of course, this assumes that the project members are on the lookout
for new blood and are actively noticing worthy new contributors and
voting them in as committers, but a new podling should be doing that
anyway.

-garrett

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

Re: piling on

[Ian Holsman]

are you referring to mentors as well?

On 20/07/2006, at 8:09 AM, Roy T. Fielding wrote:


I believe that it is a bad idea to allow people to add themselves
to a proposal as committers without first obtaining the consent of
the person(s) making the proposal.  Being a committer in the incubator
is giving a person the right to veto code changes based on whatever
technical reason they deem significant.  We should not hand out that
right like candy to anyone who happens to edit a wiki page.

Podlings must be open to new contributors and should add contributors
to the list of committers fairly quickly, at least when compared to
more established Apache projects.  However, the core team must be
allowed to select other core members based on mutual consensus,
since consensus is how code changes are approved.  How a community
exercises that consensus is one of the primary determinants for
graduation.

In contrast, letting anyone "pile on" to a podling while it is at
the proposal stage is placing an unequal burden on a new podling
that we would never place on a full project.  If the community is
not cohesive, no consensus will be possible and we effectively
hamstring the podling before it is even started.

Roy

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



--
Ian Holsman
[EMAIL PROTECTED]
http://economychat.com discussion on the economy and economics in  
general

Re: piling on

[Andrus Adamchik]

+1.

As a member of an incubating project I totally agree with this.

What I didn't know is that there was a policy that allowed anyone to  
just declare themselves committers without consensus of the existing  
project participants?


Andrus


On Jul 19, 2006, at 6:09 PM, Roy T. Fielding wrote:


I believe that it is a bad idea to allow people to add themselves
to a proposal as committers without first obtaining the consent of
the person(s) making the proposal.  Being a committer in the incubator
is giving a person the right to veto code changes based on whatever
technical reason they deem significant.  We should not hand out that
right like candy to anyone who happens to edit a wiki page.

Podlings must be open to new contributors and should add contributors
to the list of committers fairly quickly, at least when compared to
more established Apache projects.  However, the core team must be
allowed to select other core members based on mutual consensus,
since consensus is how code changes are approved.  How a community
exercises that consensus is one of the primary determinants for
graduation.

In contrast, letting anyone "pile on" to a podling while it is at
the proposal stage is placing an unequal burden on a new podling
that we would never place on a full project.  If the community is
not cohesive, no consensus will be possible and we effectively
hamstring the podling before it is even started.

Roy



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

Re: piling on

[Garrett Rooney]

On 7/19/06, Ian Holsman <[EMAIL PROTECTED]> wrote:

are you referring to mentors as well?


Personally, yes, I feel this should apply to mentors as well.  While
there are cases where a mentor needs commit access for some sort of
procedural issues (maintaining STATUS files, helping to fix up
licensing issues, and whatnot), they should absolutely not have
general commit access to the codebase until they have earned it like
any other developer.

Note that this is exactly what I did with the Abdera podling, despite
the fact that I'm acting as a mentor I sent in patches and waited for
them to be applied like any other contributor would have to.

-garrett

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

Re: piling on

[Garrett Rooney]

On 7/19/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:

+1.

As a member of an incubating project I totally agree with this.

What I didn't know is that there was a policy that allowed anyone to
just declare themselves committers without consensus of the existing
project participants?


I don't believe there's actually a policy that actively allows it, but
I have seen it happen with several projects, and it certainly seemed
odd to me.

-garrett

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

Re: piling on

[Matthias Wessendorf]

also +1 on Roy,

On 7/19/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:

On 7/19/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
> +1.
>
> As a member of an incubating project I totally agree with this.
>
> What I didn't know is that there was a policy that allowed anyone to
> just declare themselves committers without consensus of the existing
> project participants?


asking me the same :)


I don't believe there's actually a policy that actively allows it, but
I have seen it happen with several projects, and it certainly seemed
odd to me.


in adffaces podling we don't. we prefer the *regular way*

-Matthias


-garrett

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





--
Matthias Wessendorf

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

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

Re: piling on

[Andrus Adamchik]

On Jul 19, 2006, at 6:19 PM, Garrett Rooney wrote:


On 7/19/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:

+1.

As a member of an incubating project I totally agree with this.

What I didn't know is that there was a policy that allowed anyone to
just declare themselves committers without consensus of the existing
project participants?


I don't believe there's actually a policy that actively allows it, but
I have seen it happen with several projects, and it certainly seemed
odd to me.

-garrett


Ah, ok. Probably makes sense to mention in the incubator docs [1]  
that new committers are to be voted in following the normal Apache  
procedures.


I am +0 to extend this policy to the mentors as well. From Cayenne  
experience I don't recall a mentor ever having to commit code *as a  
mentor*. Although we have a mentor who was already a committer, but  
that's a totally different story.


[1] http://incubator.apache.org/guides/committer.html

Andrus

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

Re: piling on

[Ian Holsman]

I was more thinking of how mentors volunteer to guide the project

should the podlings have a say on who gets to mentor them?

for example I could become a mentor of Blaize (I actually like the  
project)

but shouldn't the proposer have a say ?

On 20/07/2006, at 8:17 AM, Garrett Rooney wrote:


On 7/19/06, Ian Holsman <[EMAIL PROTECTED]> wrote:

are you referring to mentors as well?


Personally, yes, I feel this should apply to mentors as well.  While
there are cases where a mentor needs commit access for some sort of
procedural issues (maintaining STATUS files, helping to fix up
licensing issues, and whatnot), they should absolutely not have
general commit access to the codebase until they have earned it like
any other developer.

Note that this is exactly what I did with the Abdera podling, despite
the fact that I'm acting as a mentor I sent in patches and waited for
them to be applied like any other contributor would have to.

-garrett



--
Ian Holsman
[EMAIL PROTECTED]
join http://gyspsyjobs.com the marketplace for django developers

RE: piling on

[Noel J. Bergman]

Roy,

This piling on behavior seems to have come from the notion that if you get
on the initial vote, you're in, but otherwise you have to earn
committership.  And the justification for the first part seemed to be making
sure that a company could not start with a lot of its own people, and keep
out existing ASF committers and other interested parties.

My long standing proposed solution for this is embedded in my description of
project startup:

  - bootstrap the PPMC from the PMC (assigning Mentors)
  - election by the PPMC of project contributors to the PPMC
  - election by the PPMC of Committers

So the Mentors first task is to formally bring on board the key outside
players, and then that PPMC elects Committers, both to start and going
foward.  This addresses your point that:

> Podlings must be open to new contributors and should add contributors
> to the list of committers fairly quickly, at least when compared to
> more established Apache projects.  However, the core team must be
> allowed to select other core members based on mutual consensus,
> since consensus is how code changes are approved.  How a community
> exercises that consensus is one of the primary determinants for
> graduation.

--- Noel


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

Re: piling on

[Martin Sebor]

Garrett Rooney wrote:

On 7/19/06, Ian Holsman <[EMAIL PROTECTED]> wrote:


are you referring to mentors as well?



Personally, yes, I feel this should apply to mentors as well.  While
there are cases where a mentor needs commit access for some sort of
procedural issues (maintaining STATUS files, helping to fix up
licensing issues, and whatnot), they should absolutely not have
general commit access to the codebase until they have earned it like
any other developer.


FWIW, one of the checkboxes on the status page says:

   Give all Mentors access to all incubator SVN modules (to be
   done by PMC chair).

so it seems they are required to have access whether the rest
of the committers like it or not.

Martin

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

RE: piling on

[Noel J. Bergman]

Garrett Rooney wrote:

> Personally, yes, I feel this should apply to mentors as well.

The Mentors are all Incubator PMC members, and the Incubator PMC as a whole
oversees all Incubator projects.  Every Incubator PMC member has an equal
binding vote on every Incubator matter, and ought to be able to act in an
appropriate and responsible manner.  Yes, if we create our own discord,
we'll have to deal with it amongst ourselves, but we're not going to start
by limiting the scope of our PMC members.  Especially not without some
justification that it is necessary.

--- Noel


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

RE: piling on

[Noel J. Bergman]

Ian Holsman wrote:

> should the podlings have a say on who gets to mentor them?
> for example I could become a mentor of Blaize (I actually like the
> project) but shouldn't the proposer have a say ?

If you accept that a Mentor is just a name for an Incubator PMC member who
is active in the project community --- and what else does it mean,
really --- then the answer is no.  All Incubator projects are governed by
the Incubator PMC, and only the ASF Board (in a somewhat tenuous use of the
word "establish", but we all accept that interpretation of 6.3 as
operational) determines whom is on that roster.

So, no, projects do not get to determine their own oversight.  They haven't
earned that right, and won't until and unless they graduate to TLP status.

But in terms of the leadership, or even respect, facet of Mentor semantics,
Mentors do not become leaders by fiat.  They have to earn it and maintain
it.

--- Noel


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

Re: piling on

[Garrett Rooney]

On 7/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Garrett Rooney wrote:

> Personally, yes, I feel this should apply to mentors as well.

The Mentors are all Incubator PMC members, and the Incubator PMC as a whole
oversees all Incubator projects.  Every Incubator PMC member has an equal
binding vote on every Incubator matter, and ought to be able to act in an
appropriate and responsible manner.  Yes, if we create our own discord,
we'll have to deal with it amongst ourselves, but we're not going to start
by limiting the scope of our PMC members.  Especially not without some
justification that it is necessary.


Sure, but I think it should be made clear to mentors that the fact
that nothing is preventing them from committing changes to the project
they mentor doesn't mean that they should do so with abandon.  If they
want to contribute as a committer they should earn that right as any
other contributor would.  Of course, if they need to change something
because the podling has screwed something up from a
legal/procedural/whatever standpoint, that's another issue entirely,
and they shouldn't hesitate to do so.

-garrett

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

Re: piling on

[Andrus Adamchik]

As always there is another dimension to every problem... Noel brings  
a good point about single company contributions. The solution seems  
wrong though.


PPMC can oversee the process and should be able to veto proposed  
committers without sufficient earned karma, but I don't see the  
downsides of self-government of the incubating project. IIRC there  
are rules requiring committer diversity on graduation. So if the  
project committers turn down existing ASF committers *who earned  
karma*, the project is not going to graduate anyways. And if outside  
people, who did not earn karma, formally get on board and do not  
contribute, what good does it do to anybody?


Andrus


On Jul 19, 2006, at 6:39 PM, Noel J. Bergman wrote:

Roy,

This piling on behavior seems to have come from the notion that if  
you get

on the initial vote, you're in, but otherwise you have to earn
committership.  And the justification for the first part seemed to  
be making
sure that a company could not start with a lot of its own people,  
and keep

out existing ASF committers and other interested parties.

My long standing proposed solution for this is embedded in my  
description of

project startup:

  - bootstrap the PPMC from the PMC (assigning Mentors)
  - election by the PPMC of project contributors to the PPMC
  - election by the PPMC of Committers

So the Mentors first task is to formally bring on board the key  
outside

players, and then that PPMC elects Committers, both to start and going
foward.  This addresses your point that:


Podlings must be open to new contributors and should add contributors
to the list of committers fairly quickly, at least when compared to
more established Apache projects.  However, the core team must be
allowed to select other core members based on mutual consensus,
since consensus is how code changes are approved.  How a community
exercises that consensus is one of the primary determinants for
graduation.


--- Noel


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





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

Re: piling on

[Jean T. Anderson]

Andrus Adamchik wrote:
...
> [...] Probably makes sense to mention in the incubator docs [1]  that
> new committers are to be voted in following the normal Apache  procedures.

Actually it's the incubator ppmc doc that discusses voting in new
committers:

   http://incubator.apache.org/guides/ppmc.html

If that wording isn't clear, please post.

 -jean

> I am +0 to extend this policy to the mentors as well. From Cayenne 
> experience I don't recall a mentor ever having to commit code *as a 
> mentor*. Although we have a mentor who was already a committer, but 
> that's a totally different story.
> 
> [1] http://incubator.apache.org/guides/committer.html
> 
> Andrus
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

RE: piling on

[Noel J. Bergman]

Martin Sebor wrote:

> one of the checkboxes on the status page says:
> Give all Mentors access to all incubator SVN modules (to be
> done by PMC chair).
> so it seems they are required to have access whether the rest
> of the committers like it or not.

Yes, they must have it to enable oversight, but they do not have to use it.
One can exercise restraint and earn one's merit, unless abnormal
circumstances demand action from an oversight role.

There is an interesting relationship between earned (contrasted with
unearned) ability and restraint.  Consider that I can, as a purely technical
matter, modify any file anywhere in the ASF, in source control or otherwise.
If there was the slightest chance that I would actually (ab)use that
ability, I would not have it.  Nor would I ever do so.  At the least, the
repercussions would be disastrous.

Likewise, I would expect any Incubator PMC member to demonstrate
self-restraint, and to behave in accordance with the project's practices.

--- Noel


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

RE: piling on

[Noel J. Bergman]

Garrett Rooney wrote:

> Sure, but I think it should be made clear to mentors that the fact
> that nothing is preventing them from committing changes to the project
> they mentor doesn't mean that they should do so with abandon.

Does my response to Martin sufficiently reflect your view?

--- Noel

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

Re: piling on

[Garrett Rooney]

On 7/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Garrett Rooney wrote:

> Sure, but I think it should be made clear to mentors that the fact
> that nothing is preventing them from committing changes to the project
> they mentor doesn't mean that they should do so with abandon.

Does my response to Martin sufficiently reflect your view?


Yes, we are 100% in agreement as far as I can tell.

-garrett

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

RE: piling on

[Noel J. Bergman]

Andrus Adamchik wrote:

> PPMC can oversee the process and should be able to veto proposed
> committers without sufficient earned karma, but I don't see the
> downsides of self-government of the incubating project.

The PPMC *is* the self-governing body for the Incubating project.  Which is
why I keep saying that the recommendation should be to have at least three
(3) Mentors on the project, thus enabling the PPMC to actually hold binding
votes without needing to wait on the rest of the PMC (although we should
still be included).  Without at least three mentors, a PPMC lacks the
necessary minimum number of votes, and must wait for other PMC members to
vote on each issue.

As for the question of whether or not a candidate has "sufficient earned
karma", the PPMC, following the explanation above, has the ability to make
the decision for each situation.

--- Noel


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

Re: piling on

[Andrus Adamchik]

I guess I misread the proposed bootstrap procedure and its  
ramifications.



- bootstrap the PPMC from the PMC (assigning Mentors)
- election by the PPMC of project contributors to the PPMC
- election by the PPMC of Committers


1. I was wondering why incubating project committers who are not PPMC  
members can't vote for new committers. Of course they can still  
propose the candidates and leave the vote up to PPMC. Fair enough.


2. Ok, so ASF existing committers who sign up as committers (not  
mentors) on the initial proposal would have to go through a PPMC vote  
as well. That's a good solution.


I am all for implementing this procedure then.

Andrus



On Jul 19, 2006, at 7:30 PM, Noel J. Bergman wrote:

Andrus Adamchik wrote:


PPMC can oversee the process and should be able to veto proposed
committers without sufficient earned karma, but I don't see the
downsides of self-government of the incubating project.


The PPMC *is* the self-governing body for the Incubating project.   
Which is
why I keep saying that the recommendation should be to have at  
least three
(3) Mentors on the project, thus enabling the PPMC to actually hold  
binding
votes without needing to wait on the rest of the PMC (although we  
should

still be included).  Without at least three mentors, a PPMC lacks the
necessary minimum number of votes, and must wait for other PMC  
members to

vote on each issue.

As for the question of whether or not a candidate has "sufficient  
earned
karma", the PPMC, following the explanation above, has the ability  
to make

the decision for each situation.

--- Noel


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





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

Re: [Proposal] Blaze

[Sahan Gamage]

Hi all,

As an Apache committer in the Web services project I would like to
join the initial commiter list of this project.
My work in web services project mainly focuses on transport layer of
Apache Axis2C project as well as implmenting the Apache Sandesha2C
project - an implementation of WS-RM protocol.
I find this project interesting and would like to join the community.
If you guys think that I am worh enough to be an initial committer for
this, please add me to the initial committer list.

- sahan

On 7/20/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>
>> Henri said:
>> This worries me - accepting an implementation whose specification does
>> not yet have a defined license or containing standards body. Maybe
>> we've done it before though.
>
> This is not true - AMQP has a well defined license and it is posted in
> the spec, and you can implement
> the specification freely - without strings.

Bad wording on my part. I mean the license once it is at the standards body.

> On the topic of  - at which standards body it will land at, why is that
> a concern, as the license of
> the specification is well defined no matter where it goes

I was assuming that standard bodies dictate the license to a large
extent, and given that those have caused trouble in the past the idea
of a new project with that still undefined is a worry. The term
"standards body" is a mental flag :)

I asked Cliff as champion about this bit and he said he'd reply here
in a few hours.

Hen

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




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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

Sanjiva Weerawarana wrote:

On Tue, 2006-07-18 at 21:38 -0400, Noel J. Bergman wrote:
  

Jason,

I am +1 for the project, overall.

I do suggest that we start out with the PPMC of you and the other Mentors,
have you bring Dan and other appropriate people onto the PMC as your first
order of business, and them go about selecting Committers.  From what I
recall at ApacheCon, there was some uncertaintly about the current roster,
so let's allow the PPMC to review and address as appropriate.

As was discussed at ApacheCon EU, I hope that the project will continue
efforts to collaborate with the rest of the Web Services community at the
ASF, because I hate to see wasted, redundant, effort when collaboration is
possible.  And it certainly appears from discussion that they are willing to
explore any number of options.

So give it your best effort, and good luck.  :-)



+1 Noel. I'd like to join the PPMC too as an interested party observer.
I will poke my nose in as a mentor when possible but don't have the
cycles to commit to it.

Hi Sanjiva,

I'm confused, you're saying you don't have the time to commit to it, but 
you want to be one? Mentors have some very concrete responsibilities:


http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor

While I value your feedback and input, if you don't have enough time, I 
don't understand why you should be a mentor. We have 4 mentors already, 
and from a logistical standpoint I find it hard to keep up with. Each 
mentor tends to have a different opinion or different input.  While more 
input can be great, it can easily get to the point of overload and 
impedes Getting Stuff Done. :-)


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [Proposal] Blaze

[Carl Trieloff]

Sahan,

Thank you for your interest, do you mind if we do a brief call to understand
what your interest is and what or where you are wanting to contribute.

Looking forward to working with you,
Carl.


Sahan Gamage wrote:

Hi all,

As an Apache committer in the Web services project I would like to
join the initial commiter list of this project.
My work in web services project mainly focuses on transport layer of
Apache Axis2C project as well as implmenting the Apache Sandesha2C
project - an implementation of WS-RM protocol.
I find this project interesting and would like to join the community.
If you guys think that I am worh enough to be an initial committer for
this, please add me to the initial committer list.

- sahan

On 7/20/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>
>> Henri said:
>> This worries me - accepting an implementation whose specification 
does

>> not yet have a defined license or containing standards body. Maybe
>> we've done it before though.
>
> This is not true - AMQP has a well defined license and it is posted in
> the spec, and you can implement
> the specification freely - without strings.

Bad wording on my part. I mean the license once it is at the 
standards body.


> On the topic of  - at which standards body it will land at, why is 
that

> a concern, as the license of
> the specification is well defined no matter where it goes

I was assuming that standard bodies dictate the license to a large
extent, and given that those have caused trouble in the past the idea
of a new project with that still undefined is a worry. The term
"standards body" is a mental flag :)

I asked Cliff as champion about this bit and he said he'd reply here
in a few hours.

Hen

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




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




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

Re: [Proposal] Blaze

[Carl Trieloff]

Carl Trieloff wrote:


Sahan,

Thank you for your interest, do you mind if we do a brief call

(or email...or discuss right here on the list -- whatever your preference)

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

Looking forward to working with you,
Carl.


Sahan Gamage wrote:

Hi all,

As an Apache committer in the Web services project I would like to
join the initial commiter list of this project.
My work in web services project mainly focuses on transport layer of
Apache Axis2C project as well as implmenting the Apache Sandesha2C
project - an implementation of WS-RM protocol.
I find this project interesting and would like to join the community.
If you guys think that I am worh enough to be an initial committer for
this, please add me to the initial committer list.

- sahan

On 7/20/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 7/19/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
>
>> Henri said:
>> This worries me - accepting an implementation whose specification 
does

>> not yet have a defined license or containing standards body. Maybe
>> we've done it before though.
>
> This is not true - AMQP has a well defined license and it is 
posted in

> the spec, and you can implement
> the specification freely - without strings.

Bad wording on my part. I mean the license once it is at the 
standards body.


> On the topic of  - at which standards body it will land at, why is 
that

> a concern, as the license of
> the specification is well defined no matter where it goes

I was assuming that standard bodies dictate the license to a large
extent, and given that those have caused trouble in the past the idea
of a new project with that still undefined is a worry. The term
"standards body" is a mental flag :)

I asked Cliff as champion about this bit and he said he'd reply here
in a few hours.

Hen

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




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




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




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

RE: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Noel J. Bergman]

Dan Diephouse wrote:

> Sanjiva Weerawarana wrote:

> > I'd like to join the PPMC too as an interested party observer.
> > I will poke my nose in as a mentor when possible but don't
> > have the cycles to commit to it.

> While I value your feedback and input, if you don't have enough time, I
> don't understand why you should be a mentor. We have 4 mentors already,
> and from a logistical standpoint I find it hard to keep up with. Each
> mentor tends to have a different opinion or different input.  While more
> input can be great, it can easily get to the point of overload and
> impedes Getting Stuff Done. :-)

Sanjiva is an Incubator PMC member, and entitled to voice (and vote) where
and how he sees fit within the Incubator.  He, like every other Incubator
PMC member, has earned that right.  And it is good that you value his
feedback and input.

As for your legitimate concern, if you do find that there are discordant
views coming to CeltixFire from the PMC, please first discuss it within the
project, and if that doesn't help to resolve it, inform the Incubator PMC so
that we can address the problem.

--- Noel


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[William A. Rowe, Jr.]

Noel J. Bergman wrote:

Dan Diephouse wrote:


We have 4 mentors already,
and from a logistical standpoint I find it hard to keep up with. Each
mentor tends to have a different opinion or different input.  While more
input can be great, it can easily get to the point of overload and
impedes Getting Stuff Done. :-)


As for your legitimate concern, if you do find that there are discordant
views coming to CeltixFire from the PMC, please first discuss it within the
project, and if that doesn't help to resolve it, inform the Incubator PMC so
that we can address the problem.


I was gonna say ... when we do things right, all of your mentors, one of them
or 5 of them all speak with one voice.  When that doesn't happen confront them
(politely) with the discrepancy.  90+% of the time, you probably will discover
they were saying the same thing, different ways, same net result.


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

William A. Rowe, Jr. wrote:

Noel J. Bergman wrote:

Dan Diephouse wrote:


We have 4 mentors already,
and from a logistical standpoint I find it hard to keep up with. Each
mentor tends to have a different opinion or different input.  While 
more

input can be great, it can easily get to the point of overload and
impedes Getting Stuff Done. :-)


As for your legitimate concern, if you do find that there are discordant
views coming to CeltixFire from the PMC, please first discuss it 
within the
project, and if that doesn't help to resolve it, inform the Incubator 
PMC so

that we can address the problem.


I was gonna say ... when we do things right, all of your mentors, one 
of them
or 5 of them all speak with one voice.  When that doesn't happen 
confront them
(politely) with the discrepancy.  90+% of the time, you probably will 
discover

they were saying the same thing, different ways, same net result.
Just to be clear, I'm talking about things like "How should we explain X 
on our proposal." There is a lot of the process which is not black and 
white, but more opinion based.


Cheers,

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

[STATUS] (incubator) Wed Jul 19 23:53:33 2006

[Rodent of Unusual Size]

APACHE INCUBATOR PROJECT STATUS:  -*-indented-text-*-
Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $]

Web site:  http://Incubator.Apache.Org/
Wiki page: http://wiki.apache.org/incubator/

[note: the Web site is the 'official' documentation; the wiki pages
 are for collaborative development, including stuff destined for the
 Web site.]

Pending Issues
==

o We need to be very very clear about what it takes to be accepted
  into the incubator.  It should be a very low bar to leap, possibly
  not much more than 'no problematic code' and the existence of a
  healthy community (we don't want to become a dumping ground).

o We need to be very very clear about what it takes for a podling
  to graduate from the incubator.  The basic requirements obviously
  include: has a home, either as part of another ASF project or as
  a new top-level project of its own; needs to be a credit to the
  ASF and function well in the ASF framework; ...

See also:

  https://issues.apache.org/jira/browse/INCUBATOR

Resolved Issues
===

o The policy documentation does not need ratification of changes
  if there seems consensus. Accordingly, the draft status of these
  documents can be removed and we will use the lazy "commit first,
  discuss later" mode common across the ASF for documentation
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=517190)

o Coming up with a set of bylaws for the project
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=517190)

o All projects under incubation must maintain a status Web page that
  contains information the PMC needs about the project.
  (http://incubator.apache.org/guides/website.html)

o Projects under incubation should display appropriate "disclaimers"
  so that it is clear that they are, indeed, under incubation
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=504543)

o Clearly and authoritatively document how to edit, generate,
  and update the Web site (three separate functions)
  (http://incubator.apache.org/guides/website.html).

The Incubation Process
==

TODO: this does not belong in the STATUS file and probably was integrated into
other documentation a while ago. That should be double-checked and then this
section should be removed.

This tries to list all the actions items that must be complete for a project
before it can graduate from the incubator. It is probably incomplete.

Identify the project to be incubated:

  -- Make sure that the requested project name does not already exist
 and check www.nameprotect.com to be sure that the name is not
 already trademarked for an existing software product.

  -- If request from an existing Apache project to adopt an external
 package, then ask the Apache project for the cvs module and mail
 address names.

  -- If request from outside Apache to enter an existing Apache project,
 then post a message to that project for them to decide on acceptance.

  -- If request from anywhere to become a stand-alone PMC, then assess
 the fit with the ASF, and create the lists and modules under the
 incubator address/module names if accepted.

Interim responsibility:

  -- Who has been identified as the mentor for the incubation?

  -- Are they tracking progress on the "project status" Web page?

Copyright:

  -- Have the papers that transfer rights to the ASF been received?
 It is only necessary to transfer rights for the package, the
 core code, and any new code produced by the project.

  -- Have the files been updated to reflect the new ASF copyright?

Verify distribution rights:

  -- For all code included with the distribution that is not under the
 Apache license, do we have the right to combine with Apache-licensed
 code and redistribute?

  -- Is all source code distributed by the project covered by one or more
 of the following approved licenses:  Apache, BSD, Artistic, MIT/X,
 MIT/W3C, MPL 1.1, or something with essentially the same terms?

Establish a list of active committers:

  -- Are all active committers listed in the "project status" file?

  -- Do they have accounts on cvs.apache.org?

  -- Have they submitted a contributors agreement?

Infrastructure:

  -- CVS modules created and committers added to avail file?

  -- Mailing lists set up and archived?

  -- Problem tracking system (Bugzilla)?

  -- Has the project migrated to our infrastructure?

Collaborative Development:

  -- Have all of the active long-term volunteers been identified
 and acknowledged as committers on the project?

  -- Are there three or more independent committers?

 [The legal definition of independent is long and boring, but basically
  it means that there is no binding relationship between the individuals,
  s