Discussion:
Disclaimer text for incubated projects
(too old to reply)
Cliff Schmidt
2003-10-01 16:25:01 UTC
Permalink
After getting positive feedback from this list about the idea of allowing
incubated projects to publish binary releases as long as they clearly
identified them as being part of an incubated project, I've written the
following paragraph to be used on the web site and inside the README
file (in addition to using "incubated" in the file name of the download):

"XMLBeans is an incubated subproject under the sponsorship of the Apache
Software Foundation's (ASF) XML project. Incubation is required of all
newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the
completeness or stability of the code, it does indicate that the project
has yet to be fully endorsed by the ASF."

Please let me know if there are any suggestions or concerns about this
text; otherwise, I'll move forward with it.

Thanks,
Cliff
Rodent of Unusual Size
2003-10-01 16:47:50 UTC
Permalink
Post by Cliff Schmidt
"XMLBeans is an incubated subproject under the sponsorship of the Apache
Software Foundation's (ASF) XML project.
it all looks good, except for this. i think i would prefer something
like

'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'

the original uses the past tense and the semantically semi-null
term 'subproject'.

just mho.
--
#ken P-)}

Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/

"Millennium hand and shrimp!"
Erik Abele
2003-10-01 17:26:55 UTC
Permalink
Post by Rodent of Unusual Size
Post by Cliff Schmidt
"XMLBeans is an incubated subproject under the sponsorship of the Apache
Software Foundation's (ASF) XML project.
it all looks good, except for this. i think i would prefer something
like
'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'
Definitely better. +1 to the rest.

Cheers,
Erik
Greg Stein
2003-10-03 11:00:36 UTC
Permalink
Post by Rodent of Unusual Size
Post by Cliff Schmidt
"XMLBeans is an incubated subproject under the sponsorship of the Apache
Software Foundation's (ASF) XML project.
it all looks good, except for this. i think i would prefer something
like
'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'
the original uses the past tense and the semantically semi-null
term 'subproject'.
All good.

Note that wsrp4j *STILL* needs to mention they are an incubated project on
their web pages. There isn't any kind of a mention, let alone some kind of
normative text.

I raised this two weeks ago, yet I see no motion to fix it. Personally,
that makes me want to go and rip down the project's web pages. I would
*seriously* recommend that wsrp4j people fix those pages. ASAP. The
project's arrival in the Incubator is suspect enough, so I'm not really
all that willing to give it slack. Fix it or it gets yanked.

-g
--
Greg Stein, http://www.lyra.org/
Tetsuya Kitahata
2003-10-03 11:38:40 UTC
Permalink
(CC: ***@ws.apache.org)

It seems that the same goes for the JaxMe, too.

Anyway, please take a glance at
http://ws.apache.org/
... <note> section.

Regards,

-- Tetsuya. (***@apache.org)

On Fri, 3 Oct 2003 04:00:36 -0700
(Subject: Re: Disclaimer text for incubated projects)
Post by Greg Stein
Post by Rodent of Unusual Size
Post by Cliff Schmidt
"XMLBeans is an incubated subproject under the sponsorship of the Apache
Software Foundation's (ASF) XML project.
it all looks good, except for this. i think i would prefer something
like
'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'
the original uses the past tense and the semantically semi-null
term 'subproject'.
All good.
Note that wsrp4j *STILL* needs to mention they are an incubated project on
their web pages. There isn't any kind of a mention, let alone some kind of
normative text.
I raised this two weeks ago, yet I see no motion to fix it. Personally,
that makes me want to go and rip down the project's web pages. I would
*seriously* recommend that wsrp4j people fix those pages. ASAP. The
project's arrival in the Incubator is suspect enough, so I'm not really
all that willing to give it slack. Fix it or it gets yanked.
-g
--
Greg Stein, http://www.lyra.org/
-----------------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: ***@apache.org http://www.terra-intl.com/
Greg Stein
2003-10-03 11:39:00 UTC
Permalink
Post by Tetsuya Kitahata
It seems that the same goes for the JaxMe, too.
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
That <note> section has zero bearing on the wsrp4j pages themselves. I hit
those pages via a link, not the top-level. In the Age of Google, it is
relatively rare to navigate through a menu.

Oh, geez. JaxMe has no notice on its pages either.

To what document do I need to add rule that says "a project ABSOLUTELY
MUST make clear that it is under incubation?" We've already been through
this process where incubated projects are not being clear about their
status; that needs to be captured and retained for ALL incubated projects.

But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.

-g
--
Greg Stein, http://www.lyra.org/
Tetsuya Kitahata
2003-10-03 12:10:58 UTC
Permalink
(CC: ***@ws.apache.org)

On Fri, 3 Oct 2003 04:39:00 -0700
Post by Greg Stein
Post by Tetsuya Kitahata
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
<snip/>
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
Aha, Okay. I think that the folks in wsrp4j just did not know how
to do. It happens all the time. People should not blame ones' ignorance.
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
# This is "INCUBATION" project, not "GOLEM" project ;-)

--

JaxMe folks, wsrp4j folks,

Could it be possible for you to append "Disclaimer" page and left-side
navi for such a page to each pages?

JaxMe: create disclaimer.xml (alike to other xml files) and put it
into xdocs/ directory.
Then, edit xdocs/stylesheet/project.xml (LEFT-SIDE NAVI)
and re-build the site.
WSRP4J: create disclaimer.xml (alike to other xml files) and put it
into src/documentation/content/xdocs/ directory.
Then, edit src/documentation/content/xdocs/site.xml
(LEFT-SIDE NAVI) and re-build the site.

NOTE:
Both "built" files should be put onto the "ws-site" module
(*targets*/XX/ directory)

Editing "index.html/xml" would be also highly appreciated, I think.

You can make use of the sentence shown at "<note> section":
http://ws.apache.org/

Hope this helps.


-- Tetsuya. (***@apache.org)
Nicola Ken Barozzi
2003-10-03 12:19:50 UTC
Permalink
Greg Stein wrote:

...
Post by Greg Stein
To what document do I need to add rule that says "a project ABSOLUTELY
MUST make clear that it is under incubation?"
If we kept all incubated projects under the incubator it would have been
clear enough.
Post by Greg Stein
We've already been through
this process where incubated projects are not being clear about their
status; that needs to be captured and retained for ALL incubated projects.
Proposal: if we still don't want to make incubator-xxx repositories for
these files, I would still suggest that:

1 - the websites are placed in
incubator.apache.org/projects/subproject
2 - these projects have as project logo the Incubator Logo
3 - They all have as a bottom line disclaimer a note that the project
is in incubation

Greg, if you want to be more sure that it's done, IMO we need to be a
bit more normnative and say *exactly* what is needed to have.

I think the above proposal is reasonable, as it minimizes the
infrastructure changes when the project is out of incubation (basically
0) and keeps the project clearly in incubation.
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Greg Stein
2003-10-03 12:53:05 UTC
Permalink
Post by Nicola Ken Barozzi
...
Post by Greg Stein
To what document do I need to add rule that says "a project ABSOLUTELY
MUST make clear that it is under incubation?"
If we kept all incubated projects under the incubator it would have been
clear enough.
I'm alright with that, but I think we need infrastructure sign-off first.
If they respond with, "holy crap. moving cvs repositories and mailing
lists are the biggest pains in the ass", then we may want to reconsider
"everybody under incubator.apache.org". If the response is, "pfft. no big
deal. we can easily move mailing lists and cvs repositories" then I'd
agree with you. Put *everybody* under incubator and only move them when
they exit.

[ cc'd infrastructure for commentary ]
Post by Nicola Ken Barozzi
Post by Greg Stein
We've already been through
this process where incubated projects are not being clear about their
status; that needs to be captured and retained for ALL incubated projects.
Proposal: if we still don't want to make incubator-xxx repositories for
1 - the websites are placed in
incubator.apache.org/projects/subproject
2 - these projects have as project logo the Incubator Logo
3 - They all have as a bottom line disclaimer a note that the project
is in incubation
Since the web site is the primary "arrival point" for the projects, this
would do the trick. Depending on infrastructure@'s response, I'd totally
agree with this. I'll go one step further and note that the Board has
mandated that the Incubator is a required step for incoming projects;
thus, all PMCs must follow its rules for incoming projects. IOW, a PMC
cannot maintain a separate website, but must always defer to the incubator
pages pending exit-from-incubation.
Post by Nicola Ken Barozzi
Greg, if you want to be more sure that it's done, IMO we need to be a
bit more normnative and say *exactly* what is needed to have.
Agreed. Thus my query: where? :-)

And with the "where" question, we are pending infrastructure's
recommendation.
Post by Nicola Ken Barozzi
I think the above proposal is reasonable, as it minimizes the
infrastructure changes when the project is out of incubation (basically
0) and keeps the project clearly in incubation.
Agreed. Great recommendation!

Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Noel J. Bergman
2003-10-03 23:00:57 UTC
Permalink
Post by Greg Stein
Post by Nicola Ken Barozzi
If we kept all incubated projects under the incubator it would have been
clear enough.
I'm alright with that, but I think we need infrastructure sign-off first.
If they respond with, "holy crap. moving cvs repositories and mailing
lists are the biggest pains in the ass"
CVS, mailing lists, web site, and eyebrowse archives. I haven't moved the
James archives (the lists, themselves, were moved long ago to the correct
domain), yet, since Berin and I are still working our way through a backlog
of eyebrowse requests, but here are the instructions to move James' mailing
lists from Jakarta to James:

http://nagoya.apache.org/wiki/apachewiki.cgi?Eyebrowse/JamesMove

It is a bit of a pain, so it would be nice to be able to create the
eyebrowse archive in the intended destination. Mind you, the archive domain
is transparent to the outside world. It would be possible to put a
podling's eyebrowse archives under the intended TLP's directory tree with no
external visibilty.

Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
address changed from james-***@jakarta.apache.org to
server-***@james.apache.org. Moving the web site was easy.

Since, AIUI, the CVS module is just a rename from incubator-X to TLP-X, that
ought not be much of an issue. A rename and a minor edit in avail, right?
Am I missing something?

--- Noel
Tetsuya Kitahata
2003-10-03 23:26:22 UTC
Permalink
On Fri, 3 Oct 2003 19:00:57 -0400
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
People (committers) left it as it was, so I guess many *newbies* would
have wander off, by complaining,
"Heck! I can not subscribe to XX project mailing list!!"
The same goes for "CVS repository", I can easily imagine. I re-wrote
something before (in June, July -- 6 months AFTER the graduations)..

I sometimes re-wrote "http://jakarta.apache.org/site/mail2.html" and
so on.

Removing the domain would be a pain.

