Re: [VOTE] Official Name for "Geronimo" Project

[Brian McCallister]

Hmm, how about:

Apache ctx.lookup("apache/j2ee/name");

It's unpronounceable, but so is httpd ;-)

-Brian

On Monday, December 1, 2003, at 03:42 PM, Greg Stein wrote:

On Mon, Dec 01, 2003 at 01:18:15AM -0800, Andrew C. Oliver wrote:
On 12/1/03 12:16 AM, "Greg Stein" <[EMAIL PROTECTED]> wrote:
On Sat, Nov 29, 2003 at 07:10:16PM -0500, Rich Bowen wrote:
...
Appropriating the name "Geronimo" for our uses will cause, and has
caused, controversy.
I believe the only controversy has been from people who state that 
the
name will cause controversy. IOW, it is entirely self-generated, 
rather
than any *actual* problem.

Have we actually seen legitimate complaints? Or just *belief* that 
they
will occur?
Could you please enumerate for me what constitutes a legitimate 
complaint?
Somebody who is actually affected by the name. e.g. in this case, one 
of
Geronimo's heirs or another custodian.

I think Sam is right: this is really just a bikeshed. Everybody has 
their
particular color they want, and they feel they can contribute by 
ensuring
their color is selected.

Cheers,
-g
--
Greg Stein, http://www.lyra.org/
-
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: Apache Gallery Project

[Brian McCallister]

I can almost guarantee that you could get hosted at sourceforge. Beyond 
that i don't know of anyone providing hosting for that type of project.

-Brian

On Dec 8, 2003, at 9:32 PM, Jay Zylstra wrote:

I'll interpret the lack of response to mean this idea doesn't fit
Apache.  Okay.  But since the need remains for a free gallery of common
Web app icons (document, search, print, etc.), does anyone have a
suggestion of where such a project would fit, or is anyone aware of an
existing one?
JayZ

-Original Message-
From: Jay Zylstra [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 22, 2003 11:58 PM
To: [EMAIL PROTECTED]
Subject: RE: Apache Gallery Project
I didn't mean that the gallery would be under LGPL specifically, but
something akin to it.  As I understand, there are really three types of
licensing for intellectual property:
1)  Owner restricts access to the property, and charges to use it
(Microsoft,
SCO, etc.)
2)  Owner allows others to use and enhance the property, but must
release
enhancements likewise (GPL)
3)  Owner allows others to use and enhance the property, and
enhancements can
be kept (LGPL, Apache)
I meant that I favor the latter option, since many can use and
contribute to a shared library, while leveraging it in products to make
a living by charging for it.  As a user of that library, it is then in
my interest to contribute to its maintenance and enhancement because
others will then support and build upon those enhancements, and we all
win.  I agree that the ASL 1.1 seems too software-specific for an image
gallery, considering its explicit reference to source and binary code.
The best approach would seem to be the creation of a new Apache Media
License for images, documentation, and other non-code property.
So, now that the LGPL issue is clarified, would something like this 
make
sense as an Apache project?  Since Apache is all about providing the
common tools and technologies necessary to build Web apps (and other
apps as well), I think it fits.  If not, where would such an effort
belong?  I'm against just starting another lone project on SourceForge,
because it would just get lost in the crowd.

JayZ

-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Friday, November 21, 2003 8:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Apache Gallery Project


On Fri, 21 Nov 2003, Jay Zylstra wrote:

4)  Start an LGPL-like project where many share in the free creation
and use of the artwork
Artwork project (http://fedora.redhat.com/projects/artwork), the
Apache Gallery project would be licensed under Apache's more liberal
LGPL-like
You need to research the licencing a bit. The Apache licence is far 
more
libreral than LGPL. There have been questions on LGPL's validity for
something like Java, it's validity for something like images would seem
non existent.

Possibly you might want to consider the various documentation licences.
They may be a better fit than the source code licences like the ASF
licence.
[OT: It does raise interesting questions over the licencing of Apache
documentation and images]
license, which wouldn't force me to open-source my work, and thus
destroy my livelihood.  Once incubated, I'm not sure if it would best
belong under Commons or Jakarta.  Wherever it would land, it would
Definitely not Jakarta. It's nothing to do with Java. Equally, it's
pushing it as to whether it's to do with Commons as it's not something
that is coming from the Apache commiting community [ie) another Apache
project].
Whether artwork is something that fits in the Apache realm, I'll leave
for others to argue over. I see no blatant reason why it could not.
Hen

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


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


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



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

Re: [RT] "We are under incubation" icon

[Brian McCallister]

Following the Axion thread and "it is important that users know it is 
not a regular Apache project" concern -- I think this is an excellent 
solution.

-Brian

On Dec 23, 2003, at 10:35 AM, Tetsuya Kitahata wrote:

Hello,

From the conversation here, it came to my mind that it
would be nice to create "We are under incubation" icon,
which (sub)projects being incubated **should** use on their
websites.
If "We are under incubation" icon would be really nice, each
(sub)projects wouldn't have to be resides
in incubator.apache.org (url/website), i guess.
As for mailing list, "Message Trailer" (footer of each
messages) can substitute it.
Random Thought. Sorry.

-- Tetsuya. <[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: Questions regarding a Clover donation

[Brian McCallister]

Speaking of Clover, OJB has had a license donated to us for use on OJB 
-- but we've just passed it around to the committers thus far.

Would love to put it in cvs but the legality of that is ?? to us.

-Brian

On Apr 21, 2004, at 7:39 PM, Erik Abele wrote:

On 13.04.2004, at 22:48, Alex Karasulu wrote:

Hi,

I would like to get a free group clover license that is offered for
open source projects for the Directory project.
First off I was wondering if we already have one for the entire
ASF.  Secondly I was wondering if there are any requirements I must
abide by according to the ASF.
Sorry to chime in so late but if you can get an Apache-wide license 
for some piece of software, please let members@ know about it so that 
we can record it appropriately (and make sure that others have access 
to it if need be). On the other hand, if it's only a PMC-wide license 
the respective PMC can handle it itself of course... ;)

Cheers,
Erik

I was also thinking of approaching JetBrains for IDEA licenses for our
group as well.
Thanks,
Alex



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

Re: Questions regarding a Clover donation

[Brian McCallister]

On Apr 23, 2004, at 6:28 PM, Noel J. Bergman wrote:

Anyone granted Committer status is given a copy, as I
understand you, but although it is an open ended license, it isn't 
open to
the world, as it would be in CVS.

That is how we've interpreted it thus far. Need to talk to the Clover 
people =)

-Brian



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

Axion Status

[Brian McCallister]

Anyone know the status of Axion's incubation? I don't see any news 
since December.

-Brian



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

Clover and CVS

[Brian McCallister]

TheCortex responds on putting the Clover Jar in CVS.

-Brian

Begin forwarded message:

From: Clover Sales <[EMAIL PROTECTED]>
Date: April 28, 2004 4:19:32 AM EDT
To: Brian McCallister <[EMAIL PROTECTED]>
Subject: [Ticket#: 200404181013] Re: Clover license details
Hi Brian,

Yes, you can put your version of clover into your CVS repository. This 
only applies to the actual jar itself. Please do not put the license 
key in CVS :).

Kind regards,
Daniel
Clover Sales
http://www.thecortex.net/clover
Email. [EMAIL PROTECTED]
Tel. +61-2-9906-7079 Fax. +61-2-9906-7718
PO Box 859, Crows Nest 1585, Sydney Australia
Brian McCallister <[EMAIL PROTECTED]> wrote:
Thank you!

Question -- can we put this in our public CVS repository? Right now we
are just sending it committers, but it is a little inconvenient and,
well, would be nice to just keep everything in CVS =)
-Brian

On Apr 19, 2004, at 8:47 PM, Clover wrote:

Dear Brian,

Cortex is pleased to be able to support the Apache OJB project
with a free Team Edition license of Clover.
To download your licensed version of Clover, please click on the
link below (or cut and paste it into a web browser, depending on
your mail client)
If you have difficulty with the above link, you can proceed to the
Clover downloads page at http://www.thecortex.net/clover/dl.jsp
and enter the registration code:
This version of Clover is only licensed for use on the Apache OJB
project. If you have another project you'd like to use Clover on,
please apply for a separate license.
We appreciate your feedback on all aspects of Clover. Our new online
forums are a great place to get help with Clover, or suggest a new
feature:
http://www.thecortex.net/forums/

Alternatively, please use one of the following email addresses to
contact us:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If you use and like Clover, we'd love you to:

- put a "Coverage by Clover" logo on your project website:

  http://www.thecortex.net/clover/logo.html

Regards,
The Clover Team
Apr 19, 2004
http://www.thecortex.net/clover
You are receiving this notification because your email address was
used to register an application for a free Clover license to support
the Apache OJB project. If you believe you have received this email
in error, please contact us



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

Axion Status

[Brian McCallister]

Just checking in again on Axion =) Last I heard (April) we were waiting 
on the final CLA and a software grant:

http://marc.theaimsgroup.com/?l=incubator-general&m=108325596609966&w=2
Any progress?
Also, unrelated to the ASF move -- any word on another release? 1 year 
anniversary of Axion's last release is coming up next month =)

-Brian

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

Re: Chameleon proposal

[Brian McCallister]

Is there any code actually available right now? I couldn't find 
anything on the site.

Is anyone involved with Chameleon's development besides yourself? (I 
know you are looking for additional developers, but is there anyone 
else right now? A stable community is a key component to an ASF project 
(which can seem like a chicken and egg problem at times)).

-Brian
On Jun 16, 2004, at 3:52 PM, Robert McIntosh wrote:
Any other thoughts regarding accepting this for incubation?
Thanks,
Robert McIntosh

"Noel J. Bergman" <[EMAIL PROTECTED]>
06/09/2004 09:56 PM
Please respond to
[EMAIL PROTECTED]
To
<[EMAIL PROTECTED]>
cc
Subject
RE: proposal



I am sending this proposal to the incubator list to see if there is
any interest for a new persistence project.

it is not just an O/R mapper, but a generic persistence engine that
can be used as an O/R mapping tool.
How does this compare with Torque (http://db.apache.org/torque/) and 
OJB
(http://db.apache.org/ojb/)?

Have others expressed interest in collaborating on this with you?
 --- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


*** PLEASE NOTE ***
This message, along with any attachments, may be confidential or 
legally
privileged.  It is intended only for the named person(s), who is/are 
the
only authorized recipients. If this message has reached you in error,
please notify the sender immediately and promptly destroy it without
review. Dissemination, distribution or copying of this communication is
strictly prohibited. Thank you for your help.
**

-
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: Personal attacks and respect

[Brian McCallister]

As an innocent bystander of the flamewar that spawned this email:
Nicola commented on some technical changes, it started deteriorating  
into shed painting, Nicola posted an email on de-escalating conflict in  
technical discussions, then Stephen attacked Nicola directly for some  
as-yet-unspecified ("you know why, Nicola") historical reason that  
Nicola is not allowed to suggest ways to de-escalate conflict.

From there things went ballistic (the technical discussion wrapped up  
quickly and happily) in personal attacks and slanders and the  
discussion was suggested to move here.

http://nagoya.apache.org/eyebrowse/BrowseList?listName=directory- 
[EMAIL PROTECTED]&by=thread&from=815543
http://nagoya.apache.org/eyebrowse/BrowseList?listName=directory- 
[EMAIL PROTECTED]&by=thread&from=817324
http://nagoya.apache.org/eyebrowse/BrowseList?listName=directory- 
[EMAIL PROTECTED]&by=thread&from=816749

I suggest avoiding argumentum ad hominem in technical discussions. It  
benefits no one, is logically invalid, and plays havoc on communities  
=)

-Brian
On Jul 8, 2004, at 9:50 AM, Stephen McConnell wrote:
Nicola:
If you have a problem with my annoyance at your presumption to preach -
then present it here away from any particular project.
Stephen.
-
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: Incubation of iBATIS Data Mapper

[Brian McCallister]

+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, but, 
in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted people, 
oops!), I realized over the weekend. Will fix it as soon as I get the 
site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being a 
member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the 
project would be quite happy to provide a hat peg and help as needed =) 
I'd love to see iBATIS join the DB project, and this seems the natural 
home for it, but if they really want a TLP, I certainly won't stand in 
the way (and would still be +1).

-Brian

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

Re: Incubation of iBATIS Data Mapper

[Brian McCallister]

+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, but, 
in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted people, 
oops!), I realized over the weekend. Will fix it as soon as I get the 
site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being a 
member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the 
project would be quite happy to provide a hat peg and help as needed =) 
I'd love to see iBATIS join the DB project, and this seems the natural 
home for it, but if they really want a TLP, I certainly won't stand in 
the way (and would still be +1).

-Brian

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

[OT] Re: Incubation of iBATIS Data Mapper

[Brian McCallister]

Sorry for the double post, guess moderator let posting from my unsubbed 
account through!

-Brian
On Aug 9, 2004, at 10:10 AM, Brian McCallister wrote:
+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, 
but, in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted 
people, oops!), I realized over the weekend. Will fix it as soon as I 
get the site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being 
a member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that 
the project would be quite happy to provide a hat peg and help as 
needed =) I'd love to see iBATIS join the DB project, and this seems 
the natural home for it, but if they really want a TLP, I certainly 
won't stand in the way (and would still be +1).

-Brian

-
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: Making Daffodil Replicator an Open Source : Suggestion

[Brian McCallister]

This sounds like a great tool! Offline synching for any JDBC compliant 
database with triggers and procedures is good stuff.

Are the sources available anywhere right now?
The general steps to enter incubation are described in the document:
http://incubator.apache.org/incubation/Incubation_Policy.html
Is anyone involved with the Daffodil Replicator already involved with 
the ASF? I ask as the next step is to generate a formal proposal, which 
entails a nomination my an ASF member ( 
http://www.apache.org/foundation/how-it-works.html#roles ) and deciding 
on a sponsor (either the incubator PMC, the board, or an existing TLP 
-- Daffodil sounds like it may fit well into the db.apache.org project, 
I invite you to bring up conversation on [EMAIL PROTECTED]).

-Brian
On Aug 10, 2004, at 3:30 AM, Ashish Srivastava wrote:
We have decided to make Daffodil Replicator an open source with Apache.
We have a team of 75 professionals who developed Daffodil DB and
Daffodil Replicator. And will continue working with same after making 
it
open source.

Any suggestion or comment?
Project Description:
Daffodil Replicator is a powerful data replication utility which allows
the users to work off line and can merge the data when get online.
Daffodil Replicator is platform independent software based on JDBC
driver. Any Database which supports JDBC Driver with Triggers and
procedure can take part in replication either at publication server or
on subscription side.
Important links:
Documentation on Daffodil Replicator is available at:
  http://www.daffodildb.com/pdf/daffodil_replicator.pdf
Evaluation version of Daffodil Replicator is available at:
  http://www.daffodildb.com:8080/eval/filldetails.jsp



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

Federations [was: Re: Incubation of iBATIS Data Mapper]

[Brian McCallister]

Agreed on the federation thing =) The point is to foster the domain 
community, while best managing disparate (large) projects. I think what 
XML is doing is an excellent way to approach this.

-Brian
On Aug 10, 2004, at 11:03 AM, J Aaron Farr wrote:
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 7:13 AM
To: [EMAIL PROTECTED]
Subject: RE: Incubation of iBATIS Data Mapper
Since there does seem to be interest in reviewing a proposal from 
iBATIS,
I've setup a draft in the Incubator wiki.

http://wiki.apache.org/incubator/IbatisProposal
Based on the discussion here, I've included a section on whether to 
apply
as TLP or subproject.
+1 to iBatis incubation.  I'd love to join in.
As for TLP vs db.apache.org, it probably belongs as a TLP.
We're seeing a general explosion of new TLP's in Apache or subprojects
graduating to TLP level. IMHO at some point we're going to reach a
critical mass where it will no longer be very feasible for the Board to
directly handle so many TLP's.  I believe the XML group is on to 
something
with the project federation idea.  Maybe there needs to be a DB 
federation
instead of or in addition to the DB TLP?

