Moving xmlbeanscxx to dormant status (was [REPORT] XMLBeans May 2007)

[Cliff Schmidt]

Incubator PMC Folks,

The XMLBeans PMC, which is currently the sponsoring PMC for the
xmlbeanscxx podling, would like to move this podling to a
dormant/retired status.  As mentioned in the last XMLBeans PMC status
report to the board below, the project no longer has enough community
interest to continue.

Unless other Incubator PMC members have comments/concerns, I will
(with my IPMC hat on) make the change to the project status page to
reflect this.

Cliff
(representing the XMLBeans PMC)

-- Forwarded message --
From: Cezar Andrei
Date: May 11, 2007 10:30 AM
Subject: [REPORT] XMLBeans May 2007
To: [EMAIL PROTECTED]

It's time for quarterly report to the board. Please send any feedback
before morning of Monday 14.


XMLBeans report May 2007

Development increased to the end of the quarter in order to push for a
new release. The preparations for the new release influenced traffic
on both dev and user lists, but we've also seen an increased traffic
from user community unrelated to the release.

There were no new committers or PMC changes.

A new release is in the process, there has been already 2 RC-s, and
the third is in the making to include a change request to remove the
QName and NamespaceContext classes from the xmlbeans jar.

xmlbeansc++ subproject: XMLBeans PMC and subproject mentor Cliff
Schmidt recommended in the last board report to close the subproject
due to lack of interest from committers and community.

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

Re: all licenses go into the LICENSE file (was: Re: [VOTE] approve release of OpenJPA 0.9.7)

[Cliff Schmidt]

On 4/30/07, Leo Simons <[EMAIL PROTECTED]> wrote:

On Apr 25, 2007, at 6:23 AM, Niclas Hedhman wrote:
> On Wednesday 25 April 2007 11:55, Patrick Linskey wrote:
>>>   * OpenJPA includes software developed by the SERP project
>>> Copyright (c) 2002-2006, A. Abram White. All rights reserved.
>>>
>>> The "All rights reserved." means that it has not been
>>> properly licensed, and I as the licensee of OpenJPA will have
>>> no rights to it either.
>>>
>>> Clarification, please.
>>
>> Serp is BSD-licensed. I'm not sure if that answers the clarification,
>> but seems like it's a useful tidbit. If I understand correctly, the
>> call-out in LICENSE.txt handles that case sufficiently.
>
> A... I now see that the LICENSE file contains all the licenses
> appended
> after each other. Not exactly my personal preference, but Ok.

A more detailed draft policy that has been circulated on board@ some
months ago (I don't think its on the web yet) by our legal VP (a.k.a.
Cliff) specifies that all these licenses go into the LICENSE file.

The main reason that the policy is of draft status is that Cliff
doesn't have enough cycles to take care of it all. A legal committee
has been formed recently which will hopefully help address, so that
this kind of information becomes sufficiently public.

I believe some information rests within the legal-discuss archives

   http://mail-archives.apache.org/mod_mbox/www-legal-discuss/

but I don't subscribe to that list.

A rule of thumb -- when in doubt, follow the example set by httpd...

   http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE


Yes -- excellent advice.  It's true that we don't have one dedicated
document that says this anywhere, but it has been buried in this page
for years: http://apache.org/dev/apply-license.html#new:

"If the distribution also contains source files not owned by the ASF,
such as third-party libraries, then be sure to leave their licenses
intact. In some cases, you may want to ask the author(s) of
third-party code to relicense it under the 2.0 license, since that
will simplify the distribution. Otherwise, you should append their
license(s) to the LICENSE file at the top of the distribution, or at
least put a pointer in the LICENSE file to the third-party license. "

Cliff

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

[RESULT][VOTE] Add Kevin Smith as a Qpid Committer

[Cliff Schmidt]

The Qpid PPMC already passed their vote in favor of making Kevin a
committer, but this email is to indicate that the vote is now official
with the following three +1s from Incubator PMC members (and no other
IPMC votes):

Paul Fremantle
William Rowe
Cliff Schmidt

Congratulations, Kevin.  I will now send the formal request to root to
set up your account.  Sorry for the mix-up with the delay in getting
the IPMC votes.

Cliff

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

[RESULT][VOTE] Add Rupert Smith as a Qpid Committer

[Cliff Schmidt]

The Qpid PPMC already passed their vote in favor of making Rupert a
committer, but this email is to indicate that the vote is now official
with the following three +1s from Incubator PMC members (and no other
IPMC votes):

Paul Fremantle
William Rowe
Cliff Schmidt

Congratulations, Rupert.  I will now send the formal request to root
to set up your account.  Sorry for the mix-up with the delay in
getting the IPMC votes.

Cliff

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

[RESULT] [VOTE] Add Tomas Restrepo as a Qpid Committer

[Cliff Schmidt]

The Qpid PPMC already passed their vote in favor of making Tomas a
committer, but this email is to indicate that the vote is now official
with the following three +1s from Incubator PMC members (and no other
IPMC votes):

Paul Fremantle
William Rowe
Cliff Schmidt

Congratulations, Tomas.  I will now send the formal request to root to
set up your account.  Sorry for the mix-up with the delay in getting
the IPMC votes.

Cliff

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

Re: Adding new committers process

[Cliff Schmidt]

On 4/6/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:

Ok, I think that has cleared things up a bit for me I'll send out
these requests that I've been sitting on for a few weeks now as we
need to get the accounts set up for our new committers.


Just as it appeared this subject was cleared up, Noel replied to
Qpid's root requests with the following clarifications:

1. Only IPMC members (e.g. mentors) should send root requests for new
podling committers.
2. A podling committer vote requires three IPMC +1s to be approved
(ideally the mentors, assuming the project still has three mentors).

This was not my recollection and is not how I read what we have
documented at http://incubator.apache.org/guides/ppmc.html:

"Only votes cast by (P)PMC members are binding. If the vote is
positive, the contributor formally becomes an Apache  committer. A
(P)PMC member should then follow the documented procedures to complete
the process, but please CC both the Incubator PMC and the PPMC when
sending the necessary e-mails to root."


From Noel's comments, it sounds like those "(P)"s should be removed

from the above sentence.

I honestly don't know if this is a case of things evolving rules, or
different IPMC members thinking they agreed with each other and not
realizing they had different ideas, or (equally likely) that I knew
the "right way" to do this long ago and have since lost my mind.

So, I have chosen to handle this by offering my IPMC/mentor vote to
the three qpid votes that were summarized on this list last month.
I've been very impressed with how the Qpid folks have discussed and
evaluated which contributors should join them as committers, and I
have no problem endorsing their choices.  I can also do the sending of
the root requests when there are two other +1 IPMC votes.

But, I wanted to bring the issue up here so everyone can tell me either:

"Cliff -- you've lost your mind.  It's always been done this way.  You
should get on top of these things or take a vacation and come back
refreshed."

or

"H...I guess I was confused as well.  I should make sure the
project I'm mentoring is following the points Noel made above."

Cliff

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

Re: [RESULT] Add Rupert Smith as a Qpid Committer

[Cliff Schmidt]

On 3/15/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:

All,

This vote closed on Tuesday night and the result is as follows:

Votes Cast:

9+
0-

Thus, Rupert Smith should now be created as a committer on the Qpid project.


Although this vote closed several weeks ago, I'm adding my +1 as the
mentor and member of the Incubator PMC.

Cliff

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

Re: [RESULT] Add Kevin Smith as a Qpid Committer

[Cliff Schmidt]

On 3/15/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:

All,

This vote closed on Tuesday night and the result is as follows:

Votes Cast:

6+
0-

Thus, Kevin Smith should now be created as a committer on the Qpid project.


Although this vote closed several weeks ago, I'm adding my +1 as the
mentor and member of the Incubator PMC.

Cliff

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

Re: [RESULT] Add Tomas Restrepo as a Qpid Committer

[Cliff Schmidt]

On 3/15/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:

All,

This vote closed on Tuesday night and the result is as follows:

Votes Cast:

9+
0-

Thus, Tomas Restrepo should now be created as a committer on the Qpid
project.


Although this vote closed several weeks ago, I'm adding my +1 as one
of the mentors and a member of the Incubator PMC.

Cliff

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

Re: [VOTE] Approve release of SCA specification APIs by Tuscany project

[Cliff Schmidt]

On 3/15/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:

On 3/13/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> The Tuscany community recently voted to release version 1.0-
> incubating of our implementation of the API classes for the OSOA
> specification V1.0:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/%
> [EMAIL PROTECTED]
>
> The source archives and RAT reports can be found at:
>http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating
> and the binary in the Maven repo at:
>http://people.apache.org/repo/m2-incubating-repository/org/osoa/
> sca-api-r1.0/1.0-incubating

ok except for the signature issue

major issues
==

gpg --verify sca-api-r1.0-1.0-incubating.jar.asc sca-api-r1.0-1.0-incubating.jar
gpg: Signature made Sun Mar  4 01:53:25 2007 GMT using DSA key ID 11007026
gpg: BAD signature from "Jeremy Boynes <[EMAIL PROTECTED]>"

MD5 sums look right

notes and comments
=

(subjective, not binding)

it's good to include the project name in the jar

the latest advice on best practice from cliff is that a separate
DISCLAIMER.txt is preferred to including the incubator disclaimer in
the NOTICE.txt. the reason is that the NOTICE.txt has legal
implications so it's best to restrict the contents. incubator policy
asks that the DISCLAIMER is distributed but this isn't something we
require by downstream. IMHO this isn't important enough to consider
re-rolling.


Just to clarify, I haven't advocated for a file necessarily named
"DISCLAIMER.txt" just for the incubator disclaimer.  I don't recall
if/what the Incubator PMC policy is on that.  I do remember when we
started the disclaimer thing (almost four years ago), we were just
adding it to the top of the README.  Either case seems reasonable to
me (with my Incubator PMC hat on) unless we have a stated policy
specifying exactly one thing.

Otherwise, Robert's comment about my advice on the NOTICE file is
correct.  The NOTICE file should only be used for attributions and
other notices required to be included by some third-party license or
as required by http://apache.org/legal/src-headers.html#notice.

Cliff


i assume that this is an apache implementation of an osoa standard
(please correct me if this is wrong). the MANIFEST is short on details
and is missing standard/required/recommended attributes. it's good to
have the relationship between implementator and specifier clearly
listed in the MANIFEST.

org/osoa/sca-api-r1.0/1.0-incubating/ it's unusual to see 1.0 in there
twice but then again, this may well be intentional (but though it best
to point it out)

- robert


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

Re: [RESULT] Add Rupert Smith as a Qpid Committer

[Cliff Schmidt]

On 3/15/07, Marnie McCormack <[EMAIL PROTECTED]> wrote:

Thus, Rupert Smith should now be created as a committer on the Qpid project.

Cliff - is this something you can action from a practical perspective please
? If I can do it please let me know.


Just forwarded an old email I sent to qpid-dev with instructions for
the new committers and the PPMC.

Cliff

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

Re: Contents of NOTICE file

[Cliff Schmidt]

The only third-party notices that should be inserted in the NOTICE
file are ones that are explicitly required by a necessary license.


From what you've described below, it doesn't sound like you a license

for Libxml is necessary.

Cliff

On 3/15/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

We are having a discussion on tuscany-dev to decide if we need to add our
use of Libxml in the NOTICE file for the release we are preparing. We
compile against the headers but no Libxml artifacts are included in anything
we distribute. We document that libxml is a pre-req.

The question is do we need to mention this in the NOTICE file. I notice that
axis2c which also builds against libxml does not include mention of it in
the NOTICE.

If we do have to list this do we also have to list other things we build
against but do not distribute: curl, linux headers, gcc libraries etc. etc.

Cheers,

--
Pete



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

Re: [RESULT] was: [VOTE] [RETRY] Release of Apache XAP 0.3.0

[Cliff Schmidt]

On 3/6/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:

On 2/25/07, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> Hi,
> Congrats on the getting the vote passed and the release out.
>
> I'd like to re-iterate my question: besides Cliff, where are your
> other two mentors?

i've been unwell (but i'm better now)


Good to hear you're doing well now.

Yoav, I understand your question about other mentors; but I do want to
point out that Robert gave lots and lots of helpful feedback to this
list about issues with their proposed release.  Since they addressed
his concerns before proposing then next release and since you and
Aaron covered the other required PMC votes, I wasn't too worried about
oversight.

Cliff

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

Re: [VOTE] [RETRY] Release of Apache XAP 0.3.0

[Cliff Schmidt]

On 2/14/07, Bob Buffone <[EMAIL PROTECTED]> wrote:


Incubator,

Several issues were found with the previous release files and have been
resolved:

1.) NOTICE file contained a list of the Committers
- Issue Raiser: William A. Rowe, Jr.
- Resolution: List of committers has been removed from the file.

2.) No signature files
- Issue Raiser: Daniel Kulp
- Resolution: Figured out how to sign the release, then signed the
release.  Also, added a KEYS file to the repository under XAP as well as
uploaded the key to the MIT server.

3.) LGPL code in the release without listing it in the NOTICE and
LICENSE.
- Issue Raiser: Robert Burrell Donkin
- Resolution: The code that had a LGPL license has been removed.  It
wasn't actually being used, so removing it was the best solution.

4.) Author tags in the code.
- Issue Raiser: William A. Rowe, Jr.
- Resolution: No change in this release.  We (XAP Committers) will
work to remove the author tags for the next release and adopt the no
author tags in code going forward.

--
New versions of the release files can be found at:
http://people.apache.org/~bbuffone/xap-release/

Please cast your votes:

[ ] +1 Release is approved
[ ] -1 Veto the release (provide specific comments)


+1

Cliff

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

Re: podling BIS notifications

[Cliff Schmidt]

On 2/20/07, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

BIS notices have to be made if a product contains encryption
functionality controlled by the EAR's 5D002 classification, or
is specifically designed to make use of a 5D002 classified item
(as would the case if the source code contains calls to OpenSSL
or JCE interfaces), or if any released package contains any other
product that is classified as 5D002 (as it would if the
Bouncy Castle jar was included in a release package).

