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