Just my $0.02
jaaron
-
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: Federations [was: Re: Incubation of iBATIS Data Mapper]

[Brian McCallister]

On Aug 10, 2004, at 1:15 PM, Noel J. Bergman wrote:

  TLP reporting is a corporate structure issue, whereas
federation is about sharing resources (e.g., web-site and mail domain) 
and
community building.

Exactly!
-Brian

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

Re: [VOTE] Accept iBATIS for Incubation

[Brian McCallister]

+1 I think iBatis is a good fit.
-Brian
On Aug 23, 2004, at 12:52 AM, Clinton Begin wrote:
See: http://wiki.apache.org/incubator/IbatisProposal
[ ] Accept iBATIS into the Incubator
[ ] Reject iBATIS
Vote ends 12pm (Noon) EDT, Thursday August 26, 2004.
Clinton
-
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: Where proposal should be sent?

[Brian McCallister]

If it is what I think it is... bring it in, please, ASAP. If it isn't 
what I think it is... very curious.

-Brian
On Sep 30, 2004, at 8:21 PM, hammett wrote:
- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
We have a CLI project in the Incubator to run CLI applications (.NET 
being
Microsoft's proprietary and patented technology on top of the CLI).  
There
are people interested in seeing CLI technology at the ASF.
Nice !
If I understand correctly, you will be proposing a set of standalone
tools,
frameworks and an IoC container for building CLI applications.
In a nutshell.
You might want to talk with William Rowe about it, and see if he has
interest in it,
too.
Certainly! Who is he? Google knows about 300 pages related to this 
name :-)
Is he working with the link between Apache Httpd and CLI ?

Cheers,
hammett
-
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: Where proposal should be sent?

[Brian McCallister]

It includes things I thought it would, and more. Aspect# and the 
dynamic proxy stuff is what I was hoping for ;-)

-Brian
On Oct 1, 2004, at 1:39 PM, hammett wrote:
May I put the first draft in the incubator wiki?
Cheers!
hammett
PS: What you think it is? I'm very curious now! :-P
- Original Message -
From: "Brian McCallister" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 01, 2004 2:30 PM
Subject: Re: Where proposal should be sent?

If it is what I think it is... bring it in, please, ASAP. If it isn't
what I think it is... very curious.
-Brian

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

[Brian McCallister]

+1 (non-binding)
-Brian
On Oct 18, 2004, at 5:41 PM, hammett wrote:
My non-binding vote just to bring the topic back :-D
+1
Cheers,
hammett
- Original Message - From: "Leo Simons" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 5:30 AM
Subject: [VOTE] Proposal for Castle

Hi all,
Please vote on the Castle incubation proposal:
   http://wiki.apache.org/incubator/CastleProposal
+1 from me.
References:
http://nagoya.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]&msgNo=4289
http://nagoya.apache.org/eyebrowse/BrowseList? 
[EMAIL PROTECTED]&by=thread&from=894370

- Leo Simons

-
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: mod_aspdotnet graduation, please vote

[Brian McCallister]

+1 non-binding

-Brian


On Wed, 17 Nov 2004 08:50:35 -0800, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Confirmed!
>   :)
> 
> 
> 
> On Nov 16, 2004, at 9:04 PM, Noel J. Bergman wrote:
> 
> > And I will represent that Jim Jagielski also indicated that he is +1 in
> > person when I saw him at ApacheCon.
> >
> > Since the PPMC consists of the Incubator PMC and the HTTPD PMC, and
> > we've
> > votes from both with no objections, if there are no objections by the
> > close
> > of ApacheCon (another 24 hours or so), go ahead with graduation
> > processing
> > upon your arrival home.
> >
> >   --- Noel
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> --
> ===
>   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
>"There 10 types of people: those who read binary and everyone else."
> 
> 
> 
> 
> -
> 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: DB JDO new project

[Brian McCallister]

OJB supports a JDO interface via a plugin to the  JDO 1.0.X reference 
implementation (which is SCSL, non-commercial variant) so is basically 
useless right now. This same RI is part of the initial codebase for 
this project, so the OJB JDO 1.0.X interface can actually become useful 
=)

-Brian
On Dec 7, 2004, at 12:01 PM, Oliver Zeigermann wrote:
Doesn't ORB already support JDO?
Oliver
On Tue, 07 Dec 2004 08:47:19 -0800, Craig Russell 
<[EMAIL PROTECTED]> wrote:
Hi,
The DB project voted to adopt JDO last week-end, and they suggested I
contact you to set up the resources for the project.
I've attached the proposal. Perhaps you can suggest the next step for
me to pursue?
Thanks,
Craig
--
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

-
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: Derby release, pt. II

[Brian McCallister]

On Dec 7, 2004, at 2:06 PM, Andrew McIntyre wrote:
Noted. :-) For future reference, could you tell me if there is a 
location on www.apache.org or cvs.apache.org that IS an acceptable 
location to post proposed items?

Best way I know of would be ~/public_html/
-Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JDO Project Resources

[Brian McCallister]

Hi all, could we have the following mailing lists for the incubating 
JDO project when you get a chance?

jdo-ppmc, jdo-dev, jdo-commits, jdo-user
space in subversion
and a JIRA project?
Apache committers already on the books needing access include:
Geir Magnusson ( geirm )
Dain Sundstrom ( dain )
Brian McCallister ( brianm )
We'll pester the others for CLA's =)
Thank you!
-Brian
On Dec 7, 2004, at 11:47 AM, Craig Russell wrote:
Hi,
The DB project voted to adopt JDO last week-end, and they suggested I
contact you to set up the resources for the project.
I've attached the proposal. Perhaps you can suggest the next step for
me to pursue?
Thanks,
Craig
--
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

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

[JDO] Project Name

[Brian McCallister]

As there are no JDO lists (yet, just asked for them), I'll bring one 
concern I have up here, which is the name.

Are we allowed to call the project "JDO" ? This would be like naming 
the big servlet container project in Jakarta "Servlet" I think. I 
imagine it is technically Apache JDO, which is probably fine. Figure it 
is worth bringing up, particular as the project will play host to the 
official javax.jdo.* namespace, an confusing people is not generally 
ideal.

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

Open Source Community Research

[Brian McCallister]

Bob McWhirter recently pointed me to an interesting paper on community 
dynamics in open source development, of local interest it uses Beehive 
as an example.

http://opensource.mit.edu/papers/westomahony.pdf
Thought it might be of interest here as a the incubator (for those 
involved in projects *in* the incubator, not necessarily for those 
*running* the incubator, though there is a lot of overlap) is largely 
about growing a community, and most recently, growing a community 
around an existing product.

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

JDO Next Step

[Brian McCallister]

Apparently I stepped on some toes asking for resources for the JDO 
project.

The current status of db-jdo is:
	The DB PMC has voted to accept it
	A proposal has been created, but cannot be put in subversion as there 
is no svn repo yet

What is the next step we need to take?
-Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JDO Next Step

[Brian McCallister]

Thank you! Appreciate you getting it set up.
Go ahead and put me on as moderator for the lists for now =)
-Brian
On Dec 15, 2004, at 9:02 AM, Noel J. Bergman wrote:
Apparently I stepped on some toes asking for resources
for the JDO project.
None that I know of, actually.  The SVN setup is easy, but I'd like to 
see
the mailing lists created first, so that SVN has a place to post commit
notices.  Geir wants to give it a try, else I'll try to get to it this
evening.

--- 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: JDO Next Step

[Brian McCallister]

Any progress on setting up resources?
Thanks again!
-Brian
On Dec 16, 2004, at 7:28 PM, Brian McCallister wrote:
Thank you! Appreciate you getting it set up.
Go ahead and put me on as moderator for the lists for now =)
-Brian
On Dec 15, 2004, at 9:02 AM, Noel J. Bergman wrote:
Apparently I stepped on some toes asking for resources
for the JDO project.
None that I know of, actually.  The SVN setup is easy, but I'd like 
to see
the mailing lists created first, so that SVN has a place to post 
commit
notices.  Geir wants to give it a try, else I'll try to get to it this
evening.

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


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

Apache JDO Resources

[Brian McCallister]

Hi all, sorry to bug you again on this one.
Could we have the following resources set up for the incubating Apache 
JDO project:
mailing lists @db.apache.org

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(go ahead and make me the initial moderator)
A subversion repository
A JIRA project
Thank You!
-Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Lucene4c

[Brian McCallister]

I'd love to see this happen, and bringing it into the Lucene Project 
proper seems to make sense, from a Lucene outsider.

-Brian
On Feb 14, 2005, at 8:35 AM, Garrett Rooney wrote:
I'd like to propose the Lucene4c project for incubation.
Lucene4c is a port of the Lucene search engine from Java to C, using 
the Apache Portable Runtime library for portability.  The project is 
far from complete, and code to date is primarily concerned with 
reading an existing Lucene index, which must be created with another 
Lucene implementation (currently only Java Lucene has been tested).  
The plan is to complete support for the rest of the index format and 
then move on to implementing search functionality (beyond the current 
proof of concept code anyway).  Once we've reached that point work 
will begin on actual indexing functionality so that Lucene4c can stand 
alone, without the use of another Lucene implementation for 
bootstrapping.

The project would be part of the new Lucene top leve project, and Erik 
Hatcher has offerred to serve as a sponsor.

While I have yet to expand the community of developers further than 
myself, I am anxious to do so, and I expect to be able to draw both 
from people as of yet unassociated with Lucene who have expressed 
interest in such a project and from existing Lucene developers who 
have expressed interest in establishing cross-language compatibility 
tests for the various Lucene ports.

Lucene4c already has ties to existing ASF projects, particularly 
Lucene itself and APR.  Bringing it into the ASF would only strengthen 
those ties.

More details, including where to get the current release or 
development versions of the code can be found at the Lucene4c web site 
at http://electricjellyfish.net/garrett/lucene4c/

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

JDO Subversion Repository

[Brian McCallister]

Sorry to bug folks about this again, but could anyone create a 
subversion repository for the JDO project in incubation?

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

Re: Prepping for Derby graduation vote

[Brian McCallister]

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:
-BEGIN PGP SIGNED MESSAGE-
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!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQjd4xJrNPMCpn3XdAQFFVwP/XtafSzOx8yzQbXk5atN9SXjcREBPSbdn
bzz+jpV+xNCiMGeH9cyNj1c8lLf2wBuPAfA/Py9QTBpt6lodo6MhvdHCGFmSiQWF
EKfnle5ScycsLFCr+AlcCrf1Ejzc1dIuWwqhNFSZ5mV/NR5ees5aC5iQVfJ6uF1x
hVnZRY8pyxU=
=71W7
-END PGP SIGNATURE-
-
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 iBATIS and recommend as TLP

[Brian McCallister]

I've not been following the iBatis incubation closely (as they 
expressed a preference to not go under DB, and, while I quite like 
iBatis, only have so much time) but if they have a range of 
sub-projects already, and a sufficient developer community, a TLP makes 
sense from my perspective.

I think this brings up the discussion of a strict hierarchy *not* being 
the best design for the ASF from a development/communication 
perspective, even if it is the best fit from a legal responsibility 
point of view =) That is a topic which has been beaten on a lot though, 
so I'd prefer to not rehash it again.

Speaking as a DB PMC member, I'd still welcome iBatis under the DB 
umbrella, and am completely confident the rest of the PMC would as 
well. The size and scope of the project is at least as large as other 
TLP's though, and I cannot imagine they'd have trouble keeping 
themselves in business that way -- especially with the experienced ASF 
hands who are already involved.

Whatever works best for everyone involved =)
-Brian
ps: Another Vonnegut fan!
On Mar 29, 2005, at 6:37 AM, Ted Husted wrote:
On Mon, 28 Mar 2005 22:41:18 -0500, Noel J. Bergman 
<[EMAIL PROTECTED]> wrote:
 Ted,
 It seems appropriate to graduate, but should iBATIS be a TLP, or go 
under
 db.apache.org, along with Derby and related Jakarta Commons code 
that has
 been moving, in your opinion?

         --- Noel
We did discuss it when the application for incubator was made (see 
message #4003 of 09 Aug 2004), but given that the db project has been 
revitalized lately, it is worth mentioning again.

The primary issue is scope. Currently, iBATIS has two core products, 
along with the usual examples and documentation bundles. The core 
DataMapper is an adapter that transfers data between database 
statements and objects. The second product is a DAO framework. Both 
products are available for Java and C#. Counting the example 
applications and documentation, we have eight product distributions in 
play now, overseen by six very active PPMC members. Some of us would 
like to start a PHP5 implementation before long. To keep all the 
products compatible, we also plan a specification product. That would 
bring the total number distributions to twelve or more.

As it stands, the iBATIS product line is cohesive since the products 
share common implementation strategies and will ultimately be 
implementations of a formal specification.  iBATIS is only loosely 
coupled to the other db.apache.org products. The products all involve 
database technologies, but they do not share a common codebase or 
coding paradigm, or, AFAIK, development community.  

IMHO, merging the iBATIS PPMC with the db PMC would tend to create a 
granfaloon [http://www.kcoyle.net/granfalloons.html] :) rather than a 
karass. :)

-Ted.

-
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: Prepping for Derby graduation vote

[Brian McCallister]

Correct, Jeremy is the only non-IBM committer.
-Brian
On Mar 30, 2005, at 10:28 PM, Noel J. Bergman wrote:
Cliff Schmidt wrote:
Doesn't Derby have at least three independent committers?
There's Jeremy and the IBM folks...who's the other one?
As far as I know, Jeremy is the only non-IBM Committer to Derby.
--- 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: [VOTE] Graduate Derby from the incubator

[Brian McCallister]

On Apr 3, 2005, at 11:02 AM, Rodent of Unusual Size wrote:
At least one person from the DB PMC has voted in favour of graduation,
which I hope means that the project understands the issues of
assuming oversight and feels comfortable doing so.  Having more
people from the DB PMC/project weigh in on the vote would be
nice. :-)
DB PMC hat on:
The only thing weighing on me about graduating Derby is that all the 
committers, but one, work for the same employer. There are a number of 
other folks under consideration, but they aren't committers (yet, 
hopefully).

Ken makes a good point about it not being a TLP, and the DB PMC 
prodding the developer community growth. I have to agree with this 
argument, especially when I put it next to the DdlUtils project 
(commons-sql) with, er, two committers.

Derby depends on nothing else at Apache (except ant for its build), and 
is depended on by nothing else at Apache. This is *good* from a 
technical point of view, but is a weakness from a community health 
point of view.

To use DdlUtils as an example again, despite that project having only 
two (active) committers on the project, another Db project, OJB is 
dependent on the project (which is a big chunk of the reason we want to 
get it out of the commons sandbox), and has a strong motivation 
therefore to keep it going. OJB has a pretty good sized committer base, 
and has already pushed past the ~retirement of the initial project 
leader (who still pokes his head in on big design issues, but is 
otherwise pretty much inactive). So, despite DdlUtils having a small 
committer base when aiming for the same level in the ASF hierarchy 
(subproject), it has a much larger developer community strongly 
motivated to maintain it, even if they are not committers on it now.

Derby has a much larger committer base, but that committer base is 
rather homogenous by ASF standards. No other ASF projects I am aware of 
(except maybe Geronimo?) actually use Derby right now, or use it in 
such a way that swapping out to HSQLDB isn't trivial. This lack of 
dependency is good, technically, but does not build a strong community 
support system (if all the BeanUtils committers were hit by trucks, 
there is no real doubt that other Struts folks would step in 
immediately).

DB PMC hat off:
I don't doubt the long-term viability of Derby. It is a great project 
which works well, and has a responsive and growing developer community. 
Even if the IBM committers were to be informed they were no longer 
allowed to contribute under terms of their employment, I am confident 
that despite the slowdown that would occur, the developer community 
would step up (the db pmc would just need to do more work in the 
interim).