Don't be silly, guys. it would be nice to be able to create the
eyebrowse archive, mailing list itself and cvs repository in the
intended destination. (except, the destination would be TLP,
such as geronimo)

-- Tetsuya. (***@apache.org)
Noel J. Bergman
2003-10-04 05:34:10 UTC
Permalink
Post by Tetsuya Kitahata
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
I'm only reporting experience, not proposing action.
Post by Tetsuya Kitahata
People (committers) left it as it was, so I guess many *newbies* would
have wander off, by complaining,
No Committers left, so I have no idea what you are talking about. Also, the
subscriber list was moved. The only thing that anyone needed to do was
change their address book.

--- Noel
Sam Ruby
2003-10-04 09:30:46 UTC
Permalink
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 19:00:57 -0400
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
I'd like us to all step back and take a look at the bigger picture.

Apparently, the root of this is a statement that something about the
incubation process of Lenya raised hackles. I suggest that there may be
multiple root causes for this.

Putting incubator as a part of the name is a form of disclaimer. One
that is relatively expensive. I, too, would rather we explore cheaper
alternatives before we decided to require this for every project.

It seems to me a disclaimer on the website, perhaps also in the root
directory of the associated CVS trees, and a process which prevents any
official "release" to be created by projects in incubation should be
more than sufficient.

- Sam Ruby
Nicola Ken Barozzi
2003-10-04 09:49:01 UTC
Permalink
Post by Sam Ruby
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 19:00:57 -0400
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
I'd like us to all step back and take a look at the bigger picture.
Apparently, the root of this is a statement that something about the
incubation process of Lenya raised hackles. I suggest that there may be
multiple root causes for this.
Putting incubator as a part of the name is a form of disclaimer. One
that is relatively expensive. I, too, would rather we explore cheaper
alternatives before we decided to require this for every project.
It seems to me a disclaimer on the website, perhaps also in the root
directory of the associated CVS trees, and a process which prevents any
official "release" to be created by projects in incubation should be
more than sufficient.
Sorry, but this has not worked.

I knew that many did not want renamings to occur, being touted as
"expensive", so I still stand behind my last proposal (that has been
trimmed here) which seems to me like a possible "compromise":

1 - the websites are placed in
incubator.apache.org/projects/subproject
2 - these projects have as project logo the Incubator Logo
3 - They all have as a bottom line disclaimer a note that the roject
is in incubation

Note that point 2 and 3 have not much to do with infrastructure, and
point 1 is not under direct control of this list, as the project members
would still have access to the incubator-site module, as part of the
project.
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Tetsuya Kitahata
2003-10-04 10:16:42 UTC
Permalink
On Sat, 04 Oct 2003 11:49:01 +0200
Post by Nicola Ken Barozzi
Sorry, but this has not worked.
I guess you had a karma for jakarta-site2 and you had left
1. ojb-***@jakarta.apache.org
2. ojb-***@jakarta.apache.org
3. turbine-torque-***@jakarta.apache.org
......
at http://jakarta.apache.org/site/mail2.html
as they were for 6 months or therabouts.

In such a situation, I can not believe any of your words. (Sorry,
but it WAS true)

The same goes for the change of the cvs repository names
(http://jakarta.apache.org/site/cvsindex.html)

... for 6 months. nonfeasance :-)
(Yes, I can point out and count up what had occured at xml.apache,
though, ..... I've had enough)

People, developers, tend not to update documents.
Less-restrictive-alternatives (oh! ... legal-term?) would be
highly appreciated, I suspect.

Are there any reason for you to stick to incubator.apache.org domain,
(sub)domain so much?
From my point of view, "disclaimer" page would be enough and
the best "alternative".

Cheers,

-- Tetsuya. (***@apache.org)
Stephen McConnell
2003-10-04 10:23:09 UTC
Permalink
Post by Tetsuya Kitahata
From my point of view, "disclaimer" page would be enough and
the best "alternative".
+1
--
Stephen J. McConnell
mailto:***@apache.org
Nicola Ken Barozzi
2003-10-04 11:20:15 UTC
Permalink
Post by Tetsuya Kitahata
On Sat, 04 Oct 2003 11:49:01 +0200
Post by Nicola Ken Barozzi
Sorry, but this has not worked.
I guess you had a karma for jakarta-site2 and you had left
......
at http://jakarta.apache.org/site/mail2.html
as they were for 6 months or therabouts.
Tell the people that were doing that move, not me.
Post by Tetsuya Kitahata
In such a situation, I can not believe any of your words. (Sorry,
but it WAS true)
What don't you believe?!? >:-|

Are you just trying to piss me off or will you comment on my proposal
points? >:-|
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Sam Ruby
2003-10-04 14:01:07 UTC
Permalink
Post by Nicola Ken Barozzi
Post by Sam Ruby
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 19:00:57 -0400
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
I'd like us to all step back and take a look at the bigger picture.
Apparently, the root of this is a statement that something about the
incubation process of Lenya raised hackles. I suggest that there may
be multiple root causes for this.
Putting incubator as a part of the name is a form of disclaimer. One
that is relatively expensive. I, too, would rather we explore cheaper
alternatives before we decided to require this for every project.
It seems to me a disclaimer on the website, perhaps also in the root
directory of the associated CVS trees, and a process which prevents
any official "release" to be created by projects in incubation should
be more than sufficient.
Sorry, but this has not worked.
What exactly has not worked? The disclaimers are new. No disclaimers
are present in any CVS trees that I am aware of. The process proposal
of not allowing releases from incubation is a novel one as far as I know.

If a project's destination is unknown, certainly it belongs in
incubation. If it's destination is known, then I would think that there
is a value of be able to observe the community "in situo" before exiting
incubation.
Post by Nicola Ken Barozzi
I knew that many did not want renamings to occur, being touted as
"expensive", so I still stand behind my last proposal (that has been
1 - the websites are placed in
incubator.apache.org/projects/subproject
2 - these projects have as project logo the Incubator Logo
3 - They all have as a bottom line disclaimer a note that the roject
is in incubation
Note that point 2 and 3 have not much to do with infrastructure, and
point 1 is not under direct control of this list, as the project members
would still have access to the incubator-site module, as part of the
project.
2 and 3 are not in debate. We could achieve 1 with a symbolic link.
Quite frankly, I'm more concerned about cvs and mailing lists than the
web site. I would be willing to compromise on #1 if it were limited to
the web site, however I will note that the ASF is not uniform in the
mechanisms for producing web sites, so either multiple build tools will
need to be accomodated, or the websites will have to be reworked when
the codebase leaves incubation.

- Sam Ruby
Nicola Ken Barozzi
2003-10-04 19:11:40 UTC
Permalink
...
Post by Sam Ruby
Post by Nicola Ken Barozzi
Post by Sam Ruby
It seems to me a disclaimer on the website, perhaps also in the root
directory of the associated CVS trees, and a process which prevents
any official "release" to be created by projects in incubation should
be more than sufficient.
Sorry, but this has not worked.
What exactly has not worked? The disclaimers are new. No disclaimers
are present in any CVS trees that I am aware of.
Which is why it hasn't worked. The problem is that it's not easy to both
have all sites have that disclaimer and keep it there,.
Post by Sam Ruby
The process proposal
of not allowing releases from incubation is a novel one as far as I know.
True. In fact for me it's not in debate.
Post by Sam Ruby
If a project's destination is unknown, certainly it belongs in
incubation. If it's destination is known, then I would think that there
is a value of be able to observe the community "in situo" before exiting
incubation.
It seems so, yes...
Post by Sam Ruby
Post by Nicola Ken Barozzi
I knew that many did not want renamings to occur, being touted as
"expensive", so I still stand behind my last proposal (that has been
1 - the websites are placed in
incubator.apache.org/projects/subproject
2 - these projects have as project logo the Incubator Logo
3 - They all have as a bottom line disclaimer a note that the roject
is in incubation
Note that point 2 and 3 have not much to do with infrastructure, and
point 1 is not under direct control of this list, as the project
members would still have access to the incubator-site module, as part
of the project.
2 and 3 are not in debate. We could achieve 1 with a symbolic link.
Then basically we agree :-)
Post by Sam Ruby
Quite frankly, I'm more concerned about cvs and mailing lists than the
web site.
Well, for CVS and mailing lists, we have seen that changing names is not
something that has to be done lightly, for various reasons.

For those we have no other reasonably means other than disclaimers, I agree.
Post by Sam Ruby
I would be willing to compromise on #1 if it were limited to
the web site, however I will note that the ASF is not uniform in the
mechanisms for producing web sites, so either multiple build tools will
need to be accomodated, or the websites will have to be reworked when
the codebase leaves incubation.
Ahhh, maybe me was not clear. I just want the site to *appear* under
incubator uris, not to be in incubator-site CVS. It's totally
unreasonable that projects must use our site system for their work.

Le me try and rephrase the proposal with the above clarifications:

1 - the projects' websites are published under
incubator.apache.org/projects/project
2 - these projects have as project logo the Incubator Logo
3 - All project sites all have as a bottom line disclaimer a note
that they are in incubation
4 - the CVS and mailing lists are to appear under the sponsoring
PMC name (if it's a new project the sponsoring PMC is the
Incubator itself)
5 - The CVS contains a discalimer file and the mailing lists have
the disclaimer in the footer
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Justin Erenkrantz
2003-10-11 08:35:39 UTC
Permalink
Post by Nicola Ken Barozzi
I knew that many did not want renamings to occur, being touted as
"expensive", so I still stand behind my last proposal (that has been
I'll just chime in belatedly and say that if the incubated project used
Subversion, renaming is *easy*. CVS sucks for this.

While we can do renaming of lists, etc, it's a pain (saying as one of
the four schmucks that will get stuck doing it). I think we're willing
to do it as long as it's infrequent. The biggest problem is that
projects want their old aliases to work for a little while. From our
perspective, that's the really annoying part. -- justin
Nicola Ken Barozzi
2003-10-11 08:44:17 UTC
Permalink
Post by Justin Erenkrantz
Post by Nicola Ken Barozzi
I knew that many did not want renamings to occur, being touted as
"expensive", so I still stand behind my last proposal (that has been
I'll just chime in belatedly and say that if the incubated project used
Subversion, renaming is *easy*. CVS sucks for this.
;-)

Unfortunatley, projects should stick to what they'll use later.
Post by Justin Erenkrantz
While we can do renaming of lists, etc, it's a pain (saying as one of
the four schmucks that will get stuck doing it). I think we're willing
to do it as long as it's infrequent. The biggest problem is that
projects want their old aliases to work for a little while. From our
perspective, that's the really annoying part.
As this is a technical thing, can't scripting be used to automate it?
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Berin Lautenbach
2003-10-04 10:20:59 UTC
Permalink
All,

FWIW - the following is the extract (at time of writing) from the draft
Policy document relating to the current discussion.

I am about to move this into the drafts section of the site, so people
can start hacking within CVS.

Cheers,
Berin

= Podling Constraints =

== Branding ==

Podlings are, by definition, not yet fully accepted as part of the
Apache Software Foundation. Podling web sites MUST include a clear
disclaimer on their website and in all documentation stating that they
are in incubation.

Podlings SHOULD use the following text for all disclaimers :

<i><project name> is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the <name of sponsoring entity>.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.</i>


Podlings wishing to use a different disclaimer message MUST have the
disclaimer approved by the Incubator PMC prior to use.

== Releases ==

As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically
available CVS) made by Podlings will not be endorsed by the ASF.