A conservative read of the EAR would indicate that JXTA depending
on Bouncy Castle makes JXTA 5D002, so if Tuscany is specifically
designed to use JXTA then it would also be 5D002.  (The same sad
fate applies to Apache httpd 2.x modules as well, apparently,
even if they aren't designed to make use of the SSL components.)

Hence, the podling should bring it to the attention of the IPMC
when a release vote is made, and the IPMC chair should be the one
to edit the exports page and send the appropriate message to the
BIS *prior* to the release being published.  Noel can delegate that
if he wants, but whoever has the hat needs to be kept aware of
the situation.  The notice only needs to be sent once per product
when it is first considered for release and later only if the
product's encryption functionality changes.


+1 to everything above -- although, rather than saying a later notice
needs to be sent out when the encryption functionality changes, I'd
put it as, "a later notice needs to be sent when any information on
the prior notice has changed"...but this would typically only be the
case for changes in manufacturer to some included crypto component.
See http://www.apache.org/dev/crypto.html#faq-additionalemails.


We don't know exactly where the line needs to be drawn, since
the BIS has been very lenient or very overloaded in the
past and never (to my knowledge) taken us to task for doing
it wrong.  Or maybe we always did it right.  Nevertheless, the EAR
is the law as far as the ASF is concerned, and has to be obeyed
even if we think the law is confusing and pointless.

My guess is that ongoing development of source code bits within
subversion qualifies as an open conference, just like our mailing
lists, and thus not subject to the export controls.  It is only


No -- the BIS folks consider open source development in between
releases to be the same as beta releases.  There is a separate license
just for betas, but the TSU one is simpler.  This is why we send the
TSU notification prior to starting to commit encryption code to SVN.
This is also covered in the FAQs:

http://www.apache.org/dev/crypto.html#faq-firstnotification
http://www.apache.org/dev/crypto.html#faq-public

If any of these FAQs could be more clear, let me know.


when the bits appear in functioning product form that the
encryption controls apply (it is the encryption *functionality*
that is controlled, so says the regulations, since everyone knows
that encryption itself is not a secret technology). *shrug*
But being proactive on the notice is always better than being
reactive to government agents.

Note, however, that if anyone commits something like the OpenSSL
or Bouncy Castle source code and/or binaries, which are products
in and of themselves, to the subversion instance, then the PMC
must file an export notice for the subversion area even if no ASF
product has been released yet.  That is because distributing
third-party products from a public web server is the same as
exporting them.  Personally, I think it is wrong for projects to
commit code to subversion unless it is intended to be maintained
as source, but I know that some "real" projects at the ASF are too
lazy to write build scripts and instead use our subversion instance
as a binary distribution medium.

As far as timing goes, the notice should be sent as soon as
it becomes clear that the product will eventually contain code
that is designed for a given 5D002 product (i.e., anything that
uses encryption for purposes other than mere authentication).
Preferably, before that code is committed to subversion.  The real
benefit of having the exports page (aside from answering the FAQ)
is that we now have a single source link to provide to the BIS
that is independent of the product names and release versions,
and so we can easily send the notice once, before any chance of
an export occurs, and not worry about it later.


+1
...although, speaking of the exports page, I noticed that there is now
software with an ECCN of "EAR99".  I'm not aware of any software we
distribute at Apache that meets this category.  Can anyone tell me
what the rationale is for this?


Note: For those wondering about history, we submitted the
equivalent of BIS notices for the Apache HTTP Server a long time
ago when the ASF first began, and then again when the regulations
changed, and again just last week to make the exports page the
official source link.  AFAIK, we have never received a response
from the BIS or its predecessor, but that m

Board response to January Incubator PMC Report

[Cliff Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Incubator PMC,

On behalf of the Board, I want to thank you for the latest status  
report.  There was one part of the report we would like to follow-up on:


The report on Heraldry mentions a "single large block checkin",  
"almost no activity" on the dev list, and license problems not being  
responded to "despite requests from the mentors".  The Board requests  
that the Incubator PMC describe what action it plans to take about  
this situation in next month's report.


Thank you,

Cliff

- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFuSlKy6dGskFZ6tsRAocZAKCfgV6Uu+4nvPox/H2tPKhhxIVfgwCfTwYY
aIo4DiTXeg3EVhWAhuZDxRU=
=qdaB
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFuSl9y6dGskFZ6tsRAm7wAJ9y/87YotQRj77N3WnBScnMSYzJ6gCgmflq
LOFnvjPg3OvizHMXkA/FYZ4=
=h+DV
-END PGP SIGNATURE-

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

Re: [VOTE] Release Qpid M1

[Cliff Schmidt]

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

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


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

Cliff


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

-Brian

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

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

> The Qpid community voted on and almost approved to release qpid-
> java-1.0-incubator-M1, we are a vote short.
>
> I would thus like to request the Incubator PMC to review the
> release and if someone could help us get this remaining vote to be
> able to request to publish the release.
>
> You can preview the release at:
>http://people.apache.org/~rajith/qpid-release/M1/
> which includes the links to the binary and sources releases.
>
>
> The svn branch used for the M1 release is located at:
>https://svn.apache.org/repos/asf/incubator/qpid/branches/M1/
> The results of the vote held on the Qpid dev list where as follows
>
> Vote Summary
> 
> 0 -1 or 0 votes
> 2 +1 Mentors 12   +1 PPMC
> 4 +1 Others
>
> Mentors
> ---
> Cliff Schmitt
> Paul Fremantle
>
> PPMC
> 
> Alan Conway
> Kim van der Riet
> Martin Ritche
> Marnie McCormack
> Steve Vinoski
> Gordon Sim
> Robert Grieg
> Rajith Attapatta
> John O'Hara
> Bhupendra Bhardwaj
> Rafael Schloming
> Carl Trieloff
>
> Others
> --
> Suresh Kodichath Frank Lynch
> Sam Joyce
> Tejeswar Das
>
>  Regards
> Carl
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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




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

Including snapshot dependencies from other ASF projects

[Cliff Schmidt]

The Qpid community has been debating whether or not they should
include an unreleased snapshot version of MINA within their upcoming
Qpid release, and whether they would even be allowed to do so by
"Apache rules".  The committers want to do the right thing and have
asked their mentors for advice.  Paul and I (mentors) have both said
that there could be a way to do this properly, but we also both
thought it was worth discussing on this list, in part because we
expect other podlings out there will have similar questions.

I don't want to revisit the ongoing infrastructure thread about what
constitutes a release, where builds/releases should and shouldn't be
placed, etc.  Instead, I'm hoping to understand concerns that
Incubator PMC members have about one of our projects releasing code
that includes unreleased code from another project/podling.  The key
point here is that any PMC that releases any code is always
responsible for what it is releasing, whether it's code written under
the purview of the PMC or other dependencies included in the project
-- this isn't a question about whether unreleased code can be
distributed without being voted upon; it's a question of which PMC is
doing the voting.

To see the debate that the Qpid community has been having, take a look
at some of the threads at
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/thread?3,
particularly the "Maven and artifacts" thread.  Part of the debate
involves technical pros and cons, but I'm trying to get at any policy
issues.

I should point out that the Qpid committers have already submitted
patches to the MINA folks, and from what I've read, MINA has been very
receptive and helpful.  The issue here is that even when the patch is
committed to MINA's trunk, they may not choose to create a release
just for this patch or for other reasons within the timeframe when
Qpid would like to do their release.  One thing I'm not sure about is
whether the MINA folks have any concerns about Qpid including the
snapshot in their release.

While this issue could apply to any ASF project, not just incubating
ones, I'm raising the issue here because this would be the PMC that
would ultimately approve or reject the release.

Interested in hearing everyone's thoughts (especially PMC members).

Thanks,
Cliff

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

Re: [DISCUSS] incubator voting process

[Cliff Schmidt]

On 11/10/06, Sam Ruby <[EMAIL PROTECTED]> wrote:

If we go the first route, then we should treat this list as an
announcements list.  Results of votes for releases and graduation are
posted here, and incubator PMC members will be given 72 hours to raise
an issue.


I've been advising podlings with three mentors to conduct release
votes on their dev list, but ping the mentors beforehand to make sure
they vote.  Then, having three PMC +1s, they should forward the vote
results from their dev list to this list to allow the rest of the PMC
72 hours to raise any concerns.  If no response, the release goes out
based on the earlier three PMC votes.

If one of the mentors doesn't want to +1 it, that's a problem that
should be discussed in any case.  If a mentor doesn't have time to
review the occasional release of their podling, they probably
shouldn't be a mentor.

I prefer to keep the release vote on the podling's dev list where
their community lives; I also prefer to reduce the noise on this list
for uneventful project-specific release votes.


If we go the second route, then we need to set the expectation that most
PMC members participate in most votes.


I don't think this is ever going to happen.  I sure hope no one on the
PMC votes for the release of a product they haven't taken a close look
at (not making technical judgements, but everything else).  And I
really doubt, with the number of podlings that the average PMC member
will have time to do this in most cases

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

Re: [VOTE] Graduate Harmony to TLP status (pending board approval)

[Cliff Schmidt]

On 10/24/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

So, I am asking for a vote of the Incubator on graduation of Harmony
that is conditional on the board's approval of a TLP for that purpose.
This way we don't have to vote again after the board meeting on
Wednesday (or whenever the board considers the proposal).

Please send in your +1/0/-1 to approve/abstain/disapprove.


+1


Status: 


a little strange that the Incubation Status Reports section reads,
"none yet", but I've seen several of them in Incubator board reports
and such a piece of bureaucracy won't change my vote.

Cliff

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

Re: Re: Policy on Initial Committership

[Cliff Schmidt]

On 10/6/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:

If the Proposer controls the Proposal (and not stick it on a freely editable
Wiki), then isn't it very straight forward?


+1, although I think a Wiki still *should* work if the established
etiquette was not to make edits to someone else's proposal


You feel excluded (I have); Convince the Proposor that you belong.


+1


You feel "piling on" is happening; Ask the Proposer to qualify the selection
criteria, and have a dialog if you find it "inappropriate".


+1, and the Champion should be the first one to bring up this topic
with the proposed initial committers, before the proposal even shows
up at Apache.


I mean, who cares if "Company X" starts a podling in ASF Incubator with 400
employees getting commit access to that project?


+1, I think it is a mistake to impose an artificial limit to the
number of people who can be initial committers from the same company
if each one of them is going to be spending a significant amount of
time working on the project.


If we change the wording in Graduation Criteria to include "maximum 30% of
committers from the same company", then that excessive initial PPMC on the
Proposal quickly becomes a handicap.


I agree with the sentiment here, but we've been through the 50% rule
before and found it to have flaws.  There have been podlings that most
Incubator PMC members were quite happy with by the time the graduation
vote came around, but they consisted of >50% from the same employer.
We specifically dropped the 50% requirement about 2.5 years ago when
we saw that a podling was operating openly, transparently, and based
on merit; and, they had added a couple committers to further diversify
the group, but were having trouble finding more contributors with
consistent and valuable contributions to bring in as a committer.
They also didn't want to drastically drop the 'merit bar' for
committers just to meet some imposed percentage so they could graduate
(many ways to 'game the system' here).

What I believe we've found works best over the years is to consider
the entire behavior of the project over its incubation and raise
questions about any trends pushing it in the wrong direction.  We also
should consider any actual or perceived employer domination that is
either biasing project decisions or intimidating others from getting
involved.

I wish we could just have an objective list of numerical requirements,
but I think it has to come down to the judgement of the Incubator PMC
members.

(not to say that I thought Niclas was advocating for a particular
numerical requirement right now -- I just wanted to agree with his
idea that employer domination can be considered at graduation, but
caution the use of hard numbers)

Cliff

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

Qpid mailing lists

[Cliff Schmidt]

The Qpid project (formerly known as Blaze and Glasgow) mailing lists
are now set up.  Please subscribe to the dev list if you are
interested in following or participating in the project.  A commits
list is also set up for those wanting to track changes to the
repository.

Here's the info:
qpid-dev at incubator.a.o
qpid-commits at incubator.a.o

As with any Apache mailing list, to subscribe, simply send a blank
email to *-subscribe, e.g. qpid-dev-subscribe at incubator.a.o.

Cliff

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

[RESULT] [VOTE] Glasgow accepted for incubation

[Cliff Schmidt]

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

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

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

Cliff

On 8/10/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:

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

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

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

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

Thanks,
Cliff

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

Binding +/-0
Bill

Binding -1s:
Garrett, Brian



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

Spec process concerns (without voting):
Mads, Leo

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



On 8/3/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> I believe all open questions about the Glasgow proposal (originally
> submitted as "Blaze") have now been addressed enough to call a vote
> for accepting the project for incubation.
>
> Therefore, as the champion of this project, I am calling a vote.  As
> usual, the binding votes will be those case by Incubator PMC members
> (since the project is requesting sponsorship from the Incubator PMC);
> however all participants on this list are encouraged to vote if they
> have a strong feeling one way or another.
>
> The traditional 72-hour voting period would end during a weekend for
> most timezones; so I propose extending that by an additional day, with
> the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
> 
http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=7&year=2006&hour=17&min=0&sec=0&p1=0)
>
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=1.
>
> Note the old wiki page (with the full history of changes since the
> original proposal) can be found here:
> http://wiki.apache.org/incubator/Blaze
>
> Cliff
>
> 
> = Glasgow Proposal (renamed from Blaze) =
>
> == RATIONALE ==
> Glasgow provides multiple language implementations of the Advanced
> Messaged Queuing Protocol (AMQP) specification and related
> technologies including PGM, transaction management, queuing,
> distribution, security, management and heterogeneous multi-platform
> support for messaging (links to these specifications are in the
> "Initial Source" section of this proposal.)
> Glasgow's overall goal is to create an open and interoperable
> implementation for messaging which implements the emerging AMQP
> specification, in keeping with the philosophy of the Foundation. This
> implementation will provide a messaging solution that will be language
> and platform agnostic by using a well defined wire specification.
> Providing both libraries for the framing and protocol in addition to
> brokers in both Java and C/C++ allows for integration with Apache and
> non-Apache projects in a manner that facilitates heterogeneous
> deployment with full interoperability for SOA & distributed systems.
> The seed code for the project will consist of in-progress C/C++ and
> Java implementations of the AMQP specification that we intend to
> continue development on in conjunction with other Apache communities.
> More information on the scope of the seed code can be found in
> subsequent sections of this proposal.
>
> == CRITERIA ==
> === Meritocracy: ===
> The Glasgow committers recognize the desirability and necessity 

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

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

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

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

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

Thanks,
Cliff

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

Binding +/-0
Bill

Binding -1s:
Garrett, Brian



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

Spec process concerns (without voting):
Mads, Leo

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



On 8/3/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:

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

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

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

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

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

Cliff


= Glasgow Proposal (renamed from Blaze) =

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

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

=== Community

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

[Cliff Schmidt]

On 8/7/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:

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

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


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

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

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

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

Cliff

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

Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)

[Cliff Schmidt]

On 8/4/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:

IMO the reason this naming debate hasn't been settled is because of the
way in which the change from Blaze to Glasgow was achieved: it was done
privately and the result was announced here.


hmm...sounds like we should have some docs that suggest that the
moment a group of people proposes a new project for incubation (if
they don't already have an existing open project mailing list), they
should use the [EMAIL PROTECTED] list as their pre-project discussion
list.  When any question about the proposal comes up, all proposed
committers (10-20 of them) are encouraged to have their own discussion
on our lists to work out what they'd like to do.  Might even be better
to say that the moment a few of them have an idea for the proposal,
they should use our general list to discuss the proposal drafts before
proposing it to us. ;-)

I have no doubt that every committer of every proposal I've ever been
involved has understood the importance of open discussions on apache
lists once the project starts.  However, I think most of them have
hesitated to use apache lists for project-specific discussions before
their proposal has even been accepted (other than to respond to
concerns/questions from the incubator community).


We're *such* a whacky bunch.


indeed, we are.

Clif

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

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

On 8/4/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:

On 8/4/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> nor would I, as a mentor, ever allow any project to move through
> incubation without actively working to create such a community.

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


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

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

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

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

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

Cliff

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

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

On 8/4/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:

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

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


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

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

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

Cliff

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

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

Coach, 

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

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

Thanks,
Cliff
  
  

-Original Message-
From: "Coach Wei" <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 11:32:14 
To:
Subject: RE: [VOTE] Accept Glasgow into Incubator

+1 (non binding) from me.

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

---Coach Wei

> -Original Message-
> From: Cliff Schmidt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 03, 2006 12:52 PM
> To: general@incubator.apache.org
> Subject: [VOTE] Accept Glasgow into Incubator
> 
> I believe all open questions about the Glasgow proposal (originally
> submitted as "Blaze") have now been addressed enough to call a vote
> for accepting the project for incubation.
> 
> Therefore, as the champion of this project, I am calling a vote.  As
> usual, the binding votes will be those case by Incubator PMC members
> (since the project is requesting sponsorship from the Incubator PMC);
> however all participants on this list are encouraged to vote if they
> have a strong feeling one way or another.
> 
> The traditional 72-hour voting period would end during a weekend for
> most timezones; so I propose extending that by an additional day, with
> the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
>
http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=7&year=
20
> 06&hour=17&min=0&sec=0&p1=0)
> 
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=1.
> 
> Note the old wiki page (with the full history of changes since the
> original proposal) can be found here:
> http://wiki.apache.org/incubator/Blaze
> 
> Cliff
> 
> 
> = Glasgow Proposal (renamed from Blaze) =
> 
> == RATIONALE ==
> Glasgow provides multiple language implementations of the Advanced
> Messaged Queuing Protocol (AMQP) specification and related
> technologies including PGM, transaction management, queuing,
> distribution, security, management and heterogeneous multi-platform
> support for messaging (links to these specifications are in the
> "Initial Source" section of this proposal.)
> Glasgow's overall goal is to create an open and interoperable
> implementation for messaging which implements the emerging AMQP
> specification, in keeping with the philosophy of the Foundation. This
> implementation will provide a messaging solution that will be language
> and platform agnostic by using a well defined wire specification.
> Providing both libraries for the framing and protocol in addition to
> brokers in both Java and C/C++ allows for integration with Apache and
> non-Apache projects in a manner that facilitates heterogeneous
> deployment with full interoperability for SOA & distributed systems.
> The seed code for the project will consist of in-progress C/C++ and
> Java implementations of the AMQP specification that we intend to
> continue development on in conjunction with other Apache communities.
> More information on the scope of the seed code can be found in
> subsequent sections of this proposal.
> 
> == CRITERIA ==
> === Meritocracy: ===
> The Glasgow committers recognize the desirability and necessity of
> running this project as a full meritocracy; indeed, the scope of the
> project's technical aspects are so varied that we find it hard to
> envision success any other way. One of the most important lessons that
> can be derived from the historic evolution of middleware is that
> specifications architected in isolation from real usable code that has
> been developed to solve tangible, real world problems or amongst a
> narrowly restricted list of contributors often do not see widespread
> adoption. Our goal in crafting this implementation and providing our
> learning to the specification team is to develop the best possible
> language agnostic advanced message queuing platform.  We understand
> that in order to do so, we will need to engage all interested  members
> of the community and operate to the standard of meritocracy that
> characterizes successful Apache projects.
> 
> === Community: ===
> The project's primary objective is to build 

Re: [VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

Coach, 

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

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

Thanks,
Cliff
  
  

-Original Message-
From: "Coach Wei" <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 11:32:14 
To:
Subject: RE: [VOTE] Accept Glasgow into Incubator

+1 (non binding) from me.

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

---Coach Wei

> -Original Message-
> From: Cliff Schmidt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 03, 2006 12:52 PM
> To: general@incubator.apache.org
> Subject: [VOTE] Accept Glasgow into Incubator
> 
> I believe all open questions about the Glasgow proposal (originally
> submitted as "Blaze") have now been addressed enough to call a vote
> for accepting the project for incubation.
> 
> Therefore, as the champion of this project, I am calling a vote.  As
> usual, the binding votes will be those case by Incubator PMC members
> (since the project is requesting sponsorship from the Incubator PMC);
> however all participants on this list are encouraged to vote if they
> have a strong feeling one way or another.
> 
> The traditional 72-hour voting period would end during a weekend for
> most timezones; so I propose extending that by an additional day, with
> the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
>
http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=7&year=
20
> 06&hour=17&min=0&sec=0&p1=0)
> 
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=1.
> 
> Note the old wiki page (with the full history of changes since the
> original proposal) can be found here:
> http://wiki.apache.org/incubator/Blaze
> 
> Cliff
> 
> 
> = Glasgow Proposal (renamed from Blaze) =
> 
> == RATIONALE ==
> Glasgow provides multiple language implementations of the Advanced
> Messaged Queuing Protocol (AMQP) specification and related
> technologies including PGM, transaction management, queuing,
> distribution, security, management and heterogeneous multi-platform
> support for messaging (links to these specifications are in the
> "Initial Source" section of this proposal.)
> Glasgow's overall goal is to create an open and interoperable
> implementation for messaging which implements the emerging AMQP
> specification, in keeping with the philosophy of the Foundation. This
> implementation will provide a messaging solution that will be language
> and platform agnostic by using a well defined wire specification.
> Providing both libraries for the framing and protocol in addition to
> brokers in both Java and C/C++ allows for integration with Apache and
> non-Apache projects in a manner that facilitates heterogeneous
> deployment with full interoperability for SOA & distributed systems.
> The seed code for the project will consist of in-progress C/C++ and
> Java implementations of the AMQP specification that we intend to
> continue development on in conjunction with other Apache communities.
> More information on the scope of the seed code can be found in
> subsequent sections of this proposal.
> 
> == CRITERIA ==
> === Meritocracy: ===
> The Glasgow committers recognize the desirability and necessity of
> running this project as a full meritocracy; indeed, the scope of the
> project's technical aspects are so varied that we find it hard to
> envision success any other way. One of the most important lessons that
> can be derived from the historic evolution of middleware is that
> specifications architected in isolation from real usable code that has
> been developed to solve tangible, real world problems or amongst a
> narrowly restricted list of contributors often do not see widespread
> adoption. Our goal in crafting this implementation and providing our
> learning to the specification team is to develop the best possible
> language agnostic advanced message queuing platform.  We understand
> that in order to do so, we will need to engage all interested  members
> of the community and operate to the standard of meritocracy that
> characterizes successful Apache projects.
> 
> === Community: ===
> The project's primary objective is to build 

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

