cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [1.8] Let's get this right
Date Wed, 13 Sep 2000 20:32:33 GMT
On Wed, 13 Sep 2000, Robin Green wrote:

> 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.

what we've done in the past is once the code is pretty stable and we want
to release, stefano tests it under apache/win, i test it under
apache/linux, and if everything seems fine, we push it out. sure, a more
formal testing procedure would be nice, but we haven't exactly been
swamped with offers by highly responsive people to test on other platforms
- nor do we have much of a test suite.

> >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.)

that problem plagues all software development. the best we can do is to
not change contracts/APIs between layers without significant advance
warning. i think we've done a great job on that so far.

> 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.

i disagree. i've got a whole slew of bug fixes to xinclude processor, sql
logicsheet, and a new esql logicsheet. no one using cocoon-1.8dev has
reported any problems. release early, release often - i like that motto.

> So how about defining two variables that we should test.

[ discussion of formal testing snipped ]

if you want to spearhead that, you the man. i don't have the time to
devote to it.

> 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

+1. are you gonna fix or is this open-ended?

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

+1, that's easy

> 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)

-1, we don't need to hold up a release for this, just update the web
site. of course if it's ready now, no reason not to include it.

> 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! ;)

-1, ditto

> 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).

wasn't aware there were any synch. bugs in Engine - did i miss this
discussion? if the bugs have been there for awhile, then i'd vote -1,
let's release, then test the patches extensively and release 1.8.1.

> 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".

-1, that's a heavy duty change, save it for 1.8.1

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

-1, it's also open-ended. i want 1.8 out the door! we know it's not
perfect, but it's definitely a step forward. :) also, i _know_ there are
people using 1.7.4 on production sites who haven't removed
ProducerFromRequest - and we're still shipping 1.7.4 with insecure default
settings. let's release a secure 1.8 and start work on 1.8.1.

> 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.

need help, i'm here. it wasn't 100% obvious to me how to set it up. :)

i'm sure we can reach a good compromise on releasing 1.8 - but i really
don't want to hold it up for everything on your list - we've been
essentially ready to release it for over a month now.

- donald


Mime
View raw message