I don't know "official ASF policy" on subproject acceptance (if there 
even is such a thing), so have timeboxed my voting decision so that I 
can learn more before having to chime in =)

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

Re: [VOTE] Graduate Derby from the incubator

[Brian McCallister]

To clarify my statement on project dependencies:
I think that Derby has already grown a large and diverse community 
around itself, and that is important to consider as well. Projects 
dependent upon derby, be they ASF or otherwise, have a significant 
second-order effect on the project's truck number. Other ASF projects 
dependent on Derby are a useful metric here as we are familiar with 
those projects, to a greater or lesser degree.

Things Derby depends on (except from the licensing and technical points 
of view) are not particularly relevant to estimating Derby's viability 
(1), but things dependent upon Derby are quite relevant to estimating 
Derby's viability. If you throw away good will and solely base 
motivation on need, projects which have healthy communities which rely 
on Derby are strongly motivated to help maintain Derby -- if the 
current maintainers are incapable of doing so (otherwise most people 
are happy to work on their own stuff).

That is the point I was awkwardly wandering towards. It is *not* a 
substitute for the contributor/committer pool on the project itself, 
but it is a relevant measure of the developer community invested in 
Derby.

-Brian
On Apr 3, 2005, at 11:51 AM, Brian McCallister wrote:
On Apr 3, 2005, at 11:02 AM, Rodent of Unusual Size wrote:
At least one person from the DB PMC has voted in favour of graduation,
which I hope means that the project understands the issues of
assuming oversight and feels comfortable doing so.  Having more
people from the DB PMC/project weigh in on the vote would be
nice. :-)
DB PMC hat on:
The only thing weighing on me about graduating Derby is that all the 
committers, but one, work for the same employer. There are a number of 
other folks under consideration, but they aren't committers (yet, 
hopefully).

Ken makes a good point about it not being a TLP, and the DB PMC 
prodding the developer community growth. I have to agree with this 
argument, especially when I put it next to the DdlUtils project 
(commons-sql) with, er, two committers.

Derby depends on nothing else at Apache (except ant for its build), 
and is depended on by nothing else at Apache. This is *good* from a 
technical point of view, but is a weakness from a community health 
point of view.

To use DdlUtils as an example again, despite that project having only 
two (active) committers on the project, another Db project, OJB is 
dependent on the project (which is a big chunk of the reason we want 
to get it out of the commons sandbox), and has a strong motivation 
therefore to keep it going. OJB has a pretty good sized committer 
base, and has already pushed past the ~retirement of the initial 
project leader (who still pokes his head in on big design issues, but 
is otherwise pretty much inactive). So, despite DdlUtils having a 
small committer base when aiming for the same level in the ASF 
hierarchy (subproject), it has a much larger developer community 
strongly motivated to maintain it, even if they are not committers on 
it now.

Derby has a much larger committer base, but that committer base is 
rather homogenous by ASF standards. No other ASF projects I am aware 
of (except maybe Geronimo?) actually use Derby right now, or use it in 
such a way that swapping out to HSQLDB isn't trivial. This lack of 
dependency is good, technically, but does not build a strong community 
support system (if all the BeanUtils committers were hit by trucks, 
there is no real doubt that other Struts folks would step in 
immediately).

DB PMC hat off:
I don't doubt the long-term viability of Derby. It is a great project 
which works well, and has a responsive and growing developer 
community. Even if the IBM committers were to be informed they were no 
longer allowed to contribute under terms of their employment, I am 
confident that despite the slowdown that would occur, the developer 
community would step up (the db pmc would just need to do more work in 
the interim).

I don't know "official ASF policy" on subproject acceptance (if there 
even is such a thing), so have timeboxed my voting decision so that I 
can learn more before having to chime in =)

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

[OT] Re: [VOTE] Graduate Derby from the incubator

[Brian McCallister]

On Apr 22, 2005, at 2:16 PM, Daniel John Debrunner wrote:
Pity my Derby internals proposal was rejected by Apachecon Europe :-)
Would you consider doing it as a BOF if you will be there? I would like 
to attend it!

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

JDO (Quick) Status Report

[Brian McCallister]

The Apache JDO project is chugging along. The 1.X reference 
implementation, API spec (javax.jdo interfaces), and TCK have been 
migrated to the ASF subversion repository, and the 2.0 API spec and TCK 
are under development. Expert Group communication is being migrated or 
mirrored to the ASF mailing lists as much as possible, including the 
regular conference call minutes.

Two additional committers, Matthew Adams and Erik Bengtson, have been 
added to the project this quarter, in addition to the initial project 
committers. Both Matthew and Erik are members of the JSR 243 expert 
group, as well.

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

Re: Proposal for STDCXX

[Brian McCallister]

Big +1 (non-binding)
-Brian
On May 13, 2005, at 5:27 PM, Heidi Buelow wrote:
Proposal for an Apache-run version of the C++ Standard Library
Submission date: 12 May 2005, Tim Triemstra, Heidi Buelow (TimT @  
RogueWave
dot-com, Buelow @ RogueWave dot-com)

(0) rationale
The goal of the Apache C++ Standard Library project is to provide a  
free
implementation of the ISO/EIC 14882 international standard, often  
called the
"STL" or "stdlib", which is consistent and portable across all major
platforms and compilers. For the sake of this proposal, the project  
will be
called "STDCXX" to blend in with other Apache names.

Currently, C++ developers spend considerable effort porting code among
platforms, as compiler vendors are focused on backward  
compatibility rather
than cross-platform portability. There are other free  
implementations, but
none have the quality, license flexibility, or platform support  
necessary to
serve as a universal foundation for the C++ language.

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. Unique attributes  
include:

Complete compliance with the C++ standard
Complete implementation of locale library (not OS dependant)
User control over strict or loose standards compliance
Largest test suite of any major implementation
High performance
Reference counted basic_string using atomic locking
Thread-safety, including iostream and locale objects
Fast compiles and extremely small executable file sizes
Proven, portable, and fully tested on each platform
Many platforms (Windows, Linux, Solaris, HP-UX, AIX, etc.)
Platform-specific compilers (eg: MSVC, Sun Forte, HP aCC, GCC)
Fully configurable and documented build control
Ten years of deployment in the world's most critical systems
Highly respected documentation, well maintained and up to date
The day the project is launched, it will already provide the strongest
foundation library for the C++ language available, both in terms of  
platform
and standards support.

(0.1) criteria
Meritocracy: The STDCXX project should adhere to the same open,  
merit-based
community standards as other Apache projects, while also closely  
tracking
the relevant C++ standards.

Contributions and Core Developers: The initial code contribution  
will be a
fully-functional implementation of the ISO/EIC 14882 international  
standard,
including the Standard Template Library (STL), locales, and iostreams
libraries. As each platform's build system is packaged, additional  
ports
will be contributed.

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.

Community: We estimate there are over 300,000 developers using the  
original
commercial code, and several have already expressed interest in  
becoming
contributors. This established, loose-knit group of users exposed  
to the
existing code base via OEM or as direct customers should ensure a  
vibrant
community once the open source project is started.

It is likely that the Apache C++ Standard Library would be a desirable
project to be used by other Apache projects as a foundation to ensure
excellent performance and easy portability across platforms. It can  
serve
many of the same goals as the existing APR project, but directly  
address the
needs of C++ developers. Those other projects will be encouraged to  
actively
participate in the library's community as well.

Apache Alignment: With the success of open/free software, C/C++ has  
seen a
bit of a revival as a popular language for its portability, power, and
performance. In fact, Apache has a considerable number of key  
projects based
on these languages. These projects and the entire developer  
community at
large would benefit from a C++ standard implementation from a  
trusted source
such as Apache. Without such a respected organization behind the  
project,
developers will have to constantly choose a less-portable solution,  
or a
solution more risky due to a small user community.

(0.2) known risks
Orphaned Products: One of the first questions when a commercial entity
offers code to the public is "will this code be abandoned?" To be  
clear,
Rogue Wave decided to initiate this process due to its own desire to
stabilize the C++ market, making the creation of higher-level products
easier and more portable. For a long time the contributed code has  
served
primarily as a foundation for other commercial products, not as  
revenue
producer on its own. Regardless of Apache's interested in the  
project, Rogue
Wave

Re: [VOTE] Derby 10.1 incubating release

[Brian McCallister]

+1 (non-binding)

-Brian

On Jul 16, 2005, at 9:39 AM, Andrew McIntyre wrote:


Hello Incubator,

On behalf of the Derby development community, I'd like to request
permission to post the files you can find here:

http://people.apache.org/~fuzzylogic/derby_10.1/

as an incubating release on the Derby website. The big news for this
release is the contribution of the network client driver for Derby to
Apache.

Here is a link to the vote on derby-dev:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/% 
[EMAIL PROTECTED]


and the final result:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/% 
[EMAIL PROTECTED]


Please vote with your approval if you find the release archives  
satisfy the guidelines for incubating releases as described here:


http://incubator.apache.org/incubation/ 
Incubation_Policy.html#Releases%0D


and that no other potential issues as regards incubating releases  
are discovered.


Many thanks,
Andrew McIntyre


-
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 Derby as sub-project of Apache DB

[Brian McCallister]

+1 (derby ppmc and db pmc hats on)

-Brian

On Jul 20, 2005, at 8:40 PM, Daniel John Debrunner wrote:


Noel said that rather than hassling the Incubator PMC members for
release approval, we should just graduate!

So please vote on graduating Derby to a sub-project of Apache DB.

The developer community continues get the Apache Way and its diversity
has increased since the last graduation vote (where it got good  
reports).


We've added five new committers during incubation based upon their
contributions, which gives us committers from three independent  
entities.


We've performed two releases (though the latest is waiting approval  
from

the incubator PMC :-)

DB-PMC has discussed the inclusion of a sub-set of Derby PPMC members.

DB-PMC has voted to accept the project (see status file)
http://incubator.apache.org/projects/derby.html

-

My vote +1.

Thanks!
Dan.


-
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: [RESULT] [VOTE] Graduate Derby as sub-project of Apache DB

[Brian McCallister]

On Jul 26, 2005, at 11:21 AM, Jeremy Boynes wrote:


So what happens now? :-)

Logistical details that come to mind are:
* adding Derby committers to the DB PMC - I assume a vote on who to  
add

  takes place on the DB PMC list, is this in progess?


yes.

Cannot comment on the rest =)

* moving the SVN root under the DB project and granting Derby  
committers

  karma to the appropriate trees there
* updating the project pages in Incubator to reflect graduation
* updating the project web site to reflect the move under DB
* updating the DB website to reflect the new subproject
* change the JIRA category from Incubator to DB
* no change to the mailing lists as they already point to  
db.apache.org


I'm sure I've missed some stuff - anyone else?
Volunteers?

--
Jeremy

Daniel John Debrunner 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)
Three (3) members of the DB-PMC voted +1 (Brian, Geir, Henning).
Thanks,
Dan.



-
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: [RESULT] [VOTE] Graduate Derby as sub-project of Apache DB

[Brian McCallister]

I created jira issues for the infra folks to please move the repo and  
add the Derby committers to the DB group.


Once that goes through someone (from Derby =) can set up the site  
under /www/db.apache.org/derby/ and we can fight with maven until it  
links the Derby stuff from the top level (is a reactor build deeper  
than my understanding of maven).


-Brian

On Jul 29, 2005, at 6:47 PM, Jean T. Anderson wrote:


Daniel John Debrunner wrote:


Jeremy Boynes wrote:


Jean T. Anderson wrote:





I'm happy to take care of web site updates on Jeremy's list below.

Brian, can we move forward with graduation-related work, such as
requesting that infrastructure move derby's svn repo and committer
karmas from infrastructure to db? Or are we waiting for some other
loop to close first?



I believe we are waiting for the conclusion of the vote by the DB  
PMC.



 I think we can move forward, as I understand the DB-PMC is voting on
adding Derby-PPMC members to itself. That should not hold up any  
move of

svn or karma.



According to http://www.apache.org/dev/committers.html , it's still  
the DB PMC that needs to put the request into infra for the move  
("The request to the infrastructure@ list or the apmail@ alias  
needs to come from your Project Management Committee.").


 -jean


According to the status file DB-PMC has voted to accept Derby,  
that was

my understanding as well after talking to Brian last week.
Dan.
-
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]

JDO2 Snapshots

[Brian McCallister]

Is it okay for the (incubating) jdo project to post snapshots to the  
maven repository at ibiblio via the cvs.apache.org repo?


The only catch is figuring a good way to label it as in incubation.  
One option is to include it the artifact id, so it would be something  
like:


jdo2-incubating-2.0-SNAPSHOT

Any thoughts?

-Brian

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

Re: [vote] JDO out of incubation and into the DB project ( was Re: [discussion] JDO out of incubation)

[Brian McCallister]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

DB PMC Hat On

[ X ] +1 Graduate JDO from the Apache Incubator to be a part of the  
DB TLP

[ ] -1 Do not graduate at this time because :


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

iD8DBQFDlxMraOuMdvjqKWcRAkt0AJ9vdRr4ecqfKCPOeiIufpDQ7gm2gwCffciv
iCdK22Yb3gDDjKbBHSzhsWo=
=CfiQ
-END PGP SIGNATURE-

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

Re: [PROPOSAL] Solr

[Brian McCallister]

I know of at least half a dozen private implementations of exactly  
this. I definitely would like to see some common cause oon it.


Will read proposal in more detail tomorrow morning!

-Brian

On Jan 3, 2006, at 7:19 AM, Yonik Seeley wrote:


Hello Incubator PMC folks,

I would like to propose a new Apache project named Solr.
http://wiki.apache.org/incubator/SolrProposal
The project is being proposed as a sub-project of Lucene, and the
Lucene PMC has agreed to be the sponsor.

-Yonik


'''Proposal for new project Solr '''

Yonik Seeley -- yonik at apache dot org


'''(0) rationale'''

Solr is a search server based on Apache Lucene and focused on
full-text search, relevancy, and performance.

Some of the server features include:
   * Query and update interfaces over HTTP and XML.
   * Replication based on index snapshots and rsync.
   * A schema allowing declarative specification of fields and their
types, including specification of text analysis filter chains.
   * External configuration for Lucene parameters, stopword lists, and
synonym lists.
   * A web based admin interface with statistics and debugging.
   * An extensive caching framework for filters, queries, documents,
and user caches.
   * Plugins for customizing query handling, caching and many other
server aspects.

Solr is currently an internal CNET project, and is used to power
search and faceted browsing in a number of CNET sites.

'''(0.1) criteria'''

''Meritocracy: ''

Solr's developers are comfortable operating as a meritocracy.

''Community: ''

Establishing an active open source community will be the top priority.

''Core Developers:''

Solr starts with three committers.

''Alignment:''

Solr currently uses the following Apache projects: Ant, Lucene.

'''(0.2) warning signs'''

''Orphaned products: ''

Solr is not an orphan, use within CNET is growing rapidly.

''Inexperience with open source:''

Solr's committers are experienced with open source and have made
contributions to other open source projects.

''Homogenous developers:''

Solr's initial committers are all CNET employees since it's currently
an internal project.

''Reliance on salaried developers:''

Some committers are currently paid to make contributions to Solr.

''No ties to other Apache products:''

Solr has strong ties to Lucene.

''A fascination with the Apache brand:''

The committers respect the Apache brand and feel that Apache is the
right place to generate a strong open source community.

'''(1) scope of the subprojects'''

The scope of the project is to provide a stand-alone full-text  
search server.
The proposal is that this project become a sub-project of Apache  
Lucene.


'''(2) identify the initial source from which the subproject is to be
populated'''

CNET will donate the initial source code for this project.

'''(3) identify the ASF resources to be created '''


'''(3.1) mailing list(s) '''

 * solr-dev
 * solr-user

'''(3.2) Subversion or CVS repositories'''

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

'''(3.3) Jira '''

 * Solr (SOLR)