[Cliff Schmidt]

Just as I was posting the vote thread for the Glasgow project, I saw
Noel had updated the new wiki page with a concern about the name
collision with the old Sun codename for their JavaBeans Activiation
Framework (see 
http://wiki.apache.org/incubator/GlasgowProposal?action=diff&rev2=2&rev1=1).

I already mentioned that I didn't see this as a problem earlier in
this thread and didn't hear further concerns, but am repeating this to
be extra clear.  There certainly is no registered trademark for it and
the "unregistered use" of it appears pretty dead.  I'm partly basing
this off of Craig's post:

On 7/27/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

For just a moment, I thought you were serious.

JavaBeans Activation Framework, 1999.
JavaBeans Drag and Drop, 1998.

If Glasgow were really a software name to be worried about, I think
we might have heard more of it in the last 6 years...


Cliff

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

[VOTE] Accept Glasgow into Incubator

[Cliff Schmidt]

ameworks (such as Celtix or ServiceMix).
* Support and integration of Security.
* Management tools.
* Support for additional class frames such as tunneling

== INITIAL SOURCE ==
A group of companies are developing a set of specifications relating
to the creation of commodity enterprise class messaging, collectively
called Advanced Message Queuing Protocol (AMQP). In progress versions
are available at:
* http://www.envoytech.org/spec/amqp/
* http://www.iona.com/opensource/amqp/
* http://www.redhat.com/solutions/specifications/amqp/
* http://www.twiststandards.org/tiki-index.php?page=AMQ
* http://www.faqs.org/rfcs/rfc3208.html


The initial contributors have been developing Java and C++ code bases
(licensed under the Apache License 2.0) which implement aspects of
these specifications, and intend to donate it to Apache. The current
working svn is available at:
https://etp.108.redhat.com/source/browse/etp/trunk/blaze

Although the Glasgow project expects to bootstrap using these
materials and in the case of specifications, to provide feedback that
will be incorporated into their ongoing development, we expect and
encourage the open source community to take the project in new
directions not envisioned by them to create a world class
implementation of the AMQP specification and related technologies.

== Interactions with the specifications ==
The specification is being developed by group of companies, under a
contract that requires the resulting work to be published to a
standards body. This model has been chosen to assure that anyone that
contributes to the specification grants a copyright and patient
license to all contributions made to the specification on every
publication (draft or final). This ensures that the specification will
always be open and implementable by anyone without royalties or
commercial limitations. We feel that this is a very strong model for
keeping this work entirely open and will fit well with the Apache
project enabling innovations to pass in both directions across the
extended community.

Dealing with feedback from the Glasgow project to specifications
It is key that the best implementation and specifications be created
based on technical merit and practicalities for adoption by both the
parties developing the specification and the committers within the
Apache community. Given this, one of the important aspects is how
issues discovered during the development of this implementation are
incorporated back into the specifications.  The following feedback
loop exists to ensure that any specification input incuding the
Glasgow community can have their feedback incorporated into the
specifications.
=== MECHANISMS FOR FEEDBACK ===
a.) In the same way anyone can issue a JIRA on any Apache project
having signed the Apache CLA, anyone can issue a "JIRA" to the
specification working group through the RLA (Reviewer License
Agreement). This agreement provides a license to that IP so that the
specification team can incorporate it and the specifaction as they
like and the specifications can remain entirely open and royalty free.
b.) In the same spirit of Apache, if an individual has shown
understanding of the project and substantive contribution to the
specification, a vote based on technical merit and understanding of
the goals of the work can be initiated to have that parties Employer
join the specification working group. On such acceptance the employer
is required to sign an agreement to make sure that employer also
grants the ongoing and consistent licenses to the work as posted in
specifications.

The Reviewer License Agreement (RLA) can be viewed from the AMQP
specification page of any of the members as listed above.

== ASF resources to be created ==
mailing list(s)
 * glasgow-dev
 * glasgow-commits
Subversion repository
 * https://svn.apache.org/repos/asf/incubator/glasgow
Jira
* Glasgow (GLASGOW)

=== INITIAL COMMITTERS ===
 * Rajith Attapattu (Red Hat)
 * Mark Atwell (JPMC)
* Bela Ban (Red Hat)
 * Bhupendra Bardwaj (JPMC)
* Alan Conway (Red Hat)
 * Tejeswar Das (IONA)
 * Ovidiu Feodorov  (Red Hat)
* Tim Fox (Red Hat)
 * Paul Fremantle (WSO2)
 * Eoghan Glynn (IONA)
 * Robert Greig (JPMC)
 * Chamikara Jayalath (WSO2)
* Sam Joyce (IONA)
 * John O'Hara (JPMC)
* Frank Lynch (IONA)
 * Marnie McCormack (JPMC)
 * Martin Ritchie (JPMC)
 * Rafael Schloming (Red Hat)
 * Archit Shah (Red Hat)
 * Stephen Shaw (JPMC)
* Gordon Sim (Red Hat)
 * James Strachan (LogicBlaze)
 * Manik Surtani (Red Hat)
* Paul Taylor (IONA)
 * Carl Trieloff (Red Hat)
 * Kim van der Riet (Red Hat)
 * Steve Vinoski (IONA)
 * Sergey Yedrikov (IONA)

=== APACHE SPONSOR ===
The Glasgow team will make the submission to the incubator as the
sponsor for incubation.

Champion
* Cliff Schmidt (consultant to Red Hat)
Mentors:
 * James Strachan
* Cliff Schmidt (consultant to Red Hat)
 * Paul Fremantle

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

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

[Cliff Schmidt]

Brian,

As the Champion for this proposal, I'd like to move this on to a vote.
I just read all the related posts one more time, and I believe your
concern below is the only one that hasn't been directly addressed (if
I'm wrong about this, someone speak up).  So, I want to offer my
thoughts on it and you can tell me if there is more to discuss before
voting.  Otherwise, I'll probably start the vote within the next 12-24
hours, unless there are other concerns that pop up.

See below.

Cliff

On 7/31/06, Brian McCallister <[EMAIL PROTECTED]> wrote:

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

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


I don't see this as being different from any proposal that comes to
the Incubator that wants to implement something other than a broadly
accepted standard.  We often get proposals for things based on some
vendor's previously proprietary software.  Sometimes the proposal
includes committers employed by a couple independent companies; in
this case, there are 3-4 employers.  I definitely think we need to be
careful about these projects, which is why I've always been a big fan
of strong incubator branding.

However, I do completely understand your concern about the ASF giving
AMQP a boost too early.  So, while there may be some boost from it
getting incubation status at Apache (which we have to weigh up with
all new projects), your concern is the same thing that makes me
hesitant to advocate that the ASF should join the AMQP spec group.  It
would provide easy participation for ASF committers to the spec work,
but it could also be a big endorsement that I don't think we should be
giving to this group at this stage.  I get the impression that Carl
and the others would be happy to have the ASF; I'm just not sure it's
the right decision for us...but none of this makes me thing this
project should not be accepted for incubation.  Do you feel
differently?

Cliff

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

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

[Cliff Schmidt]

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

On Aug 1, 2006, at 11:36 AM, Sanjiva Weerawarana wrote:

> On Tue, 2006-08-01 at 12:36 -0400, Carl Trieloff wrote:
>> Brian,
>>
>> Just as in JCP, OASIS or W3C the real work happens on private
>> channels,
>> that said we are in
>> the process of creating public pages, from which to link user and
>> feedback lists for anyone to
>> read, access and interact with the working group.
>
> Correction: W3C working groups do *all* technical work in public
> mailing
> lists that are open to all.
>
> That change occurred probably 5+ years ago.

Umm, I don't think so.  As a TAG member, I encountered many discussions
that were in members-only areas, and they are still going on (XML
Schema,
for example).  The TAG would refuse to participate in any such
discussion,
which often required permissions be obtained to move comments from a
private forum to a public one.  W3C decisions are all made in public.
Maybe you are referring to working groups that have been initiated in
the past five years?


yep -- I figured Sanjiva was just thinking of the WGs in the Web
Services Activity, which have tended to follow the policy he
described.  There have been a few others like that, but my
experience/observation has been that the majority of W3C WGs still do
most of their work on private lists.  It can still be an ordeal just
to get some WGs to make f2f minutes available publicly.

Cliff

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

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

[Cliff Schmidt]

On 8/1/06, Brian McCallister <[EMAIL PROTECTED]> wrote:

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


Brian,

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

Cliff

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

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

[Cliff Schmidt]

Does anyone have any further concerns about this proposal?

- I think Glasgow is fine since it appears not to conflict with any
registered software marks.  I don't think we need to be worried about
the university reference, and we obviously have several projects
already named for cities.  I'm also not worried about any company's
old unregistered code names.

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

As the champion for the project, I'll start a vote for this unless I
hear unresolved concerns in the next 48 hours or so.  I'll also make
sure the wiki is updated, if necessary, before calling the vote.

Cliff

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

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

[Cliff Schmidt]

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

OTOH, experience has shown that an effective open source project
can cause a previously closed "standard" to be forced into the open
or be supplanted.


+1


In any case, BLAZE is one of the more over-registered trademarks
in the USPTO with 329 applications, most of them live and at least
one registered for web software.  It is not an acceptable name for
a podling.


Good point -- thanks, Roy!

Cliff

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

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

[Cliff Schmidt]

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

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.


First of all, let me apologize for the longest email I've written in
some time.  I've obviously had too many of these thoughts built up in
my head over the last couple years, and it's all apparently spilling
out now...

But before I begin to ramble, let me give a brief response to Henri's
comment above:
The major concern we've had around standards bodies lately was with
OASIS's WS-Security.  That Technical Committee's IPR mode (IP rights
licensing) does not conform to any of the three options of the new
OASIS IP policy.  Instead it is called legacy, meaning that it could
be anything, and we were unhappy with the particular terms that the
vendors picked (which are now being considered for revision based on
our feedback).  That was probably the reason for your mental flag.

Regarding whether a standards body would dictate the IPR terms is that
it is not their IP to dictate.  They body either has an IPR policy (or
at least an IPR option) that is compatible with the license the
authors have chosen (and have agreed to keep in force in future
versions) or they don't.  If they don't, the contract that they
authors signed to keep the spec under RF terms doesn't allow the spec
to be submitted to such a standards body.  But, the thing is that the
W3C, OASIS, and many others do, in fact, have Apache-friendly options
if the authors choose to pick them when forming the TC.

now on to my big-picture thoughts about this proposal...

The cool thing is that several people (Brian, Dims, Paul, and others)
have been asking the exact same questions I asked when I was
approached to champion and mentor this project.  The answers I got
from Carl sounded equal to or an improvement over other projects we've
accepted for incubation in the past.  Based on these answers, I had
two thoughts:
- It's difficult to reject a proposal when we've accepted others that
are based on less-open specifications (unless we've declared such
projects as failures, not to be repeated), and
 - If the Blaze committers are willing to accept the fact that they
will not graduate from the Incubator until the AMQP process meets our
standards for specification openness, I'd like to spend my time using
this project to help get ASF folks to reach a consensus on exactly
what we mean by open specifications implemented at Apache.

In short, Blaze is more open than Tuscany; but we might want a higher
bar.  I'd like us to document exactly what that bar is and hold all
podlings to it before we let them graduate.


on to some specific issues...

1. Licensing of the specification.
a. Copyright licensing
Carl had told me that the specification license would allow for
royalty-free (RF) distribution of the specification itself.  I think
(and would like others to confirm) that it might be important to be
able to include a copy of the spec within source code distributions of
any release.  We would clearly need the distribution right for this.
And, even if we didn't need to do this, we might want to check the
spec into subversion or possibly post the whole or parts of the spec
on an ASF website.  We would need a distribution right for this as
well (some specification licenses reference the right to display, but
this is not enough).  Some people might even claim that an
implementation of the spec copies and eventually distributes parts of
the specification in its source and/or binaries.  I'm actually not too
worried about this argument, although it might be another reason to
want to see the word "distribute" in the RF grant for the spec.

* The bad news on this is that the spec license appears only to grant
copy, display, and implement rights, not distribution.
* The good news is that I asked Carl about this today, and he says
he's surprised at that as well and expects it is only an
administrative hassle to get it fixed, but that it will happen.
 * The ugly news is that the SCA spec that Tuscany is based upon
seems to have the same problem.

b. Patent licensing
* The good news is that there is an RF license for all patent claims
required for  implementation, and there is no contract required to be
signed, nor is there any requirement for cross-licensing, instead just
a patent-retaliation clause not too far different than that in the
Apache License.
* The bad news is that it's a whole lot of text to accomplish
something nearly identical to many shorter versions that make people
more comfortable and don't require as much lawyer time.


2. Application of the non-public specification drafts.
If a project is chartered to implement a specification (whether in a
standards body or not), I don't ever want to see c

Re: [VOTE] CeltiXfire Project Proposal

[Cliff Schmidt]

On 7/12/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

There has been plenty of discussion around the CeltiXfire proposal,
we feel that all the issues forwarded have been addressed, and we
would now like to officially propose CeltiXfire to the Incubator for
consideration. The proposal can be found in the Incubator wiki here:

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


+1

Cliff

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

Re: [doc] Roles and Responsibilities Update Needed [WAS Re: Mentors - the more, the merrier?]

[Cliff Schmidt]

On 7/14/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:

On 7/14/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
> Kenneth Tam wrote:
>
> > http://incubator.apache.org/incubation/Roles_and_Responsibilities.html
>
> > "A Mentor is a role undertaken by a permanent member of the Apache
> > Software Foundation and is chosen by the Sponsor to actively lead in
> > the discharge of their duties (listed above)."
>
> We still haven't fixed that doc?  Ok, rhetorical.  We need to fix that
> doc.


+1

i'm still working on a couple of draft documents so i'm not sure i'll be
able to get this one before the middle of next week.

anyone care to volunteer?


Could someone point to the post that would explain how it should be fixed?

Cliff

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

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Cliff Schmidt]

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

Cliff Schmidt wrote:
> It also allows this mentor to demonstrate the role of a chair

How hard is it to understand that the PMC Chair has no role (slight
hyperbole)?


Then I guess I would have to ask you, "how hard is it to understand
that the PMC chair does, in fact, have a very specific role?".
Section 6.3 of our bylaws describes that specific role.


If the PMC Chair is a visible role, the community is already in
trouble.  The only role that a PMC Chair normally fills is getting the
quarterly report filed.  And this is why I feel strongly that we are
discussing the wrong thing to do.


I must be misunderstanding something about what you are saying,
because I can think of a few things that you have done as Incubator
PMC Chair that has been more than filing reports...and I've been glad
you've done such things.


Projects should not be trained to rely
upon an individual; they should be trained to act collaboratively.


I completely agree, but I've found a good PMC chair to be very helpful
to guiding the rest of PMC on process issues, among other things.  I
guess we've had different experiences in our years of participating
and chairing PMCs.

Cliff

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

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Cliff Schmidt]

On 7/13/06, David Blevins <[EMAIL PROTECTED]> wrote:

Maybe you'd start with one of the mentors as chair then, maybe half way
through incubation, start grooming a new ppmc chair from within the project.


+1
This addresses my concern about formally identifying the mentor who is
taking the key responsibility for the podling (rather than three
rarely available mentors with no one of them taking responsibility).
It also allows this mentor to demonstrate the role of a chair,
particularly during the beginning of the project when the project
could use help with both community processes and logistics.  And I
definitely agree with the idea of handing off that role during
incubation to one of the committers as soon as one of them as got the
idea.

Cliff

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

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Cliff Schmidt]

On 7/12/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:

On 7/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:



(And I'll note now that I'm interested in participating, although can't
> commit the time to be a mentor right now.)
>

this seems like a good opportunity to reintroduce an existing issue (
http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/[EMAIL 
PROTECTED])
under a better heading :-)

the incubator seems to be moving to favouring more mentors. this works
better in many ways: it gives an initial ppmc a builtin quruom and provides
better oversight. the role of a solo mentor has traditionally been difficult
and has consumed a lot of energy. multiple mentors would allow wider
participation (without some of the current worries about mentors becoming
overstretched by working on too many projects).