However, as software releases are an important part of any software
project, they are permitted in certain circumstances, as follows.

Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC. Such approval SHALL
be given only after the Incubator PMC has followed the process detailed
in (Reference to Charter), and SHALL NOT occur until all source has been
legally transferred to the ASF.

Therefore, should a Podling decide it wishes to perform a release, the
Podling SHALL formally request the Incubator PMC approve such a release.
The request SHALL have the endorsement of the Mentor.

Should the Incubator PMC, in accordance with (Reference to Charter) vote
to approve the request, the Podling MAY perform the release under the
following constraints :

* the release archive MUST contain the word "incubating" in the
filename; and
* the release archive MUST contain an Incubation disclaimer (as
described in the previous section), clearly visible in the main
documentation or README file.
Post by Sam Ruby
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 19:00:57 -0400
Post by Noel J. Bergman
Judging from the move we made with james, CVS was easy. ezmlm a bit more
involved, but our users seemed to find us easily enough when the list
I'd like to oppose this. (Sorry)
I'd like us to all step back and take a look at the bigger picture.
Apparently, the root of this is a statement that something about the
incubation process of Lenya raised hackles. I suggest that there may be
multiple root causes for this.
Putting incubator as a part of the name is a form of disclaimer. One
that is relatively expensive. I, too, would rather we explore cheaper
alternatives before we decided to require this for every project.
It seems to me a disclaimer on the website, perhaps also in the root
directory of the associated CVS trees, and a process which prevents any
official "release" to be created by projects in incubation should be
more than sufficient.
- Sam Ruby
---------------------------------------------------------------------
Stephen McConnell
2003-10-04 12:44:56 UTC
Permalink
Post by Berin Lautenbach
<i><project name> is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the <name of sponsoring
entity>. Incubation is required of all newly accepted projects until
a further review indicates that the infrastructure, communications,
and decision making process have stabilized in a manner consistent
with other successful ASF projects. While incubation status is not
necessarily a reflection of the completeness or stability of the code,
it does indicate that the project has yet to be fully endorsed by the
ASF.</i>
Berin:

I have a problem with the last sentence in the above paragraph as it
implies a association between the incubator and project code completness
and/or stability. Here is a suggested replacement that eliminates the
concern:

<i><project name> is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the <name of sponsoring entity>.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. As such, the project has not been formally
endorsed by the ASF.</i>

Stephen.
--
Stephen J. McConnell
mailto:***@apache.org
Berin Lautenbach
2003-10-05 10:22:48 UTC
Permalink
Post by Stephen McConnell
Post by Berin Lautenbach
<i><project name> is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the <name of sponsoring
entity>. Incubation is required of all newly accepted projects until
a further review indicates that the infrastructure, communications,
and decision making process have stabilized in a manner consistent
with other successful ASF projects. While incubation status is not
necessarily a reflection of the completeness or stability of the code,
it does indicate that the project has yet to be fully endorsed by the
ASF.</i>
I have a problem with the last sentence in the above paragraph as it
implies a association between the incubator and project code completness
and/or stability. Here is a suggested replacement that eliminates the
<i><project name> is an effort undergoing incubation at the Apache
Software Foundation (ASF), sponsored by the <name of sponsoring entity>.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. As such, the project has not been formally
endorsed by the ASF.</i>
I am comfortable with this. Any objections with this ammendment going
in the policy draft?

Cheers,
Berin
David Jencks
2003-10-04 17:11:03 UTC
Permalink
Post by Berin Lautenbach
== Releases ==
As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically
available CVS) made by Podlings will not be endorsed by the ASF.
....
Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC.
To me, one possible reading of these two statements is that explicit
approval of the Incubator PMC is required for any change to code held
in publicly available CVS. I doubt that is what anyone intends.


david jencks
Stephen McConnell
2003-10-04 17:43:31 UTC
Permalink
Post by David Jencks
Post by Berin Lautenbach
== Releases ==
As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically
available CVS) made by Podlings will not be endorsed by the ASF.
....
Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC.
To me, one possible reading of these two statements is that explicit
approval of the Incubator PMC is required for any change to code held
in publicly available CVS. I doubt that is what anyone intends.
What is intended and what happens are two very different things.

Apache is publishing incubator code via CVS. Restrictions above and
beyond that are accademic and simply unnecessary overheads on projects
under incubation. I would suggest the the incubator PMC address
due-diligence at the appropriate level. In this context the appropriate
level is the license.

(a) if a new project is importing code it should import it under
an Incubator variant of ASL 1.1 with appropriate disclaimers
(b) if (a) is not satisfied - then the repository is not available
to the public - period - simple
(c) let the project publish what it wants providing it is
consitent with the license

Stephen.
--
Stephen J. McConnell
mailto:***@apache.org
Berin Lautenbach
2003-10-04 23:42:04 UTC
Permalink
Post by David Jencks
Post by Berin Lautenbach
As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically
available CVS) made by Podlings will not be endorsed by the ASF.
....
Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC.
To me, one possible reading of these two statements is that explicit
approval of the Incubator PMC is required for any change to code held in
publicly available CVS. I doubt that is what anyone intends.
Actually - yes and no :>. The intent was that code can not go into the
CVS until the Incubator PMC is comfortable that any legal issues have
been worked through.

Whether that needs explicit approval or is up to the Shepherd/Mentor to
determine is where the content is confusing.

Cheers,
Berin
Noel J. Bergman
2003-10-05 05:00:06 UTC
Permalink
[lots of really good stuff]
The draft seems to be using RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt)
terminology. If so, let's please reference the RFC early in the document so
that readers can find the operation definitions (thus establishing common
volcabulary).
Post by Berin Lautenbach
As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically
available CVS) made by Podlings will not be endorsed by the ASF.
Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC.
one possible reading of these two statements is that explicit
approval of the Incubator PMC is required for any change to code held
in publicly available CVS. I doubt that is what anyone intends.
Clearly not the intent. Nor are we talking about CVS snapshots.

--- Noel
Berin Lautenbach
2003-10-05 06:13:24 UTC
Permalink
Post by Noel J. Bergman
The draft seems to be using RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt)
terminology. If so, let's please reference the RFC early in the document so
that readers can find the operation definitions (thus establishing common
volcabulary).
Whoops. There is a line in there :

"Where capitalised, these terms are to be used as per the definitions
found in RFC 2119 (Reference)."

So I think I was thinking (which is a lot of thinking) the same thing :>.

Will fix.

Cheers,
Berin
Noel J. Bergman
2003-10-05 19:37:49 UTC
Permalink
Post by Berin Lautenbach
Post by Noel J. Bergman
The draft seems to be using RFC 2119
(http://www.ietf.org/rfc/rfc2119.txt)
Post by Berin Lautenbach
Post by Noel J. Bergman
terminology. If so, let's please reference the RFC early in the document so
that readers can find the operation definitions (thus establishing common
volcabulary).
"Where capitalised, these terms are to be used as per the definitions
found in RFC 2119 (Reference)."
So I think I was thinking (which is a lot of thinking) the same thing :>.
Will fix.
Fix what? Looks like you already did it. I was looking at your e-mail, not
the site, and the line wasn't in the extract, but has been in the full
document since the third revision on Sept 28th. :-) Mea culpa. :-)

--- Noel
Berin Lautenbach
2003-10-06 09:42:14 UTC
Permalink
Post by Noel J. Bergman
Post by Berin Lautenbach
"Where capitalised, these terms are to be used as per the definitions
found in RFC 2119 (Reference)."
So I think I was thinking (which is a lot of thinking) the same thing :>.
Will fix.
Fix what? Looks like you already did it. I was looking at your e-mail, not
the site, and the line wasn't in the extract, but has been in the full
document since the third revision on Sept 28th. :-) Mea culpa. :-)
The Incubator site version now also has a link to the RFC (which is what
the "(Reference)" thing was there to remind me to do).

Which is what I fixed!

Cheers,
Berin
Leo Simons
2003-10-04 12:02:12 UTC
Permalink
Hi gang,

long e-mail, with analysis of pros and cons, and some policy
draft on some issues Berin didn't address yet last time I checked.

Disclaimers
-----------
a question at hand: how do we make clear to everyone that a
project and all its related assets are "under incubation" (along
with what that means)?

Lets split that out a bit according to "involved peeps":

board -- I have the distinct feeling that, normally, the board
will know what is under incubation by virtue of reports from PMC
chairs. No problem here.

infrastructure team -- for these peeps, it mostly doesn't matter;
all they need to know is that all infrastructure requests and
setup are governed by a PMC, and a CC of those requests to
***@incubator suffices. No problem here.

sponsors -- these people had better know! No issue.

podling developers -- sponsors had better make sure these people
know as well! No issue.

potential podling developers -- if these people come from within
apache, most of them will at least be somewhat familiar with
incubator, and a simple and clear "disclaimer text" on a project
front page will allow them to find out whatever they need.

If these come from external projects, they may have a few more
questions, but that is something probably best solved by good docs
on the incubator website and some people around on the podling
mailing lists to direct people to it.

The trick, of course, is making sure these people actually read
the disclaimer text. To make that happen, it needs to appear on
their screen before any "get involved" or "subscribe" link...

If you can get at downloads or mailing list information without
going through the project website, that will be a problem. This
is what Tetsuya (can you pick a nickname please? I keep
copy-pasting that 'cause its impossible to remember the right
spelling :D:D) outlines went wrong with the mail2.html page
@ jakarta.

users -- most users are dumb. They will read right past any
disclaimer, will not even think about what "incubator" means and
will just click on "download". I very much doubt that many users
will respond *that* differently to a project whether its url is
jakarta.apache.org/geronimo, incubator.apache.org/geronimo or
geronimo.apache.org. Its "the apache J2EE server", no matter what
internal procedure applies. Marking something as "alpha" or
"beta" might work, but "incubation" is probably not in the active
vocabulary for a rather large part of the user community.