'''(4) identify the initial set of committers '''

 * Yonik Seeley, CNET (Lucene committer)
 * Bill Au, CNET
 * Chris Hostetter, CNET

'''(5) identify apache sponsoring individual '''
 * Doug Cutting, Champion
 * Lucene PMC, Sponsor
 (as defined in
http://incubator.apache.org/incubation/ 
Roles_and_Responsibilities.html)


-
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] accept Solr into incubator

[Brian McCallister]

+0 (would be +1 but I am trying not to +1 anything which I cannot  
commit time to help with)


I will use it, though =)

-Brian


On Jan 10, 2006, at 1:38 PM, Yoav Shapira wrote:


Hi,
+1 from me.

Yoav

On 1/10/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:

This is as clear as day: +1.

Otis


- Original Message 
From: Doug Cutting <[EMAIL PROTECTED]>
To: general@incubator.apache.org
Sent: Tue 10 Jan 2006 12:21:49 PM EST
Subject: [VOTE] accept Solr into incubator

I propose that we accept the CNET's Solr project into the incubator.

Discussion on this list evidenced broad interest in this project,  
which

bodes well for its ability to build a developer community.

The Lucene PMC would be happy to accept Solr as a Lucene sub-project
once it graduates from the incubator.

The proposal is at:

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

+1

Doug


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





--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.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: [VOTE] Changes to Incubator process(es)

[Brian McCallister]

On Jan 11, 2006, at 6:28 AM, Davanum Srinivas wrote:

[ -1 ] - Any proposal should hit [EMAIL PROTECTED] first, No PR  
before that.


[ -1 ] - Any PR should be vetted by PRC, No Excuses.


If this includes blogging about it (which recently was an issue) then  
it won't work, regardless of what we want. This is addressing a real  
problem, but is not an enforceable option unless we know what PR  
means, and "No Excuses" is insufficient as it implies any  
communication with the public, which simply won't work.


A bad solution to a problem is not a solution and creates barriers to  
a good solution.


[ -0 ] - Any new proposal should have 3 ASF Members / Officers as  
mentors

(without regard to affiliation)


Current ASF projects which have less than that now. A mentor who  
isn't a contributor is probably a bad idea, so what does it say if  
current projects fail incubator requirements?



[ -1 ] - Any new proposal should list at least one person as a
infrastructure volunteer.


Nice in theory, not doable in practice. Should be strongly encouraged  
to help with infrastructure, but no way it should be a requirement.


[ -1 ] - A sponsoring PMC should hold their VOTE to sponsor a  
proposal or

IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED]


PMC sponsors projects to the incubator. Let the PMC talk it over  
ahead of time and decide on a course of action.


[ -0 ] - Any existing committer from any Apache project should be  
able to

volunteer to work on the proposed project within the 72 hours. Any
later, it would be through regular karma process. (To promote
inclusion/diversification from day one)


I think this is a bad solution to a real problem. I don't have a  
better solution at the moment.



[ -1 ] - IP Clearance needs to be preceded by a proposal posted to
[EMAIL PROTECTED] as well


A PMC isn't allowed to discuss wanting to bring code in?

[ +1 ] - IP Clearance has to be OK'ed by Incubator PMC VOTE (before  
code

gets checked in to a sponsoring project's SVN)


Isn't this required now?


[ -1 ] - Petition the Board to require Incubator PMC VOTE to begin
incubation process even for projects that other PMC's want to sponsor.


This removes the ability for PMC's to bring code in. Where do we draw  
the line between code donations and patches?




[ -1 ] - Within 72 hours of a new project hitting the  
[EMAIL PROTECTED]

mailing list, that any incubator PMC member can call for an advisory
vote and comment period if they see issues with what's been presented
by the sponsoring PMC.


They can do this now, how is it a change?

-Brian

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

Removing Axion Resources

[Brian McCallister]

The DB PMC would like to ask that the Axion incubation resources be  
removed and that Axion no longer be considered in incubation.


-Brian McCallister

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

Re: [VOTE] approve a milestone release of ActiveMQ?

[Brian McCallister]

+1

On Jan 30, 2006, at 12:06 AM, James Strachan wrote:

On the developer list the committers voted to create a milestone  
release of ActiveMQ...
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200512.mbox/[EMAIL PROTECTED]


then the committers voted to approve the distro
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200601.mbox/[EMAIL PROTECTED] 
%3e


the results were 8 +1s and no -1s.

You can download and review the distro here
http://people.apache.org/~chirino/incubator-activemq-4.0-M4/

So based on the incubation guidelines
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

I'd like to ask the Incubator PMC to approve the release
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

[ ] +1 Release the binary as 4.0-M4
[ ] -1 Veto the milestone release (provide specific comments)

Incidentally those interested in the incubation status can view the  
status here

http://wiki.apache.org/geronimo/ActiveMQ_Incubation


Here's my +1

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


-
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: Is deciding the destination up front a mistake? (Was: Let's rewind!!!)

[Brian McCallister]

Re: Both Sam and Brett

I like this. I like this a lot.

-Brian

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

Re: [VOTE-RESULT] Yoko - A CORBA Server Sub-Project Proposal - PASSED

[Brian McCallister]

On Feb 8, 2006, at 6:23 PM, Alan D. Cabrera wrote:


At graduation, the community will decide its final resting place?


Interesting choice of words =)

-Brian

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

Re: [VOTE] Incubator PMC to approve the 4.0-M4 release of ActiveMQ

[Brian McCallister]

+1

-Brian

On Feb 17, 2006, at 10:09 AM, James Strachan wrote:

In accordance with the incubator release procedure (see below) the  
ActiveMQ community has voted on and approved a proposal to release  
the 2nd candidate of the 4.0-M4 release.
We would now like to request the permission of the Incubator PMC to  
perform the release.


Thanks
James

Proposal:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
200602.mbox/[EMAIL PROTECTED] 
%3e


Vote result:
8 +1s, no -1

Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0-M4/ 
distributions/


Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Here's my +1

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


-
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: Cayenne ASF Proposal

[Brian McCallister]

Andrus and Bill initially opened discussion on [EMAIL PROTECTED] I  
suggested they aim for a top level project status for a few reasons:


* Cayenne already has an mature ASF-style structure and community  
(reportedly =)
* There are ~subprojects (the gui tool, etc) in Cayenne, and sub-sub- 
projects seem to be frowned upon

* DB is getting kind of umbrella shaped already

That said, I am very willing to broach the subject of sponsorship  
with the DB PMC, I just figure the discussion of the best way to  
proceed makes more sense here. I think that Cayenne would prefer to  
be a top level project, in the end, and I agree with that goal. The  
best way to help that happen... well, we're discussing all that =)


-Brian

On Feb 25, 2006, at 12:40 PM, Andrus Adamchik wrote:


Hi Yoav,

We've actually looked at the DB option (and are still open to it as  
a second choice). The reasoning behind the TLP proposal is that  
Cayenne has quite some history as an open source project and we  
have a number of subprojects that may not fit into the DB community  
scope as there is no database involved.


Cayenne is all these things:

* An object relational mapping framework (ORM). This part similar  
in functionality to OJB.
* A framework for remote objects persistence (user API similar to  
ORM, but no DB on the backend). I am not even sure how to classify  
that ... persistence through web services (??)

* UI tools (ORM tools and tools for object to UI binding)
* [still in the early stages] JPA implementation (JSR-220) - this  
is another ORM API, but IMO within Apache it has most synergy with  
Geronimo.


In fact we've already presented our proposal to the DB community,  
and the consensus seems to be that TLP is a better option:


http://www.mail-archive.com/general@db.apache.org/msg00247.html

Andrus


On Feb 25, 2006, at 11:17 PM, Yoav Shapira wrote:


Hola,
db.apache.org might be a better place for Cayenne than a TLP, no?
It's similar to OJB...

Yoav

On 2/25/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:

Hi folks,

We at Cayenne project (http://objectstyle.org/cayenne) would like to
join Apache. We wrote a proposal draft that can be viewed here:

http://objectstyle.org/confluence/display/CAY/ASF+Proposal

Brian McCallister volunteered to help us as a mentor. And now we  
need

a Sponsor. I understand that for TLP a sponsor must be either
Incubator PMC or the ASF Board. I am asking for advice on how we can
go about that.

Thanks
Andrus



--
Andrei (aka Andrus) Adamchik
Cayenne Persistence Framework
Lead Architect
http://objectstyle.org/cayenne/



 
-

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





--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.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]




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

Re: Cayenne ASF Proposal

[Brian McCallister]

On Feb 28, 2006, at 4:02 PM, Thomas Dudziak wrote:

Though it wasn't posted to the PMC list (I only saw it because of  
the announcement on the incubator list).


Erg, could have sworn I CC'ed the pmc list once discussions heated  
up. My apologies!


-Brian


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

Re: [VOTE] accept Cayenne into incubator

[Brian McCallister]

On Mar 2, 2006, at 6:24 AM, Andrus Adamchik wrote:



Sorry, this is confusion on my end. I will change the Sponsor to  
DB, but is this consistent with the fact that we have no final  
decision on how Cayenne will graduate from the incubator (as TLP or  
DB subproject)?


You cannot actually do that unless the DB PMC votes to sponsor  
Cayenne, which we haven't done. If Thomas wants to introduce such a  
motion I'm happy to consider it, but as of yet, it hasn't happened.  
If that is the path Cayenne wants to take, let us know and we'll chat  
about it =)


-Brian


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

Re: Incubation Process and PPMCs

[Brian McCallister]

On Mar 14, 2006, at 9:51 AM, Yoav Shapira wrote:


And continuning the discussion from the OpenJPA proposal thread, do
the other 27 - 15 = 12 people on the proposal get moved into
non-committer status?


Speaking as one of those twelve, I'd greatly appreciate not being  
removed just because I am maintaining part of the codebase which  
works quite well at the moment (the "dirt easy, platform neutral,  
wire protocol" part).


-Brian



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

Re: [VOTE] Accept OpenJPA as an Incubator Podling

[Brian McCallister]

+1

-Brian

On Mar 19, 2006, at 5:33 AM, Geir Magnusson Jr wrote:



What follows is the official proposal for OpenJPA.  The unofficial
version can be found here

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

Please vote on acceptance of this proposal.  The vote will run 1  
week until Sunday, March 26, 2006 or until all Incubator PMC  
members have voted.


[ ] +1 Accept the OpenJPA proposal
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


== 
=



OpenJPA Project Proposal
=
OpenJPA will be an ASL-licensed implementation of the Java Persistence
API (JPA) which is defined as part of JSR-220.

Rationale
=
We think that Open JPA is something that will benefit from wide  
collaboration, being able to build a community of developers and  
committers that outlive the founders, and that will be embraced by  
other

Apache efforts, such as the Geronimo project as part of an EJB 3.0
container. Given the existing momentum forming behind JPA even at this
early stage, we are confident that an industrial-grade ASL
implementation of JSR220 will attract a diverse community.
Criteria

Meritocracy
===
The Open JPA committers recognize the desirability of building  
software

as a meritocracy and look forward to growing a healthy community of
developers to enhance the JPA APIs.

Community
=
The proposed committer community is includes members of the BEA JPA  
team

and several individuals from the Apache community.

Core Developers
===
Fourteen of the initial committers are BEA employees. One of those  
is a

committer on the Apache JDO project. We anticipate that five of these
fourteen will be involved in the core code development, and the other
nine will be involved in documentation and ongoing QA for the project.

Three of the initial committers are committers on the Geronimo  
project.

Two are IBM employees involved in the WebSphere product team. One is
from Intel.

Alignment
=
Open JPA will be a candidate for use in Geronimo as the default JPA
implementation. Other projects that have general-purpose JPA needs may
be users of the Open JPA project.

Open JPA has some level of alignment with the Apache DB project. In
particular, the Open JPA codebase already includes support for Derby
databases.

JPA is for use in any Java application, not just J2EE. Therefore, any
application that needs to do data persistence in the object/relational
style (including any application that currently uses Hibernate) will
benefit from Open JPA.

License
===
The existing codebase is owned by BEA and is subject to a proprietary
license. The applicable code will be relicensed under the Apache
Software License 2.0.


Avoiding the Warning Signs
==

Orphaned products
-
Open JPA is a derivative of the basis of the BEA WebLogic Server (WLS)
EJB3 JPA implementation, and so is an important piece of the BEA  
code base.


As this is a very eagerly anticipated specification for the Java
community, we expect that this project will continue to grow and  
develop
within its own community, and be embraced by other open source  
projects

(such as Geronimo) as well.

Inexperience with open source
-
The authors of the existing code (who will be part of the initial
committer list) have experience with open source development  
already, in

both professional and personal contexts. Examples: serp ([WWW]
http://serp.sourceforge.net) (used in Kodo currently), sqlline and  
jline

([WWW] http://sqlline.sourceforge.net and [WWW]
http://jline.sourceforge.net) (used by the Kodo development team, and
used by the Apache JDO team), Growl ([WWW] http://growl.info).

Four of the initial committers have extensive experience within the
Geronimo project, among other open-source projects.

Homogeneous developers
--
The members of the initial committer list have been working in a
distributed, multi-national, asynchronous environment for the last  
five

years, while working at SolarMetric. We had a team of up to 7 people
working from 6 different locations over the course of the last five  
years.


Reliance on Salaried Developers
---
Most of the developers are paid by their employer to contribute to  
this

project, but given the anticipation from the Java community for the a
JPA implementation and the committers' sense of ownership for the  
code,

the project would continue without issue if no salaried developers
contributed to the project.

No ties to other Apache products

Open JPA will likely be used by Geronimo, requires some Apache  
products
(regexp, commons collections, commons lang, commons pool), and  
supports

Apache commons logging.

A fascination with the Apache brand
---
We think that Open JPA is something that will benefit 

Jini Head's Up

[Brian McCallister]

http://archives.java.sun.com/cgi-bin/wa?A2=ind0604&L=jini- 
users&F=&S=&P=4029


-Brian

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

Re: Suggestion for documentation format

[Brian McCallister]

Anakia ( http://jakarta.apache.org/velocity/anakia.html ) compatible 
XML.

-Brian

On Friday, August 22, 2003, at 08:52 AM, Jochen Wiedmann wrote:



Hi,

what is the suggested way for writing an Apache projects documentation?
The project in mind 
(http://nagoya.apache.org/wiki/apachewiki.cgi?JaxbProposal)
is written in Java.

Regards,

Jochen

-
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: Official Apache Directory Project Proposal Submission

[Brian McCallister]

What are voting rules (ie, who is eligible for binding votes for 
acceptance into the incubator, incubator committers, committers at 
large, etc?)

-Brian McCallister

On Wednesday, September 10, 2003, at 02:37 PM, <[EMAIL PROTECTED]> 
wrote:

On behalf of the Apache members and LDAPd members associated with this 
perspective Incubator podling, I officially submit the Incubator 
proposal for what will eventually become the Apache Directory Project. 
 The proposal document is online here as a wiki:

http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject

Thanks much,
Alex Karasulu
-
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: Official Apache Directory Project Proposal Submission

[Brian McCallister]

Am writing up a post, but you might also want to say something about 
this on [EMAIL PROTECTED] as an LDAP is sort of a db =)

A high-profile new project could help liven up DB some ;-)

-Brian

On Wednesday, September 10, 2003, at 03:53 PM, <[EMAIL PROTECTED]> 
wrote:

We're at the disposal of the Incubator and hope to find answers to 
these policy questions ourselves.  In the LDAPd project for example we 
followed Apache rules for accepting committers to the best of our 
abilities.  Where ever possible we try to follow the Apache way.  
Hopefully Nicola and those at the incubator can shed more light on how 
best to proceed and what policies to adopt.

Sincerely,
Alex Karasulu
From: Brian McCallister <[EMAIL PROTECTED]>
Date: 2003/09/10 Wed PM 03:00:12 EDT
To: [EMAIL PROTECTED]
Subject: Re: Official Apache Directory Project Proposal Submission
What are voting rules (ie, who is eligible for binding votes for
acceptance into the incubator, incubator committers, committers at
large, etc?)
-Brian McCallister

On Wednesday, September 10, 2003, at 02:37 PM, <[EMAIL PROTECTED]>
wrote:
On behalf of the Apache members and LDAPd members associated with 
this
perspective Incubator podling, I officially submit the Incubator
proposal for what will eventually become the Apache Directory 
Project.
 The proposal document is online here as a wiki:

http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject

Thanks much,
Alex Karasulu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



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



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



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

Re: Official Apache Directory Project Proposal Submission

[Brian McCallister]

inline

On Thursday, September 11, 2003, at 02:24 PM, <[EMAIL PROTECTED]> 
wrote:

 Both and RDBMS and an LDAP server are databases really.
This is exactly what gets me excited. OODBMS's are basically dead (sad 
as they are nice to develop on) O/R tools are getting as easy to 
develop on as the native OODB. In a lot of ways LDAP style distributed, 
hierarchical databases lend themselves to object persistence better 
than relational databases can hope to, particularly in read-heavy 
applications (ie, most web based).

-Brian



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

Re: Official Apache Directory Project Proposal Submission

[Brian McCallister]

Argh, keep emailing with unsubscribed account... My apologies if a 
moderator approves a clone of this message later

I wasn't so much looking for projects to put under the DB wing, but 
thinking of people who might be interested in LDAPd. An LDAP most 
definately is *not* an RDBMS, but it is a protocol for accessing 
hierarchical databases. After filesystems and DNS, ldap's are probably 
the most widely used hierarchical databases around.

I for one would be more than happy to contribute LDAPd, particularly if 
said alternative is Java embedable.

So, if it comes to a vote and I am allowed to vote, it has my +1.

-Brian

On Thursday, September 11, 2003, at 02:26 PM, Noel J. Bergman wrote:

you might also want to say something about this on
[EMAIL PROTECTED] as an LDAP is sort of a db =)

A high-profile new project could help liven up DB some ;-)
I think that naming and directory services are sufficiently different 
from
an ODBMS or RDBMS.