but this approach may lead to problems if none of the mentors actually have
enough consistent energy to devote to the podling.

i've been wondering whether the answer may be to have a chair for each ppmc
analogous to the role of the pmc chair. the initial pmc would be composed of
the mentors for the podling and so a chair would need to be elected from
within their number. at least one mentor would therefore need to commit to
devote the energy required to perform this role. they would also form the
first point of contact for the incubator pmc.


This sounds good to me, unless you are implying that the ppmc would
only include mentor-types and not all interested committers.  Can't
tell from what you've written above, but I've heard others talk about
how to select a ppmc, as if it wasn't open to all committers, and I
think it should be open.

But, to your main point -- I have always favored either one dedicated
mentor or one of the mentors being identified as the primary one -- so
I like your 'ppmc chair = dedicated mentor' idea.

Cliff

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

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Cliff Schmidt]

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:

> below) and other recent threads, here's what I would propose also be
> doc'd:
>
> "IRC can be used by a podling to bring new people up to speed (e.g.
> Q&A between available committers and interested users/contributors),
> although such sessions should be archived and made available to those
> not able to attend.  However, using IRC as a means to conduct
> development/architecture discussions is discouraged.  Even with the
> best intentions, experience has shown that it is difficult to maintain
> such discussions without implicit decisions being made in the
> process."

that sounds good. it makes clear that IRC *can* be used for Q/A. and
it should be
made public. For instance for a Q&A "session" the content could/should
end-up in a FAQ or the FAQ should/could be enhanced.

also no dev/arch decissions is mentioned.


Just to be clear, this proposed piece of text was meant to supplement
what we have now that categorically excludes off-list decision making.

Cliff


> On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Jean-
> >
> >
> > > Given this paragraph in the committers guide [1]:
> > >
> > > > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
> > >
> > > Would adding this sentence to the end help?
> > >
> > >Decisions only get made on Apache mail lists -- not anywhere
> > >off list, such as IRC, IM, or private emails.
> >
> >
> > yes! I like it! I'd like to provide a patch, or go ahead if you have
> > "write" rights.
> >
> > -Matthias
> >
> > > > btw. 404 for:
> > > > http://incubator.apache.org/howtoparticipate.html
> > >
> > > oof! some post-docathon moldly links need to be cleaned up. thanks for
> > > pointing it out.
> > >
> > >  -jean
> > >
> > > [1] http://incubator.apache.org/guides/committer.html
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > futher 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]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Matthias Wessendorf

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




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

[doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Cliff Schmidt]

More explicit documentation is usually a good thing, and having clear
docs stating that decisions must only take place on the mailing lists
is no exception...however, that's not really what this thread was
about.

Most of this thread has been about what non-decision-making role
should IRC play, if any, for a podling project?  The XAP folks already
knew decisions shouldn't be made on IRC; they were talking about
whether regular, open IRC discussions could be helpful.  Based on this
thread (particularly Noel and Geir's thoughts, which I steal much of
below) and other recent threads, here's what I would propose also be
doc'd:

"IRC can be used by a podling to bring new people up to speed (e.g.
Q&A between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process."

Thoughts?

Cliff

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:

Jean-


> Given this paragraph in the committers guide [1]:
>
> > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
>
> Would adding this sentence to the end help?
>
>Decisions only get made on Apache mail lists -- not anywhere
>off list, such as IRC, IM, or private emails.


yes! I like it! I'd like to provide a patch, or go ahead if you have
"write" rights.

-Matthias

> > btw. 404 for:
> > http://incubator.apache.org/howtoparticipate.html
>
> oof! some post-docathon moldly links need to be cleaned up. thanks for
> pointing it out.
>
>  -jean
>
> [1] http://incubator.apache.org/guides/committer.html
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Matthias Wessendorf

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




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

Re: Extensible Ajax Platform (XAP) Project Update

[Cliff Schmidt]

On 7/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:

This thread may be dead/resolved, in which case just ignore me.


It was only "mostly-dead"...but you've raised some good points that I
agree with.


Cliff Schmidt wrote:
> On 6/23/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> The use of e-mail as the primary means for communication is part of ASF
>> policy and philosophy, and we can certainly learn lessons from
>> projects that
>> have gone against it.  IRC tends to breed a more closed, albeit arguably
>> more integrated, community.
>>
>> That said, if IRC can be used as a learning tool to rapidly bring new
>> people
>> up to speed, and if the information gathered from those sessions is
>> preserved for others to follow up via web-site and e-mail, how do people
>> perceive that?
>
> I've never done that on a project, but I think it could be a
> reasonable thing for a project to try.  I believe the Synapse folks
> have been doing regular IRC meetings from early on.  I'd be interested
> in their perspective on the pros and cons, particularly as an
> incubating project.

Someone did point out that dev traffic is falling off while commit
traffic is same or increasing.


Yep -- and since asking about the Synapse perspective, I haven't seen
a persuasive argument that IRC has been a particularly positive thing
for them.  The key issue could be whether IRC is used as "a learning
tool to rapidly bring new people up to speed" (as Noel asked, and I
echoed, curiosity about) , or whether it is more for development
discussions (which I think is a dangerous move, particularly for a new
project).


> As a XAP mentor, I know that the committers already understand that no
> decisions will be made over IRC, that logs of each IRC will be
> immediately made available to the entire community, and that they need
> to be sensitive to any concerns from people wishing but unable to
> participate.  But, are there other thoughts from the Synapse folks or
> anyone else who has used regular IRC meetings?

I think that people can have that understanding, but I think that it
doesn't matter - it's been my experience that while people are able to
quote the letter of the law as well as the explain the reason behind it,
people unintentionally make "informal decisions" on IRC and execute on
them, all with the best of intentions.  I know i've seen it with
Geronimo, and it can be very disruptive, even though it may be accidental.

I think lots of decisions made on dev lists are the same - informal -
without the trappings of a vote or such, because many decisions are made
by "lazy consensus" - people discuss things or search for help, and then
continue down whatever modified path the group explicitly or implicitly
agreed to.


+1


In the case of XAP, I'm guessing that many of the committers are
employees or contractors/consultants of Nexaweb.  Were I a mentor, I'd
want to be sure that pre-existing development process is being
sufficiently broken up to make it an Apache community development
project, and would worry that regular IRC meetings might be confused
with periodic development meetings...


I'm not as concerned about this point.  Having a semi-monthly IRC
session to help bring new people up to speed is unlikely to be the
thing that holds back a closed development process from becoming an
open and collaborative one.

The short, sound-bite version of the advice I give companies that are
trying to transition their development process to one like Apache's
is, "commits should make sense with the context of the public dev-list
archive alone, and the dev-list should make sense with the context of
the code base alone." (there are exceptions such as bug/issue history,
etc, but that doesn't fit in the sound-bite ;-)   The idea being to
prevent potential hallway conversations or other communication from
being part of the context of the work.

The kind of IRC session that Noel was asking about is less likely to
be the problem.  However, I agree with your concerns people
unintentionally making informal decisions on development-oriented IRC
meetings.

Cliff

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

Re: [VOTE] Accept Heraldry into the Incubator

[Cliff Schmidt]

On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems like the discussion on Heraldry has died down, so I'd like
to call for a VOTE on accepting Heraldry into the incubator.


+1

Cliff

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

Re: Extensible Ajax Platform (XAP) Project Update

[Cliff Schmidt]

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

The use of e-mail as the primary means for communication is part of ASF
policy and philosophy, and we can certainly learn lessons from projects that
have gone against it.  IRC tends to breed a more closed, albeit arguably
more integrated, community.

That said, if IRC can be used as a learning tool to rapidly bring new people
up to speed, and if the information gathered from those sessions is
preserved for others to follow up via web-site and e-mail, how do people
perceive that?


I've never done that on a project, but I think it could be a
reasonable thing for a project to try.  I believe the Synapse folks
have been doing regular IRC meetings from early on.  I'd be interested
in their perspective on the pros and cons, particularly as an
incubating project.

As a XAP mentor, I know that the committers already understand that no
decisions will be made over IRC, that logs of each IRC will be
immediately made available to the entire community, and that they need
to be sensitive to any concerns from people wishing but unable to
participate.  But, are there other thoughts from the Synapse folks or
anyone else who has used regular IRC meetings?

Cliff

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

Re: Dublin Docathon (was Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix)

[Cliff Schmidt]

On 6/19/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:

On 6/7/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> That was my plan as well; so I'm pretty flexible.  I guess I'd
> probably prefer not to schedule anything formal on Monday morning,
> since some folks may still be getting in.

How does Monday afternoon work?


Works for me -- also probably works okay for those in U.S. helping remotely.

I'll be in Dublin in the mid-morning.  I'll plan (as I've also heard
Robert say) to be working on docs most of Monday and Tuesday with
whomever is there.  It sounds like that will likely include Robert,
Justin, Noel, Sanjiva, possibly Ross, and me.  And then, there's Jean,
Eddie, and David Crossley who have offered to help remotely if
possible.  I'm not sure exactly how this remote thing will work, but I
think it would be worth trying to see if getting everyone's attention
on docs around the same time helps efficiently divide the work up and
offer faster feedback across docs.

Cliff

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

Re: Dublin Docathon (was Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix)

[Cliff Schmidt]

On 6/7/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:

On 6/7/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
>
> On 5/6/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> > So, let me put it this way: I'm committed to sit at a table for at
> > least eight hours during the two hackathon days and make some progress
> > on this stuff with Robert and whomever else can make it.  We should
> > also be able to have some live collaboration over irc with folks who
> > aren't able to make it to Dublin.
>
> Count me in as well for a 'docathon' - I'll be in Dublin too.


great :-)

Do we have a preferred date / time that we should collectively block
> out that also works reasonably well for our remote participants?  At
>
this point, I'm *mostly* open - but my schedule is getting more and
> more committed as we approach the 'Con.


nope  (I will be around most of the hackathon working on documentation so
will be available for ad hoc doc) but a more focussed docathon block sounds
good.


That was my plan as well; so I'm pretty flexible.  I guess I'd
probably prefer not to schedule anything formal on Monday morning,
since some folks may still be getting in.

Cliff

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

Re: [RESULT] Request to release (revised) Tuscany M1

[Cliff Schmidt]

yes -- it's true that the policy is still only proposed and that the
proposed policy allows for a transition/evaluation period to see the
impact of some of the requirements.

I would not suggest that you remove something from the release just
because it's under the NPL.  However, you should make sure the license
is copied into or referenced in the LICENSE file.

Cliff

On 6/1/06, ant elder <[EMAIL PROTECTED]> wrote:

Is pulling this M1 release really necessary? I was under the impression that
right now it _is_ ok to be redistributing the NPL 1.1 licensed Rhino binary.
Back in August last year the ASF board Special Order 6B, Allow
redistribution of MPL- and NPL-licensed executables, was approved by
unanimous consent, see section 6b at
http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_08_17.txt

Cliff's proposed third-party licensing policy at
http://people.apache.org/%7Ecliffs/3party.html is still only a proposal
isn't it? Even if it has now become ASF policy, it gives us one year to sort
out the Rhino licensing or to find a replacement. I did ask Cliff about this
specific issue back in March on legal-discuss, his reply is at
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200603.mbox/[EMAIL 
PROTECTED]


Given all this I'd really like to at least get this M1 release of Tuscany
out now as is. We've tried real hard to make Tuscany easy for new users to
get started, requiring a separate rhino download would make it that little
bit harder.

   ...ant

Jeremy Boynes wrote:
> To be on the safe side, I'm going to propose that
> we remove the Rhino jar from the distribution and
> update the NOTICE files etc. with information for
> users on where it can be downloaded from and under
> what terms. Do we need another IPMC vote after such
> a change or is lazy consensus acceptable?
>
> --
> Jeremy




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

[VOTE][RESULT] XAP Proposal PASSED

[Cliff Schmidt]

Based on the following votes (five of which were cast by PMC  
members), the XAP proposal has been accepted for incubation under the  
sponsorship of the Incubator PMC.


+1 Davanum Srinivas
+1 Noel J. Bergman
+1 Craeg Strong
+1 Henri Yandell
+1 Susan Wu
+1 Craig L Russell
+1 Sanjiva Weerawarana
+1 Jim Jagielski

As one of the project's mentors, I'll make the infrastructure  
requests and ensure all committers and corporate contributors get  
their CLAs in.  I'll also send a follow-up note to this list when the  
project mailing lists are set up, so that those interested can  
subscribe.


Cliff


On May 18, 2006, at 10:20 AM, Cliff Schmidt wrote:


Since this project was proposed a couple weeks ago, it now has a
champion, three mentors, and has further diversified its initial
committership.  Additional details about the project have been
discussed on this list, and I don't believe there are any unresolved
concerns.

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

The traditional 72-hour voting period would end in the middle of the
weekend; so I'll propose extending that by an additional day, with the
vote closing on Monday May 22, 2006 18:00 UTC (see
http://www.timeanddate.com/worldclock/fixedtime.html? 
month=5&day=22&year=2006&hour=18&min=0&sec=0&p1=0)


Please vote on the XAP proposal (rev 12 on the wiki and copied below).





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

Re: Who is attending ApacheconEU

[Cliff Schmidt]

On 5/18/06, Danny Angus <[EMAIL PROTECTED]> wrote:

They're keen to move this into open-source and I was wondering if any
apache-ites would be available at apacheconEU for me to talk to about
it and possibly to introduce these guys to.


If you're interested, Lars Eilebrecht and I will be giving the same
talk we've given the last few conferences called, "Behind the Scenes
of the Apache Software Foundation".  It will include about 45 minutes
or so on incubation.

See 
http://www.eu.apachecon.com/konferenzen/psecom,id,488,track,1,nodeid,,_language,uk.html#session-we1.

Cliff

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

[VOTE] XAP (Extensible Ajax Platform) Proposal (was XAP (Extensible Ajax Platform) Proposal)

[Cliff Schmidt]

ies Inc. The
donating company will contribute the intial code base immediately
after the proposal is accepted and necessary infrastructure has been
set up. For further background or technical infomation, please see
http://www.nexaweb.com/open/xap and http://www.openxal.org for more
details.

2.1 External Dependencies of the project

None.

3. Identify the ASF resources to be created
3.1 mailing list(s)

   * xap-ppmc (with moderated subscriptions)
   * xap-dev
   * xap-commits
   * xap-user

3.2 Subversion repository

   * https://svn.apache.org/repos/asf/incubator/xap

3.3 Jira

   *  xap

4. Identify the initial set of committers:

   * Atsuko Pien
   * Scott Boyd
   * Robert Buffone
   * Cliff Schmidt
   * Coach Wei
   * James Margaris
   * Michael Turyn
   * Jonathan Levin
   * Peter Eacmen
   * Animesh Kumar
   * Doug Schepers

5. Identify Apache sponsoring individual

Champion: Cliff Schmidt

Mentors: Cliff Schmidt, Susan Wu, Robert Burrell Donkin.

We request that the Apache Incubator PMC sponsor XAP as an incubating
project. There is not currently another TLP that would be an obvious
fit as sponsor for this project. As the project approaches graduation,
we would reevaluate possible TLP destinations and work with others at
Apache to consider whether a new TLP is warranted to include XAP and
possibly other related Apache projects.

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

Dublin Docathon (was Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix)

[Cliff Schmidt]

On 4/24/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:

really need to try to find time to get to grips with the documentation on
the foundation and incubator sites. been thinking about making this a goal
of mine for infrathon/hackthon in dublin (though sorting out my flights is
another job i should have done but haven't).


Let's do it.  We've been talking about the documentation problem for
years.  We've made a good bit of progress every once in a while during
those years, but I bet we could make a whole lot of progress if we
forced ourselves to all get together and dedicate 4-16 hours on it
during the hackathon.  Noel, Jean, and a few others have also talked
about working on docs lately; I've wanted to help, but haven't made
the time to work on anything not directly related to legal stuff.

So, let me put it this way: I'm committed to sit at a table for at
least eight hours during the two hackathon days and make some progress
on this stuff with Robert and whomever else can make it.  We should
also be able to have some live collaboration over irc with folks who
aren't able to make it to Dublin.

Thanks for the inspiration, Robert.

Cliff

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

Re: VOTE: Release Roller 2.2-incubating

[Cliff Schmidt]

On 4/30/06, David Crossley <[EMAIL PROTECTED]> wrote:

Craig McClanahan wrote:
> David M Johnson <[EMAIL PROTECTED]> wrote:
> >
> >OK, so Cliff says we need to have copyright notices on all files
> >before we can release 2.2 and that we should make the release on
> >Apache infrastructure this time.
> >
> >He also mentioned that somebody has a script that will automatically
> >apply said copyright notice to all source files. Anybody know where
> >this script can be found?
>
> There are a variety of relicensing scripts in various languages, in the
> "relicense" subdirectory of the "committers" SVN module.  You should have
> access to that by checking out [1].
>
> - Dave
>
> Craig
>
> [1]  https://svn.apache.org/repos/private/committers

I have some local modifications to the Perl version
of that tool, but i am waiting to hear the outcome of
last week's board meeting before committing the changes.


I explained the issues to the board last week and told them that we
now have a header approved by our lawyers -- just waiting on one last
piece of feedback before sending out the proposed text and process to
the legal-discuss list.  I told the board I'd have the official
resolution ready for them to vote on at the May 17th meeting.

Cliff

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

Re: licensing issues in clucene

[Cliff Schmidt]

On 4/29/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:

On Saturday 29 April 2006 02:57, Ben van Klinken wrote:
> For historical reasons, CLucene is dual licensed as Apache 2.0 license
> or LGPL. As I understand it, the apache license is currently is not
> compatible with GPL projects and therefore GPL projects can't
> distribute apache licensed software, so we would like to maintain the
> LGPL license as well.

Although Apache is not about its license, there are a lot of mechanisms in
Apache that assumes that there is only one license and that such license is
the Apache License v2.0

Although not directly forbidden, it will be a great burden on the project
(without support from the infrastructure team) and big deterent to manage to
maintain a dual-licensing scheme.

E.g.
Apache does not work with Copyright assigns, so each contribution is still
Copyrighted to the original author. Contribution via JIRA requires the
contributor to actively indicate that the contribution is covered by ALv2.
For a potential dual-licensing scheme, you must obtain the approval from the
contributor individually and separately from the normal procedures.
Furthermore, what if the contributor explicitly prohibits licensing under one
or the other licenses?
I doubt that the project will manage.


Now, as Noel points out, the compatibility issue is from our perspective very
obscure, and requires not only patents, but that the patent holder sues and
is distributing the (L)GPL'd work themselves (or something along those
lines)...
Somehow, it doesn't stop RedHat/Debian/et al to ship ALv2 stuff as part of the
GPL'd GNU/Linux platform.

