"Morrison, John" wrote:
>
> >
> > So here is my suggestion:
> > - Making another beta which should include the points mentioned below
>
> Is this with regards to b2 or a new b3?
b2 is already released, I believe a b3 is in order.
> > What do we need for the next beta?
> > - Incorporate all outstanding patches and bugfixes (Dims has already
> > requested for this).
> > - Fix all outstanding bugs
>
> Listed in 'bugzilla'? (if you have a URL I'd appreciate it!)
Here you go!
http://nagoya.apache.org/bugzilla/index.html
> > - Decide which parts of C2.1 should go into 2.0
>
> I get the feeling that this has been done as people have gone along...
I agree. I don't think there is anything that hasn't been asked already
that should be back-ported.
> > - Update documentation. This point needs the most work, I think. The
> > documentation is currently a bit crowded. For example we have the
> > Sitemap documentation which explains all sitemap components, but
> > for matchers, selectors and actions there are different documents.
> > This should be unified and we should split the documentation into
> > user and developer documentation. The user docs mainly for
> > installing,
> > configuring and using c2 by creating own pipelines and using the
> > existing components.
> > The developer doc should contain everything needed for building
> > own components.
>
> Yeah, I think. Lot's a work though for somebody who knows the system inside
> and out.
What about adopting Avalon's documentation build strategy. It's great PR
for a project to generate its own documentation! Besides, you would have a
nice migration path to DocBook (there is a StyleBook to DocBook stylesheet
included in Avalon).
> Question: could we do this in two phases; user docs then developer? Could
> you come up with some section headings/toc? If we (well, you until I get
> ssh through the firewall ;) committed an outline document would other
> developers help to flesh it out?
Documentation planning is an excercise that is vital, and really helps the
end user. The only documentation that was actually planned for Avalon is
the "Programming with Avalon" documentation. It is very logical, and easy
to follow. I would use that as a template for how to go about writing the
docs. I started putting together developer documentation for Cocoon internally
a while ago. I need to flesh it out, and remove references to my company's
documents--but it should be a great start. I wanted to give Cocoon the
same treatment I gave the Avalon documentation.
Truthfully, there should be three different types of documentation:
1) Installation and Configuration
2) Designing with Cocoon (including webapp development)
3) Cocoon Internals (how to program Cocoon itself)
Again, the URI space needs to be mapped, and planned. Documentation is a
big step. I have some "unplanned time off" soon, so I'll see what I can
do while I find another employer (don't you just love it when your company
runs low on clients).
> > - Final versions of the other projects used by c2, mainly these
> > are Avalon Excalibur, Avalon LogKit and Xalan. Perhaps we must also
> > update to a newer FOP version.
>
> How close are these? I know FOP is a 'long' way off.
Avalon Excalibur is going to have one more Beta release with the new Thread
Pooling code and the new Resource Monitoring code once it is sufficiently
tested.
Avalon LogKit was recently released as Beta 4. We might have one last
beta release of that before final. In all we are looking at least a month
in the future.
As to Xalan and FOP, I am not sure.
> > - Layout the distribution: What files in which format should really
> > get into the distribution. As everybody has the recompile the dist
> > to get the examples (in detail the sql examples) running, I think
> > we shouldn't include a half binary dist. We should only distribute
> > the sources, the required libraries, examples and (perhaps build)
> > documentation.
>
> Could we get the parameters for the database to be 'picked up' from the
> web.xml file? That would save folks from having to build it themselves,
> either that or, in the binary dist disable the demo samples with a comment
> as to why?
I don't think so--at least not with hsql database.
> > I would propose to schedule the next (and hopefully final) beta for
> > the end of september, so we have the final release at the end of
> > October (the former ApacheCon Europe date....).
> >
> > Thoughts? Comments? Suggestions?
That actually sounds like a good timeframe. LogKit will be final by
then (hopefully), and Excalibur will most likely reach the proper maturity
by then.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