Infrastructural burden
----------------------
(responding partially on behalf of the infrastructure team I
guess, but all IMVHO...I'm not on the infrastructure team)

The infrastructure peeps are pretty busy. Something like the
renaming of a cvs repository is probably usually done in a minute
or three (including reading the request, verifying it, doing the
'mv' and 'ln' on the server, and sending another e-mail to confirm
its done), but it does all add up.

In my experience, configuration changes for bugzilla, eyebrowse
and ezmlm are more of an issue than changes to cvs, webserver or
basic unix (ie permissions); probably because the latter are
naturally easier to manage and there's more people around to do
it.

However, the combined energy invested by all people who work on
use a project is a lot bigger still. Bookmarks and address books to
be updated (along with memory), referring websites to be changed,
uncommitted code changes to manually merge, cvs modules to checkout
anew, etc. The bigger the project, the more annoying the change.

Thus, until it becomes clear there's an actual problem with
putting podling materials in their intended final locations, I'd
recommend doing so.

Finally, I would assert changes to cvs and e-mail configuration
are more annoying to deal with than movement of websites,
especially since the web allows for easily setting up sophisticated
redirections (without infrastructure team intervention) whereas for
other stuff its more involved.


So...the compromise...


------------------------------------------------------------
Draft policy
------------
It is desireable that all (potential) developers and users of a
podling project understand that it is under incubation and what
that entails. Having said that, we otherwise wish to minimize
burden on the infrastructure team and in all other ways make the
"Podling Experience" as pleasant as possible. To that end, a few
guidelines.

Resource allocation
-------------------
- new podlings get a website @
incubator.apache.org/projects/$podling
- all podling developers get access to incubator-site cvs to be able
to update their project and list it on the main incubator website
- new podlings get their own unix group if they're destined for
top level, otherwise the 'incubator' unix group is used until they
graduate, at which point the unix group is changed to that of their
new new tlp
- cvs, e-mail, task management and any other resources
are set up as if the project were at its proposed destination
already, ie:
- new podlings get a cvs module named $tlp-$podling, or
$podling if they're destined for top level
- if a mailing list is set up for the project, it is named
dev@$podling.apache.org if the project is destined for top
level, or whatever else is appropriate if its not
destined for top level.
If there is not podling-specific mailing list, the podling
needs to opt to either use the destination projects' mailing
list or ***@incubator.apache.org, but the choice should
be clear on the podling website

Branding
--------
The podling website should have a notice (<insert here>) on its
front page pointing out that its under incubation, a notice in the
root of its cvs (in README.txt or WARNING.txt or ...), a notice
inside and alongside any downloadables it produces in a prominent
location, and ideally, a notice wherever a sponsoring project
directly links to one of the podlings' resources (other than its
website).

Finally, the podling needs to display the incubator logo on its
website.
---------------------------------------------------------------

back to my corner!


- Leo
Sam Ruby
2003-10-04 14:05:11 UTC
Permalink
Post by Berin Lautenbach
Branding
--------
The podling website should have a notice (<insert here>) on its
front page pointing out that its under incubation, a notice in the
root of its cvs (in README.txt or WARNING.txt or ...), a notice
inside and alongside any downloadables it produces in a prominent
location, and ideally, a notice wherever a sponsoring project
directly links to one of the podlings' resources (other than its
website).
I would go further. Essentially, a release by a podling would require a
vote by the incubator PMC to do so. I would recommend that this be an
extremely rare event.

Alphas, Betas, nightly builds, etc., I have no problem with.
Post by Berin Lautenbach
Finally, the podling needs to display the incubator logo on its
website.
---------------------------------------------------------------
back to my corner!
- Leo
- Sam Ruby
Leo Simons
2003-10-04 14:22:51 UTC
Permalink
Post by Sam Ruby
I would go further. Essentially, a release by a podling would require
a vote by the incubator PMC to do so.
a release by *any* project requires its supervising PMC to vote
it through. Since for podlings, the supervising PMC is by definition
the incubator PMC, you're not going anywhere spectacular :D

- LSD
Post by Sam Ruby
Ok - going with Apache tradition - its not the PMC that makes the
decision of a *release*.
BZZZT. According to the bylaws, the only people authorized to make
decisions
on behalf of the ASF (including the decision to release code to the general
public) are officers or the PMC responsible for the project. All other
votes are to be ignored or considered advisory only, and no I don't care
how long some of our umbrella projects have been ignoring that fact.

....Roy
Stephen McConnell
2003-10-04 14:41:55 UTC
Permalink
Post by Leo Simons
I would go further. Essentially, a release by a podling would require
a vote by the incubator PMC to do so.
a release by *any* project requires its supervising PMC to vote
it through. Since for podlings, the supervising PMC is by definition
the incubator PMC, you're not going anywhere spectacular :D
- LSD
Ok - going with Apache tradition - its not the PMC that makes the
decision of a *release*.
BZZZT. According to the bylaws, the only people authorized to make
decisions
on behalf of the ASF (including the decision to release code to the general
public) are officers or the PMC responsible for the project. All other
votes are to be ignored or considered advisory only, and no I don't care
how long some of our umbrella projects have been ignoring that fact.
....Roy
BZZZT, BZZZT, the above statement presumes that "release" and
"publication" are one and the same. The distinction between a vote to
"release" and a vote to "publish" is in my option an import aspect of
active community based decision making. Communities vote to release, and
PMCs demonstrate responsible oversite through control of “publication.
The people who care about the subject make a collective decision to
release something. That decision is not binding on Apache. All it does
is establish a recommendation to a PMC to publish. A PMC can then
endorce (or not) a release recommendation by the community. This
approach reflects a respect for the *decisions* of the community while
delivering the appropriate due-diligence by the responsible PMC.

Stephen.
Post by Leo Simons
---------------------------------------------------------------------
--
Stephen J. McConnell
mailto:***@apache.org
Leo Simons
2003-10-04 15:00:27 UTC
Permalink
Post by Stephen McConnell
BZZZT, BZZZT, the above statement presumes that "release" and
"publication" are one and the same. The distinction between a vote to
"release" and a vote to "publish" is in my option an import aspect of
active community based decision making. Communities vote to release,
and PMCs demonstrate responsible oversite through control of
“publication. The people who care about the subject make a collective
decision to release something. That decision is not binding on Apache.
All it does is establish a recommendation to a PMC to publish. A PMC
can then endorce (or not) a release recommendation by the community.
well, sure. Totally agree. You've got the roles and responsibilities
right.

In theory.

In practice, such an approach is way too cumbersome. The
PMC is supposed to be at least a substantial subset of the
development community. Meaning the same people would vote
twice on the same thing. Something, by the way, which in a
healthy community is usually not controversial at all.

So, we start with your picture of roles and responsibilities and
then we streamline the process a bit. We usually roll all those
votes into one, put in place a release manager, etc etc.

Or, you might say, we implement the community vote to release
by lazy consensus, and we might do so for the choice of release
manager as well.

Natural thought: "lets make the PMC vote lazy consensus as well".
And there is a problem. Can't do that. Legal oversight, bylaws,
accountability, etc etc. So the PMC must always hold the publication
vote.

But, since we've made the "release" vote subject ot lazy consensus,
and since the only "publication" vote a PMC holds is on the
publication of "releases", lets make "publication vote" into synonymous
to "release vote".

And there you have it steve: we're actually in agreement! There's
really no need for you to BZZZT here.
Post by Stephen McConnell
This approach reflects a respect for the *decisions* of the community
while delivering the appropriate due-diligence by the responsible PMC.
Respect for the decisions by the community from the PMC had
better be implicit and it had better generally be known to all
participants that the respect is there. If this is not crystal clear
to all, what you have is a screwed-up community.

cheers!

- Leo
Greg Stein
2003-10-03 12:45:15 UTC
Permalink
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 04:39:00 -0700
Post by Greg Stein
Post by Tetsuya Kitahata
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
<snip/>
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
Aha, Okay. I think that the folks in wsrp4j just did not know how
to do. It happens all the time. People should not blame ones' ignorance.
Agreed. And I raised the point two weeks ago, noting that Apache Lenya
also missed out on the disclaimer and that raised hackles. That it was
best for all incubated projects to insert some text about their status
within the disclaimer.

But if NOTHING is done after two weeks, then it is no longer about
ignorance, but about failure to let people know about the projects' actual
status. A completely different matter.
Post by Tetsuya Kitahata
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
Good point. My post was more aimed at the people who are shepherding the
project (e.g. Sam) rather than the developers. IMO, Sam should know
better, and should have fixed this long ago.
Post by Tetsuya Kitahata
# This is "INCUBATION" project, not "GOLEM" project ;-)
Not sure I understand the GOLEM reference, but the smiley is noted :-)
Post by Tetsuya Kitahata
--
JaxMe folks, wsrp4j folks,
Dims has already taken care of the pages. Woo! :-) He used Cliff's text
from XMLBeans, which is quite an excellent description/disclaimer. (thanks
Cliff!)

Thanks, Dims!
Post by Tetsuya Kitahata
...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Sam Ruby
2003-10-03 15:59:53 UTC
Permalink
Post by Greg Stein
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 04:39:00 -0700
Post by Greg Stein
Post by Tetsuya Kitahata
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
<snip/>
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
Aha, Okay. I think that the folks in wsrp4j just did not know how
to do. It happens all the time. People should not blame ones' ignorance.
Agreed. And I raised the point two weeks ago, noting that Apache Lenya
also missed out on the disclaimer and that raised hackles. That it was
best for all incubated projects to insert some text about their status
within the disclaimer.
But if NOTHING is done after two weeks, then it is no longer about
ignorance, but about failure to let people know about the projects' actual
status. A completely different matter.
Post by Tetsuya Kitahata
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
Good point. My post was more aimed at the people who are shepherding the
project (e.g. Sam) rather than the developers. IMO, Sam should know
better, and should have fixed this long ago.
I'm under the weather, and a little irritable, but this is starting to
get under my skin.

I am trying to follow http://incubator.apache.org/process.html

I have asked for this to be updated.

I have asked for information on how I can update this.

These questions have gone unanswered.

- Sam Ruby
Post by Greg Stein
Post by Tetsuya Kitahata
# This is "INCUBATION" project, not "GOLEM" project ;-)
Not sure I understand the GOLEM reference, but the smiley is noted :-)
Post by Tetsuya Kitahata
--
JaxMe folks, wsrp4j folks,
Dims has already taken care of the pages. Woo! :-) He used Cliff's text
from XMLBeans, which is quite an excellent description/disclaimer. (thanks
Cliff!)
Thanks, Dims!
Post by Tetsuya Kitahata
...
Cheers,
-g
- Sam Ruby
Jason van Zyl
2003-10-03 13:20:53 UTC
Permalink
Post by Sam Ruby
I'm under the weather, and a little irritable, but this is starting to
get under my skin.
I am trying to follow http://incubator.apache.org/process.html
I have asked for this to be updated.
I have asked for information on how I can update this.
These questions have gone unanswered.
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
--
jvz.