DB might want to consider adopting Jakarta Commons DBCP.  That topic 
has
come up before, and didn't lack support.

There are some other candidates that the DB PMC could look into 
incubating
and adopting.  For example, http://axion.tigris.org/ is a rather 
obvious
candidate, especially considering the committer list (geir jvanzyl 
mpoeschl
rwald).

Firebird would be nice, but they seem more interested in selling 
memberships
in their foundation, which is completely incompatible with the ASF
meritocracy.

There there are ODBMS such as Ozone (wrong license, though).

	--- 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: Official Apache Directory Project Proposal Submission

[Brian McCallister]

I wasn't so much looking for projects to put under the DB wing, but 
thinking of people who might be interested in LDAPd. An LDAP most 
definately is *not* an RDBMS, but it is a protocol for accessing 
hierarchical databases. After filesystems and DNS, ldap's are probably 
the most widely used hierarchical databases around.

I for one would be more than happy to contribute LDAPd, particularly if 
said alternative is Java embedable.

So, if it comes to a vote and I am allowed to vote, it has my +1.

-Brian

On Thursday, September 11, 2003, at 02:26 PM, Noel J. Bergman wrote:

you might also want to say something about this on
[EMAIL PROTECTED] as an LDAP is sort of a db =)

A high-profile new project could help liven up DB some ;-)
I think that naming and directory services are sufficiently different 
from
an ODBMS or RDBMS.

DB might want to consider adopting Jakarta Commons DBCP.  That topic 
has
come up before, and didn't lack support.

There are some other candidates that the DB PMC could look into 
incubating
and adopting.  For example, http://axion.tigris.org/ is a rather 
obvious
candidate, especially considering the committer list (geir jvanzyl 
mpoeschl
rwald).

Firebird would be nice, but they seem more interested in selling 
memberships
in their foundation, which is completely incompatible with the ASF
meritocracy.

There there are ODBMS such as Ozone (wrong license, though).

	--- 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: Official Apache Directory Project Proposal Submission

[Brian McCallister]

inline

On Thursday, September 11, 2003, at 02:24 PM, <[EMAIL PROTECTED]> 
wrote:

 Both and RDBMS and an LDAP server are databases really.
This is exactly what gets me excited. OODBMS's are basically dead (sad 
as they are nice to develop on) O/R tools are getting as easy to 
develop on as the native OODB. In a lot of ways LDAP style distributed, 
hierarchical databases lend themselves to object persistence better 
than relational databases can hope to, particularly in read-heavy 
applications (ie, most web based).

-Brian



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

Re: Official Apache Directory Project Proposal Submission

[Brian McCallister]

I wasn't so much looking for projects to put under the DB wing, but 
thinking of people who might be interested in LDAPd. An LDAP most 
definately is *not* an RDBMS, but it is a protocol for accessing 
hierarchical databases. After filesystems and DNS, ldap's are probably 
the most widely used hierarchical databases around.

I for one would be more than happy to contribute LDAPd, particularly if 
said alternative is Java embedable.

So, if it comes to a vote and I am allowed to vote, it has my +1.

-Brian

On Thursday, September 11, 2003, at 02:26 PM, Noel J. Bergman wrote:

you might also want to say something about this on
[EMAIL PROTECTED] as an LDAP is sort of a db =)

A high-profile new project could help liven up DB some ;-)
I think that naming and directory services are sufficiently different 
from
an ODBMS or RDBMS.

DB might want to consider adopting Jakarta Commons DBCP.  That topic 
has
come up before, and didn't lack support.

There are some other candidates that the DB PMC could look into 
incubating
and adopting.  For example, http://axion.tigris.org/ is a rather 
obvious
candidate, especially considering the committer list (geir jvanzyl 
mpoeschl
rwald).

Firebird would be nice, but they seem more interested in selling 
memberships
in their foundation, which is completely incompatible with the ASF
meritocracy.

There there are ODBMS such as Ozone (wrong license, though).

	--- 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: Official Apache Directory Project Proposal Submission

[Brian McCallister]

