Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
From: "Robin Green" <greenrd@hotmail.com>
To: cocoon-dev@xml.apache.org
Subject: [1.8] Let's get this right
Date: Wed, 13 Sep 2000 10:49:10 BST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F200M1j8vxNZTZPxrM300009cc0@hotmail.com>

-1 on releasing now.

In fact, there's one very good reason why we _can't_ release right now - the 
docs won't build! Fixing that is my #1 development priority right now.

Beyond that, are there any other critical showstoppers? Well, not that I'm 
aware of (but see below!). However, Uli makes a very good point:

>What does - in the case of cocoon - mean "to release it"? Is it just that
>an archive is built of the current code and a version number slapped onto
>it? In that case, why not automatically release a new version each night?
>
>Or is there, in fact, some testing going on and only if it has been proved
>stable, it is released?

I have been given to understand that only the person who prepares the 
release actually tests the release - relying on the fact that other people 
will have been using CVS versions for weeks. So, it's very informal. This 
could be changed.

>In that case could you publicize the platforms you
>are testing cocoon with? I think it is vital for 3rd party developers to
>know what platform to shoot for with their code.
>
>Also, I don't want to install a new cocoon version some day and one old
>cocoon app in a faraway corner of our server suddenly stops working and
>no-one notices, until the damage has been done.

Exactly. This is a big worry of mine too. (Not so much with Cocoon itself 
but with classes I've written to run in a cocoon environment - but that's 
another story.)

Cocoon is more and more being used in production sites (see livesites and 
there must be a fair few more that we don't know about!), so why not just 
have a few days official testing period on cocoon-dev? No need to rush it 
forward a few days just because of a feeling that "a release is long 
overdue" - which it is, I agree, but not _desperately_ so.

So how about defining two variables that we should test.

1. We need to know that it builds and runs on both a Windows OS and a 
Unix-class OS. This is not completely academic - we've had problems like 
CRLF terminators etc. in the past.

2. Servlet engines:
a) Tomcat is designated by Sun as the official reference implementation of 
the Servlet API, so this is a no-brainer
b) JServ - still widely used, and is 2.0 as opposed to Tomcat which is 2.2.
c) one other - suggestions?

Again, not academic - one of the taglibs doesn't have 2.0 compliance right 
now. If we could just ensure that the candidate release worked on two OSes, 
and 3 specified engines (no need to test all 6 combinations), that would be 
a step in the right direction.


Beyond testing, I would also like to hold up the release for at least _some_ 
of the following things which I think are quite important:

1. Get docs to build, as mentioned above

2. Ensure that the new mailing list archive URL replaces the old one 
completely (I haven't seen the cvs-commit for that yet)

3. Add some common-sense recommendations to the mailing list page (search 
the FAQ and the archive first; use informative Subject lines; don't keep 
reposting too often; don't post user questions to cocoon-dev except in 
special cases)

4. I've done an expanded FAQ with new answers, split into sections (needs 
tweaking the faq DTD and Stylebook though), with persistent fragment IDs for 
posting to the mailing lists, which together with (3) should help people 
find answers faster AND increase the signal-to-noise ratio on the users list 
(AND let me keep my sanity! ;)

5. Commit the fixes to the synchronization bugs in Engine.java (which could 
cause pages to block indefinitely) and the primitive profiler (this all 
comes as one patch so it would be more work to separate them than just to 
commit them).

6. (Can drop this for this release if people think best, but it is a 
highly-requested feature and very useful!). Configurable and optional class 
auto-reloading for user classes in XSP pages. This code has been well-tested 
in my last employer's system. I will add a prominent warning to the docs 
that this must be used with care because of dangers of memory bloat (totally 
utterly separate class objects are created for each page, as separate as 
webapps in catalina). Fortunately you can split up classes into "reload 
this" and "do not reload these, to conserve memory".

7. Fix all known cacheing bugs once and for all - I think this is doable.

If you're wondering why I still haven't committed anything yet, same reason 
- still need to setup linux to commit (dialup config, ssh, cvs etc.) I'm 
getting there - should be ready tommorow.


Stefano, I'd be happy to do the mechanics of the release as you requested - 
but only if I was happy that it wasn't being too rushed! ;)  And of course 
I'm happy to be cocoon-users moderater regardless.

--
Robin

P.S. Uli - if you want to contribute to this discussion, ensure that you're 
subscribed to cocoon-dev.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.