My personal recommendation; Drop the dual licensing scheme, as it will break
if contribution numbers rises and would make less noise/problem when/if
coming to the Apache Incubator.


I generally agree with everything Niclas and Noel have said, I'll just add:

- A few months ago, folks on the Harmony project were interested in
being able to dual-license their contributions to GPL and Apache.  I
believe there was a fairly strong consensus against it, including from
one or more ASF board members.  Others may remember the details
better.

- As Niclas said, contributors retain the copyright ownership in their
contributions.  There's nothing to stop each individual from licensing
their code some other way outside of the ASF.  However, the problem is
that you can't ensure that all contributors to the project will do
this, particularly as the project grows.  So this dual-licensing thing
doesn't really work at Apache.  I've actually written CLAs and set up
procedures to handle doing this at other communities (it's not too
difficult), but I've never seen any consensus at the ASF to do such a
thing.

- It's true that the FSF does not believe the Apache License is
compatible with the GPL v2.  I could certainly understand why you
might be concerned that the FSF's position would make some of your
users not want to combine the Apache software with their other GPL or
LGPL works.   If it's any consolation, it is extremely likely that the
FSF will make it clear that GPLv3 and LGPLv3 are compatible with the
current version of the Apache License.  Of course, the GPLv3 won't be
released for 8-11 months and will only immediately affect software
licensed as GPLv2 or later.

Cliff

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

Re: VOTE: Release Roller 2.2-incubating

[Cliff Schmidt]

-1 until the following is corrected:

I see a couple problems with what I've just downloaded at
http://people.apache.org/~snoopdave/roller-2.2-rc/:

