Re: projects incubated by the incubator PMC

[Leo Simons]

Jason van Zyl wrote:

What's going to happen with AltRMI and the FtpServer? They just sit in
the incubator indefinitely? There's no IP issues as these came from
within Apache anyway? If an incubated codebase has no slated home within
then I would ask how it even landed here in the first place?
Both AltRMI and FtpServer started inside avalon, ie

Apache Jakarta Avalon Excalibur AltRMI and
Apache Jakarta Avalon Applications FtpServer
it was decided at some point that avalon had too much code that did not
really 'fit', and we endevoured to figure out what to do with it. Some of
it went to jakarta-commons, some of it went to be (part of) a sourceforge
project, some was simply removed. With AltRMI and FtpServer, the
feeling was that they were good codebases that would make fine projects
inside apache.
Since, at that time, avalon couldn't quite figure out where these two
should go, that decision was delegated to the Incubator.
All of this happened before rigid thoughts about the incubator process
were formed. If these project were to come in now, I am sure that we
would have tried to answer some of these questions earlier.
That was background. So where do they go now? Well, allthough it
has not been discussed much, I think the general plan has been 'wait
and see how these develop, and make the decision later'. The point
about later not transforming into 'indefinitely' is a good one, but I
think something like a '6-month rule' is not a good plan. Individual
cases need individual attention. If that wasn't the case, we could just
automate the process.
I think its a good idea to start a discussion about what we want to do
with AltRMI and FtpServer, but guys, could we please do so in a bit
less of an 'argument mode' and more of a 'problem solver' mode?
My point in raising this discussion is to focus on Ruper as it's a small
tool with no final landing destination as far as I can tell. I wasn't
paying attention to lists, was away for a few days and came back to see
it being mentored/helped by the Incubator itself.
I voted +1 making the silly assumption that a destination was required. 

To my knowledge Nicola has made attempts to have projects like
Centipede, Ruper be absorbed into Apache via Ant and those haven't been
successful so I am assuming that's probably still the case (someone feel
free to correct me if I'm wrong). Adam Jack contacted me personally just
to shoot the shit about Ruper and I told him his code would be welcome
in Maven.
If the code has no final destination then I am a very strong -1 to the
code being accepted.
why? Fear of becoming another sourceforge? Fear of dead codebases?
The former will not happen if the Incubator does its job (which should be
assumed :D), the latter is very easily remedied.
- LSD



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

Re: projects incubated by the incubator PMC

[Rodney Waldhoff]

On Sun, 7 Dec 2003, Roy T. Fielding wrote:

