leosimons 2003/01/27 05:34:37
Modified: src/documentation/content/xdocs/project book.xml
Added: src/documentation/content/xdocs/project patches.xml pmc.xml
releases.xml roadmap.xml
Log:
docs docs docs, gotta like docs
docs docs docs, forrest really rocks
docs docs docs, better link than copy-paste
docs docs docs, please customize to taste
docs docs docs, they're never up-to-date
docs docs docs, but we're trying as of late!
Revision Changes Path
1.2 +1 -1
jakarta-avalon-site/src/documentation/content/xdocs/project/book.xml
Index: book.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-site/src/documentation/content/xdocs/project/book.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- book.xml 25 Jan 2003 18:19:51 -0000 1.1
+++ book.xml 27 Jan 2003 13:34:37 -0000 1.2
@@ -8,7 +8,7 @@
<menu label="Basics">
<menu-item label="Index" href="index.html"/>
- <menu-item label="Our Mission" href="mission.html"/>
+ <menu-item label="Our Mission" href="../mission.html"/>
<menu-item label="Project History" href="../history/index.html"/>
<menu-item label="Meritocracy"
href="http://jakarta.apache.org/site/decisions.html"/>
<menu-item label="High esteem"
href="http://dictionary.reference.com/search?q=esteem"/>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/project/patches.xml
Index: patches.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Avalon project: Release Planning</title>
</header>
<body>
<section>
<title>Not written yet....</title>
<p>We haven't got our release process written down yet.</p>
</section>
<section>
<title>Relevant links</title>
<ul>
<li><link href="http://jakarta.apache.org/site/decisions.html";>Jakarta decision
process</link></li>
<li><link href="http://httpd.apache.org/dev/release.html";>HTTPD release
policy</link></li>
<li><link
href="http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&output=most_doomed&links=1&banner=1&quip=0";>Bug
summary</link></li>
<li><link href="http://cvs.apache.org/~bodewig/mirror.html";>Distribution Mirroring
howto</link></li>
<li><link href="http://cvs.apache.org/builds/";>Nightly builds</link></li>
<li><link href="http://gump.covalent.net/jars/latest/";>Nightly builds:
jars@covalent</link></li>
<li><link href="http://freshmeat.net/articles/view/392/";>Freshmeat on software
builds</link></li>
<li><link href="http://java.sun.com/docs/books/tutorial/jar/sign/signing.html";>Java
tutorial: jar signing</link></li>
<li><link href="http://java.sun.com/j2se/1.4/docs/tooldocs/tools.html#security";>JDK
Security tool docs</link></li>
<li><link
href="http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/RELEASE-PLAN-4.1.txt";>Tomcat
4 release plan</link></li>
<li><link
href="http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/Attic/Avalon-4.0-RELEASE-PLAN";>Framework
4 release plan</link></li>
</ul>
</section>
<section>
<title>Noel's thoughts</title>
<p>Noel J Bergman wrote to avalon-dev:</p>
<source>
Q: "Is the Avalon PMC able to define a coordinated Release of all the A4
modules such that we know that they all work together?"
My primary concern is not the code, but whether or not the Avalon PMC is
ready to act on its responsibilities, and do a coordinated Release of A4. I
firmly believe that the Avalon PMC has a responsibility to determine a
consistent set of packages that work together, rather than leave it as a
Chinese menu for users to figure out.
My suggestion is that the Avalon Community make it a priority to take stock
of A4, put together a Release Plan, designate a Release Manager, and act as
a group to do a Release. Here are a few items to consider for the Release
Plan:
1) Identify bugs and incompatibilities.
2) Decide which ones will be fixed.
3) Decide what other changes are necessary, e.g., packaging.
4) Make the code changes.
5) Test
6) Update the documentation and web site.
The documentation on the web site doesn't appear to reflect the past year's
changes. And I'm still bemused over how a COP platform that "is a framework
that allows components of varying scale to be created, managed [and] used"
is going to explain why Component is deprecated. But
Here are a few useful links:
Jakarta: http://jakarta.apache.org/site/decisions.html
Apache HTTPD release policies: http://httpd.apache.org/dev/release.html
Avalon bug summary:
http://nagoya.apache.org/bugzilla/reports.cgi?product=Avalon&output=most_doo
med&links=1&banner=1&quip=0
Mirroring: http://cvs.apache.org/~bodewig/mirror.html
Subsequent to the Release, I would suggest that the Avalon Community
consider how best to focus its resources. From what I seem to be hearing
from Paul and others regarding the state of the code and the possibilities
for proper interoperation between A4 containers, I am beginning to believe
that the best option is for the Community to put A4 in maintenance mode, and
focus on A5. But, again, that is something for the Avalon Community to
decide after doing a Release.
--- Noel
</source>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/project/pmc.xml
Index: pmc.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Avalon project: The Avalon PMC</title>
</header>
<body>
<section>
<title>Informative material only</title>
<p>These pages exist only to provide some down-to-earth insight
in how things work at the ASF. They're informative only, not
normative. They may contain errors or inadequacies. IANAL.</p>
</section>
<section>
<title>So what is this PMC thing?</title>
<p>Apache is a legal entity, ie a real non-profit organisation,
with a charter, members, a board, a president, etc etc. You can
read all about that
<link href="http://www.apache.org/foundation/";>here</link></p>
<p>A PMC, Project Management Committee, is a group of people
appointed with the task of managing someting that fits with the
apache software foundation goals. The Avalon PMC, for example,
is tasked with managing avalon.</p>
</section>
<section>
<title>What, management?! We've already got plenty of those at
work!</title>
<p>We're all programmers, and that is what we want to occupy us
with. We like to share and work on our software together, which
is why we make it free software. However, there is always some
stuff which still requires management.</p>
<p>For example, in order to protect ourselves and our users, all
software hosted at apache must be properly copyrighted to the ASF,
and licensed under the ASF license. This is something the PMC is
responsible for.</p>
<p>Also, remember that the PMC consists of the same people that do
the development work. There's no "bossing around" here. The PMC
exists only to facilitate free software developers in "doing their
thing", just like the ASF exists "to provide organizational, legal,
and financial support for the Apache open-source software
projects".</p>
</section>
<section>
<title>The PMC Chair and Officer of the Foundation</title>
<p>The position of Avalon PMC chair is an important one; the PMC
chair has special responsibilities and priviledges as detailed in
the ASF bylaws.</p>
</section>
<section>
<title>So, who's on the PMC?</title>
<p>This information is contained in the avalon STATUS file, and
also <link href="../whoweare.html">on this page</link>.</p>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/project/releases.xml
Index: releases.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Avalon project: Patches and Bugrepors</title>
</header>
<body>
<section>
<title>Bugzilla!</title>
<p>It's not perfect. But it is the issue tracking system we use, and
we ask that you do, too.<br/>
<br/>
<b><link
href="http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Avalon&version=unspecified&rep_platform=all&op_sys=all&[EMAIL PROTECTED]";>Enter
a bug</link></b><br/><br/>
but please make sure the bug you're reporting doesn't exist yet, you
include
all relevant information, etc etc. See
<link
href="http://nagoya.apache.org/wiki/apachewiki.cgi?HowDoISubmitUsefulBugReports";>this
page</link>
for more on how to submit bug reports, or try google.</p>
</section>
<section>
<title>Submitting patches</title>
<p>Generate patches using <code>cvs diff -u</code>, or <code>diff
-u</code>.
Please create your patches relative to the root of the cvs module the patch
should be applied to. Please compile changes to multiple files
in a single patch file. Make sure the patch adheres to the coding
standards,
and includes appropriate javadoc.</p>
<p>When you've built the patch, file a new bug report in bugzilla if one
does not exist yet, explain the reason behind the patch, how the patch
fixes
the issues, and add the patch as an attachment.</p>
<p>If your patch is not getting applied or there is no response, start
nagging
the developers (politely, please :D) on the development mailing list.</p>
<section>
<title>Documentation patches</title>
<p>Please submit documentation patches against the xml sourcefiles used
for generating the documentation, and not against the documentation
itself.</p>
</section>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/project/roadmap.xml
Index: roadmap.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Apache Avalon project: Development Roadmap</title>
</header>
<body>
<section>
<title>Not written yet....</title>
<p>We haven't got a formal roadmap. The plan is something like
(the below taken from the STATUS file):</p>
<source>
Avalon will be focussing container development into two efforts.
The first one is the creation of Avalon ESCA. To this end, most
existing avalon container projects will refocus to be part of
that goal.
The roadmap for this effort is roughly as follows:
- Milestone 1: ECM replacement (Codename: Fortress)
- Milestone 2: Proper Meta Model (Codename: Merlin3)
- Milestone 3: Phoenix Compatible (Codename: Phoenix5)
- Milestone 4: Profileable, pluggable container (Codename: Spearhead)
The second container development effort is the maintainance of existing
released efforts with an existing userbase, ie phoenix. This will merge
into the ESCA effort when there is an ESCA release compatible with
those existing efforts.
====================================================================
ECM --> Fortress --> Merlin3 --> Phoenix5 --> Spearhead --> ...
^ ^ ^
| : |
Merlin1+2 (unreleased)-| : |
All other | :(synergy) |
container dev code -/ : |
: |
Phoenix4 -------------------------------/
====================================================================
</source>
</section>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