1. There's no NOTICE file.
2. Although there is clear mention of the LGPL components in the
README (which isn't required), I don't see anything in the LICENSE
file (which is required).  There should be either a copy of all
relevant licenses or a pointer to the other relevant licenses in the
LICENSE file.

Please read http://apache.org/dev/apply-license.html#new.

Cliff

On 4/25/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Dave Johnson wrote:
> > We've gone through 5 release candidates and are ready to release
> > Roller 2.2-incubating.
>
> > next time [we'll] use [the] official [disclaimer] wording.
>
> As per
> http://incubator.apache.org/incubation/Incubation_Policy.html#Branding, you
> need to either request the PMC to approve your substitute language or just
> use the boilerplate we approved for general use.
>
> I do not personally have a problem with your substitute wording:
>
>This release of Roller is not endorsed by the Apache Software Foundation.
>Roller is in the Apache Incubator and is not an official Apache project.
>
> so for a one-off usage I'll give you my +1,  Others may have an issue with
> the wording, and vote against the release with that wording.
>
> --- 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: Mistaken copyrights

[Cliff Schmidt]

On 4/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
> In the WebWork2 podling, we have several files that contain a copyright
> header naming the file as belonging to the ePlus corporation.  Turns out,
> this copyright was mistakenly applied due a developer's mistaken IDEA
> configuration, which was set to add that copyright to every new file.  That
> developer, Jason Carriera, is one of the WebWork 2 project leaders and now
> part of the podling.
>
> What can we do to resolve this?  Could it be as simple as Jason removing the
> copyright that shouldn't be there in the first place?  Does ePlus need to
> file a code grant for the two files?  What about a CCLA?  If one or both are
> filed, can we replace the copyright with an Apache copyright?

ePlus should sign a cCLA if their IP will be regularly contributed to
an Apache project.  If there are committers on the project who are
ePlus employees, it's likely that their contributions are
work-for-hire, meaning that it's not their IP to license to Apache --
so we need an ePlus cCLA, in addition to the committer's iCLA.

If ePlus has not signed a cCLA yet, but there is any sort of
significant code within the Apache project that belongs to them, we
should ask them for a Software Grant (CLAs do not cover past
contributions).

If there is code in an Apache project contributed under a (c/i)CLA
that mistakenly has a copyright header naming an entity that never
owned the code (and we are sure about this), we should just fix it
ourselves.

If there is code in an Apache project contributed under a (c/i)CLA
that has a copyright header that names an entity that does own a
particular contribution, but we want to replace the source header with
our standard header representing the collective work of the entire
project, then we should make sure the owner understands our header
policy and move their copyright header to the NOTICE file (e.g. "This
product includes contributions that are Copyright 2006 {IP-OWNER}.").

For any third-party code (code that was developed and distributed
elsewhere, but that we just include within our products, based on the
accepted accompanying open source license) that includes a copyright
header in its source files or attached to a binary file, we should not
change or remove the copyright header at all.

Hope that covers all possibilities.

Cliff

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

Re: [VOTE] Graduate Jackrabbit to TLP status (pending board approval)

[Cliff Schmidt]

On 3/12/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> The Apache Jackrabbit committers have voted to request graduation
> from the Incubator as a TLP.



> Please send in your +1/0/-1 to approve/abstain/disapprove.

+1

Cliff

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

Re: Is the incubator out of control?

[Cliff Schmidt]

On 12/21/05, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Ted Leung wrote:
> >
> > On Dec 21, 2005, at 8:22 AM, Noel J. Bergman wrote:
> >
>
> >>
> >>> I think that the incubation process is setting an incredibly
> >>> low bar for access to the Apache brand name
> >>
> >> And we require disclaimers and clear notice that projects ARE in the
> >> Incubator.  Look at how the folks are complaining that we are trying
> >> to make
> >> the projects look different by being in the Incubator.  They ARE
> >> different.
> >> And they MUST be Incubator branded, and follow Incubation rules.
>
> >
> > Most people in the world are unaware of the difference between an
> > incubated project and an Apache project.  Roy has also stated that once
> > a project is in the incubator it ought to be regarded as an Apache project.
>
> that can be easily resolved.
> you start up another domain say 'theincubator.org' or something 'proving
> grounds' related and make sure it has no apache branding, and that no
> project or PR firm can mention apache there.

Although I'm not sure we should take that step right now, I don't
think that's such a crazy suggestion.  I do believe we should rethink
the branding of incubating project:

Today, we complain that corporations working on incubating projects
are taking advantage of the Apache brand.  We wonder why the press and
public aren't aware of the distinction of incubating projects, and yet
we *require* these projects always preface their name with the same
master brand we use on fully endorse projects, "Apache".

We can't keep a low bar for incoming incubating projects and allow for
this confusion.  We may indeed need a multibrand strategy when it
comes to incubating projects.

Cliff

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

Re: AJAX Toolkit Framework Proposal

[Cliff Schmidt]

On 12/20/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Mike,
>
> Some one comes to ASF with a proposal, typically we give it our full
> consideration. I can understand why cliff asked about eclipse option
> (Beehive/Eclipse stuff!),

Actually, I had two purposes behind my question.  One was to learn
more about why the people behind the proposal wanted to come to
Apache.  Although it is nice to hear from Sam, as the project
champion, I was addressing Adam because I thought it would be nice to
hear from someone listed as a project committer as to why they thought
Apache community was a better fit.

My second reason for asking was as a polite gesture towards the
Eclipse Foundation, being another respectable, non-profit, open source
organization.  I strongly believe that the ASF is not an island in the
world of open source, and that it is good for us and all participants
in open source if we do what we can to minimize communication problems
about projects that others may have an interest in.  I probably don't
need to say any more about the relevancy of that issue to this
thread...but even when a miscommunication has nothing to do with the
ASF, I would prefer that it is addressed before the proposal becomes a
project associated with Apache.

Cliff

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

Re: AJAX Toolkit Framework Proposal

[Cliff Schmidt]

Adam,

Can you tell me if you considered proposing this to the Eclipse Foundation?

Since this project appears to have far stronger dependencies on
Eclipse Foundation projects rather than anything from Apache, can you
tell me why you think bringing this project here is likely to help you
build a stronger community than you would find at Eclipse?  Is there
some other overriding reason you prefer to bring this project to
Apache?

Cliff


On 12/20/05, Adam Peller <[EMAIL PROTECTED]> wrote:
> AJAX Toolkit Framework Proposal
>
> 0.  Rationale
>
> While the term AJAX (Asynchronous Javascript and XML) has only recently
> been coined, the underlying web standards and technologies (JavaScript
> a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
> Although the term is used in a variety of ways, AJAX typically describes
> techniques towards developing interactive applications on the web client
> including asynchronous messaging, use of XML grammar in client-side
> applications, incremental page updates, and improved user interface
> controls. AJAX applications combine the rich UI experience of programmed
> clients with the low-cost lifecycle management of web-based applications.
>
> AJAX has raised awareness of the high potential of web applications, it has
> encouraged companies to adopt rich web-based interfaces over traditional
> "fat" clients, and it has spawned development activity to create toolkits
> and abstractions to make AJAX-style development easier and more powerful.
> This is an important trend for open source.  The client itself can be
> composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
> Konqueror, and does not require any particular operating system, helping to
> make a more level playing field for all development.  More importantly,
> AJAX is back-end agnostic as transactions are done over HTTP.  Keeping the
> client open forces vendors to keep the communication channel open as well,
> and this can only continue as long as the client technology keeps pace with
> proprietary alternatives.  The open, standards based communications channel
> is what drives many technologies inside Apache, so success of the open
> client is vital to Apache.  The mission of this project is to encourage
> innovation around enterprise-strength client runtimes and tools and build a
> community which can select and nurture a select set which will be most
> beneficial to the web.
>
> 0.1 Criteria
>
> Meritocracy:
>
> Apache was chosen for an incubator primarily because of the guidance the
> community can provide.  The two subprojects put forth are among the first
> attempts to formalize this style of development.  Additional ideas, tools
> or entire runtimes may come forward and indeed would be welcomed to the
> project, either wholesale as new subprojects or incorporated into the
> existing code.
>
> Community:
>
> The contributed work was inspired by open source development but needs a
> strong and diverse community to validate its mission and carry it forward.
> A primary objective of the project is to build a vibrant community of users
> and active contributors.
>
> Core Developers:
>
> All of the initial committers are members of Zimbra and IBM development
> teams.  All developers have worked on open source projects before and have
> experience and understanding of open source principles.
>
> Alignment:
>
> Initial implementation consists of two sub projects.
>
> The AJAX Toolkit Framework will provide a strategic framework for
> Interactive Development Environments (IDEs) for the many different AJAX
> toolkit offerings in the market. It provides a rich set of tools for the
> AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
> checking; Mozilla web browser; integrated DOM browser; integrated
> JavaScript debugger; and wizards and development aides tuned to specific
> libraries and toolkits.  The Framework is extensible to support other AJAX
> toolkits and has a wizard-based tool to facilitate the integration of new
> toolkits in the framework.
>
> The AJAX Toolkit Framework has dependencies on  Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> Plugin extensions to Eclipse. It embeds 4 other open source components:
> Rhino, JSLint, Rico and Zimbra.  No code modifications will be made to the
> 4 open source components specified. They are incorporated to accommodate
> Eclipse plugin architecture and distributed as-is by repackaging them as
> part of the AJAX Toolkit Framework.
>
> The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> framework, provides a rich client library, similar in style to traditional
> object-oriented widget libraries like Eclipse's SWT.  This toolkit hides
> implementation details and browser quirks and makes web development more
> accessible to the enterprise developer.  It provides
>
>  * User interface development
>  * Network communications (both sy

Re: [VOTE] @domain for Incubator mailing lists

[Cliff Schmidt]

On 12/17/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Please vote on the following:
>
>   New mailing lists should be created under the
>   @incubator.apache.org domain, just as all of
>   the other project resources, e.g., the web
>   site and SVN subtree.

-0, and here's why:

- I think identification of the incubating status of projects is very
important, but I personally prefer Dain's suggestion of adding a
footer message to mailing list posts (maybe with a shorter version of
the disclaimer required in READMEs), which might be more effective
than the mailing list address.

- I think that the domain name should reflect the sponsoring project,
whether that is the Incubator PMC or some other PMC.

- I would have been -1, if it wasn't for the fact that Noel says that
it is a minimal infra cost to move mailing lists now.

Cliff

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

Re: New project

[Cliff Schmidt]

This list is one place to submit proposals, but see the Incubator
Process document for more details:
see 
http://incubator.apache.org/incubation/Process_Description.html#Establishment.

Cliff

On 11/11/05, Federico Paparoni <[EMAIL PROTECTED]> wrote:
> Hi i would like to suggest a new project for the Apache Incubator. Where i 
> have to submit it?
> Best regards
>
> Federico Paparoni
>

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

Re: [VOTE] Proposal for Tobago, an Apache MyFaces subproject

[Cliff Schmidt]

On 9/5/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 9/6/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Well, I didn't argument against using the incubator infrastructure.
> >
> > Nobody seemed too interested here, though (in contradiction to the
> > MyFaces community, who was very interested), that's why Ted probably
> > thought about going through the MyFaces sandbox directly as a code
> > grant is already in place and the licensing issue is very clear.
> >
> > No problem at all for going through a separate incubator SVN - Ted ?
> >
> > and thanks for at least some feedback to this proposal ;)
> 
> Perhaps the best thing to do would be to vet just the code through the
> incubator. Once the IP is cleared, we can move it to the MyFaces area,
> and deal with things like new committers as MyFaces project issues.
> I'm not comfortable asking root for new accounts or other resources
> under the auspices of the Incubator PMC when we don't have a quorum of
> three binding +1s here.

I've read the proposal and looked at the current project site.  As a
member of the Incubator PMC, I'd vote +1 if a vote was needed. 
However, since it sounds like the MyFaces PMC has already voted to
accept the  project; so I would suggest that you treat this project
like any new incubator project and get accounts set up for each new
committer (after CLAs are received).

As far as whether just the code goes through incubation or whether the
whole community goes through incubation, I think that's a call made by
the MyFaces PMC.  If the PMC believes that most of the key committers
are new to Apache, then they should have the entire project incubated
(still not requiring a vote of the Incubator PMC until graduation,
under the current rules).  If the MyFaces PMC believes that their own
community (current set of committers and contributors) can already
support the code, then they should just incubate the code and add any
outside committers through their normal meritocratic process.

Cliff

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

Re: a few steps before approving a project

[Cliff Schmidt]

Thanks, Dims -- I really appreciate the response!  

Comments and responses to your questions below.

Cliff

On 9/1/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Please see below:
> 
> On 8/31/05, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> > - change the Incubator PMC charter (not that we have a official
> > charter) to include approving of all new projects, so that once a
> > sponsor PMC (if not the Incubator PMC) approves a new project, the
> > Incubator PMC still has to give a final approval.
> 
> +1. It does not have to be a formal VOTE on the pmc mailing list. It
> could be a note from PMC chair to general@ after a week or so. If
> something crops up in that time frame, PMC Chair can ask for a VOTE.
> 
> > - ensure all proposals use the same standard template -- we've
> > recently gotten proposals that simply copied some other proposal they
> > saw -- we're not really making sure that any one set of standard
> > questions is answered.
> 
> +1 Absolutely (We do this already, but its because we are lazy :)
> 
> > - add a question to the template asking whether the person(s)
> > proposing are aware of similar open source projects inside or outside
> > the ASF.  I'm not suggesting that a project wouldn't get approved if
> > there is some similar high profile open source project, but at least
> > we are explicitly asking the question and getting the information.
> 
> +0 Folks involved know better than to waste everyones time duplicating
> work. But If this list makes you sleep better, sure. But i don't
> really think it will help much.
> 
> > - consider having a formal liaison at a few key external open source
> > communities to give a friendly notice to whenever the Incubator PMC
> > knows there's a proposal that could be controversial.   This really
> > only works if we add the new proposal question mentioned above and
> > create a more centralized process of looping the Incubator PMC in
> > *before* a project is approved.
> 
> -0 (leaning toward -0.25/-0.5) for formal liaison. Don't want
> pre-existing preudjices to judge the proposal.
> AND
> Incubator our sandbox. -0 to have a pre-sandbox-sandbox. Let's do
> whatever is needed in public. What are u worried about here? press? I
> thought we are here to share our work and make the world a better
> place. Not focused on poll numbers or what the press says.

I was thinking this liaison notice would happen after the sponsor PMC
has voted to take on the project, but before the Incubator PMC gives
its final approval.  I imagine there could be the occasional case
where the Incubator PMC finds out something that would cause the
consensus to believe that accepting the proposal would not be in the
ASF's best interest.  However, in most cases, this liaison would just
be a chance to politely negotiate any potential PR issues before
officially accepting the project for incubation (when press releases
may or may not occur and when reporters start interviewing people).

> > - require that the Incubator PMC loops in the PRC on any project that
> > could have any chance of media attention (either because of the
> > overall significance of the project, the potential for controversy,
> > expected vendor press releases, or the opportunity to release a joint
> > statement with some other organization).
> 
> +1 Question is when do u want this to happen BEFORE the proposal hits
> the [EMAIL PROTECTED] or after that? Again, don't want a
> pre-sandbox-sandbox.

I've always been in favor of public proposals (and have ensured that
was the case in each of the three ASF project proposals I've been
involved in).  So, I definitely am not saying that the PRC must be
looped in before anyone proposes or discusses a proposal on a public
list!  However, I think there's value in getting the PRC looped in
before officially *accepting* the project for incubation.  I haven't
ever noticed a lot of press as a direct result of incubator
discussions, and I think there's a big difference between the press
that can be made about the discussion of a proposal and what can be
made of an Apache decision to start an incubating project.

> > I really don't want to add more process than necessary, but as the
> > ASFs importance continues to grow, I think there a few issues that
> > should be addressed with each new project, and I'm hoping steps like
> > these could help that to happen.  Of course, an incubating project
> > isn't an officially endorsed ASF project, but we still call it "Apache
> > foo" and it's certainly perceived by the outside as being an action by
> > the ASF when it is accepted for incubation.
> 

Re: a few steps before approving a project

[Cliff Schmidt]

Dims,

With all due respect for your frustration and its expression (I'm
actually not being sarcastic), could you also respond to the subject
of this thread and possibly the thoughts that started it?  I was
really hoping this could remain a discussion of the pros and cons of
things along those lines.

I realize that the thread changed track long before this post, but I'm
arbitrarily picking right now to request that any flames against or in
defense of some past proposal be posted under a different subject
line.

I just would like to hear more thoughts from people about whether
there are things we could do to improve our process of approving new
proposals as the ASF continues to grow.

Cliff


On 9/1/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> My 2 cents, Hani style :)
> 
> 



> 

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

Recent Incubator proposals ( was Re: a few steps before approving a project)

[Cliff Schmidt]

(renaming the subject to try to keep the past flames and future
discussions somewhat separate)

On 9/1/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> There was ONLY one press release...that was vetted by the [EMAIL PROTECTED] 
> Please
> complain to the folks there.

Actually, there were at least two that I know of:

IONA: http://www.iona.com/pressroom/2005/20050822b.htm
Sonic: 
http://www.sonicsoftware.com/news_events/pressitem/pressrelease_648412/index.ssp?

I was the PRC member who gave feedback to IONA, which they
incorporated.  Any complaints about that one should be directed at me.
 Giving it another look now, I think I should have  suggested that one
of the sentences be reworded to not indicate that IONA is joining the
project, but that IONA is sponsoring employees who are joining the
project.

Cliff

 
> There was one document (unsolicited) from Gartner. I've already
> personally sent a response with help from Justin and others (Thanks
> justin).
> 
> So there is nothing left for to do for me other than keep hearing
> choice words, so i'll just stop and listen. Pile it on :(
> 
> If there is something else i did not do, that i have control on, let me know.
> 
> -- dims
> 
> On 9/1/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> > I don't see what this has to do with Synapse, but whatever ...
> >
> > > IF we even seem to appear to sneak something by AM sure we will get an
> > > earful BUT in this case we courted IONA and got their support and
> > > showed that we can build diversity that spans OW and Apache. For this
> > > what do we get, brick bats again.
> >
> > No, actually, nobody has complained about IONA.  People are complaining
> > that the mentors are doing a crappy job of controlling the other
> > commercial organizations who seek to spin Synapse into something that
> > makes other companies look good.
> >
> > > Look we have no code, some code from Infravio is using Axis 1.X and
> > > the porposal makes it clear that it is only for "consultation" and not
> > > a seeding codebase. So we are practically starting from scratch. No
> > > one even understands that.
> >
> > Then you shouldn't have any seed code and you should just create
> > a directory and start working.  You created this mess yourselves
> > by turning it into a Web Services marketing event.
> >
> > > Am getting demoralized now because of all this brouhaha over nothing.
> > > Guess, we don't really mean to be open. Suddenly even building
> > > businesses around Open Source seems to be a bad idea given the
> > > reactions for just one DAMN PROPOSAL. I guess given all the acrimony
> > > we should stop introducing any projects in Apache. Let's just rot and
> > > die.
> >
> > Look, I am going to explain this as roughly as possible.  Apache
> > exists now, today, because people like ME and Randy and Jim and
> > Brian (and now Greg and Justin and Sam and ...) have forcibly
> > prevented various companies from abusing their participation in
> > OUR projects through factually incorrect press releases. It is
> > YOUR responsibility to do that with projects that YOU agree to
> > mentor, even if it means publicly humiliating the idiots in PR
> > when they make mistakes.
> >
> > This will be a far harder task in the Web Services area (filled
> > with companies who exist solely on the basis of press releases and
> > nothing else) than it was for the original Web projects.  You are
> > swimming in a sewer of bad companies trying to do good.  It should
> > not be surprising that we need to hose the project down before it
> > can join Apache.  We need to do that to protect both Apache and
> > the new project.  It only takes ONE bad project to undue all of
> > the gains we have made within the ASF.  It is the fact that we
> > take such care with new projects that differentiates Apache from
> > other sites that merely host code.
> >
> > Roy
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
> 
> -
> 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: a few steps before approving a project

[Cliff Schmidt]

On 9/1/05, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
> --On September 1, 2005 10:50:20 AM -0700 Cliff Schmidt
> <[EMAIL PROTECTED]> wrote:
> 
> > If the answer to one or more of the questions was not simply "yes",
> > then there might be another step or two, such as requiring you or your
> > employer to sign and submit a "software grant".  Some folks might say
> > you always have to sign and submit a software grant for all large
> > contributions, but with my Legal Affairs hat on, I'm not aware of why
> > that would be necessary if the answer to all questions above is "yes".
> 
> For code developed on our public mailing lists, then I don't think a
> software grant is warranted; but for works developed wholly outside of the
> ASF, I think it is prudent to have the grant on file.  -- justin

Sure - it certainly doesn't hurt, and I don't care enough to debate
this point when there are so many other fun things to debate these
days.  ;-)  I'll wait to discuss this when (if ever) I hear complaints
that the software grant becomes an burden for committers who aren't
sure when a large patch that includes some old functions they wrote
years ago turns into something requiring a software grant.

Cliff

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

Re: a few steps before approving a project

[Cliff Schmidt]

Remember that putting "code" through incubation (as opposed to a
"community") can be a really fast process -- as fast as someone can
give a solid account to the Incubator PMC of the audit trail of the
code.

But, yes -- it sounds like such a thing probably should have been
brought through the Incubator.  In this case, speaking as a member of
the Incubator PMC and as the Legal Affairs guy, I would ask the
following questions:

1. Are you the author of all the code?  Are you sure none of the code
is a derivative work of some other IP not owned by you?
2. Are you sure your employer (if any) doesn't have a claim on the IP
rights associated with the code?
3. Do you already have a signed individual CLA on file with the ASF?

If the answers to all questions is "yes", I would vote that the code
should immediately "graduate" from incubation.  If that was the
consensus of the rest of the PMC, it would be that quick.

If the answer to one or more of the questions was not simply "yes",
then there might be another step or two, such as requiring you or your
employer to sign and submit a "software grant".  Some folks might say
you always have to sign and submit a software grant for all large
contributions, but with my Legal Affairs hat on, I'm not aware of why
that would be necessary if the answer to all questions above is "yes".

Cliff
 

On 9/1/05, James Carman <[EMAIL PROTECTED]> wrote:
> So, does that mean that Jakarta Commons Proxy will have to go through the
> Incubator?  Right now, it's a commons sandbox project, so it's not
> officially supported.  The code first lived in my "syringe" project I
> created over at java.net.  It was all developed by me under the Apache
> License 2.0.  Will Commons Proxy have to go through the Incubator to get
> into commons proper?  Or, should it be in the incubator now?
> 
> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 01, 2005 9:08 AM
> To: general@incubator.apache.org
> Subject: Re: a few steps before approving a project
> 
> Sanjiva Weerawarana wrote:
> > On Wed, 2005-08-31 at 11:43 -0700, Justin Erenkrantz wrote:
> >
> >>The Incubator's charter from the board says:
> >>
> >>
> >>RESOLVED, that the Apache Incubator PMC be and hereby is
> >>responsible for the acceptance and oversight of new products
> >>submitted or proposed to become part of the Foundation; and be
> >>it further
> >>
> >>Previously, the board had to deal with this directly.  The board delegated
> 
> >>this to the Incubator PMC.
> >
> > Whoa. I had understood this as "incoming external projects" instead of
> > any in-bred ones.
> >
> > So by your (and Jim's) interpretation, we did Axis2 wrong?? We started
> > that with people who were Axis committers and started with no external
> > code contrib from anyone. We didn't go thru the incubator - just created
> > an SVN tree and started hacking.
> >
> > Are you guys saying that that was wrong and that the incubator had to
> > get involved to teach us the Apache way? Huh?
> >
> > Can we get board clarification on this please? Reading the above
> > resolution that is by no means clear, at least to me.
> 
> If the SVN tree was always on ASF infrastructure, the code was always
> under the Apache License, and the committers were all ASF committers,
> then no trip through the incubator is necessary.
> 
> If any ONE of these things are not true (example: code on CodeHaus
> created by ASF committers with Apache license), then incubator needs to
> be involved to ensure that there is a proper audit trail.
> 
> - Sam Ruby
> 
> -
> 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] Proposal for Tobago, an Apache MyFaces subproject

[Cliff Schmidt]

Yes, but don't take my personal thoughts/proposals to be policy. 
Matthias is right that the current policy does not require an
Incubator PMC vote.

Cliff 

On 8/31/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Well,
> 
> as Cliff has just pointed out, that should not be enough, at least in
> the future.
> 
> regards,
> 
> Martin
> 
> On 8/31/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Thanks Ted,
> >
> > well just a note, the MyFaces PMC has already voted for Tobago.
> >
> > -Matthias
> >
> > On Wed, 2005-08-31 at 09:51 -0400, Ted Husted wrote:
> > > I would like to call for a vote of the Incubator PMC on the MyFaces 
> > > proposal
> > > to incubate the Tobago codebase, and if successful, to create a Tobago
> > > subproject within the MyFaces project.
> > >
> > > The proposal was first circulated to general@ in message #5937, and is
> > > currently represented on the Incubator wiki
> > >
> > > * http://wiki.apache.org/incubator/TobagoProposal
> > >
> > > as last edited 2005-08-31 13:04:20 by ArvidHuelsebus.
> > >
> > > Here's my +1.
> > >
> > > -Ted.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> --
> 
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
> 
> -
> 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: a few steps before approving a project

[Cliff Schmidt]

On 8/31/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 11:43 -0700, Justin Erenkrantz wrote:
> > The Incubator's charter from the board says:
> > 
> >
> > RESOLVED, that the Apache Incubator PMC be and hereby is
> > responsible for the acceptance and oversight of new products
> > submitted or proposed to become part of the Foundation; and be
> > it further
> >
> > Previously, the board had to deal with this directly.  The board delegated
> > this to the Incubator PMC.
> 
> Whoa. I had understood this as "incoming external projects" instead of
> any in-bred ones.
> 
> So by your (and Jim's) interpretation, we did Axis2 wrong?? We started
> that with people who were Axis committers and started with no external
> code contrib from anyone. We didn't go thru the incubator - just created
> an SVN tree and started hacking.
> 
> Are you guys saying that that was wrong and that the incubator had to
> get involved to teach us the Apache way? Huh?
> 
> Can we get board clarification on this please? Reading the above
> resolution that is by no means clear, at least to me.

I can tell you how I've always advocated where the line is, and I
always *thought* most folks agreed with this, but I could be wrong:

The Incubator is responsible for incubating code for legal issues and
committers for community issues.  Any large base of incoming code
(such as would require a software grant) should be "incubated" to the
extent that the Incubator PMC is satisfied that there are no obvious
licensing issues -- if this is the only issue it can be a very quick
process.  Any brand new community should also be "incubated"; in other
words, if a new subproject gets started at a PMC and that subproject
is primarily composed of new committers with a new or non-existent
community, then the project should live under the supervision of the
Incubator PMC prior to graduating.

So, it sounds like this wouldn't have applied to Axis2.  

Cliff

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

Re: a few steps before approving a project

[Cliff Schmidt]

On 8/31/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 11:01 -0700, Cliff Schmidt wrote:
> > BTW, the XMLBeans PMC just voted to add a single member to the PMC,
> > and even that required a 72-hour wait after getting Board
> > acknowledgement (which is fine with me)why should there be
> > fewer checks to get an entire project approved?
> 
> You're missing a key point: Incubation is supposed to be the *starting
> point* for getting a project into the ASF. Graduation is the process for
> getting it approved, not starting incubation. Are you seriously
> suggesting that we change that?? If not IMO the checks need to be *while
> incubating* and not prior to incubation, but YMMV.

My point is that the approval of a project for incubation has been
proven many times to have PR impact and other ramifications (whether
the ASF drafts or approves a press release or not).  And if there are
any concerns about a project that can be known before accepting it for
incubation, I think the concerns should be considered at that time,
not after what is typically a 6-12 month graduation   period.  I
continue to stand behind out incubator branding guidelines, but I also
think we have to recognize that simply accepting a project for
incubation is perceived as a statement by the ASF.

This is why I think we need to add more consideration to the
acceptance of projects for incubation.

Cliff

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

a few steps before approving a project

[Cliff Schmidt]

I'd like to suggest a few changes to the process of approving new
project proposals.  The purpose of these changes would be to allow the
ASF to consider big picture issues related to the acceptance of new
projects into the Incubator, which isn't as likely to happen with our
current set of rules where any of our 30+ PMCs can approve a new
project for incubation and where the Incubator PMC itself has a pretty
informal process for evaluating new proposals.

Here are some of the ideas I have in mind (note that some are
dependent on the implementation of others):

- change the Incubator PMC charter (not that we have a official
charter) to include approving of all new projects, so that once a
sponsor PMC (if not the Incubator PMC) approves a new project, the
Incubator PMC still has to give a final approval.

- ensure all proposals use the same standard template -- we've
recently gotten proposals that simply copied some other proposal they
saw -- we're not really making sure that any one set of standard
questions is answered.

- add a question to the template asking whether the person(s)
proposing are aware of similar open source projects inside or outside
the ASF.  I'm not suggesting that a project wouldn't get approved if
there is some similar high profile open source project, but at least
we are explicitly asking the question and getting the information.

- consider having a formal liaison at a few key external open source
communities to give a friendly notice to whenever the Incubator PMC
knows there's a proposal that could be controversial.   This really
only works if we add the new proposal question mentioned above and
create a more centralized process of looping the Incubator PMC in
*before* a project is approved.

- require that the Incubator PMC loops in the PRC on any project that
could have any chance of media attention (either because of the
overall significance of the project, the potential for controversy,
expected vendor press releases, or the opportunity to release a joint
statement with some other organization).

I really don't want to add more process than necessary, but as the
ASFs importance continues to grow, I think there a few issues that
should be addressed with each new project, and I'm hoping steps like
these could help that to happen.  Of course, an incubating project
isn't an officially endorsed ASF project, but we still call it "Apache
foo" and it's certainly perceived by the outside as being an action by
the ASF when it is accepted for incubation.

BTW, the XMLBeans PMC just voted to add a single member to the PMC,
and even that required a 72-hour wait after getting Board
acknowledgement (which is fine with me)why should there be
fewer checks to get an entire project approved?

Cliff

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

Re: Incubating Project Releases (was Re: JDO2 Snapshots)

[Cliff Schmidt]

On 8/16/05, Leo Simons <[EMAIL PROTECTED]> wrote:
> Cliff Schmidt wrote:
> > On 8/10/05, Leo Simons <[EMAIL PROTECTED]> wrote:
> >
> >>Cliff Schmidt wrote:
> >>
> >>>On 8/8/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>>I don't mind an incubating project making verifiable releases with
> >>>>proper voting and the appropriate disclaimers.
> >>>
> >>>I completely agree, and I believe this is exactly what projects want to do.
> >>>
> >>>Are there any PMC members who disagree with Roy's opinion?
> >>
> >>Certainly not me.
> >>
> > I just really want to make sure I'm not misinterpreting Roy's
> > statement.  Why would there be any debate at all about what JDO wanted
> > to do if the statement above was the consensus of the PMC?
> 
> Because they wanted to do something else, namely publish a snapshot to a
> maven repository, a thing which exists primarily so build tools can do
> automated downloads of its contents without bothering the user of said
> build tool much about it, hence lacks "appropriate disclaimers".
> 
> Furthermore, its becoming common practice around the open source java
> land to call things a "snapshot" to wiggle out of doing "proper voting"
> or building "verifiable releases".
> 
> So they failed at least one and potentially all of the requirements.

ahh -- I thought they were only talking about doing snapshot releases
because they believed it was their only choice while in incubation;
this is why I wanted it clear that a proper release could be done by
an incubating project that follows the branding guidelines.

Cliff

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

Re: Incubating Project Releases (was Re: JDO2 Snapshots)

[Cliff Schmidt]

On 8/10/05, Leo Simons <[EMAIL PROTECTED]> wrote:
> Cliff Schmidt wrote:
> > On 8/8/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> >
> >>I don't mind an incubating project making verifiable releases with
> >>proper voting and the appropriate disclaimers.
> >
> > I completely agree, and I believe this is exactly what projects want to do.
> >
> > Are there any PMC members who disagree with Roy's opinion?
> 
> Certainly not me.
> 
> - LSD

Okay -- that makes three of us.  

I just really want to make sure I'm not misinterpreting Roy's
statement.  Why would there be any debate at all about what JDO wanted
to do if the statement above was the consensus of the PMC?

The answer could be as simple as: "snapshots are meant for the
development team and not to be pushed on users.  You maybe shouldn't
even link to them from the web site.  However, if what you want is to
encourage your user community to use and give you feedback about what
you have so far, just do a release.  It could be a v0.5 or a 1.0 or a
1.2 -- whatever is appropriate to the state of your code.  Any
incubating project you can do this if you go to the effort to make a
verifiable release with proper voting and the appropriate disclaimers.
 BTW, one more thing -- are you sure you're not ready to graduate from
the incubator yet?  We'd really like to see that be your focus.  After
that point you won't have to worry about using the disclaimer text and
the '*incubating*' filename."

Cliff

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

Incubating Project Releases (was Re: JDO2 Snapshots)

[Cliff Schmidt]

On 8/8/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> I don't mind an incubating project making verifiable releases with
> proper voting and the appropriate disclaimers.

I completely agree, and I believe this is exactly what projects want to do.

Are there any PMC members who disagree with Roy's opinion? 

Cliff

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

Re: JDO2 Snapshots

[Cliff Schmidt]

On 8/7/05, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> On 8/7/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> 
> > Please note that although we have attempted to establish a balanced policy,
> > it is not our goal to have widespread adoption of projects that are still in
> > the Incubator.  We want projects to be making a focused effort to get out of
> > the Incubator.
> 
> To me, that's a contradiction. "Widespread adoption" will help
> building a community. Which is clearly a primary goal of most projects
> in incubation.

I agree with Jochen on this.  I hesitate to bring this subject up yet
again, but since it has been one of my pet concerns in the past:

There have been times when the Incubator PMC has defined the bar for
graduation to include (in addition to the legal check, the logistics,
and the general Apache-style community) strong user adoption and a
very diverse set of committers.  The "diverse set of committers" has
sometimes been defined as not only the three independent committers,
but also the requirement that no single committer (or single employer
of many committers) is critical to the project.  Obviously it is much
easier to get to this state if the project isn't being limited in what
it can release.  In addition, this requirement for graduation could
take quite a while for some large project, during which time they
might want to actually do an official v 1.0 or 2.0 release.

I have proposed in the past (and gotten consensus) that incubating
projects can do full official releases, as long as they follow the
incubating brand guidelines, which include labeling the download
filenames with the word "incubating" and inserting the disclaimer
statement in the README.  However, many on the PMC would rather not
see formal releases while in incubation; instead, they would rather
see the project graduate sooner without the hard-line requirement for
a strong/diverse user/dev community.

So, here's what it appears we are telling new projects (roughly
sequential phases):
1. ensure there are no legal issues as soon as you enter incubation

2. figure out the logistics of mailing lists, bug tracking, source
repositories, etc at the same time

3. release only snapshot-style distributions as needed, as long as
they follow the incubator branding guidelines.  No official releases
are allowed.  Nothing that resembles a normal Apache product release.

4. bring on enough committers to ensure there are at least three
working for independent interests (the releases described in 3. should
be enough to get this point done)

5. ensure you've built a healthy user and developer community. 
Healthy user community = some user interest manifesting itself on a
mailing list.  Healthy developer community = evidence of following a
consensus-based, meritocratic development style and responding to the
user community, but no requirement that one committer (or many
committers working for one employer) can't be doing 95% of the
commits.

6. after making sure any remaining issues on the incubation checklist
are complete, request graduation.

Note that 1-6 must happen before the project's user/dev community
feels it's time to put out an official release.  IMO, if the Incubator
PMC intends for step 5 to be defined in stronger terms, we need to be
a little more flexible with projects that want to do releases.

Cliff

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

Re: [RESULT] [VOTE] Graduate Derby as sub-project of Apache DB

[Cliff Schmidt]

On 7/25/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
> Daniel John Debrunner wrote:
> 
> > So please vote on graduating Derby to a sub-project of Apache DB.
> 
> Passed with eleven (11) +1 votes (including one ++1 vote :-)
> 
> Three (3) members of the Incubator PMC voted +1 (Noel, Geir, Roy)

I realize I missed the voting period (sorry!), but I just wanted to
offer a post-vote +1 from another Incubator PMC member.  I've always
been impressed with the way the project has been run, and I'm now also
impressed with how the initial committers have managed to bring on a
few more on such a significant existing code base.

Cliff

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

Re: [VOTE] Graduate Beehive into a TLP

[Cliff Schmidt]

On 7/18/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Noel,
> Cliff is driving the pmc selection/vp recommendation process.
> 
> Cliff,
> Could you please respond?

Sure -- I'll follow up my earlier thread on the beehive ppmc list re:
board resolution and VP candidate.

Cliff

> 
> thanks,
> dims
> 
> On 7/18/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > Dims,
> >
> > It appears that there are sufficient votes and no objections.  Please
> > prepare a request to be submitted to the Board meeting, which will be next
> > week.
> >
> > --- Noel
> >
> >
> 
> 
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>

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

Re: [VOTE] Graduate Beehive into a TLP

[Cliff Schmidt]

On Jul 14, 2005, at 4:49 PM, Simon Kitching wrote:


Yes the current discussion on legal-discuss is wrt wss4j, but the
question for beehive was more general: are there any patents that have
been explicitly granted for the use of Beehive?


This is not how the question should be asked.  The question is "Is  
anyone aware (most particularly the Beehive PPMC / Incubator PMC) of  
some patent holder claiming that Beehive may infringe on their  
patent?".  As far as I know, the answer is "definitely not".  We  
don't go out looking to see what patents some part of our projects  
could potentially be violating.



For example, have BEA
issued any "licenses" to Apache with respect to stuff that Beehive
implements?


BEA signed a corporate CLA (in addition to the individual CLAs signed  
by the BEA employees working on the project).  In that CLA, the  
contributor agrees to:


 "grant to the Foundation and to
   recipients of software distributed by the Foundation a perpetual,
   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
   (except as stated in this section) patent license to make, have
   made, use, offer to sell, sell, import, and otherwise transfer the
   Work, where such license applies only to those patent claims
   licensable by You that are necessarily infringed by Your
   Contribution(s) alone or by combination of Your Contribution(s)
   with the Work to which such Contribution(s) was submitted."

So, we aren't currently worried about any contributor owning patents  
that their contributions might infringe upon.  We're covered there.   
The issue with the wsss4j stuff was that the specification authors  
made it very clear that they held essential patents to the  
implementation of the specification...and some of these parties were  
not the authors of the contributed code to Apache (and did not sign a  
CLA or software grant to cover it).


Cliff


Regards,

Simon

On Thu, 2005-07-14 at 16:32 -0700, Kenneth Tam wrote:


Beehive doesn't currently have any implementations of the WS-*
standards, including WS-Security -- the intent was to at some point
look to other Apache projects that were implementing those standards
(I don't subscribe to legal-discuss, but I presume the discussion in
question is wrt WSS4J?).

On 7/14/05, Simon Kitching <[EMAIL PROTECTED]> wrote:





On 7/12/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:


Dear Incubator PMC,

I believe Beehive is ready to function as a standalone PMC. Please


see


the latest status at:
http://incubator.apache.org/projects/beehive.html



Could someone please provide information on any patents known to  
apply

to this project?

There has been discussion on legal-discuss@apache.org regarding the
situation for WS-Security where IBM has granted patent license  
for the
Apache project but not to anyone who modifies the code (modifiers  
of the

code must apply for a patent license separately).


The "legal issues" section of the beehive status page does not  
address
patent issues. It would be good to confirm that this situation  
does not

apply to Beehive.

Sorry if this has already been discussed...

Thanks,

Simon


 
-

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] Graduate Beehive into a TLP