Thomas works for a commercial RDBMS company. License change has been
raised before :-(  I'm a part time committer on that project.
So my recollection is correct, that the stumbling block is Thomas' name
credit, yes?  Too bad, since otherwise it would seem to be a good fit 
for
db.apache.org.
I wouldn't be surprised if Axion is a direct result of this, especially 
considering who is on the development team for it. I will be surprised 
if there isn't a proposal from them someday.

HSQLDB would be a good fit, oh well.

-Brian

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

Re: [PROPOSAL] Aurora for Incubation

[Brian McCallister]

Aurora is aimed at long-running stateless services (like app servers)?

-Brian


On Mon, Aug 26, 2013 at 3:27 PM, Dave Lester wrote:

> Hi All,
>
> We're pleased to share a draft ASF incubation proposal for Aurora, a
> service scheduler used to schedule jobs onto Apache Mesos that we've
> developed at Twitter. Aurora provides all of the primitives necessary to
> quickly deploy and scale stateless and fault tolerant services in a
> datacenter. The complete proposal can be found:
> https://wiki.apache.org/incubator/AuroraProposal, and also pasted below.
>
> In particular, we'd love to add additional mentors to the project. Your
> feedback is appreciated.
>
> Dave
>
> = Abstract =
>
> Aurora is a service scheduler used to schedule jobs onto Apache Mesos.
>
> = Proposal =
>
> Aurora is a scheduler that provides all of the primitives necessary to
> quickly deploy and scale stateless and fault tolerant services in a
> datacenter.
>
> Aurora builds on top of Apache Mesos and provides common features that
> allow any site to run large scale production applications. While the
> project is currently used in production at Twitter, we wish to develop a
> community to increase contributions and see it thrive in the future.
>
> = Background =
>
> The initial development of Aurora was done at Twitter, and is planned to be
> open sourced. This proposal is for Aurora to join the Apache Incubator.
>
> = Rationale =
>
> While the Apache Mesos core focuses on distributing individual tasks across
> nodes in a cluster, typical services consist of dozens or hundreds of
> replicas of tasks. As a service scheduler, Aurora provides the abstraction
> of a "job" to bundle and manage these tasks. Aurora provides many key
> functionalities centered around a job, including: definition, the concept
> of an instance and the serverset, deployment and scheduling, health
> checking, and introspection. It also allows cross-cutting concerns to be
> handled like observability and log collection.
>
> = Current Status =
>
> == Meritocracy ==
>
> By submitting this incubator proposal, we’re expressing our intent to build
> a diverse developer community around Aurora that will conduct itself
> according to The Apache Way and use meritocratic means of accepting
> contributions. Several members of the Aurora team overlap with Apache
> Mesos, which successfully graduated from the Incubator and has embraced a
> meritocratic model of governance; we plan to follow a similar path forward
> with Aurora and believe that a synergy between both projects will make this
> even easier.
>
> == Community ==
>
> Aurora is currently being used internally at Twitter. By open sourcing the
> project, we hope to extend our contributor base significantly and create a
> vibrant community around the project.
>
> == Core Developers ==
>
> Aurora is currently being developed by a team of seven engineers at
> Twitter.
>
> == Alignment ==
>
> The ASF is a natural choice to host the Aurora project, given the goal of
> open sourcing the project and fostering a community to grow and support the
> software. Additionally, Aurora integrates with Apache Mesos, and Apache
> ZooKeeper for service discovery.
>
> We believe that inclusion within Apache will build stronger ties between
> these projects, and create further alignment between their goals and
> communities.
>
> = Known Risks =
>
> == Orphaned Products ==
>
> The core developers plan to continue working full time on the project, and
> there is very little risk of Aurora being abandoned since it is running
> hundreds of services as part of Twitter’s infrastructure. Additionally,
> members of the Mesos community beyond Twitter have expressed interest in an
> advanced scheduler like Aurora (see “Interested Parties” section); we
> believe that need will drive some of the community involvement necessary
> for the project to incubate successfully.
>
> == Inexperience with Open Source ==
>
> Initial Aurora committers have varying levels of experience using and
> contributing to Open Source projects, however by working with our mentors
> and the Apache community we believe we will be able to conduct ourselves in
> accordance with Apache Incubator guidelines. The close relationship between
> the Aurora team and Apache Mesos means there is an awareness of the
> incubation process and a willingness to embrace The Apache Way.
>
> == Homogenous Developers ==
>
> The initial set of committers are from a single organization, however we
> expect that once approved for incubation the project will attract
> contributors from more organizations. We have already had conversations
> with other companies who have expressed an interest in Aurora.
>
> == Reliance on Salaried Developers ==
>
> Initial Aurora committers are salaried developers at Twitter, however
> shortly after open sourcing the code we plan to diversify the project’s
> core committers and contributors.
>
> == Relationships with Other Apache Products ==
>
> Initially, Aurora has been 

Re: [VOTE]: Graduate Apache jclouds as an Apache Top Level Project

[Brian McCallister]

And a belated +1, not that it needs the extra vote, but jclouds functions
great!


On Tue, Sep 24, 2013 at 3:56 AM, Suresh Marru  wrote:

> On Sep 23, 2013, at 2:57 PM, Andrew Bayer  wrote:
>
> > Reminder - it'd be great to get more eyes and make sure we're not missing
> > anything for graduation. Thanks!
>
> + 1 (already voted on PPMC list, just cheer leading for others to look
> over)
>
> Andrew,
>
> Since 5 IPMC member/mentors already voted on the Podling dev list, I do
> not think any further votes are needed. But as you put it rightly, more
> eyes and reviews will be better. I would just put a end time to close the
> vote. Since the next board meeting is 3 weeks away, no hurry though.
>
> Suresh
>
> >
> > A.
> >
> >
> > On Fri, Sep 20, 2013 at 5:00 PM, Andrew Bayer  >wrote:
> >
> >> argh, line breaks all vanished in weird ways. Here's a better format:
> >>
> >> The Apache jclouds project entered incubation in April of 2013, and
> since
> >> then has shipped two releases, added a committer, and transitioned
> >> thoroughly into the Apache Way for decision-making, development process,
> >> etc. Our website[1] conforms, so far as we can tell, with Apache's
> >> standards, the existing jclouds registered trademark has been
> transferred
> >> to the ASF[2], we've decided on a set of project bylaws[4], and now
> we've
> >> held a vote[5] on a graduation resolution[6, and below] to be added to
> the
> >> agenda for the next ASF board meeting.
> >> The vote has passed[7] with 7 binding PPMC +1s and 4 binding mentor +1s,
> >> so on behalf of the Apache jclouds project, I'd like to request the
> IPMC's
> >> approval for our graduation. Thanks!
> >>
> >> Please cast your vote:
> >>
> >> [ ] +1 Graduate the Apache jclouds podling from Apache Incubator as a
> TLP
> >> [ ] +0 Indifferent to the graduation status of Apache jclouds podling
> >> [ ] -1 Reject graduation of Apache jclouds podling from Apache Incubator
> >> because ...
> >>
> >> The vote will be open for 72 hours, until 5pm PDT on Monday, September
> >> 23rd.
> >>
> >> [1]: http://jclouds.incubator.apache.org/
> >> [2]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-37
> >> [3]: http://apache.markmail.org/thread/q6sqwspp55sjtk2v
> >> [4]: https://wiki.apache.org/jclouds/Bylaws
> >> [5]: http://markmail.org/thread/vnnvej3q7sla3btl
> >> [6]: https://wiki.apache.org/jclouds/GraduationCharter
> >> [7]: http://apache.markmail.org/thread/55d6vle5be43gwtv
> >>
> >> Thanks again -
> >> The Apache jclouds project
> >>
> >> ---
> >>
> >> WHEREAS, the Board of Directors deems it to be in the best
> >> interests of the Foundation and consistent with the Foundation's
> >> purpose to establish a Project Management Committee charged with
> >> the creation and maintenance of open-source software related to
> >> providing a cloud agnostic library for the JVM that enables
> >> developers to access a variety of supported cloud providers using
> >> one API, for distribution at no charge to the public.
> >>
> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >> Committee (PMC), to be known as the "The Apache jclouds Project",
> >> be and hereby is established pursuant to Bylaws of the
> >> Foundation; and be it further
> >>
> >> RESOLVED, that The Apache jclouds Project be and hereby is
> >> responsible for the creation and maintenance of a software
> >> project related to providing a cloud agnostic library for the JVM
> >> that enables developers to access a variety of supported cloud
> >> providers using one API; and be it further
> >>
> >> RESOLVED, that the office of "Vice President, jclouds" be and
> >> hereby is created, the person holding such office to serve at the
> >> direction of the Board of Directors as the chair of The Apache
> >> jclouds Project, and to have primary responsibility for
> >> management of the projects within the scope of responsibility of
> >> The Apache jclouds Project; and be it further
> >>
> >> RESOLVED, that the persons listed immediately below be and
> >> hereby are appointed to serve as the initial members of The
> >> Apache jclouds Project:
> >>
> >> * Adrian Cole (adrianc...@apache.org)
> >> * Andrew Bayer(aba...@apache.org)
> >> * Andrew Gaul (g...@apache.org)
> >> * Andrew Phillips (andr...@apache.org)
> >> * Becca Wood  (silky...@apache.org)
> >> * Everett Toews   (ever...@apache.org)
> >> * David Nalley(ke4...@apache.org)
> >> * Ignasi Barrera  (n...@apache.org)
> >> * Ioannis Canellos(ioca...@apache.org)
> >> * Matt Stephenson (matts...@apache.org)
> >>
> >> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrew Bayer be and
> >> hereby is appointed to the office of Vice President, jclouds, to
> >> serve in accordance with and subject to the direction of the Board
> >> of Directors and the Bylaws of the Foundation until death,
> >> resignation, retirement, removal or disqualification, or until a
> >> successor is appointed; and be it further
> >>
> 

Re: [VOTE] Release Apache Mesos 0.10.0-incubating (RC2)

[Brian McCallister]

+1


On Tue, Dec 11, 2012 at 12:56 PM, Benjamin Hindman wrote:

> Please vote on releasing the following candidate as Apache Mesos
> (incubating) version 0.10.0. This will be the second incubator release for
> Mesos in Apache.
>
> The candidate for Mesos 0.10.0-incubating release is available at:
>
>
> http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz
>
> The tag to be voted on:
>
>
> https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.10.0-incubating-RC2
>
> The MD5 checksum of the tarball can be found at:
>
>
> http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz.md5
>
> The signature of the tarball can be found at:
>
>
> http://people.apache.org/~benh/mesos-0.10.0-incubating-RC2/mesos-0.10.0-incubating.tar.gz.asc
>
> Mesos' KEYS file, containing the PGP keys used to sign the release:
>   http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS
>
> Please vote on releasing this package as Apache Mesos 0.10.0-incubating!
>
> The vote is open until Friday, December 14th at 5:00 pm (PST) and passes if
> a majority of at least 3 +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.10.0-incubating
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Mesos, please see http://www.mesosproject.org.
>

Might I have permission to edit the wiki (add a page)?

[Brian McCallister]

BrianMcCallister

Thanks!

-Brian

Re: [VOTE] Accept jclouds into the Apache Incubator

[Brian McCallister]

ute code and documentation on their own time and
> have done so for a lengthy period. Given the current stream of development
> requests and the committers' sense of ownership of the jclouds code, this
> arrangement is expected to continue with jclouds' induction into the ASF.
>
> === Relationships with Other Apache Products ===
>
> jclouds and Apache Libcloud address similiar use cases. However, jclouds
> supplies these services for the Java and Clojure communities whereas
> Libcloud provides them for the Python ecosystem.
>
> While jclouds does not directly rely upon any Apache project, it does
> support several Apache projects and has options to collaborate with several
> others. More specifically, jclouds currently supports Apache Whirr, Apache
> ACE, Apache Karaf, and Apache Camel, and options exist to use Apache Maven
> as a build tool with the jclouds API.
>
> jclouds includes support for the Apache CloudStack API and is used as a
> compatibility test tool for its EC2 interface. jclouds can also be used to
> test Apache Deltacloud EC2 portability.
>
> === An Excessive Fascination with the Apache Brand ===
>
> jclouds recognizes the fortitude of the Apache brand, but the motivation
> for becoming an Apache project is to strengthen and expand the jclouds
> community and its user base. While the jclouds community has seen steady
> growth over the past several years, association with the ASF is expected to
> expedite this pattern of growth. Development is expected to continue on
> jclouds under the Apache license whether or not it is supported by the ASF.
>
> == Documentation ==
>
> The [[http://www.jclouds.org/|jclouds]] project documentation is publicly
> available at the following sites:
>
>   * http://jclouds.org: installation guide, user guides, development
> resources, news, resources to get started
>   * https://github.com/jclouds/jclouds: current source, source code
> issues log
>   * https://github.com/jclouds/jclouds.github.com: static content for
> jclouds.org, documentation issues log
>   * https://twitter.com/jclouds: jclouds on Twitter
>   * https://groups.google.com/forum/?fromgroups#!forum/jclouds-dev: the
> jclouds development forum on Google Groups
>   * https://groups.google.com/forum/?fromgroups#!forum/jclouds: the
> jclouds community forum on Google Groups
>
> == Initial Source ==
>
> The initial source is located on GitHub in the following repositories:
>
>  * git://github.com/jclouds/jclouds.git
>  * git://github.com/jclouds/jclouds-labs.git
>  * git://github.com/jclouds/jclouds.github.com.git
>  * git://github.com/jclouds/jclouds-chef.git
>  * git://github.com/jclouds/jclouds-cli.git
>  * git://github.com/jclouds/jclouds-karaf.git
>  * git://github.com/jclouds/jclouds-examples.git
>
> == Source and Intellectual Property Submission Plan ==
>
> jclouds's initial source is licensed under the Apache License, Version
> 2.0. https://github.com/jclouds/jclouds/blob/master/resources/LICENSE.txt
>
> == External Dependencies ==
>
> This is a listing of Maven coordinates for all of the external
> dependencies jclouds uses. All of the dependencies are in Sonatype and
> their licenses should be accessible.
>
>  * aopalliance:aopalliance:jar:1.0:compile
>  * com.google.code.gson:gson:jar:2.2.2:compile
>  * com.google.guava:guava:jar:14.0.1:compile
>  * com.google.inject.extensions:guice-assistedinject:jar:3.0:compile
>  * com.google.inject:guice:jar:3.0:compile
>  * javax.annotation:jsr250-api:jar:1.0:compile
>  * javax.inject:javax.inject:jar:1:compile
>  * javax.ws.rs:jsr311-api:jar:1.1.1:compile
>  * org.99soft.guice:rocoto:jar:6.2:compile
>
> == Cryptography ==
>
> jclouds contains no cryptographic algorithms, but it does provide the
> ability for people to plug in various cryptographic libraries.
>
> == Required Resources ==
>
> === Mailing lists ===
>
>  * jclouds-dev: for development discussions
>  * jclouds-user: for community discussions
>  * jclouds-private: for PPMC discussions
>  * jclouds-commits: for code changes
>
> === Apache git repository ===
>
> The jclouds team is experienced in git and requests the following
> allocation on the Apache git server:
>
> git://git.apache.org/incubator-jclouds.git
>
> === Issue Tracking ===
>
> jclouds currently uses GitHub for issue tracking. The intent is to request
> an allocation for Jira upon acceptance into the Incubator. Proposed project
> name: jclouds
>
> == Initial Committers ==
>
>  * Ignasi Barrera, ignasi dot barrera at gmail dot com
>  * Andrew Bayer, abayer at apache dot org
>  * Ioannis Canellos, iocanel at gmail dot com
>  * Adrian Cole, adrianc at netflix dot com
>  * Andrew G

Re: [VOTE] Release Apache Mesos 0.11.0-incubating (RC3)

[Brian McCallister]

+1


On Tue, May 28, 2013 at 2:24 PM, Vinod Kone  wrote:

> Please vote on releasing the following candidate as Apache Mesos
> (incubating)
> version 0.11.0. This will be the third incubator release for Mesos in
> Apache
>
> .
>
> The candidate for Mesos 0.11.0-incubating release is available at:
>
>
> http://people.apache.org/~vinodkone/mesos-0.11.0-incubating-RC3/mesos-0.11.0-incubating.tar.gz
>
>
> The tag to be voted on:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-mesos.git;a=tag;h=dbcaa0d348a88188c17a8b06b57306832a7a5885
>
>
> The MD5 checksum of the tarball can be found at:
>
>
> http://people.apache.org/~vinodkone/mesos-0.11.0-incubating-RC3/mesos-0.11.0-incubating.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
> http://people.apache.org/~vinodkone/mesos-0.11.0-incubating-RC3/mesos-0.11.0-incubating.tar.gz.asc
>
> PGP key used to sign the release:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2B1D89DA5C6E508C
>
> Please vote on releasing this package as Apache Mesos 0.11.0-incubating!
>
> The vote is open until Friday, May 31st at 18:30 UTC and passes if a
>
> majority of at least 3 +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.11.0-incubating
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Mesos, please see
> http://incubator.apache.org/mesos.
>

Re: [PROPOSAL] Mesos Project

[Brian McCallister]

> Information about Mesos can be found at http://mesos.berkeley.edu.
> The following sources may be useful to start with:
>
>  * Documentation for GitHub release: http://github.com/mesos/mesos/wiki
>  * Presentation at Hadoop User Group: 
> http://www.cs.berkeley.edu/~matei/talks/2010/hug_mesos.pdf
>  * Tech report on system design and current features: 
> http://mesos.berkeley.edu/mesos_tech_report.pdf (paper to appear at NSDI 2011 
> conference)
>
>
>
> = Initial Source =
>
> Mesos has been under development since spring 2009 by a team of graduate
> students and researchers. It is currently hosted on GitHub under a BSD
> license at http://github.com/mesos/mesos.
>
>
>
> = External Dependencies =
>
> The dependencies all have Apache compatible licenses, including BSD, MIT,
> Boost, and Apache 2.0.
>
>
>
> = Cryptography =
>
> Not applicable.
>
>
>
> = Required Resources =
>
> == Mailing Lists ==
>
>  * mesos-private for private PMC discussions (with moderated subscriptions)
>  * mesos-dev
>  * mesos-commits
>  * mesos-user
>
>
>
> == Subversion Directory ==
>
> https://svn.apache.org/repos/asf/incubator/mesos
>
>
>
> == Issue Tracking ==
>
> JIRA Mesos (MESOS)
>
>
>
> == Other Resources ==
>
> The existing code already has unit tests, so we would like a Hudson instance
> to run them whenever a new patch is submitted. This can be added after project
> creation.
>
>
>
> = Initial Committers =
>
>  * Ali Ghodsi (ali at sics dot se)
>  * Benjamin Hindman (benh at eecs dot berkeley dot edu)
>  * Andy Konwinski (andyk at eecs dot berkeley dot edu)
>  * Matei Zaharia (matei at apache dot org)
>
> A CLA is already on file for Matei Zaharia.
>
>
> = Affiliations =
>
>  * Ali Ghodsi (UC Berkeley / Swedish Institute of Computer Science)
>  * Benjamin Hindman (UC Berkeley)
>  * Andy Konwinski (UC Berkeley)
>  * Matei Zaharia (UC Berkeley)
>
>
>
> = Sponsors =
>
> == Champion ==
>
> Tom White
>
> == Nominated Mentors ==
>
>  * Dhruba Borthakur
>  * Brian McCallister
>  * Tom White
>
> == Sponsoring Entity ==
>
> Incubator PMC
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Re: [VOTE] Mesos to enter the incubator

[Brian McCallister]

m design and current features:
> http://mesos.berkeley.edu/mesos_tech_report.pdf (paper to appear at NSDI
> 2011 conference)
>
>
>
> = Initial Source =
>
> Mesos has been under development since spring 2009 by a team of graduate
> students and researchers. It is currently hosted on GitHub under a BSD
> license at http://github.com/mesos/mesos.
>
>
>
> = External Dependencies =
>
> The dependencies all have Apache compatible licenses, including BSD, MIT,
> Boost, and Apache 2.0.
>
>
>
> = Cryptography =
>
> Not applicable.
>
>
>
> = Required Resources =
>
> == Mailing Lists ==
>
>  * mesos-private for private PMC discussions (with moderated subscriptions)
>  * mesos-dev
>  * mesos-commits
>  * mesos-user
>
>
>
> == Subversion Directory ==
>
> https://svn.apache.org/repos/asf/incubator/mesos
>
>
>
> == Issue Tracking ==
>
> JIRA Mesos (MESOS)
>
>
>
> == Other Resources ==
>
> The existing code already has unit tests, so we would like a Hudson instance
> to run them whenever a new patch is submitted. This can be added after
> project
> creation.
>
>
>
> = Initial Committers =
>
>  * Ali Ghodsi (ali at sics dot se)
>  * Benjamin Hindman (benh at eecs dot berkeley dot edu)
>  * Andy Konwinski (andyk at eecs dot berkeley dot edu)
>  * Matei Zaharia (matei at apache dot org)
>
> A CLA is already on file for Matei Zaharia.
>
>
> = Affiliations =
>
>  * Ali Ghodsi (UC Berkeley / Swedish Institute of Computer Science)
>  * Benjamin Hindman (UC Berkeley)
>  * Andy Konwinski (UC Berkeley)
>  * Matei Zaharia (UC Berkeley)
>
>
>
> = Sponsors =
>
> == Champion ==
>
> Tom White
>
> == Nominated Mentors ==
>
>  * Dhruba Borthakur
>  * Brian McCallister
>  * Tom White
>
> == Sponsoring Entity ==
>
> Incubator PMC
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Re: [PROPOSAL] Propose Howl as an Apache Incubator project

[Brian McCallister]

The proposal looks fine, but the name collides with http://howl.ow2.org/

-Brian

On Thu, Feb 10, 2011 at 1:37 PM, Alan Gates  wrote:
> I would like to propose Howl as an Apache Incubator project.  Howl is a
> table and storage management service for data created using Apache Hadoop.
>  The proposal is on the Incubator wiki at
> http://wiki.apache.org/incubator/HowlProposal and is pasted below.  Thanks.
>
> Alan.
>
> == Abstract ==
> Howl is a table and storage management service for data created using Apache
> Hadoop.
>
> == Proposal ==
> The vision of Howl is to provide table management and storage management
> layers for Apache Hadoop.  This includes:
>  * Providing a shared schema and data type mechanism.
>  * Providing a table abstraction so that users need not be concerned with
> where or how their data is stored.
>  * Providing interoperability across data processing tools such as Pig, Map
> Reduce, Streaming, and Hive.
>
> == Background ==
> Data processors using Apache Hadoop have a common need for table management
> services.  The goal of a table management service is to track data that
> exists in a Hadoop grid and present that data to users in a tabular format.
>  Such a table management service needs to provide a single input and output
> format to users so that individual users need not be concerned with the
> storage formats that are chosen for particular data sets.  As part of having
> a single format, the data will need to be described by one type of schema
> and have a single datatype system.
>
> Additionally, users should be free to choose the best tools for their use
> cases.  The Hadoop project includes Map Reduce, Streaming, Pig, and Hive,
> and additional tools exist such as Cascading.  Each of these tools has users
> who prefer it, and there are use cases best addressed by each of these
> tools.  Two users on the same grid who need to share data should not be
> constrained to use the same tool but rather should be free to choose the
> best tool for their use case.  A table management service that presents data
> in the same way to all of the tools can alleviate this problem by providing
> interfaces to each of the data processing tools.
>
> There are also a few other features a table management service should
> provide, such as notification of when data arrives.
>
> A couple of developers at Yahoo! started the project. It is based on the
> Hive !MetaStore component. There is good amount of interest in such a
> service expressed from Yahoo!, Facebook, !LinkedIn, and, others. We are
> therefore proposing to place Howl in the Apache incubator and to build an
> open source community around it.
>
>
> == Rationale ==
> There is a strong need for a table management service, especially for large
> grids with petabytes of data, and where the data volume is increasing by the
> day. Hadoop users need to find data to read and have a place to store their
> data.  Currently users must understand the location of data to read, the
> storage format, compression techniques used, etc.  To write data they need
> to understand where on HDFS their data belongs, the best compression format
> to use, how their data should be serialized, etc.
>
> Most users do not want to be concerned with these issues.  They want these
> managed for them.
>
> Having it as an Apache Open Source project will highly benefit Howl from the
> point of view of getting a large community that currently uses Hadoop and
> the other products built around Hadoop (like Pig, Hive, etc.). Users of the
> Hadoop ecosystem can influence Howl’s roadmap, and contribute to it. Looking
> at it in another way, we believe having Howl as part of the Hadoop ecosystem
> will be a great benefit to the current Hadoop/Pig/Hive community too.
>
> == Current Status ==
> === Meritocracy ===
> Our intent with this incubator proposal is to start building a diverse
> developer community around Howl following the Apache meritocracy model. We
> have wanted to make the project open source and encourage contributors from
> multiple organizations from the start. We plan to provide plenty of support
> to new developers and to quickly recruit those who make solid contributions
> to committer status.
>
> === Community ===
> Howl is currently being used by developers at Yahoo! and there has been an
> expressed interest from !LinkedIn and Facebook. Yahoo! also plans to deploy
> the current version of Howl in production soon. We hope to extend the user
> and developer base further in the future. The current developers and users
> are all interested in building a solid open source community around Howl.
>
> To work towards an open source community, we have started using the !GitHub
> issue tracker and mailing lists at Yahoo! for development discussions within
> our group.
>
> === Core Developers ===
> Howl is currently being developed by four engineers from Yahoo! - Devaraj
> Das, Ashutosh Chauhan, Sushanth Sowmyan, and Mac Yang. All the engineers
> have deep expertise i

Re: [Proposal][Vote] Traffic Server

[Brian McCallister]

+1

On Thu, Jul 2, 2009 at 4:03 PM, Leif Hedstrom wrote:
> Good evening,
>
> As you know, we've been preparing our proposal to submit Traffic Server to
> the Incubator for a few weeks now. With the help from our champion (thanks
> Doug!), and the entire Incubator community, it's my pleasure to submit a
> request for Traffic Server to be accepted into the Incubator. The proposal
> is attached below, and is also available on the Wiki:
>
>  http://wiki.apache.org/incubator/TrafficServerProposal
>
>
> Since our first draft, we've added a number of mentors and contributors, and
> also added and improved on the proposal. I would like this to be considered
> our official application, and that the Incubator votes (+ or -) on our
> acceptance as a podling.
>
> Sincerely,
>
> -- leif
>
>
> Traffic Server
>
> 
>
>
>     Abstract
>
> Traffic Server is fast, scalable and extensible HTTP/1.1 compliant caching
> proxy server.
>
>
>     Proposal
>
> The goal is to create an Apache top level project to Open Source the
> existing Yahoo! Traffic Server code. Traffic Server (TS for short) is used
> in-house to deliver significant amount of HTTP traffic to millions of users.
>
> Key Features:
>
>   *
>
>     HTTP/1.1 caching proxy server
>
>   *
>
>     Scalable on SMP (TS is a hybrid thread + event processor)
>
>   *
>
>     Extensible: TS has a feature rich plugin API
>
>   *
>
>     Fast
>
>
>     Background
>
> Traffic Server is a piece of software initially acquired by Yahoo! from
> Inktomi. The software has been actively developed and used at Yahoo for the
> last three years, and we're now getting ready to Open Source this project.
>
>
>     Rationale
>
> Traffic Server fills a need for a fast, extensible and scalable HTTP proxy
> and caching. We have a production proven piece of software that can deliver
> HTTP traffic at high rates, and can scale well on modern SMP hardware. We
> have benchmarked Traffic Server to handle in excess of 35,000 RPS on a
> single box. Traffic Server has a rich feature set, implementing most of
> HTTP/1.1 to the RFC specifications.
>
>
>     Initial goals
>
> The initial goal is to build a community of developers and users of the
> Traffic Server software. Longer term goal is to address a few feature
> additions that we think are beneficial:
>
>   *
>
>     Full 64-bit support
>
>   *
>
>     Porting to more Unix flavors (currently we only support Linux)
>
>   *
>
>     Add missing features, e.g., CARP, HTCP, ESI and native IPv6
>
>   *
>
>     Incremental improvements to existing features, and performance
>
>
>     Current Status
>
>
>       Meritocracy
>
> Building our developer community using the meritocracy is important to the
> success of Traffic Server. We know there are many developers out there
> interested in the technology, and the meritocracy system is a great way to
> encourage participation.
>
>
>       Community
>
> Our hope is that our existing code, features and capabilities will attract a
> large community of both developers and users. We know that several
> developers who have previously worked on the code, are looking forward to
> participating in the Open Source efforts. We also believe that other
> organizations will find this project interesting and relevant, and
> contribute resources.
>
> The user community of Traffic Server would be similar to that of the Apache
> HTTP server, and in many cases they would overlap.
>
>
>       Core Developers
>
>   *
>
>     Leif Hedstrom 
>
>   *
>
>     Bryan Call 
>
>   *
>
>     Vijaya Bhaskar Mamidi 
>
>   *
>
>     Steve Jiang 
>
>   *
>
>     Dima Ruban 
>
>   *
>
>     Anirban Kundu 
>
>   *
>
>     Andrew Hsu 
>
>   *
>
>     Eric Balsa 
>   *
>
>     BalaKrishna  JD
>     
>
>
>       Alignment
>
> Yahoo! is already a contributor to the Apache Foundation. We are already
> familiar with the ASF process, and we know it provides everything we need
> and require to be successful. We also feel there is a natural symbiotic
> relationship between Traffic Server and the Apache HTTP server, which is how
> TS is generally used at Yahoo!. The Traffic Server team is also in the same
> organization as the Yahoo! Hadoop developers, which is already an Apache
> TLP.
>
>
>     Known Risks
>
>
>       Orphaned Products
>
> Traffic Server is widely used and deployed inside of Yahoo!. It's not going
> away anytime soon; in fact, it's growing fast.
>
>
>       Inexperience with Open Source
>
> All Yahoo! participants are active users and contributors to Open Source
> projects. Leif is a committer at Mozilla (although no longer active),
> creator of PerLDAP, as well as creator of a Yahoo! search API (pYsearch).
> Bryan Call is the creator of cksfv, and contributor to lmsensor. Dima Ruban
> has been an active developer in the FreeBSD project.
>
>
>       Homogeneous Developers
>
> The current list of committers are mostly members

Re: [Discuss] Apache Shindig as a TLP

[Brian McCallister]

Big +1

On Tue, Jan 12, 2010 at 10:04 AM, Vincent Siveton  wrote:
> Hi folks
>
> FYI, the Shindig community has successfully voted for graduation [1].
> If no objection on the charter or other, I will start a formal
> acceptance vote soon.
>
> Cheers,
>
> Vincent
>
> [1] http://shindig-dev.markmail.org/message/c47amdxjtntkjij5
>

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

Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

[Brian McCallister]

+1 (slightly late, but I have a great excuse!)

On Mon, Feb 1, 2010 at 9:24 AM, Kevan Miller  wrote:
> +1 (binding)
>
> Good luck.
>
> --kevan
>
> On Jan 28, 2010, at 2:59 PM, Eric Evans wrote:
>
>>
>> Greetings,
>>
>> We took the feedback from the earlier discussion[1] here and added our
>> active mentors to the proposed PMC, (for a total of 7 people), then ran
>> that through a new community vote[2].
>>
>> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
>> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
>>
>> There didn't seem to be any other feedback, so I'd like to start an
>> official vote to recommend graduation of Apache Cassandra to a top-level
>> project.
>>
>> Please cast your vote:
>> [ ] +1 to recommend Cassandra's graduation
>> [ ]  0 don't care
>> [ ] -1 no, don't recommend yet, (because...)
>>
>> The vote will be open for 72 hours.
>>
>> Thanks,
>>
>> --
>> Eric Evans
>> eev...@rackspace.com
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Re: [VOTE][PROPOSAL] Amber incubator

[Brian McCallister]

+1

On Wed, May 5, 2010 at 11:59 PM, Matthias Wessendorf  wrote:
> +1 (binding )
>
> sent from my Android phone
>
> Am 06.05.2010 07:57 schrieb "Gurkan Erdogdu" :
>
> +1
>
> --Gurkan
>
>
>
>
> 
> From: Simone Gianni 
> To: general@incubator.apache.org
> Sent: Wed, May 5, 2010 1:48:46 AM
> Subject: [VOTE][PROPOSAL] Amber incubator
>
>
> I would like to present for a vote the following proposal to be sponsored by
> the Shindig PMC for a ...
>

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

CloudStack?

[Brian McCallister]

I don't remember seeing anything about a CloudStack project, is there
something I missed?

http://www.citrix.com/English/NE/news/news.asp?newsID=2323072

-Brian

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

Re: [VOTE] Release Apache Mesos 0.9.0-incubating (RC5)

[Brian McCallister]

+1 swept for licensing and general organization of everything :-)