> There is no reason for a project to have a final destination until
> it has to go somewhere other than incubator, at which point it can
> decide whether it wants to be a TLP (calling for a board vote) or
> part of an existing project (calling for that project's pmc to vote).

The language and policy regarding sponsors in
 and
others, while not directly contradicting that statement, certainly seems
to encourage the opposite.

If the intention is to generally decide at the point of graduation whether
a project is a TLP or a part of an exsiting project rather than at the
time of initiation, then I think the language of policy/guidelines should
be revised.  The current language regarding sponsors makes it sound like
"lazy destination selection" is the exception rather than the rule.

> Maybe we should have a six month limit on incubation, where the
> result is promote or punt.
>
> We have no way to measure the worthiness of a project before it has
> even started, and generally speaking we are MUCH MUCH MUCH better off
> if a project gets started in Apache rather than on sourceforge.
>
> I don't care if there is some overlap with Wagon, nor do I care for
> any further discussion about which one is better -- if I can't find
> some objective criteria for evaluating software, then I obviously
> don't need that software. Once I need it, I can figure out for myself
> which one is better -- I don't need someone to assume that for me.
> It is easier for Apache to support both projects than to arbitrarily
> choose between the two.
>
> Roy
>

-- 
- Rod 

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

Re: projects incubated by the incubator PMC

[Jason van Zyl]

On Mon, 2003-12-08 at 18:07, Rodney Waldhoff wrote:
> On Sun, 7 Dec 2003, Roy T. Fielding wrote:
> 
> > There is no reason for a project to have a final destination until
> > it has to go somewhere other than incubator, at which point it can
> > decide whether it wants to be a TLP (calling for a board vote) or
> > part of an existing project (calling for that project's pmc to vote).
> 
> The language and policy regarding sponsors in
>  and
> others, while not directly contradicting that statement, certainly seems
> to encourage the opposite.
> 
> If the intention is to generally decide at the point of graduation whether
> a project is a TLP or a part of an exsiting project rather than at the
> time of initiation, then I think the language of policy/guidelines should
> be revised.  The current language regarding sponsors makes it sound like
> "lazy destination selection" is the exception rather than the rule.

I also don't think it's really that much work on the behalf of a project
trying to enter Apache to do a little leg work in resolving that before
entering. 

Clearly there should be some interest within Apache for the code to be
accepted. Either at the board level where things like Geronimo and Eve
have been discussed where upon successful incubation the project moves
to its designated TLP location. The other case being where some contact
has been made with one of the TLPs to accept the code upon successful
incubation.

I would propose those documents be changed to state that what is
outlined above is a prerequisite for entry into the incubator.

Is this something that requires a member vote as it affects everyone
here because the production of useful software is what we're doing here
at Apache so I think all members should have a say WRT to software
entering Apache.

Projects should not come here without having contacted the board (in the
case of a TLP proposal) or a TLP. Any other case should be unacceptable.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: projects incubated by the incubator PMC

[Roy T. Fielding]

I also don't think it's really that much work on the behalf of a 
project
trying to enter Apache to do a little leg work in resolving that before
entering.
I didn't say they shouldn't try -- I said it wasn't necessary.
As far as I am concerned, no existing project should be allowed
to create autonomous subprojects.  That means code which is not
destined for an existing project needs a temporary home until such
a time when the board feels it is ready to be autonomous.  Hence,
incubator was created to be a halfway house in addition to documenting
the transition of IP.
Clearly there should be some interest within Apache for the code to be
accepted. Either at the board level where things like Geronimo and Eve
have been discussed where upon successful incubation the project moves
to its designated TLP location. The other case being where some contact
has been made with one of the TLPs to accept the code upon successful
incubation.
It already requires participation of a member and a vote within the
incubator PMC, which is supposed to consist of all of the Apache members
who are interested in new project incubation.  The board tries to avoid
making technical decisions on behalf of the members.
I would propose those documents be changed to state that what is
outlined above is a prerequisite for entry into the incubator.
-1.  If the TLPs were supposed to be divisions of technology then
Maven would not be a TLP.  The only thing that distinguishes a TLP
from a piece of code adrift in cyberspace is that there exists a set
of people capable of governing themselves while collaborating on
development of that code.  Once that point is reached, the project
should be released from whatever bounds it happens to be within.
Your suggestion would require the board to do what it has already
assigned to the incubator, which the board specifically decided to
delegate in order to get more members interested in the process.
Roy

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

Re: projects incubated by the incubator PMC

[Jason van Zyl]

On Mon, 2003-12-08 at 20:43, Roy T. Fielding wrote:
> > I also don't think it's really that much work on the behalf of a 
> > project
> > trying to enter Apache to do a little leg work in resolving that before
> > entering.
> 
> I didn't say they shouldn't try -- I said it wasn't necessary.
> As far as I am concerned, no existing project should be allowed
> to create autonomous subprojects.  That means code which is not
> destined for an existing project needs a temporary home until such
> a time when the board feels it is ready to be autonomous.  Hence,
> incubator was created to be a halfway house in addition to documenting
> the transition of IP.
> 
> > Clearly there should be some interest within Apache for the code to be
> > accepted. Either at the board level where things like Geronimo and Eve
> > have been discussed where upon successful incubation the project moves
> > to its designated TLP location. The other case being where some contact
> > has been made with one of the TLPs to accept the code upon successful
> > incubation.
> 
> It already requires participation of a member and a vote within the
> incubator PMC, which is supposed to consist of all of the Apache members
> who are interested in new project incubation.  The board tries to avoid
> making technical decisions on behalf of the members.
> 
> > I would propose those documents be changed to state that what is
> > outlined above is a prerequisite for entry into the incubator.
> 
> -1.  

So you can veto a vote I would propose to members I feel is in the best
interest of preserving the integrity of the software here. Why can't the
members decide? I find it ridiculous that a body of code can land here
with absolutely no direction.

I'll I'm asking for is that projects that arrive here state there intent
which includes where they want to live in the Apache landscape. Is that
unreasonable?

In the past when the incubator didn't exist when new bodies of code came
in they became entities like xml.apache.org, jakarta.apache.org or fell
under one of those TLPs. Why should it be any different now? The only
thing the incubator should do is the IP verification and "community"
check.

> If the TLPs were supposed to be divisions of technology then
> Maven would not be a TLP.  

How does this relate at all to the discussion? But if the Incubator was
around when Maven split out of Turbine we would have asked for TLP and
it would have been clear. Sorry, but I fail to see the point you're
trying to raise using Maven as an example.

> The only thing that distinguishes a TLP
> from a piece of code adrift in cyberspace is that there exists a set
> of people capable of governing themselves while collaborating on
> development of that code.  Once that point is reached, the project
> should be released from whatever bounds it happens to be within.

What does that mean exactly? That Apache shall simply become a directory
of projects whereby the only requirement is successful incubation? If so
I think that definitely requires a vote because as a member that's not
what I see Apache being.

> Your suggestion would require the board to do what it has already
> assigned to the incubator, which the board specifically decided to
> delegate in order to get more members interested in the process.

My suggestion is simply to make it requisite that an incoming project
delcare a destination. How does that alter the roles anyone is playing
in the incubator as far as involvement and oversight.

Additionally, as pointed out by Rodney, what's documented is more akin
to what I'm saying than what you're saying if I read you correctly
vis-a-vis the free wheeling directory of projects.

> Roy
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: Apache Gallery Project

[Jay Zylstra]

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]

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: Apache Gallery Project

[Noel J. Bergman]

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

The only place at Apache where I believe that this would make sense is
Apache Commons.  You might post to [EMAIL PROTECTED], and see the
level of interest.  If not, you could try codehaus.  Contact Bob
([EMAIL PROTECTED]).

--- Noel


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

RE: projects incubated by the incubator PMC

[Noel J. Bergman]

> > > I would propose those documents be changed to state that what is
> > > outlined above is a prerequisite for entry into the incubator.
> > -1.

> So you can veto a vote I would propose to members I feel is in the best
> interest of preserving the integrity of the software here.

Where did you see a veto?  A -1 is a veto on code, not P&P.

> I find it ridiculous that a body of code can land here
> with absolutely no direction.

I accept that as your view.  I disagree with you, but I accept your opinion
as yours.

> In the past when the incubator didn't exist when new bodies of code came
> in they became entities like xml.apache.org, jakarta.apache.org or fell
> under one of those TLPs.  Why should it be any different now?

For the reasons that brought the Incubator into existence.

> Apache shall simply become a directory of projects whereby the
> only requirement is successful incubation?  If so I think that
> definitely requires a vote because as a member that's not what
> I see Apache being.

Well, first of all, successful incubation isn't nothing.  It means that the
project *started* with a Member or Officer sponsoring it, and the Incubator
PMC voting to give it a chance.  And then it was able to attract a
sustainable community, and operate according to Apache principles.  But you
are implying that you have a particular vision for the ASF.  What is that?

--- Noel


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

RE: projects incubated by the incubator PMC

[Jason van Zyl]

On Mon, 2003-12-08 at 22:37, Noel J. Bergman wrote:
> > > > I would propose those documents be changed to state that what is
> > > > outlined above is a prerequisite for entry into the incubator.
> > > -1.
> 
> > So you can veto a vote I would propose to members I feel is in the best
> > interest of preserving the integrity of the software here.
> 
> Where did you see a veto?  A -1 is a veto on code, not P&P.
> 
> > I find it ridiculous that a body of code can land here
> > with absolutely no direction.
> 
> I accept that as your view.  I disagree with you, but I accept your opinion
> as yours.
> 
> > In the past when the incubator didn't exist when new bodies of code came
> > in they became entities like xml.apache.org, jakarta.apache.org or fell
> > under one of those TLPs.  Why should it be any different now?
> 
> For the reasons that brought the Incubator into existence.

What's that in a sentence or less?

The site says to provide an entry path into Apache like there never was
one before. I am responsible for bringing BCEL, XmlRpc, OJB and various
bits and bobs in the commons. All of those were because the people
working on these projects were resourceful enough to find someone to
champion their entry into Apache. I'm sure most people see Apache as
fairly incestuous but people could always get projects here if they
tried. I didn't know anyone on any of those projects before hand so it
wasn't nepetism that got them landed here at Apache.

You speak as if there was no possible way to get into Apache before the
Incubator. Maybe for those who wanted a free lunch ticket but not for
anyone else.

> > Apache shall simply become a directory of projects whereby the
> > only requirement is successful incubation?  If so I think that
> > definitely requires a vote because as a member that's not what
> > I see Apache being.
> 
> Well, first of all, successful incubation isn't nothing.  

I didn't say it was nothing I am insisting that the incubation process
include the specification of a final destination whether as a TLP or
within an existing TLP to prevent the Incubator from becoming
ApacheForge which is something I would prefer not to see.

> It means that the
> project *started* with a Member or Officer sponsoring it, and the Incubator
> PMC voting to give it a chance.  And then it was able to attract a
> sustainable community, and operate according to Apache principles.  But you
> are implying that you have a particular vision for the ASF.  What is that?

How is what I personally see Apache as relevant to my requesting a very
simple thing of requiring a desired destination within Apache as part of
the Incubation process.

I don't see why this as seen as such a burdensome piece of information
to provide.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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