[Cliff Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/12/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Dear Incubator PMC,
>
> I believe Beehive is ready to function as a standalone PMC. Please  
see

> the latest status at:
> http://incubator.apache.org/projects/beehive.html

+1

- - The Beehive committers have clearly demonstrated their willingness  
and ability to develop and respond to their community.


- - They've built good relationships with committers on other projects,  
including Axis, Geronimo, and Struts.


- - They are clealy dedicated to working within the open, meritocratic,  
and consensus-based Apache development process.


- - Beyond community and code, they've also shown a sensitivity and  
willingness to properly handle legal and PR aspects of Apache, which  
is especially important for a TLP.


Overall, it is clear to me that the Beehive project is not only on a  
successful path for their own community, but that they are interested  
in making the rest of Apache successful as well.


Cliff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC1tXdy6dGskFZ6tsRAk+ZAJ0X/NdJ1kJcrpHJu8L5dqpFz1ehYgCeJ6KI
i25KHZFsQfm7inZRtKynVkU=
=TtXc
-END PGP SIGNATURE-

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

XMLBeans PMC has voted to sponsor xmlbeanscxx

[Cliff Schmidt]

t product goals moving
> forward around XML for which the XMLBeans model fits perfectly.  
Rather than

> simply copy the design and keep the project closed, we felt that the
> downstream products would reap significant benefits from opening  
the XML

> layer to the community. Keeping the C++ version in sync with the Java
> version, even if it were to not be accepted as an Apache project,  
can only

> help its overall adoption.
>
> Additionally, a diverse committer base is a strong goal for this  
project.
> Numerous users of the contributed XML to C++ binding tool have  
indicated
> interest in participating, many of whom have critical projects  
dependant on
> this work and resources available to continue to ensure the  
viability of the

> project well into the future.
>
> Inexperience with Open Source: Like many companies entering this  
arena, we
> have limited experience working on open source projects. Our  
primary goal is
> to foster an active community around XMLBeans/C++ so advice will  
be taken to
> heart, and significant resources will be dedicated to the project  
to get it

> off the ground. However, we hope that our experience working in open
> standards groups will aid in the transition to the open source  
community.

>
> Initial Reliance on Salaried Workers: Due to the rapid process of
> transitioning to work on the open source XMLBeans/C++ project,  
only a few of
> the listed contributors will be outside the commercial realm. We  
expect this
> list of external volunteers to grow significantly after the  
initial public

> code drop.
>
> Licensing, Patents, Miscellaneous Legal: We are conducting a legal  
review of
> the code and existing contracts. This review should be done  
shortly and any

> code contributed will be licensed under the latest ASF terms.
>
> Commercial Interest: XMLBeans/C++ will be maintained as an open  
source
> Apache project, with all relevant enhancements contributed to the  
community.
> Additionally, there is every intention to use XMLBeans/C++ within  
future
> commercial products, thereby resulting in even greater testing and  
user
> exposure. It is expected that other companies may well wish to use  
the
> project's code within their own commercial endeavors, which of  
course would

> be fine.
>
> (1) scope of the subproject
>
> The XMLBeans/C++ subproject will conform to the identical scope as  
that laid
> out for the partner Java project. Special care will be taken to  
implement
> features and add conveniences that would be expected by a C++  
developer.

>
> For clarity, the goals of the XMLBeans/C++ project are:
>
> Generation of plain C++ classes to model XML Schema Validation of C++
> objects against the source XML Schema Access to partial document  
instance
> data (fragments) Efficient "parse as necessary" access that  
forgives extra

> data Access to the full XML infoset
>
>
>
> (2) identify the initial source for subproject code
>
> Some background information may be found on the LEIF product and the
> associated Data Tier.
>
> LEIF product page (http://www.roguewave.com/products/leif)
>
> The C++/XML binding contribution code can be found at the  
following link:

>
> xmlBeans open source information
> (http://www.roguewave.com/opensource/XMLbeans.cfm)
>
> (3) identify the ASF resources to be created
>
> (3.1) mailing list(s)
>
> xmlbeanscxx-dev
> xmlbeanscxx-user
> xmlbeanscxx-commits
>
> (3.2) SVN repositories
>
> xml-xmlbeanscxx
>
> (3.3) Bugzilla
>
> xml xmlbeanscxx
>
> (4.0) identify the initial set of committers
>
> This is a preliminary list that will be updated with volunteer  
members.

>
> Tim Triemstra (TimT @ RogueWave dot-com)
> John Hinke (Hinke @ RogueWave dot-com)
> Heidi Buelow (Buelow @ RogueWave dot-com)
> Allen Brookes (ABrookes @ RogueWave dot-com)
> David Haney (David.Haney @ RogueWave dot-com)
> Michael Yoder (Michael.Yoder @ RogueWave dot-com)
>
> (5) identify apache sponsoring individual
>
> Cliff Schmidt, of the XMLBeans/Java project, has volunteered to  
sponsor this

> project.
>
> Cliff Schmidt (CliffS @ Apache dot-org)
>
> (6) open issues for discussion
>
> The original code contribution has a lot of proven code for  
creating a
> binding between XML Schema and C++ classes. However, the  
contribution will
> require a significant overhaul, and even complete re-writes in  
some areas,
> in order to reach compatibility with the XMLBeans/Java version.  
Detailed

> differences will be discussed openly within the community so that an
> appropriate plan for each area can be reached. This proposal is  
not the best
> place to lay out all the technical details, however you will fin

Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue

[Cliff Schmidt]

On 6/11/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Richard Feit wrote:
> > This is just a case where we need all the input we can get.
> 
> We'll see if we can get some additional mentoring for you.  I believe that
> we'll have another volunteer to also spend time helping beehive along.  :-)

I can volunteer to me an additional mentor if you guys would like to use me.

Cliff

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

Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue

[Cliff Schmidt]

On 6/8/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> FWIW, versioning schemes such as:
> 
>  M.mQB
> 
> where M == major, m == minor, Q in [D:Development, A:Alpha, B:Beta,
> R:Release], and B == Build# encode the release type.  I supposed that 1.0m1
> represents a milestone.
> 
> In any event, I'm sure that people can come up with some perfectly sane
> scheme to label.  The only thing is that we don't want it to smell like
> official ASF code until after the project graduates the Incubator.

How about something like:
Apache {projectname} (Incubating) vM.mQB ?

e.g. "Apache Beehive (Incubating) v1.0R555"

We already require the word "incubating" in the filenames, but things
like TheServerSide posts wouldn't normally mention this.  I'm
suggesting that the name of the release always include "(Incubating)"
wherever it is mentioned.

Cliff

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

Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue

[Cliff Schmidt]

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

>> It just doesn't make sense to me to tell a community that believes it has
>> a "1.0" quality product that they have to call it a "test snapshot".
>
> Demo?  Technology preview?  Milestone?  Happy Meal?

All of those terms (or at least the first three ;-) are references to
code quality.  If we are keeping a project in incubation until its
community is of higher quality, why would we legislate terms that have
to do with code?

> Look, maybe this is hard to understand, especially if people are coming from
> an enviroment focused on code quality first, but this isn't about the state
> of the code.  It is about the state of the community.  

As I said in my prior post, I think we all agree on this -- this
shouldn't be hard for anyone to understand.

> We had a lot of long
> discussions regarding allowing any releases at all from the Incubator, and
> it is entirely intentional and deliberate that projects in the Incubator are
> not permitted to make anything that smells like an official release.  

I agree that they should not be permitted to make anything that
resembles an official *ASF-endorsed* released.



> Nor we we want projects to be overly comfortable with a nice long stay.  We
> want projects to be serious about getting out of the Incubator from the time
> that they get into it.  If this were to mean that projects would start to
> put more emphasis on commmunity development than on their code "just" so
> that they can get out of the Incubator and make releases ... EXACTLY!

I'd be surprised if any individual or company was comfortable having
to include the word "incubating" as part of every filename in their
release, nor comfortable having a paragraph in their README stating
that the project is not officially endorsed by the ASF, nor
comfortable being required by our PRC to mention incubation in any
PR-like materials.  I think all these are all good and effective
restrictions.

> Again, our emphasis is on a healthy developer communities that can be relied
> upon to be self-sustaining and follow ASF practices for many years.

You and I completely agree on this.  However, I am trying to separate
code quality labels from branding.  We all agree that incubation is
about building community -- until a project as reached the goals
around community development, we want to distinguish the project by
requiring the incubator branding -- not the full ASF branding.  I just
don't see what that has to do with letting a project indicate to its
users what degree of stability their code base is at or whether they
expect to maintain backward compatibility on their APIs (often
signalled by the "1.0" milestone).

Cliff

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

Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue

[Cliff Schmidt]

On 6/7/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements
> 
> 
> Note: incubator projects are not permitted to issue an official Release.
> Test snapshots (however good the quality) and Release plans are OK.
> 
> 
> Maybe it should be removed? It does tend to contradict the bullet it is
> under. :-)

Good catch, Dan!  I would certainly be in favor of removing this line.  

I know there are different opinions on this within the PMC, but most
would agree that incubation has nothing to do with the technical
quality of the code.  It just doesn't make sense to me to tell a
community that believes it has a "1.0" quality product that they have
to call it a "test snapshot".  Instead we specify several
branding-related requirements to ensure the project doesn't yet claim
to be an officially-endorse ASF project.

Cliff

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

Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue

[Cliff Schmidt]

Here is my opinion on the whole release issue, which has not changed
in 18 months since the first big discussion of releases and incubation
branding.

Full Disclosure:  While this is my opinion as a member of the
Incubator PMC, it is not necessarily the consensus of the PMC.  In
addition, I was once a BEA employee and am still a (recently inactive)
committer on the beehive project; however, I have been consistent in
my views on this issue regardless of what individual/company/project
has raised the issue.

Given (my assumptions):
1. (binary) releases are useful in building interest in a project,
which often leads to a stronger community; also, the process of doing
a release is useful for a project to go through while in incubation.
2. while in incubation (when a project is still trying to reach its
goals for a diverse, collaborative, meritocratic-based community),
Apache does not want a project to claim that it is a fully-endorsed
Apache project
3. incubation status is no reflection on the technical quality or
maturity of the code base

Therefore:
1. releases should be allowed and even encouraged while incubation
(personally, I don't care whether they're called "releases",
"Releases", or "official project release".
2. projects should a) include obvious notices regarding their
incubation status and the status of their releases (e.g. in the README
file, as part of the file name, and on their web site),  b) hold a
vote of their ppmc (which should include interested members of the
Incubator PMC), and c) should ensure their mentor approves of the
release and its process.
3. projects within incubation should not be given some arbitrary
technical boundary, such as preventing them from classifying a release
as "1.0" or "2.0", based on the history and stability of the code
base.