Jason van Zyl
***@zenplex.com
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
Jim Jagielski
2003-10-03 17:37:56 UTC
Permalink
Post by Jason van Zyl
Post by Sam Ruby
I'm under the weather, and a little irritable, but this is starting to
get under my skin.
I am trying to follow http://incubator.apache.org/process.html
I have asked for this to be updated.
I have asked for information on how I can update this.
These questions have gone unanswered.
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
Ted Leung
2003-10-03 18:20:09 UTC
Permalink
Post by Jim Jagielski
Post by Jason van Zyl
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
This is great, but it's also news to me...
Post by Jim Jagielski
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
Noel J. Bergman
2003-10-03 19:13:15 UTC
Permalink
Post by Ted Leung
[The members of the Incubator PMC are:]
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
This is great, but it's also news to me...
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
Same here, but I accept the nomination (and have subscribed to the list). I
suspect that it is due to being the shephard for a project under incubation,
although I am finding the evolution of the incubator worth participating in
on its own merit. I am more surprised not to see Berin Lautenbach's name.

--- Noel
Davanum Srinivas
2003-10-03 19:20:27 UTC
Permalink
Added myself to the ***@incubator list. Yes, my +1 to Berin (if i may).

Thanks,
dims
Post by Noel J. Bergman
Post by Ted Leung
[The members of the Incubator PMC are:]
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
This is great, but it's also news to me...
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
Same here, but I accept the nomination (and have subscribed to the list). I
suspect that it is due to being the shephard for a project under incubation,
although I am finding the evolution of the incubator worth participating in
on its own merit. I am more surprised not to see Berin Lautenbach's name.
--- Noel
---------------------------------------------------------------------
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Jim Jagielski
2003-10-03 20:01:34 UTC
Permalink
Nicola is sending/has sent to you the result of
the vote.
Post by Ted Leung
Post by Jim Jagielski
Post by Jason van Zyl
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
This is great, but it's also news to me...
Post by Jim Jagielski
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
---------------------------------------------------------------------
Nicola Ken Barozzi
2003-10-04 08:14:32 UTC
Permalink
Post by Jim Jagielski
Nicola is sending/has sent to you the result of
the vote.
I was waiting for 72 hours after the ACK of the board, as is required,
to declare you guys in the PMC, but it has leaked out ;-)

In any case, you guys are in :-)
Post by Jim Jagielski
Post by Ted Leung
Post by Jim Jagielski
Post by Jason van Zyl
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
Aaron Bannert
Nicola Ken Barozzi (Chair select)
Noel Bergman (new member)
Ken Coar
Roy Fielding
B. W. Fitzpatrick
Paul Hammant
Ted Leung (new member)
This is great, but it's also news to me...
Post by Jim Jagielski
Jim Jagielski
Sam Ruby
Leo Simmons (new member)
Davanum Srinivas (new member)
Greg Stein
Sander Striker
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Tetsuya Kitahata
2003-10-05 09:05:19 UTC
Permalink
On 03 Oct 2003 09:20:53 -0400
Post by Jason van Zyl
My simple question about who is actually on the PMC has also gone
unanswered, though it has only been three days.
By the way, Jason, why don't you take a glance at
"committers" module: /board/committee-info.txt
??

(However, I admit that it seems that the update of the text file
would get behind the time)

-- Tetsuya. (***@apache.org)
Berin Lautenbach
2003-10-04 00:12:24 UTC
Permalink
Post by Sam Ruby
I'm under the weather, and a little irritable, but this is starting to
get under my skin.
I am trying to follow http://incubator.apache.org/process.html
I have asked for this to be updated.
I have asked for information on how I can update this.
Sam,

I am 90% of the way through doing an overhaul of process.html that I am
going to place (this weekend) in the drafts section of the incubator site.

In the interim, if you want to see what is going on in terms of content,
have a look at :

(To be the Non-normative process description - nearly ready to go accross).

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

(To be the normative set of incubation requirements - still embryonic,
and not yet ready to go into drafts on site)

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

Cheers,
Berin
Sam Ruby
2003-10-04 01:56:52 UTC
Permalink
Post by Berin Lautenbach
Post by Sam Ruby
I'm under the weather, and a little irritable, but this is starting to
get under my skin.
I am trying to follow http://incubator.apache.org/process.html
I have asked for this to be updated.
I have asked for information on how I can update this.
Sam,
I am 90% of the way through doing an overhaul of process.html that I am
going to place (this weekend) in the drafts section of the incubator site.
In the interim, if you want to see what is going on in terms of content,
(To be the Non-normative process description - nearly ready to go accross).
http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings
(To be the normative set of incubation requirements - still embryonic,
and not yet ready to go into drafts on site)
http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorPolicyDraft
Can I ask that you document the process of updating the site?

I want to make sure that there is a set of requirements for what status
files are expected to contain, and a description the necessary
disclaimers that need to be present on the various sites. I also want
to update http://incubator.apache.org/projects/index.html .

- Sam Ruby
Berin Lautenbach
2003-10-04 06:25:55 UTC
Permalink
Post by Sam Ruby
Can I ask that you document the process of updating the site?
Looks like it's already there, but not very obvious. I will add to the
side-bar, but in the interim :

http://incubator.apache.org/updating_docs.html
Post by Sam Ruby
I want to make sure that there is a set of requirements for what status
files are expected to contain, and a description the necessary
disclaimers that need to be present on the various sites. I also want
to update http://incubator.apache.org/projects/index.html .
There is already something (purposefully minimal) in the
IncubatorPolicyDraft document on Wiki - you are more than welcome to
modify/change/update. This is the raw text for what will be the
normative requirements, so would be the best place to put it.

Alternatively - if you still want to hit the Process document, it's
about to get changed. If you are able to hold on for 24 hours, I'll get
the new version into the drafts section so that you can update what is
going to get moved over. If not - go mad and I'll try to incorporate
your changes back into the new Process document.

Cheers,
Berin
Sam Ruby
2003-10-04 08:58:42 UTC
Permalink
Post by Berin Lautenbach
Post by Sam Ruby
Can I ask that you document the process of updating the site?
Looks like it's already there, but not very obvious. I will add to the
http://incubator.apache.org/updating_docs.html
Thank you! That is more than sufficient for my needs.
Post by Berin Lautenbach
Post by Sam Ruby
I want to make sure that there is a set of requirements for what
status files are expected to contain, and a description the necessary
disclaimers that need to be present on the various sites. I also want
to update http://incubator.apache.org/projects/index.html .
There is already something (purposefully minimal) in the
IncubatorPolicyDraft document on Wiki - you are more than welcome to
modify/change/update. This is the raw text for what will be the
normative requirements, so would be the best place to put it.
Alternatively - if you still want to hit the Process document, it's
about to get changed. If you are able to hold on for 24 hours, I'll get
the new version into the drafts section so that you can update what is
going to get moved over. If not - go mad and I'll try to incorporate
your changes back into the new Process document.
It won't be until Monday that I begin updating this.

- Sam Ruby
Tetsuya Kitahata
2003-10-04 02:39:07 UTC
Permalink
On Fri, 3 Oct 2003 05:45:15 -0700
Post by Greg Stein
But if NOTHING is done after two weeks, then it is no longer about
ignorance, but about failure to let people know about the projects' actual
status. A completely different matter.
People often lost the precious e-mails due to the current
Here "SPAM"
There "SPAM"
Everywhere "SPAM", "SPAM"
era.... It's very sad to say, however, the reality would be such.

Cautions once a week would be enough.
Post by Greg Stein
Post by Tetsuya Kitahata
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
Good point. My post was more aimed at the people who are shepherding the
project (e.g. Sam) rather than the developers. IMO, Sam should know
better, and should have fixed this long ago.
Just my two yen :-) (= 2 cents) ... Just Sam did not know how he
should put the lines, I guess. Don't blame.
The root of the evil would be the inconsistency of the "incubator
project" itself, I am sure.
Post by Greg Stein
Post by Tetsuya Kitahata
# This is "INCUBATION" project, not "GOLEM" project ;-)
Not sure I understand the GOLEM reference, but the smiley is noted :-)
D'oh... I meant "bloodcurdling gatekeeper" by "GOLEM". Maybe the
"Anime/Manga/Video-Game" Mania (Otaku?) in apache world would give
you more precise and nice explanations. :-)
# Of course, you can make use of goooooooogle ;-)

In the business world, "inbubation"/"incubator" is rather "ANGEL".
Full of "nurturing", "caring" attitudes towards the "embryo".

I suspect that the Incubator Project in the ASF is going to the
opposite .... choking the embrio into death.... without sufficient
"OXYGEN".. OH, Scared
Post by Greg Stein
Post by Tetsuya Kitahata
JaxMe folks, wsrp4j folks,
Dims has already taken care of the pages. Woo! :-) He used Cliff's text
from XMLBeans, which is quite an excellent description/disclaimer. (thanks
Cliff!)
Great! .. maybe the same should go for the pluto (incubation under
jakarta/jetspeed) project, too.

-- Tetsuya. (***@apache.org)

-----------------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: ***@apache.org http://www.terra-intl.com/
Sam Ruby
2003-10-04 09:19:53 UTC
Permalink
Post by Greg Stein
Post by Tetsuya Kitahata
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
Aha, Okay. I think that the folks in wsrp4j just did not know how
to do. It happens all the time. People should not blame ones' ignorance.
Agreed. And I raised the point two weeks ago, noting that Apache Lenya
also missed out on the disclaimer and that raised hackles. That it was
best for all incubated projects to insert some text about their status
within the disclaimer.
But if NOTHING is done after two weeks, then it is no longer about
ignorance, but about failure to let people know about the projects' actual
status. A completely different matter.
Post by Tetsuya Kitahata
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
Good point. My post was more aimed at the people who are shepherding the
project (e.g. Sam) rather than the developers. IMO, Sam should know
better, and should have fixed this long ago.
Let me turn this around. You note a problem with a prior project. You
posit a solution that you assert would prevent the problem in future
projects.

What have you done to incorporate this into the process or even bring it
forward for a vote?

