On Thu, 16 Aug 2001, Berin Loritsch wrote:
> "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).
+1 on this. I'm trying to get familiar with XEmacs for DocBook editing
ATM.
>
> > 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.
This would indeed be a great improvement
Giacomo
>
> 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]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