On Thu, Apr 19, 2012 at 5:54 PM, Matei Zaharia  wrote:
> +1
>
> Tested it on Mac OS X, seems to work fine.
>
> Matei
>
> On Apr 19, 2012, at 12:53 PM, Benjamin Hindman wrote:
>
>> Please vote on releasing the following candidate as Apache Mesos
>> (incubating) version 0.9.0. This will be the first incubator release for
>> Mesos in Apache, but the sixth release candidate.
>>
>> Changes since RC4:
>>  * Updated NOTICE to include project name and copyright date as well as to
>> include third-party licences.
>>  * Changed one of our third-party components to be included as an archive
>> of it's source rather than a binary bundle (Python egg).
>>  * Added DISCLAIMER.
>>
>> The candidate for Mesos 0.9.0-incubating release is available at:
>>
>> http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz
>>
>> The tag to be voted on:
>>
>> https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.9.0-incubating-RC5
>>
>> The MD5 checksum of the tarball can be found at:
>>
>> http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>>
>> http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.asc
>>
>> Mesos' KEYS file, containing the PGP keys used to sign the release:
>>  http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS
>>
>> Please vote on releasing this package as Apache Mesos 0.9.0-incubating!
>>
>> The vote is open until Monday, April 23rd at 8 pm (a bit more than 72 hours
>> since it's over the weekend) and passes if a majority of at least 3 +1 IPMC
>> votes are cast.
>>
>> [ ] +1 Release this package as Apache Mesos 0.9.0-incubating
>> [ ] -1 Do not release this package because ...
>>
>> To learn more about Apache Mesos, please see
>> http://incubator.apache.org/mesos.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: Incubator Proposal: SPL

[Brian McCallister]

On Sep 17, 2007, at 5:57 AM, David L Kaminsky wrote:

Tomcat
-

We're open to suggestions regarding the order in which we add  
bindings to

APIs, and doing such bindings isn't terribly hard.  If Tomcat is
particularly critical as an early demonstration, we can add that to  
the
proposal.  And, of course, the code is (suppose to be) modular, so  
others

could at it at any time.


Lot more people deploy and manage large number of Tomcat instances  
than Geronimo instances.


-Brian

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

Re: Incubator Proposal: Pig

[Brian McCallister]

+1 -- I'd offer to help as much as I can, but I know how little that  
is right now :-(


Definitely support (and will probably use at least ;-)

-Brian

On Sep 18, 2007, at 12:52 PM, Olga Natkovich wrote:


Hi,

Yahoo! research and development teams have developed a proposal  
below. The

proposal is also available on wiki at

http://wiki.apache.org/incubator/PigProposal.
We would like to ask that the ASF consider forming a podling  
according to

the proposal.

Thanks,

Olga Natkovich
  [EMAIL PROTECTED]

-- 
--

-

= Pig Open Source Proposal =

== Abstract ==

Pig is a platform for analyzing large data sets.

== Proposal ==

The Pig project consists of high-level languages for expressing data
analysis programs, coupled with infrastructure for evaluating these
programs. The salient property of Pig programs is that their  
structure is
amenable to substantial parallelization, which in turns enables  
them to

handle very large data sets.

At the present time, Pig's infrastructure layer consists of a  
compiler that
produces sequences of Map-Reduce programs, for which large-scale  
parallel
implementations already exist (e.g., the Hadoop subproject). Pig's  
language
layer currently consists of a textual language called Pig Latin,  
which has

the following key properties:

 1. ''Ease of programming''. It is trivial to achieve parallel  
execution of

simple, "embarrassingly parallel" data analysis tasks. Complex tasks
comprised of multiple interrelated data transformations are explicitly
encoded as data flow sequences, making them easy to write,  
understand, and

maintain.
 2. ''Optimization opportunities''. The way in which tasks are encoded
permits the system to optimize their execution automatically,  
allowing the

user to focus on semantics rather than efficiency.
 3. ''Extensibility''. Users can create their own functions to do
special-purpose processing.

== Background ==

Pig started as a research project at Yahoo! in May of 2006 to  
combine ideas
in parallel databases and distributed computing. The first internal  
release
took place in July 2006. The first release was a simple front-end  
to the
Hadoop Map/Reduce framework. The following releases added new  
features and
evolved the language based on user feedback. In July 2007, pig was  
taken
over by a development team and the first production version is due  
to be

released on 9/28/07.

Since its inception, we had observed a steady growth of the user  
community
within Yahoo!.  In April 2007, Pig was released under a BSD-type  
license.
Several external parties are using this version and have expressed  
interest

in collaborating on its development.

== Rationale ==

In an information-centric world, innovation is driven by ad-hoc  
analysis of
large data sets. For example, search engine companies routinely  
deploy and

refine services based on analyzing the recorded behavior of users,
publishers, and advertisers. The rate of innovation depends on the
efficiency with which data can be
analyzed.

To analyze large data sets efficiently, one needs parallelism. The  
cheapest
and most scalable form of parallelism is cluster computing.  
Unfortunately,

programming for a cluster computing environment is difficult and
time-consuming. Pig makes it easy to harness the power of cluster  
computing

for ad-hoc data analysis.

While other language exist that try to achieve the same goals, we  
believe
that Pig provides more flexibility and gives more control to the  
end user.


SQL typically requires (1) importing data from a user's preferred  
format
into a database system's internal format (2) well-structured,  
normalized

data with a declared schema, and (3) programs expressed in declarative
SELECT-FROM-WHERE blocks. In contrast, Pig Latin facilitates (1)
interoperability, i.e. data may be read/written in a format  
accepted by
other applications such as text editors or graph generators (2)  
flexibility,

i.e. data may be loosely structured or have structure that is
defined operationally, and (3) adoption by programmers who find  
procedural

programming more natural than declarative programming.

Sawzall is a scripting language used at Google on top of Map-Reduce. A
sawzall program has a fairly rigid structure consisting of a  
filtering phase

(the map step) followed by an aggregation phase (the reduce step).
Furthermore, only the filtering phase can be written by the user,  
and only a
pre-built set of aggregations are available (new ones are non- 
trivial to
add). While Pig Latin has similar higher level primitives like  
filtering and
aggregation, an arbitrary number of them can be flexibly chained  
together in
a Pig Latin program, and all primitives can use user-defined  
functions with
equal ease. Further, Pig Latin has additional primitives such as  
cogrouping,
that allow operations s

Re: [VOTE] accept Pig into Incubator

[Brian McCallister]

+1

-Brian

On Sep 25, 2007, at 10:20 AM, Doug Cutting wrote:

I would like to call the Incubator PMC to vote to incubate the  
proposed Pig project.  Discussion on this list evidenced broad  
interest in this project, which bodes well for its ability to build  
a diverse developer community.


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

+1

Doug

---

= Proposal for Pig Project =

== Abstract ==

Pig is a platform for analyzing large data sets.

== Proposal ==

The Pig project consists of high-level languages for expressing  
data analysis programs, coupled with infrastructure for evaluating  
these programs. The salient property of Pig programs is that their  
structure is amenable to substantial parallelization, which in  
turns enables them to handle very large data sets.


At the present time, Pig's infrastructure layer consists of a  
compiler that produces sequences of Map-Reduce programs, for which  
large-scale parallel implementations already exist (e.g., the  
Hadoop subproject). Pig's language layer currently consists of a  
textual language called Pig Latin, which has the following key  
properties:


 1. ''Ease of programming''. It is trivial to achieve parallel  
execution of simple, "embarrassingly parallel" data analysis tasks.  
Complex tasks comprised of multiple interrelated data  
transformations are explicitly encoded as data flow sequences,  
making them easy to write, understand, and maintain.
 2. ''Optimization opportunities''. The way in which tasks are  
encoded permits the system to optimize their execution  
automatically, allowing the user to focus on semantics rather than  
efficiency.
 3. ''Extensibility''. Users can create their own functions to do  
special-purpose processing.


== Background ==

Pig started as a research project at Yahoo! in May of 2006 to  
combine ideas in parallel databases and distributed computing. The  
first internal release took place in July 2006. The first release  
was a simple front-end to the Hadoop Map/Reduce framework. The  
following releases added new features and evolved the language  
based on user feedback. In July 2007, pig was taken over by a  
development team and the first production version is due to be  
released on 9/28/07.


Since its inception, we had observed a steady growth of the user  
community within Yahoo!.  In April 2007, Pig was released under a  
BSD-type license.  Several external parties are using this version  
and have expressed interest in collaborating on its development.


== Rationale ==

In an information-centric world, innovation is driven by ad-hoc  
analysis of large data sets. For example, search engine companies  
routinely deploy and refine services based on analyzing the  
recorded behavior of users, publishers, and advertisers. The rate  
of innovation depends on the efficiency with which data can be

analyzed.

To analyze large data sets efficiently, one needs parallelism. The  
cheapest and most scalable form of parallelism is cluster  
computing. Unfortunately, programming for a cluster computing  
environment is difficult and time-consuming. Pig makes it easy to  
harness the power of cluster computing for ad-hoc data analysis.


While other language exist that try to achieve the same goals, we  
believe that Pig provides more flexibility and gives more control  
to the end user.


SQL typically requires (1) importing data from a user's preferred  
format into a database system's internal format (2) well- 
structured, normalized data with a declared schema, and (3)  
programs expressed in declarative SELECT-FROM-WHERE blocks. In  
contrast, Pig Latin facilitates (1) interoperability, i.e. data may  
be read/written in a format accepted by other applications such as  
text editors or graph generators (2) flexibility, i.e. data may be  
loosely structured or have structure that is
defined operationally, and (3) adoption by programmers who find  
procedural programming more natural than declarative programming.


Sawzall is a scripting language used at Google on top of Map- 
Reduce. A sawzall program has a fairly rigid structure consisting  
of a filtering phase (the map step) followed by an aggregation  
phase (the reduce step). Furthermore, only the filtering phase can  
be written by the user, and only a pre-built set of aggregations  
are available (new ones are non-trivial to add). While Pig Latin  
has similar higher level primitives like filtering and aggregation,  
an arbitrary number of them can be flexibly chained together in a  
Pig Latin program, and all primitives can use user-defined  
functions with equal ease. Further, Pig Latin has additional  
primitives such as cogrouping, that allow operations such as joins  
(which require multiple programs in Sawzall) to be written in a  
single line in Pig Latin. Further, Pig Latin is designed
to be embedded into other languages, and can use functions written  
in other languages. Thus

[PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client-side
composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

Thomas Baker<[EMAIL PROTECTED]>
Tim Williamson  <[EMAIL PROTECTED]>
Brian McCallister   <[EMAIL PROTECTED]>
Thomas Dudziak  <[EMAIL PROTECTED]>
Martin Traverso <[EMAIL PROTECTED]>

= Sponsors =

== Champion ==

Brian McCallister   <[EMAIL PROTECTED]>

== Nominated Mentors ==

Brian McCallister   <[EMAIL PROTECTED]>
Thomas Dudziak  <[EMAIL PROTECTED]>
Santiago Gala   <[EMAIL PROTECTED]>
Upayavira   <[EMAIL PROTECTED]>

== Sponsoring Entity ==

The Apache Incubator.


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

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

On Nov 9, 2007, at 11:47 AM, Leo Simons wrote:


Can we see a code dump of the stuff you'll be donating?


As soon as possible :-) I am home with a nasty fever today so...  
blech. We should have the ning-specific stuff gutted out by ApacheCon  
at least!


-Brian

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

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Wow, really happy at the positive response.

I'm on my way to ATL in the morning, and am halfway healthy again, so  
will try to pull out some code during hackathon.


-Brian

On Nov 9, 2007, at 10:03 AM, Brian McCallister wrote:


Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.



= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Thomas Baker<[EMAIL PROTECTED]>
   Tim Williamson      <[EMAIL PROTECTED]>
   Brian McCallister   <[EMAIL PROTECTED]>
   Thomas Dudziak  <[EMAIL PROTECTED]>
   Martin Traverso <[EMAIL PROTECTED]>

= Sponsors =

== Champion ==

   Brian McCallister   <[EMAIL PROTECTED]>

== Nominated Mentors ==

   Brian McCallister   <[EMAIL PROTECTED]>
   Thomas Dudziak  <[EMAIL PROTECTED]>
   Santiag

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

On Nov 9, 2007, at 1:34 PM, Sylvain Wallez wrote:


Brian McCallister wrote:

Shindig Proposal


A big +1, and I'd happily be a mentor.


Thank you! We'll take you up on that :-)

-Brian




Sylvain

--
Sylvain Wallez - http://bluxte.net


-
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] Shindig, an OpenSocial Container

[Brian McCallister]

I'll update the proposal for changes from the discussion thus far and  
bing it to a vote ASAP.


Meanwhile, initial (and gnarly, following bad is good for open  
source ;-) seeder code:

http://people.apache.org/~brianm/shindig.tgz

-Brian

On Nov 9, 2007, at 10:03 AM, Brian McCallister wrote:


Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.



= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Thomas Baker<[EMAIL PROTECTED]>
   Tim Williamson      <[EMAIL PROTECTED]>
   Brian McCallister   <[EMAIL PROTECTED]>
   Thomas Dudziak  <[EMAIL PROTECTED]>
   Martin Traverso <[EMAIL PROTECTED]>

= Sponsors =

== Champion ==

   Brian McCallister   <[EMAIL PROTECTED]>

== Nominated Mentors ==

   Brian McCallister   <[EMAIL PROTECTED]>
   Tho

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

Okay, am about to submit a VOTE email with the revised proposal.

There are a couple major changes on the proposal. The biggest is the  
initial contributors and codebase. Google asked to be involved and  
offered to submit the initial implementation, which is a whole lot  
better than the one I pulled out of Ning so I think it is a great  
change. Additionally, folks from Hi5 and MySpace have been added to  
the proposal.


-Brian

On Nov 27, 2007, at 11:40 PM, Otis Gospodnetic wrote:


+1 -- my simpy.com might become a client soon. :)