- Sam Ruby
Nicola Ken Barozzi
2003-10-04 09:43:02 UTC
Permalink
...
Post by Sam Ruby
Post by Greg Stein
Good point. My post was more aimed at the people who are shepherding the
project (e.g. Sam) rather than the developers. IMO, Sam should know
better, and should have fixed this long ago.
Let me turn this around. You note a problem with a prior project. You
posit a solution that you assert would prevent the problem in future
projects.
What have you done to incorporate this into the process or even bring it
forward for a vote?
We don't need to know what has been done, we just need to get things
forward.

Sam is ready to post changes to our docs, we have new members that are
active and we are making th esite easier to update.

Case closed. :-)
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Rodent of Unusual Size
2003-10-04 18:28:38 UTC
Permalink
Post by Tetsuya Kitahata
People often lost the precious e-mails due to the current
Here "SPAM"
There "SPAM"
Everywhere "SPAM", "SPAM"
oh, you mean like all the 'apache newsletter' messages i've received
on just about every single asf list i'm on? <grin/>
Post by Tetsuya Kitahata
In the business world, "inbubation"/"incubator" is rather "ANGEL".
Full of "nurturing", "caring" attitudes towards the "embryo".
funny, that's far from the definition of 'angel' i've inferred from
people who have gone through the process of courting venture capital.
Post by Tetsuya Kitahata
I suspect that the Incubator Project in the ASF is going to the
opposite .... choking the embrio into death.... without sufficient
"OXYGEN".. OH, Scared
by the way, do you have *anything* positive to say about the
incubator? :-/
--
#ken P-)}

Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/

"Millennium hand and shrimp!"
Sam Ruby
2003-10-03 16:12:09 UTC
Permalink
Post by Greg Stein
Post by Tetsuya Kitahata
It seems that the same goes for the JaxMe, too.
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
That <note> section has zero bearing on the wsrp4j pages themselves. I hit
those pages via a link, not the top-level. In the Age of Google, it is
relatively rare to navigate through a menu.
Oh, geez. JaxMe has no notice on its pages either.
To what document do I need to add rule that says "a project ABSOLUTELY
MUST make clear that it is under incubation?" We've already been through
this process where incubated projects are not being clear about their
status; that needs to be captured and retained for ALL incubated projects.
A good start would be http://incubator.apache.org/process.html.
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
-g
- Sam Ruby
Cliff Schmidt
2003-10-03 08:23:31 UTC
Permalink
Post by Rodent of Unusual Size
Post by Cliff Schmidt
"XMLBeans is an incubated subproject under the sponsorship of the
Apache Software Foundation's (ASF) XML project.
it all looks good, except for this. i think i would prefer something
like
'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'
the original uses the past tense and the semantically semi-null
term 'subproject'.
Sounds reasonable. Since I haven't heard any other opinions, we're
going to go with the original + the one change Ken suggested.

I've also taken the liberty to update the IncubatorPolicyDraft wiki
page with the latest text. Aside from adding the paragraph, I've
also made the required word in the filename be "incubating", instead
of "incubator". I thought this better reflected the state of the
code (not an incubator itself, and not already incubated, but still
incubating).

See http://nagoya.apache.org/wiki/apachewiki.cgi?action=browse&diff=1&id=IncubatorPolicyDraft&revision=6&diffrevision=5

Hope that was helpful.

Cliff
Berin Lautenbach
2003-10-03 09:45:53 UTC
Permalink
Post by Cliff Schmidt
Post by Rodent of Unusual Size
'XMLBeans is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the ASF's XML Project.'
the original uses the past tense and the semantically semi-null
term 'subproject'.
Sounds reasonable. Since I haven't heard any other opinions, we're
going to go with the original + the one change Ken suggested.
+1 (FWIW :>)
Post by Cliff Schmidt
See http://nagoya.apache.org/wiki/apachewiki.cgi?action=browse&diff=1&id=IncubatorPolicyDraft&revision=6&diffrevision=5
Hope that was helpful.
Very. And appreciated :>.

Cheers,
Berin
Davanum Srinivas
2003-10-03 12:43:28 UTC
Permalink
Updated http://ws.apache.org/jaxme/ and http://ws.apache.org/wsrp4j with disclaimer text. Please
review.

Thanks,
dims
Post by Tetsuya Kitahata
On Fri, 3 Oct 2003 04:39:00 -0700
Post by Greg Stein
Post by Tetsuya Kitahata
Anyway, please take a glance at
http://ws.apache.org/
... <note> section.
<snip/>
Post by Greg Stein
But what pisses me off the most is that I raised this about wsrp4j a
couple weeks ago, but it wasn't fixed.
Aha, Okay. I think that the folks in wsrp4j just did not know how
to do. It happens all the time. People should not blame ones' ignorance.
Nurturing, caring attitudes would be required, for catching the
developers' heart. ;-)
# This is "INCUBATION" project, not "GOLEM" project ;-)
--
JaxMe folks, wsrp4j folks,
Could it be possible for you to append "Disclaimer" page and left-side
navi for such a page to each pages?
JaxMe: create disclaimer.xml (alike to other xml files) and put it
into xdocs/ directory.
Then, edit xdocs/stylesheet/project.xml (LEFT-SIDE NAVI)
and re-build the site.
WSRP4J: create disclaimer.xml (alike to other xml files) and put it
into src/documentation/content/xdocs/ directory.
Then, edit src/documentation/content/xdocs/site.xml
(LEFT-SIDE NAVI) and re-build the site.
Both "built" files should be put onto the "ws-site" module
(*targets*/XX/ directory)
Editing "index.html/xml" would be also highly appreciated, I think.
http://ws.apache.org/
Hope this helps.
---------------------------------------------------------------------
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Tetsuya Kitahata
2003-10-03 14:23:56 UTC
Permalink
Confirmed. Really great job! (Otsukare sama desita)

-- Tetsuya. (***@apache.org)

P.S. I think you can change the URL of the link to "Pluto"
(@ left-side navi on wsrp4j project website):
http://jakarta.apache.org/pluto/

On Fri, 3 Oct 2003 05:43:28 -0700 (PDT)
(Subject: Re: Disclaimer text for incubated projects)
Post by Davanum Srinivas
Updated http://ws.apache.org/jaxme/ and http://ws.apache.org/wsrp4j with disclaimer text. Please
review.
Thanks,
dims
<snip/>
Noel J. Bergman
2003-10-03 22:50:48 UTC
Permalink
Post by Sam Ruby
I am trying to follow http://incubator.apache.org/process.html
I have asked for this to be updated.
I have asked for information on how I can update this.
Berin Lautenbach is beginning to update the incubator documents. Apparently
you need to use Forrest. Parenthetically, I think that if we're going to
use Forrest, we have to put a publishing system in place, rather than
require each Committer to install it. Steven Noels needs help to Forrestbot
running on moof.

--- Noel
Noel J. Bergman
2003-10-03 23:00:54 UTC
Permalink
To a certain extent, the incubator is evolving, too. If evolving procedures
that are not being disseminated, that's one problem.

I propose that a good way to address this situation will be to make active
use of the new JIRA install, Serge and I have scheduled for next Thursday.
I was just discussing JIRA with Serge Knystautas, and it is possible to set
up reports so that if there is a mandated activity, such as correcting a
license, that report can be sent DAILY, whereas normal bug reports would be
sent weekly. Whenever there is a work item required BY or FOR a project,
under incubation or otherwise, it ought to be entered into the system.

This puts even more emphasis on data reliability. Pier is working on a
backup server for nagoya. Once that is in place, I can setup replication
through an ssh tunnel so that the backup server has real-time replication of
the database on nagoya. We can also do nightly XML exports from Jira and/or
just database dumps from mysql.

--- Noel
Stephen McConnell
2003-10-04 05:57:44 UTC
Permalink
Post by Noel J. Bergman
To a certain extent, the incubator is evolving, too. If evolving procedures
that are not being disseminated, that's one problem.
I propose that a good way to address this situation will be to make active
use of the new JIRA install, Serge and I have scheduled for next Thursday.
+1
This is a really excellent idea.
Stephen.
--
Stephen J. McConnell
mailto:***@apache.org
Nicola Ken Barozzi
2003-10-04 08:12:16 UTC
Permalink
Post by Noel J. Bergman
To a certain extent, the incubator is evolving, too. If evolving procedures
that are not being disseminated, that's one problem.
I propose that a good way to address this situation will be to make active
use of the new JIRA install, Serge and I have scheduled for next Thursday.
IMO it will just obfuscate tasks more. What we need is more simplicity,
not complexity. IMO just keeping STATUS files in the Incubator is simple
enough.

The issue is more about visibility. We have created an incubator CVS and
an incubator-site CVS, but the incubator is only the site, and will
always be like this.

Therefore I propose that we move the STATUS files of incubator CVS into
incubator-site, so that they will be included in the website, then kill
off incubator and rename incubator-site to incubator.
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Noel J. Bergman
2003-10-05 03:53:02 UTC
Permalink
Post by Nicola Ken Barozzi
Post by Noel J. Bergman
To a certain extent, the incubator is evolving, too. If evolving procedures
that are not being disseminated, that's one problem.
I propose that a good way to address this situation will be to make active
use of the new JIRA install, Serge and I have scheduled for next Thursday.
IMO it will just obfuscate tasks more. What we need is more simplicity,
not complexity. IMO just keeping STATUS files in the Incubator is simple
enough.
I had thought of that, and ended up removing the paragraph discussing the
STATUS file because of the differences. I am not trying to complicate the
process. I am proposing what I believe is at least as easy a process, and
which better facilitates active oversight through a more appropriate tool.

The STATUS file is passive. Jira is active. The STATUS file requires the
submitter to have CVS commit access to that module, and CVS knowledge. Jira
has its own access control, and a built-in UI. The STATUS file requires
human parsing to understand the priorities. Jira has a prioritization
model. Updating the STATUS file requires a checkout/update, edit, commit.
Jira would be simply filing an issue via the webapp.

There was a study long ago related to auto-pilots. The initial idea was
that the computer would fly the plane, and the human would monitor its
actions. Turns out that we are particularly poor at monitoring something
that is usually fine; we get bored, and inattentive. It works much better
when the computer is monitoring us, rather than the other way around.

Hence, the active nature of the issue tracker seems a key. It is like the
question of "If a tree falls in a forest, and no one is there to hear, does
it make a sound?" ** If an issue is added to STATUS, and action is not
immediate, will anyone remember? Will the change even be noticed? The
STATUS files are in a common module; to which list are the commit notices
posted? Lastly, I don't think that an inbox makes a good issue tracker.
With high e-mail volumes, if a message isn't acted upon and deleted, once it
scrolls off the screen, there is a tendency for it to be out of sight, out
of mind until the person has time to address the backlog. The issue
tracker, on the other hand, will continue to remind until the task is marked
as completed.

