Disregard Re: Undermining the Incubator

["Andrew C. Oliver" <ac...@apache.org>]

The Send button is near the close button.  I missed.
-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?

The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.

> From: "Andrew C. Oliver" <ac...@apache.org>
> Reply-To: community@apache.org
> Date: Tue, 13 Jan 2004 01:34:55 -0500
> To: "community@apache.org" <co...@apache.org>
> Subject: Re: Undermining the Incubator
> 
> In summary:  Oh of course no problems exist, its all fixed and happy.  Just
> don't mind the dead bodies floating in the pond.
> -- 
> Andrew C. Oliver
> http://www.superlinksoftware.com/poi.jsp
> Custom enhancements and Commercial Implementation for Jakarta POI
> 
> http://jakarta.apache.org/poi
> For Java and Excel, Got POI?
> 
> The views expressed in this email are those of the author and are almost
> definitely not shared by the Apache Software Foundation, its board or its
> general membership.  In fact they probably most definitively disagree with
> everything espoused in the above email.
> 
>> From: "Noel J. Bergman" <no...@devtech.com>
>> Reply-To: community@apache.org
>> Date: Mon, 12 Jan 2004 23:21:50 -0500
>> To: <co...@apache.org>
>> Subject: RE: Undermining the Incubator
>> 
>> Andrew C. Oliver wrote:
>> 
>>> I suggested that Blojsom might be a good choice for hosting ASF
>>> project news and might also make a great ASF project as I know
>>> the author is already indoctrinated
>> 
>>> I didn't say it would be a good project for the incubator.
>> 
>> The Incubator is how projects get into the ASF.
>> 
>>> I think the incubator is the #1 worst problem of the ASF presently.
>> 
>> Two things reduce the effect of your statement:
>> 
>> 1. The fact that your complaints demonstrate a lack
>>   of awareness regarding the current Incubator.
>> 
>> 2. The fact that your proposal essentially outlines
>>   how the Incubator *does* work.
>> 
>> We'll get to the latter shortly, but first ...
>> 
>> The Incubator exists for the purpose of importing codebases and projects
>> into the ASF.  There are basically three cases:
>> 
>> (a) an externally developed codebase intended to go into an existing
>> project
>> (b) an externally developed codebase intented to become a project within a
>> PMC
>> (c) an externally developed codebase intended to be a new TLP
>> 
>> In the case of the (a), we need to clear the IP.  The Incubator STATUS file
>> provides an outline and diary for doing so.  The Community issues are
>> addressed because the code is going into an existing project.
>> 
>> In the case of (b), we need to clear the IP, and ensure that the project has
>> a viable community.  Again, the STATUS file has the guidelines.
>> 
>> Lastly, in the case of (c), we need to clear the IP, ensure that the project
>> has a viable community, and that the community is ready to take its place as
>> a TLP.
>> 
>> In all cases, decisions are made by a group made up of the Incubator PMC,
>> the project's committers, and the destination PMC (if any), and known as the
>> PPMC.  That is one group directly empowered to manage that project's
>> decisions, reporting through the Incubator, and collaborating together as
>> peers.  When the PPMC decides that the project is good to graduate, based
>> upon fulfilling the necessary criteria, it is done.
>> 
>> Now, since I know that you had a bad experience with the old form of the
>> Incubator, let's first address your complaints compared to the way things
>> work now.
>> 
>>> It doesn't legally protect the ASF.
>> 
>> The Incubator ensures that the proper paperwork is done regarding CLAs, code
>> grants, etc., are filed.  Something that the other projects failed to do
>> consistently enough to result in the Incubator's formation.  Ideally, the
>> Incubator provides a focus and location, and the project(s) interested in
>> the code perform the due diligance, but the process ensures that it gets
>> done.
>> 
>>> * Exposes the Foundation to undue legal issues by protecting projects
>> PRIOR
>>>   to their legal issues being sorted out.
>> 
>> As opposed, for example, to exposing the Foundation to undue legal issues
>> when projects import codebases directly into releases without permission
>> from either the Foundation or the author?  That is one of the things the
>> Incubator exists to prevent.
>> 
>> In any event, only the Board should, and can, talk authoritatively about
>> legal protection afforded by the ASF.
>> 
>>> * Has a high potential to create a dead project zone over time (but this I
>>>   guess we'll see) as we give hosting and a fuzzy idea with many different
>>>   opinions on when a project gets out or not.
>> 
>> In actuality, one purpose of the Incubator is to help prevent non-viable
>> projects from becoming ASF projects, and to help projects become viable,
>> when possible.
>> 
>> We have a pretty good opinion as to when a project "gets out or not."  It is
>> embodied in the STATUS document, and in the minds of the PPMC, which would
>> vote for the project to graduate.
>> 
>>> * Has a number of people not involved in the project sitting roost over
>> the
>>>   project.
>> 
>> The Incubator doesn't work that way.  The people involved in the project are
>> directly involved in the project's management.  Ask the members of the Spam
>> Assassin PPMC, the Geronimo PPMC or the Directory project whether or not
>> there are "a number of people not involved with the project sitting roost"
>> over them.
>> 
>>> * Hurts already healthy communities by putting them back into an alphaish
>>>   state.
>> 
>> Healthy communities with clean codebases are not intended to stay within the
>> Incubator.  Projects in the Incubator are there because they have not yet
>> been able to complete the STATUS file successfully.  Whatever reasons exist
>> for them to be in the Incubator are those that a potential user should know.
>> 
>>> * Creates confusion.  Most people will believe the project is an Apache
>>>   project at the point of incubation.
>> 
>> Which is it?  Confusion that the project is an ASF project, or provides some
>> sort of indicator that the project is in a particular state?
>> 
>>> It doesn't protect the users
>> 
>> Incubation status indicates that a project is not yet an official ASF
>> project, and may have IP issues and/or community issues that could effect
>> its viability and suitability.
>> 
>>> is a big fat bureaucratic mess where the disinterested/uninvolved
>>> sit roost over the project.
>> 
>> The Incubator process is about as direct as it gets, without bureaucracy.
>> Each project has a STATUS file listing acting as a combination checklist and
>> fill-in-the-blanks project diary.  The form needs to be filled out.  If
>> everything is OK, the project is good to go.  If there are issues that need
>> to be addressed, the PPMC collaborates to resolve them.
>> 
>> So now let's look at your proposed solution, which you feel:
>> 
>>> * Protects the foundation
>>> * Makes the responsible people responsible and less "help"
>>>   from the peanut gallery.
>>> * Gives the "acceptance" to the project and the people
>>>   accepting it.  No more tricameral votes.
>> 
>> You propose that:
>> 
>>> * A project must have at least sponsoring MEMBER willing to go join the
>>>   project and help them adopt the voting rules, document legal issues by
>>>   performing an audit
>> 
>> We call such people Mentors.  They are members of the project's PPMC, and
>> participate as peers on that collaborative body to direct oversight of the
>> project.  You know: the way an ASF project is supposed to work.
>> 
>> The primary difference between your proposal and reality is that we don't
>> require every Mentor to be a Member.
>> 
>>> * A project's acceptance is governed by a PMC accepting it or the members
>>>   voting to create a TLP.  This should be ratified by the board who should
>>>   have veto power.
>> 
>> Projects are accepted into the Incubator based upon the vote of a PMC:
>> either a PMC that wants to oversee the project upon exit, or the Incubator
>> PMC on request of an ASF Member or Officer.  The Board does have to vote to
>> create a TLP in the event of such a project exiting.
>> 
>> The primary difference between your proposal and reality is that the Board
>> is empowered to create a TLP.
>> 
>>> * To propose the vote a project must prove that all CLAs are turned
>>> in and a license audit has been performed under the supervision of
>>> the said sponsoring member/members.
>> 
>> Correct.  All of which are in that STATUS file.
>> 
>> The primary difference between your proposal and reality is that the PPMC is
>> the body vested with supervisory responsibility, not an individual, which is
>> a legal issue.
>> 
>>> * prior to the project's acceptance into Apache it has no Apache status
>>> (legal/otherwise).  I suppose we could give it a candidate logo.
>> 
>> You mean like http://incubator.apache.org/images/apache-incubator-logo.png?
>> 
>>> I would warn any prospective project what it faces with the incubator
>> 
>> It seems to me that since the Incubator is essentially what you propose, all
>> you are doing is damaging the ability of the Foundation to grow by
>> needlessly poisoning projects against entry.
>> 
>>> I will continue to speak my mind publicly about things that I see as
>> wrong,
>>> broken or incorrect
>> 
>>> When will I stop?  When they are fixed.
>> 
>> Based upon comparing the Incubator with your own proposal for it, it is
>> evident that the Incubator was fixed.  Things did change.
>> 
>> --- Noel
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: community-unsubscribe@apache.org
>> For additional commands, e-mail: community-help@apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
> 


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

Re: Disregard Re: Undermining the Incubator

[Tetsuya Kitahata <te...@nifty.com>]

On Tue, 13 Jan 2004 22:22:17 +0100
Santiago Gala Pérez wrote:
> William A. Rowe, Jr. wrote:
> (...)
> | Many of us rant in email, delete, then recompose with some decorum.
> | Since many things that are discussed in community involve strongly held
> | personal opinions and beliefs, this safety measure ensures that
> intelligent
> | dialogs can be pursued and the best course of action followed.
> In this very spirit, 8 hours ago I was about to suggest Andy to put his
> outbox in a moderation queue, but then I thought my message was too
> harsh and I refrained from sending it...

Oh, great. Nifty. By the way, maybe I could *invent* new medicine
(patch form) which aids mitigation of the "withdrawal symptoms" of
such *writing impulse* effectively
-- USAGE: apply one patch which is effective 16 hours a day --

However, I am afraid I can not export it to the place where Andy
lives in, because the ministry of health and welfare in japan is banning
me from doing it or due to the failure of the delivery system.
I could import nicotine patch from new zealand, though.
... Very sad ...

;-)