Otis

--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

- Original Message 
From: Brian McCallister <[EMAIL PROTECTED]>
To: general@incubator.apache.org
Sent: Friday, November 9, 2007 1:03:49 PM
Subject: [PROPOSAL] Shindig, an OpenSocial Container

Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community-
developed
implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resou

[VOTE] Accept Shindig for Incubation

[Brian McCallister]

This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial applications.

= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is a  
high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential consumers
of the project. Remedying this is a large part of why we want to bring  
the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

Andy Smith      (Google)
    Brian McCallister   (Ning)
Brian Stoler(Google)
Cassie Doll (Google)
Dan Bentley (Google)
Dan Farino  (MySpace)
David Glazer(Google)
David Harkness  (Google)
David Sklar (Ning)
Doug Coker  (Google)
Evan Gilbert(Google)
Graham Spencer  (Google)
Jeffrey Regan   (Google)
John Hjelmstad  (Google)
John Panzer (Google)
Jun Yang(Google)
Jussi Myllymaki (Google)
Kevin Brown (Google)
Martin Traverso (Ning)
Paul Lindner(Hi5)
Ramkumar Ramani (Google)
Thoma

Re: [VOTE] Accept Shindig for Incubation

[Brian McCallister]

+1 from me as well :-)

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Andy Smith      (Google)
   Brian McCallister   (Ning)
   Brian Stoler(Google)
   Cassie Doll (Google)
   Dan Bentley (Google)
   Dan Farino  (MySpace)
   David Glazer(Google)
   David Harkness  (Google)
   David Sklar (Ning)
   Doug Coker  (Google)
   Evan Gilbert(Google)
   Graham Spencer  (Google)
   Jeffrey Regan   (Google)
   John Hjelmstad  (Google)
   John Panzer (Google)
   Jun Yang(Google)
   Jussi Myllymaki (Google)
   Kevin Brown (Google)
   Martin Traverso (Ning)
   Paul

[RESULT] [VOTE] Accept Shindig for Incubation

[Brian McCallister]

+1: 25
 0: 1
-1: 0

Looks like it passed! Woo hoo!

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Andy Smith      (Google)
   Brian McCallister   (Ning)
   Brian Stoler(Google)
   Cassie Doll (Google)
   Dan Bentley (Google)
   Dan Farino  (MySpace)
   David Glazer(Google)
   David Harkness  (Google)
   David Sklar (Ning)
   Doug Coker  (Google)
   Evan Gilbert(Google)
   Graham Spencer  (Google)
   Jeffrey Regan   (Google)
   John Hjelmstad  (Google)
   John Panzer (Google)
   Jun Yang(Google)
   Jussi Myllymaki (Google)
   Kevin Brown (Google)
   Martin Travers

Re: [RESULT] [VOTE] Accept Shindig for Incubation

[Brian McCallister]

I've filed infra tickets for Shindig tuff to be set up :-)

On Dec 3, 2007, at 1:33 PM, Brian McCallister wrote:


+1: 25
0: 1
-1: 0

Looks like it passed! Woo hoo!

On Nov 28, 2007, at 4:59 PM, Brian McCallister wrote:


This vote will run until Monday, Dec. 3, 2007.

[ ] +1 Accept Shindig for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


= Abstract =

Shindig will develop a container and backend server components for
hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.


= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig will provide implementations of an emerging set of APIs
for client-side composited web applications. The Apache Software
Foundation has proven to have developed a strong system and set of
mores for building community-centric, open standards based systems
with a wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an  
excellent

implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.

The Shindig OpenSocial implementation will be able to serve as
a reference implementation of the standard.

= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.

= Core Developers =

The initial set of committers includes folks from several commercial
OpenSocial container providers, including Ning, Google, Hi5, and
MySpace. We have varying degrees of experience with Apache-style
open source development, ranging from none to ASF Members.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial set of developers is diverse, but are all employed by  
OpenSocial
container providers. Building a more diverse developer community is  
a high

priority for this project.

== Reliance on Salaried Developers ==

The initial group of developers are all employed by potential  
consumers
of the project. Remedying this is a large part of why we want to  
bring the

project to Apache.

== Relationships with Other Apache Products ==

None in particular.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
  http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
  http://tinyurl.com/3y5ckx

= Initial Source =

The initial source will consist of the Javascript container and a
Java based backend providing services to the container. The source
is being contributed by Google, and will be by a code grant.

= External Dependencies =

The initial code relies on PHP and the jQuery library.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

  Andy Smith  (Google)
  Brian McCallister   (Ning)
  Brian Stoler(Google)
  Cassie Doll (Google)
  Dan Bentley (Google)
  Dan Farino  (MySpace)
  David Glazer(Google)
  David Harkness  (Google)
  David Sklar (Ning)
  Doug Coker  (Google)
  Evan Gilbert(Google)
  Graham Spencer  (Google)
  Jeffrey Regan   (Google)
  John Hjelmstad  (Google)
  John Panzer (Google)
  Ju

Re: [DISCUSS] CouchDB incubator project

[Brian McCallister]

+1 -- I am very excited to see this and think it will be good for CouchDB.

-Brian

On Thu, Jan 31, 2008 at 7:40 AM, Sam Ruby <[EMAIL PROTECTED]> wrote:

> The original source for this proposal can be found at
>
> http://www.couchdbwiki.com/index.php?title=Apache_Incubator_Proposal
>
> and a current snapshot is attached below.  Once we have established that
> there is interest, my plan is to move this content over to
> wiki.apache.org/incubator as a [PROPOSAL].
>
> I've been watching CouchDB since September, and believe that it would
> fit well in the ASF.  My preference is that it exits as a top level
> project, mainly due to my experience with umbrella PMCs, but I would
> otherwise not be adverse to it joining the DB project.  We certainly do
> not need to decide this now.
>
> - Sam Ruby
>
> Project Name: CouchDB
> -
>
> ==Proposal==
> The goal is to create either an Apache top level project, or a db
> subproject, around the existing CouchDB open source project.
>
> Key Features:
> * a REST API using JSON for data transport,
> * a JavaScript view engine based on Mozilla Spidermonkey,
> * a GNU Autotools build system supporting most POSIX systems
> * a built-in administration interface
> * experimental fulltext search with Lucene
>
> ===Rationale===
> The goals of the project are aligned with the goals of the ASF, namely
> there is interest in (continuing to) foster a collaborative, consensus
> based development process, using an open and pragmatic software license,
> and a desire to create high quality software that leads the way in its
> field.
>
> ===Initial goals===
> * Features for next release
> **  Incremental reduce support, for full map/reduce support.
> ** Document validation model (validate live and replicated changes)
> ** Documentation, Documentation, Documentation
> ** Fulltext Search
> * Priority feature work
> ** Live compaction
> ** Extensible security model
> ** LDAP authentication
> ** More query capabilities exposed to HTTP, e.g. multi-key view lookups
> * Future feature work
> ** Server storage partioning
> ** Server failover clustering
> * Requested Features
> ** hierarchical structure in documents
>
> ==Current Status==
>
> ===Meritocracy===
> The project has recently transformed from being primarily a single
> person led (and funded) project to one with a number of diverse
> participants.  Development has been coordinated primarily through a
> mailing list, with some IRC.
>
> ===Community===
> The community consists of a set of independent developers, one of which
> recently joined IBM
>
> ===Initial Developers===
> * William Beh
> * Damien Katz
> * Jan Lehnardt
> * Christopher Lenz
> * Dirk Schalge
> * Noah Slater
>
> ===Alignment===
> A database server with a strong focus on HTTP and REST principles.
>
> ===Known Risks===
> * Dependency on Erlang
> ** Including some modifications to the HTTP server stack.  The plan is
> to convert over to [http://code.google.com/p/mochiweb/ MochiWeb] (MIT
> licenced)
> * Dependency on Mozilla SpiderMonkey
> ** Including small modifications, to be sent back to Mozilla
>
> ===Orphaned Products===
> * This is a new effort, and is far from being orphaned.
>
> ===Inexperience with Open Source===
> All participants are active users and contributors to open source. One
> of them (Christopher Lenz) has experience as committer on other Apache
> projects.
>
> ===Homogenous Developers===
> The exiting committers are spread over a number of countries and
> employers.
>
> ===Reliance on Salaried Developers===
> Only one developer is being paid to work on CouchDB.  Read
> [http://damienkatz.net/2008/01/faq_about_couch.html his views] on the
> relationship he has with his employer.
>
> ===Relationships with Other Apache Products===
> Experimental usage of Lucene
>
> ===An excessive fascination with the Apache brand===
> This product started out independent of Apache and under a GPL license.
>  After discussions with a number of people within IBM, Damien Katz
> agreed to pursue both incubation at the ASF, and employment at IBM
>
> ==Documentation==
>
> ===Initial Source===
> Resides on [http://code.google.com/p/couchdb/ Google Code].  The code
> has been recently relicensed from GPL to the Apache License, Version
> 2.0, in anticipation of this submission.
>
> ===Source and Intellectual Property Submission Plan===
> The bulk of the core code was written by Damien Katz.  Major
> contributions include: a GNU Autotools build system supporting most
> POSIX systems contributed by Noah Slater,  a built-in administration
> interface provided by Christopher Lenz, and experimental fulltext search
> with Lucene by Jan Lehnardt.  ICLAs either have been, or are in the
> process of being, submitted for all code involved in this submission.
>
> ICLA's are already on file for:
> * Jan Lehnardt
> * Christopher Lenz
> ICLA's in progress:
> * William Beh
> * Damien Katz
> * Dirk Schalge
> * Noah Slater
>
> There are a few (as in single digit) number of 

Re: [VOTE] as to Thrift Proposal

[Brian McCallister]

+1

-Brian

On Thu, Feb 7, 2008 at 5:59 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:

> > On Jan 23, 2008 9:07 PM, Mark Slee <[EMAIL PROTECTED]> wrote:
> > > We've just posted the Apache Incubator proposal for Thrift onto the
> > > Wiki:
> > > http://wiki.apache.org/incubator/ThriftProposal
>
> +1
>
> -Yonik
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [VOTE] Accept CouchDB for incubation

[Brian McCallister]

+1

On Sat, Feb 9, 2008 at 8:09 AM, Sam Ruby <[EMAIL PROTECTED]> wrote:

> We've had an initial discussion, which attracted a number of messages
> of encouragement, and identified no issues or concerns.  Then we
> proceeded onto a proposal, which attracted three excellent mentors.
> Now it is time to vote on the proposal which can be found on the
> Apache Wiki, and reproduced below.
>
> I would like to proudly start this off with my +1.
>
> - Sam Ruby
>
> http://wiki.apache.org/incubator/CouchDBProposal
>
>
>