These all contribute to why I suggest that issue tracking is better done
with an issue tracker. So although I had not mentioned the STATUS file in
this context, I had given it thought. I'm interested in your response, and
those of others, to this assessment.

As for the titular topic, I have no problem with the two modules merging.

--- Noel
Nicola Ken Barozzi
2003-10-05 07:45:19 UTC
Permalink
Noel J. Bergman wrote:
...
<snipped why issue trackers are better/>
Post by Noel J. Bergman
These all contribute to why I suggest that issue tracking is better done
with an issue tracker. So although I had not mentioned the STATUS file in
this context, I had given it thought. I'm interested in your response, and
those of others, to this assessment.
What I need is that a secure document about what has been done in the
project is kept in CVS. If that document is used actively as a means to
track issues is not important.

So if a mentor wants to use an issue tracker to help keep track of
issues it's just fine, as long as the information in CVS is updated
every once in a while. When the Incubator will vote the project out, it
will be based on the contents of that file.

Since there seems to be agreement that we should have some sort of
Mentor reporting to the PMC, it would be easy for Mentors to update the
STATUS file at every report.

Does this sound reasonable?
Post by Noel J. Bergman
As for the titular topic, I have no problem with the two modules merging.
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Berin Lautenbach
2003-10-05 07:56:17 UTC
Permalink
Post by Nicola Ken Barozzi
Since there seems to be agreement that we should have some sort of
Mentor reporting to the PMC, it would be easy for Mentors to update the
STATUS file at every report.
Does this sound reasonable?
+1.

One is a tool, the other is the processed information. The PMC probably
only cares about the information and the Mentor/Shepherd can keep that
information in whatever way suits best, provided it is delivered in a
standard format.

The STATUS file is the minimal requirement, allowing the Mentor the
greatest possible flexibility in how they deliver that requirement.

Cheers,
Berin
Roy T. Fielding
2003-10-08 12:19:23 UTC
Permalink
Post by Noel J. Bergman
The STATUS file is passive. Jira is active. The STATUS file requires the
submitter to have CVS commit access to that module, and CVS knowledge.
Jira
has its own access control, and a built-in UI. The STATUS file requires
human parsing to understand the priorities. Jira has a prioritization
model. Updating the STATUS file requires a checkout/update, edit, commit.
Jira would be simply filing an issue via the webapp.
AFAIK, Jira does not authenticate that the person entering the status
information has the authority to do so, which is what we get with the
cvs process.

....Roy
Noel J. Bergman
2003-10-08 14:39:34 UTC
Permalink
Post by Roy T. Fielding
AFAIK, Jira does not authenticate that the person entering the status
information has the authority to do so, which is what we get with the
cvs process.
When I asked Serge, he replied that "You can control what an unauthenticated
person can do. It has very fine grained permission rules." So apparently,
it does do authentication, although we'd want to ensure that the person
claiming to be so-and-so on the issue tracker was really that person. As a
side note, I'll suggest that if we ever move to doing client auth over HTTPS
for Committers, we'd probably want the issue tracker to be capable of using
it, too. However, for the purpose I'm suggesting it be used, does it need
to authenticate?

I suppose that one interesting issue with the STATUS file is its purpose /
how to use it. The HTTPd project, since I just looked at the STATUS file
for httpd-2.0, seems to use it to record some bugs, list current project
status as a snapshot, record votes on decisions, etc. In some ways, it
appears that HTTPd uses the STATUS file as an issue tracker, and the CVS
preserves the historical record (e.g., when things are removed). Other
projects use bugzilla or (increasingly) Jira, and make far less use of the
STATUS file. What should be normative use is certainly not clear to me.
Nor to Serge when he asked me about it.

I would expect the primary use for the STATUS file in the incubator module
to be the project's incubation status.

I agree with Nicola Ken (and you) about using the STATUS file for project
status, and had originally thought to suggest that such change requests
could be entered into the STATUS file, too. However, it seems to me that an
issue tracker is better for managing for requests/action items. The project
using it can always reject the request. And I would expect, as a general
rule, that requests coming into a project will often be from people who
don't have authorization to either mandate the request or to change a STATUS
file, although in this instance, Greg certainly had both.

Is a request that a particular change be made to the web site a STATUS item
or a work item? FWIW, there was no change made even to the STATUS file
AFAIK. There was an e-mail, which was missed and/or not acted upon. An
issue tracker would not permit that to happen. The active nature of the
issue tracker is some thing that I feel provides a distinct advantage over
the STATUS file for tracking requests.

The ASF has different projects doing things differently. In my opinion, one
of the interesting things with Incubator is that the Incubator is going to
bring out those differences, and help to illuminate best practices across
the ASF, not just for new projects.

--- Noel
Nicola Ken Barozzi
2003-10-08 15:02:47 UTC
Permalink
...
Post by Noel J. Bergman
I agree with Nicola Ken (and you) about using the STATUS file for project
status, and had originally thought to suggest that such change requests
could be entered into the STATUS file, too.
I have checked in the incubator CVS a new version of the Incubator site,
with a proposed new layout.

I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be effectively
used for identifying action items in order?

We could use a status.xml file that contains information about who does
things, todos, and changes. The less nice side is that it's XML.

Ideas?

...
Post by Noel J. Bergman
The ASF has different projects doing things differently. In my opinion, one
of the interesting things with Incubator is that the Incubator is going to
bring out those differences, and help to illuminate best practices across
the ASF, not just for new projects.
True. But some things need to be taken into account nevertheless.

1 - security (authentication, authorization)
2 - history
3 - backups
4 - change messages to the Incubator Project
5 - one place to have all items tracked

CVS gives all of these, and IMHO no issue tracker can easily be made to
do it. In any case, we are not talking about 200 action items, but 20.
And as I said, they are free to *also* use an issue-tracker, as long as
the mentor reports these in CVS in a reasonabe timeframe (ie a couple of
weeks)
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Noel J. Bergman
2003-10-09 06:37:02 UTC
Permalink
Post by Nicola Ken Barozzi
Post by Noel J. Bergman
I agree with Nicola Ken (and you) about using the STATUS file for project
status, and had originally thought to suggest that such change requests
could be entered into the STATUS file, too.
I have checked in the incubator CVS a new version of the Incubator site,
with a proposed new layout.
Can you post a live copy to your home page or somewhere?
Post by Nicola Ken Barozzi
I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be
effectively used for identifying action items in order?
Be happy to do so. Of course, you won't be getting this until about 15
hours after you posted, but yes.
Post by Nicola Ken Barozzi
We could use a status.xml file that contains information about who does
things, todos, and changes. The less nice side is that it's XML.
Ideas?
Well, I want to hear Roy's thoughts, because the HTTP Server project seems
to do a lot more in STATUS than most other projects. Personally, I would
record in the STATUS file the incubation related information. Particularly
issues related to status of legal issues, completion of exit criteria, and
any other information that the Incubator PMC felt was important. At the
least, the STATUS file will naturally be polled by the PMC for each review
cycle. If the project chooses to copy the STATUS items into an issue
tracker so that they'll receive periodic reminders of outstanding items,
that would be their choice, but the only official document would be the
STATUS file. Since you want to use XML, if the XML were defined properly,
someone could write a tool to generate a report of all outstanding items.
But I don't think that we want to get into the process of building yet
another ad hoc issue tracker.

Or we could stick with plain text. From what I think we are saying
(including below), the original status file could come from a template,
customized if/as necessary by the PMC and placed into the incubator CVS
module.
Post by Nicola Ken Barozzi
Post by Noel J. Bergman
The ASF has different projects doing things differently. In my opinion, one
of the interesting things with Incubator is that the Incubator is going to
bring out those differences, and help to illuminate best practices across
the ASF, not just for new projects.
True. But some things need to be taken into account nevertheless.
1 - security (authentication, authorization)
2 - history
3 - backups
4 - change messages to the Incubator Project
5 - one place to have all items tracked
CVS gives all of these, and IMHO no issue tracker can easily be made to
do it.
AFAIK, a good issue tracker (bugzilla notwithstanding) will do all of the
above. But I'm *not* saying that we should use an issue tracker for
incubation status. For one thing, we trust CVS and we don't afford any of
the issue trackers the same degree of trust.

So what, specifically, are we talking about in terms of your item #5? The
fact that you say "we are not talking about 200 action items, but 20" leads
me to believe that we're in agreement, and talking about the status of items
related to incubation. And those we agree should be recorded in the STATUS
file.
Post by Nicola Ken Barozzi
they are free to *also* use an issue-tracker, as long as
the mentor reports these in CVS in a reasonabe timeframe
We appear to be saying the same things, yes?

--- Noel
Nicola Ken Barozzi
2003-10-09 08:20:06 UTC
Permalink
Post by Noel J. Bergman
Post by Nicola Ken Barozzi
Post by Noel J. Bergman
I agree with Nicola Ken (and you) about using the STATUS file for
project status, and had originally thought to suggest that such
change requests could be entered into the STATUS file, too.
I have checked in the incubator CVS a new version of the Incubator
site, with a proposed new layout.
Can you post a live copy to your home page or somewhere?
Ok, but the source files are also important, as they are what we will be
actively working with.

http://www.apache.org/~nicolaken/whiteboard/incubator-draft-new-site/index.html
http://cvs.apache.org/viewcvs.cgi/incubator/src/documentation/content/xdocs/projects/

BTW, IMHO that FAQ is atarting to come along nicely:
http://www.apache.org/~nicolaken/whiteboard/incubator-draft-new-site/faq.html
Post by Noel J. Bergman
Post by Nicola Ken Barozzi
I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be
effectively used for identifying action items in order?
Be happy to do so. Of course, you won't be getting this until about 15
hours after you posted, but yes.
:-)
Post by Noel J. Bergman
Post by Nicola Ken Barozzi
We could use a status.xml file that contains information about who does
things, todos, and changes. The less nice side is that it's XML.
Ideas?
Well, I want to hear Roy's thoughts, because the HTTP Server project seems
to do a lot more in STATUS than most other projects. Personally, I would
record in the STATUS file the incubation related information. Particularly
issues related to status of legal issues, completion of exit criteria, and
any other information that the Incubator PMC felt was important. At the
least, the STATUS file will naturally be polled by the PMC for each review
cycle. If the project chooses to copy the STATUS items into an issue
tracker so that they'll receive periodic reminders of outstanding items,
that would be their choice, but the only official document would be the
STATUS file.
+1
Post by Noel J. Bergman
Since you want to use XML, if the XML were defined properly,
someone could write a tool to generate a report of all outstanding items.
But I don't think that we want to get into the process of building yet
another ad hoc issue tracker.
Forrest already has a todo-changes-etc DTD that outputs the items. The
upside is that the changes also produce an RSS feed.
Post by Noel J. Bergman
Or we could stick with plain text. From what I think we are saying
(including below), the original status file could come from a template,
customized if/as necessary by the PMC and placed into the incubator CVS
module.
That's what I have done now, but the current STATUS files are IMHO not
suitable for the task.