Guess what?  When we (this list) spend literally hundreds of emails
discussing these issues in late 2003, we came up with a lose set of
guidelines that pretty much fit with what is described above.  See
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D.
 Note there is nothing in there that states a release can't be called
"official" or "1.0" or anything like that.  Howeverm, it must meet the
branding guidelines.

I suggest those who disagree with these written guidelines suggest
changes to them to be discussed and voted upon; otherwise, existing
projects today should follow the only documentation we have given
them.

(ready for the inevitable flames to begin, possibly from some folks I
have a lot of respect for...)

Cliff

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

Re: [POLL] Apollo, Hermes, Muse

[Cliff Schmidt]

On 5/25/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> I'm not on the incubator PMC .. but, if I may, do these projects meet
> the min. of 3 "other" committers requirement?

dims,

After a second reading, I  see how Sajiva and I could have different
interpretations of your question.  I assumed you were giving us notice
and checking concerns about doing a incubator beta release.  Sanjiva's
question appears to be about your P.S. comment concerning graduation.

Could you clarify if you are currently asking us about a vote for a
release or for graduation?

Thanks,
Cliff

> On Wed, 2005-05-25 at 12:32 -0400, Davanum Srinivas wrote:
> > Silence means assent? :)
> >
> > On 5/24/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > > Dear incubator PMC members,
> > >
> > > Folks are hard at work on Apollo, Hermes and Muse...they are making a
> > > incubated-beta release tomorrow. There are a few (at least one!) more
> > > committers who will be joining shortly. Only pending issue is the name
> > > changes after a legal review. The new names (and url's) are as
> > > follows:
> > >
> > > Apache Muse - http://incubator.apache.org/muse/
> > > Apache WSRF (was Apollo) - http://incubator.apache.org/apollo/
> > > Apache Message Broker  (was Hermes) - http://incubator.apache.org/hermes/
> > >
> > > Any issues, concerns before i place a formal VOTE?
> > >
> > > Thanks,
> > > dims
> > >
> > > PS: I need to get these out of incubation so that i can concentrate on
> > > TSIK/Harmony :)
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> >
> >
> 
> 
> -
> 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: [POLL] Apollo, Hermes, Muse

[Cliff Schmidt]

Sounds good to me, knowing that you (as the mentor) approve of the
release, and assuming the incubation release branding guidelines are
being followed.

Thanks for the note.  I think some prefer to see votes for releases
done on this list, but I'm personally fine with a note like this and
the actual voting on each dev list (with binding votes coming from the
ppmcs).

Cliff

On 5/25/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Silence means assent? :)
> 
> On 5/24/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > Dear incubator PMC members,
> >
> > Folks are hard at work on Apollo, Hermes and Muse...they are making a
> > incubated-beta release tomorrow. There are a few (at least one!) more
> > committers who will be joining shortly. Only pending issue is the name
> > changes after a legal review. The new names (and url's) are as
> > follows:
> >
> > Apache Muse - http://incubator.apache.org/muse/
> > Apache WSRF (was Apollo) - http://incubator.apache.org/apollo/
> > Apache Message Broker  (was Hermes) - http://incubator.apache.org/hermes/
> >
> > Any issues, concerns before i place a formal VOTE?
> >
> > Thanks,
> > dims
> >
> > PS: I need to get these out of incubation so that i can concentrate on
> > TSIK/Harmony :)
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> -
> 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: STDCXX voting summary

[Cliff Schmidt]

I also didn't vote, but would vote +1.  Maybe I'm too much of a
stickler for process, but I was waiting for a [VOTE] email to
follow-up on the "Proposal" thread.  Although I realize it's not
uncommon for a proposal thread to end up looking a lot like a bunch of
votes.

Cliff

On 5/19/05, Heidi Buelow <[EMAIL PROTECTED]> wrote:
> 
> Hi everyone,
> 
> It looks like the STDCXX incubator project proposal has been accepted.  Here
> is a summary of the votes.
> 
> Positive (5): Justin, Leo, Sander (binding), Brian and Brane (non binding)
> Neutral (1): Jim (binding)
> Negative ()
> 
> I will send mailing list and web page details as soon as they are ready.
> 
> We also have received messages from a few people in the community who want
> to work on the project.  We welcome you all and will soon be ready for
> actual coding.  Watch for the first code drop to start.
> 
> I want to thank our mentors, Justin Erenkrantz and Ben Laurie, for their
> help in getting us this far.
> 
> It's officially incubating.
> 
> Heidi.
> 
> Heidi Buelow
> Rogue Wave, a division of Quovadx
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: Proposal for STDCXX

[Cliff Schmidt]

Heidi,

This looks great.  A few notes/questions inline below.

Cliff

On 5/13/05, Heidi Buelow <[EMAIL PROTECTED]> wrote:
> 
> Proposal for an Apache-run version of the C++ Standard Library



> Rogue Wave Software will jump start this project by contributing the
> commercial C++ Standard Library it has been shipping for over a decade. This
> is a new, enhanced version of the OEM library provided by many vendors,
> including ARM, Sun Microsystems, HP and others. 

I saw the HP licensing note below, which seems fine; but, if the
library was provided by other vendors, can you clarify the state of
any other IP claims on the initial contribution?

> As a side note, Rogue Wave Software intends to continue distributing the
> library as part of its SourcePro/C++ product well into the future. This
> means that significant effort will continue, especially in porting, and that
> effort will directly benefit the open source community since even code
> developed to meet commercial requirements will be contributed back into the
> community.

When you say "the code will be contributed back into the community",
do you mean that Rogue Wave will work on in-house ports and
occasionally drop new versions over the top of what happens to be in
Apache at the time, or that Rogue Wave will be iteratively improving
the code base/ports in collaboration with other committers on the
project?  Of course, I'm hoping you mean the latter; but, please
clarify.  There's nothing wrong with additional future contributions
(in fact, that's goodness); but periodic replacements of a bunch of
existing code would obviously be disruptive to the other committers.

> Initial Reliance on Salaried Workers: At the time of the initial proposal,
> only one external developer has agreed to volunteer as a top-level
> contributor. However, in discussions with members of the Apache community,
> as well as partners and customers, it is clear that there is already
> significant interest. Members of other Apache projects have indicated a
> desire to participate and there is optimism that by the time the project is
> set to begin more contributors from within Apache and the user community
> will be enrolled.

Hopefully, you'll find some more interest from other folks reading
this thread.

> The license grant given by HP should
> conform to the rules of the ASF license, and is included below:
> 
> Copyright (c) 1994 Hewlett-Packard Company
> Permission to use, copy, modify, distribute and sell this software and its
> documentation for any purpose is hereby granted without fee, provided that
> the above copyright notice appear in all copies and that both that copyright
> notice and this permission notice appear in supporting documentation.
> Hewlett-Packard Company makes no representations about the suitability of
> this software for any purpose. It is provided "as is" without express or
> implied warranty.

This should be fine, as long as this notice can be placed in the
NOTICE and/or LICENSE file of any distribution, and not required to be
at the top of every source file.

> The initial tarball made available on the web site will not be immediately
> ready to include in a public CVS/SVN repository. The file set is quite
> large, and has significant complexity, especially to support dozens of
> platforms out of a single code base. The code and directory structure will
> therefore need a thorough review to be sure they are efficiently packaged
> for public, group development. We don't expect this to take long, but wanted
> to set proper expectations.

I certainly understand that it takes time once a project is accepted
to align your company's logistics with the Apache infrastructure, but
can you give us an idea of a) roughly how long are you expecting, and
b) will the eventual contribution be significantly different than what
you have posted now?

> (3.3) Bugzilla

Sure you don't want to use Jira?

> (5) identify apache sponsoring individual
> 
> Justin Erenkrantz (justin @ erenkrantz dot-com)

That says a lot!  (in a good way ;-)

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

Re: Incubator - Sandbox

[Cliff Schmidt]

On 5/13/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> 
> On May 13, 2005, at 3:46 AM, Martin Marinschek wrote:
> > The problem is that many components for JSF are developed outside of
> > Apache, some by small independent developers, some at sourceforge,
> > some in large corporations, and we really don't want to setup a
> > separate incubator subproject for each and every such component that
> > ends up donated to MyFaces - the administrative overhead would just be
> > to high...
> >
> 
> > Any suggestions how we could solve that problem?
> 
> Any code that comes in has to come in under apache license w/ proper
> contribution agreement.
> 
> But after that, you can organize it however you want.  Make a sandbox
> directory in your svn for example?

I agree with Geir, but add that you'd only need an incubator
subproject if the code could not be supported by the current MyFaces
community.  However, if the MyFaces PMC feels that the community
already exists to maintain the new code contribution, then there's no
need for an incubator subproject.

Cliff

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

Re: PROPOSAL : Apache Harmony - J2SE 5 Project

[Cliff Schmidt]

On 5/6/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Dear Incubator PMC :
> 
> We, the sponsoring members listed below, ask that you accept the
> following proposal for a new project at Apache, an effort centered
> around architecting and implementing J2SE 5.

+1

Cliff

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

Re: [VOTE] Graduate Derby from the incubator

[Cliff Schmidt]

On 4/22/05, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> The three independent committers rule is an absolute minimum
> based on the legal fact that US employees are required to be
> loyal to their full-time employer *even* when we know the people
> involved are beyond question, independently minded, and dangerous
> to approach with anything like a "command from the boss."
> The project may be cruising along like a fully-formed Apache
> community, but it doesn't actually become one until the
> decisions are made by the community in fact (by virtue of
> having the vote), not just in appearance.

+1
In addition, I believe that no matter how independently-minded the
employees are, if the employer has a change in corporate priorities
and decides to move those valuable developer resources to another more
important project, I don't think it's safe to assume the
committer-employees will all resign so that they can continue working
on the project full-time.  I can imagine that they would _wish_ to
work as much as possible on the Apache project in their off-hours, but
that may or may not be enough to keep the project from dying (from the
inability to handle the needs of the user community before they
abandon the project in favor of a more responsive set of committers) .

Cliff

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

Re: [VOTE] Graduate Derby from the incubator

[Cliff Schmidt]

On 4/22/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

> Maybe we should look for an additional metric for community health and
> diversity for next time.  It could be in addition to the "rule of 3",
> but I think this example shows where we can improve things to help
> ensure healthy communities.

I've tried to be clear in my earlier posts that the rule of 3
independent committers was just the absolute minimum.  Graduating
without adhering to this rule would certainly be special treatment,
but there are also other factors to consider...and this is where it
becomes a judgement call.  We've actually already written down some of
the factors:
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements.

"The project is not highly dependent on any single contributor
(there's at least 3 legally independent committers..."

but also (the one that I, personally, think is also important)

"...and there is no single company or entity that is vital to the
success of the project)"

It might be hard for some projects to meet this requirement even
within a year or so of incubation; but I think this is where a
judgement call comes into play: does the Incubator PMC feel that it is
not far from getting there and is therefore worth the risk of the
single vital individual/vendor dropping support for the project.

Cliff

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

Re: [VOTE] Graduate Derby from the incubator

[Cliff Schmidt]

On 4/18/05, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> 
> Brian Behlendorf wrote:
> >
> > Wouldn't "how can we increase the number of new developers on Derby while
> > still in incubation" a better question to ask?
> 
> I think only if the answer to 'does Derby need more committers before
> it can graduate' is 'yes.'  Participation is growing nicely, but the Derby
> PPMC is being careful not to hand out commit access like candy.

I definitely don't think the PPMC should lower the standard for commit
access, nor do I think the Incubator PMC should lower the standard for
Incubator graduation.

I'm really surprised we're even talking about graduation before Derby
has met the most basic rule of three independent committers (didn't we
just have a thread on this a few weeks ago about log4net?).  Once that
has been met, I'd expect a discussion about whether the project has
the kind of community that could continue to maintain and evolve the
project even if one individual / company stopped contributing to it.

I know that there are different opinions on the second point, but I
believe the three committer rule is pretty widely agreed upon.

> I guess the basic question would be, 'Does keeping Derby in the incubator
> add any value anywhere?'  At this point I feel moderately strongly that
> it doesn't, but that's just me -- and I can be convinced otherwise. :-)

I'm primarily concerned about the devaluation of the Apache brand by
lowering our standards for what it means to have a strong, diverse
community.

Cliff

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

Re: Prepping for Derby graduation vote

[Cliff Schmidt]

On Tue, 29 Mar 2005 21:44:40 -0500, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Cliff Schmidt wrote:
> > the committer diversity issue has been raised as an issue by
> > at least a couple folks.  While it looks like they meet the
> > requirement to have committers from at least three independent
> > organizations (I believe Noel and Jeremy are the two who are
> > independent from IBM)
> 
> I'm not a Derby Committer.

Oh -- my mistake.  Doesn't Derby have at least three independent
committers?  There's Jeremy and the IBM folks...who's the other one?

Cliff

> > If a single vendor/individual was to drop their contribution
> > for some reason, is there sufficient independent community to
> > continue the project?
> 
> A fair question that needs answering.
> 
> --- Noel

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

Re: Prepping for Derby graduation vote

[Cliff Schmidt]

It sounds like people involved with the project are happy with the
user community and the process being followed by the Derby committers,
and it's great they've added a committer since starting Incubation.

However, the committer diversity issue has been raised as an issue by
at least a couple folks.  While it looks like they meet the
requirement to have committers from at least three independent
organizations (I believe Noel and Jeremy are the two who are
independent from IBM), the other question that has been asked of
projects requesting graduation is:

If a single vendor/individual was to drop their contribution for some
reason, is there sufficient independent community to continue the
project?

Cliff  

On Wed, 16 Mar 2005 08:42:53 -0800, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> As that one committer I am also comfortable discussing this.
> 
> The user community is growing continuously and is very diverse. The
> developer community, while not as diverse as we would like, has
> demonstrated that it is following its charter (found at
> http://incubator.apache.org/derby/ ), is operating independently of the
> main employer, and is following Apache guidelines and method.
> 
> The committers have already committed (sorry) to growing the developer
> base and have discussed approaches that will encourage that. I would be
> willing to commit to the I-PMC and/or DB-PMC that we will continue that
> process after leaving the incubator.
> 
> I would also point out that the number of database-internals wonks with
> the time or even the contractual ability to work on an open source
> database project is limited; for example, anyone with hard-core SQL
> query optimization experience is probably employed by a vendor somewhere.
> 
> To overcome this, we are reexamining the roadmap so that there is less
> focus on database internals and more on integration and management. How
> this plays out will depend on the user community and what they want to
> see implemented, and the diversity there can only help. There are
> several people actively contributing already and I expect to see more as
> time goes on.
> 
> I do not think that the Derby community is ready at this time to become
> a TLP. However, I do believe we should discuss leaving the incubator
> heading for the DB project.
> 
> --
> Jeremy
> 
> 
> Brian McCallister wrote:
> > DB PMC Hat On: I'm quite comfortable discussing this.
> >
> > One committer has been added while in incubation, and there are a couple
> > more people under consideration. The user and developer community has
> > grown, even if the committer distribution is worrisome. Very much worth
> > talking about, though!
> >
> > -Brian
> >
> > On Mar 15, 2005, at 7:09 PM, Rodent of Unusual Size wrote:
> >
> > Considering the recent discussion about diverse communities
> > and such, this may appear ill-timed.  However..
> >
> > I'd like to open the discussion about Derby graduating from the
> > incubator.  The project has accomplished all of its stated
> > goals save for the acquisition of several additional committers.
> > I attest that the project is being operated according to the
> > Apache guidelines and method, and that the community has
> > adopted them and taken them to heart.
> >
> > Since Derby isn't heading for a TLP position (unless someone
> > wants to open that particular ball for some reason), I think
> > they've demonstrated the viability and sustainability.  I
> > would support its graduation IFF the DB project took on, as a
> > specific priority, building the developer base.  (I.e., taking
> > an active role in the project and not just accepting Derby and
> > letting it continue as it has.)
> >
> > Does anyone think this discussion is premature?
> > --
> > #kenP-)}
> >
> > Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> > Author, developer, opinionist  http://Apache-Server.Com/
> >
> > "Millennium hand and shrimp!"
> >>
> -
> 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]