-- Tetsuya. (tetsuya@apache.org)


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

Re: Disregard Re: Undermining the Incubator

[Santiago Gala Pérez <sg...@hisitech.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William A. Rowe, Jr. wrote:
(...)
| Many of us rant in email, delete, then recompose with some decorum.
| Since many things that are discussed in community involve strongly held
| personal opinions and beliefs, this safety measure ensures that
intelligent
| dialogs can be pursued and the best course of action followed.
|

In this very spirit, 8 hours ago I was about to suggest Andy to put his
outbox in a moderation queue, but then I thought my message was too
harsh and I refrained from sending it...

;-)

| Bill

Regards,
~     Santiago
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFABGGIZAeG2a2/nhoRAmKEAKDo5GNWeHw+37joT60c3e1EM1A+CQCcC1a1
j6ozIRgj0Re4jFQmV7iadFs=
=zn7N
-----END PGP SIGNATURE-----

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

Re: Disregard Re: Undermining the Incubator

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

At 12:36 AM 1/13/2004, Andrew C. Oliver wrote:
>The Send button is near the close button.  I missed.

Suggestion from an httpd/apr hothead to our community forum participants
[NOT specifically ACO]...

"Delay sending messages: [30] (minutes)"

is a really great option to enable, well worth the effort to enable.
I can't think of a modern email client that doesn't offer the feature.

Many of us rant in email, delete, then recompose with some decorum.
Since many things that are discussed in community involve strongly held
personal opinions and beliefs, this safety measure ensures that intelligent
dialogs can be pursued and the best course of action followed.

Bill  


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