In any case, I think that plaintext is needed here, so eventually I'll
have also a text version of the above-stated DTDs so we can have the
best of both worlds.
Post by Noel J. Bergman
Post by Nicola Ken Barozzi
Post by Noel J. Bergman
The ASF has different projects doing things differently. In my
opinion, one of the interesting things with Incubator is that the
Incubator is going to bring out those differences, and help to
illuminate best practices across the ASF, not just for new
projects.
True. But some things need to be taken into account nevertheless.
1 - security (authentication, authorization)
2 - history
3 - backups
4 - change messages to the Incubator Project
5 - one place to have all items tracked
CVS gives all of these, and IMHO no issue tracker can easily be made to
do it.
AFAIK, a good issue tracker (bugzilla notwithstanding) will do all of the
above.
Through SSH? Can I easily point to a doc that shows what has been done
in, let's say, 5 years from now?
Post by Noel J. Bergman
But I'm *not* saying that we should use an issue tracker for
incubation status. For one thing, we trust CVS and we don't afford any of
the issue trackers the same degree of trust.
Exactly, agreed.
Post by Noel J. Bergman
So what, specifically, are we talking about in terms of your item #5? The
fact that you say "we are not talking about 200 action items, but 20" leads
me to believe that we're in agreement, and talking about the status of items
related to incubation. And those we agree should be recorded in the STATUS
file.
Exactly. The STATUS files of the projects in the incubator site CVS are
about *incubation* STATUS.
Post by Noel J. Bergman
Post by Nicola Ken Barozzi
they are free to *also* use an issue-tracker, as long as
the mentor reports these in CVS in a reasonabe timeframe
We appear to be saying the same things, yes?
Yup :-)
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Berin Lautenbach
2003-10-10 11:08:04 UTC
Permalink
Post by Noel J. Bergman
cycle. If the project chooses to copy the STATUS items into an issue
tracker so that they'll receive periodic reminders of outstanding items,
that would be their choice, but the only official document would be the
STATUS file. Since you want to use XML, if the XML were defined properly,
someone could write a tool to generate a report of all outstanding items.
But I don't think that we want to get into the process of building yet
another ad hoc issue tracker.
Or we could stick with plain text. From what I think we are saying
(including below), the original status file could come from a template,
customized if/as necessary by the PMC and placed into the incubator CVS
module.
Apologies for coming in late on the conversation - have been away from
e-mail.

I think everyone is agreeing - but one other thought that comes to mind
that supports a text STATUS file is that it is the minimal possible
requirement.

So if we want to put a process/policy requirement in place, this is the
one that makes sense. It can be implemented using a status tracker, or
by processing an XML file - i.e. in whatever way the mentor/podling
think is best for their incubation effort. If we start saying we want
this tool or that then things start getting messy.

Doesn't mean that the Incubator can't point people to a favourite
tracker as a tool - just means it's a suggestion, not a requirement.

Cheers,
Berin
Roy T. Fielding
2003-10-11 00:59:21 UTC
Permalink
Post by Nicola Ken Barozzi
I have checked in the incubator CVS a new version of the Incubator
site, with a proposed new layout.
I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be effectively
used for identifying action items in order?
We could use a status.xml file that contains information about who
does things, todos, and changes. The less nice side is that it's XML.
I don't mind xml, but I am somewhat concerned about placing the STATUS
information where end-users are expected to look. A project's detailed
status within incubator should only be of interest to the developers and
incubator pmc. In particular, I wouldn't want people to feel the need
to dumb-down or generalize its content for the sake of user
documentation,
as is often done with website content. OTOH, it would be really nice
to replace the big text checklist with a table-formatted list, and I'd
like to reduce the number of redundant directories in the incubator
module so that people won't have to search all over for relevant bits.

BTW, having to dig way down to src/documentation/content/xdocs
just to get to the top of the website source seems a bit ridiculous.
Why are the site sources in both incubator and incubator-site?

....Roy
Noel J. Bergman
2003-10-11 02:50:09 UTC
Permalink
Post by Roy T. Fielding
Why are the site sources in both incubator and incubator-site?
Nicola Ken had indicated his plan to move the site into incubator, and to
eliminate the site module. The two top level directories would be the site/
and the projects/.

--- Noel
Nicola Ken Barozzi
2003-10-11 08:22:17 UTC
Permalink
Post by Roy T. Fielding
Post by Nicola Ken Barozzi
I have checked in the incubator CVS a new version of the Incubator
site, with a proposed new layout.
I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be effectively
used for identifying action items in order?
We could use a status.xml file that contains information about who
does things, todos, and changes. The less nice side is that it's XML.
I don't mind xml, but I am somewhat concerned about placing the STATUS
information where end-users are expected to look. A project's detailed
status within incubator should only be of interest to the developers and
incubator pmc.
Hmmm, you mean that we should not publish the status files on the
website? If this is the case I disagree, as it's important that on
public docs we are as transparent as possible.
Post by Roy T. Fielding
In particular, I wouldn't want people to feel the need
to dumb-down or generalize its content for the sake of user documentation,
as is often done with website content.
I agree on this. In fact that's why I'm trying to come up with a
"standard" status doc, that would reflect only the incubation items, and
link to the project website for more info.
Post by Roy T. Fielding
OTOH, it would be really nice
to replace the big text checklist with a table-formatted list,
ACK
Post by Roy T. Fielding
and I'd
like to reduce the number of redundant directories in the incubator
module so that people won't have to search all over for relevant bits.
That's the idea, to have a single directory with all the incubator docs.
Have also a 1-1 mapping with the website, so that we know where to look
for and where to change docs.
Post by Roy T. Fielding
BTW, having to dig way down to src/documentation/content/xdocs
just to get to the top of the website source seems a bit ridiculous.
That's the standard position, as projects usually have lots of other
artifacts. I can change it though, and having felt the same thing, will.
Post by Roy T. Fielding
Why are the site sources in both incubator and incubator-site?
I am moving the incubator stuff in only one place, ie incubator. But
it's a WIP, so I also kept the other site. The new proposed site in in
inbcubator CVS.

BTW, I wrote two mails about it on this list, did you miss them? I mean,
are we still having problems with mails?
--
Nicola Ken Barozzi ***@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Berin Lautenbach
2003-10-11 08:29:52 UTC
Permalink
Post by Nicola Ken Barozzi
BTW, I wrote two mails about it on this list, did you miss them? I mean,
are we still having problems with mails?
I seem to be getting the odd mail bounced after five days of trying?

Cheers,
Berin
Tetsuya Kitahata
2003-10-08 15:46:12 UTC
Permalink
On Wed, 8 Oct 2003 10:39:34 -0400
Post by Noel J. Bergman
The ASF has different projects doing things differently. In my
opinion, one of the interesting things with Incubator is that the
Incubator is going to bring out those differences, and help to
illuminate best practices across the ASF, not just for new projects.
Quite agreed. Bravo!

This is exacly what I wanted to express by my `POOR' Eng*r*ish.

Also, I am sure that the point is that those who would relate to the
ASF should get aware of the fact that the different rules
should be applied to differed *gradation* (STATUS?) of each projects.

For example, HTTP Server project is matured enough. There
would be less "new function requirements" than those of all the jakarta
sub-projects. Long History ... and all the committers (nearly equalled
to ASF members) really deserve to be respected by other OSS
communities and members. However, the rule which would be the best
to HTTP Project is not necessarily the best to Jakarta (and Java world).
Jakarta requires "SPEED", on the other hand, HTTP Project requires
"STABILITY" ... Different rules should be applied as a matter of course.
However, there would be also needed "consistency" as projects
under ASF umbrella. (Legal issues, etc.) Training ourselves to find it
out with our own eyes where exists the diverging point of "diversity"
and "consistency" would be necessary, I suspect.

Understanding "heterogeneousness" as well as "differentials"/"diversities"
and the attitude of the respects to each other would be highly
appreciated in this apache (apatchy!?) community, I am sure, and
sublimation of such heterogeneousness into "evolution" would be ultimate
destination for us. The Incubator Project would be sure to provide
such a "experimental" place for all the developers/committers/members
who DO love apache.org and who DO want to contribute to and get
involved in the societies, opensource communities :-)


Peace,


-- Tetsuya. (***@apache.org)

P.S. You may "s/Jakarta/XML/" or "s/Jakarta/WS/" ... ;-)

---------------------------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: ***@apache.org http://www.terra-intl.com/
Apache Software Foundation Committer: http://www.apache.org/~tetsuya/
Noel J. Bergman
2003-10-09 06:37:06 UTC
Permalink
Post by Tetsuya Kitahata
Post by Noel J. Bergman
The ASF has different projects doing things differently. In my
opinion, one of the interesting things with Incubator is that the
Incubator is going to bring out those differences, and help to
illuminate best practices across the ASF, not just for new projects.
Also, I am sure that the point is that those who would relate to the
ASF should get aware of the fact that the different rules
should be applied to differed *gradation* (STATUS?) of each projects.
You may not have realized that the STATUS file is actually a specific file
in the CVS module named STATUS. I don't agree that rules should be
different because the HTTP Server project should be about stability, and
other projects should be about rapid development. ASF software is supposed
to be something you can count on. Each package may not scale to enterprise
size, but each should strive for enterprise quality in any stable release.
Do you imagine that Tomcat, Xerces, and Axis should be anything less than
stable?

My point was not that the HTTP Server project does things differently
*because ...*. It was simply an observation that various projects do things
differently. My comment was about what is, not what should be. For
example, one rule is that the PMC is supposed to approve a release. Just
because not all projects know about or practice the rule doesn't mean that
they shouldn't.

Here in the Incubator, we are trying to teach best practices to new
projects. Since we come from different ASF projects, this nexus is where
project differences become more apparent, and where we can try to document
best practices not only for new projects, but also to disseminate to
existing ones.

I don't believe that there is any disagreement over the use of the STATUS
file. The STATUS file should be the official document regarding incubation
status for a project. AFAIK, Nicola Ken is saying the same thing, and
emphasized that he is talking about a score of items important to the PMC.
If anything, the question is what else to do in the STATUS file compared to
an issue tracker.

The HTTP Server project probably makes the fullest use of the STATUS file of
any ASF project, and I'd like to know more about their practices, since I
mostly see what goes on in Children of Jakarta projects.

--- Noel
Continue reading on narkive:
Loading...