cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [1.8] Let's get this right
Date Thu, 14 Sep 2000 13:06:41 GMT
Robin Green wrote:
> 
> -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.

You are welcome to try to do so. I tried for months, asking for people
to do testing on their platforms before release and NOTHING! SILENCE!

It's open source, damn it, if the release is not stable we make a new
one, where did the release early and often thing go? down the drain? are
we turning into a corporation that releases stuff every two years?

Let's get real, ok? there is no perfect software and will never be.

I'll fix the docs today so we can release the damn thing, ok?

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

Oh, c'mon, Cocoon is a servlet! What the heck can go wrong? Erase your
file system? please.

I've been releasing like this for 18 months and nobody complained about
it. Sure, there were many 1.x.1 releases to fix small bugs that might
have been corrected with longer tests, but NOBODY will do testing anyway
without a release.

Release in open source just means: "take it and test it for us and if it
works good for you".

It does NOT mean: "this is the most stable code we can come up with"
like in commercial enviornments.

BTW, we are MUCH more honest and it cleary shows by the quality of our
releases compared to commercial ones.
 
> 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.

All right, it's about time:

I officially resign from Cocoon1 release coordination and I hereby
request an official votation for the new release coordinator.

I officially propose Robin as the new release coordinator.

You can count my +1 for him if he accepts the position.

I think Robin will learn on his skin how hard and frustrating the job he
wants to do is and how useless testing is in the long run for open
source projects... but no matter how hard I try to explain it somebody
has to test it in practice to "get" it.

Please, understand that I "happily" resign from my current leading
position. I do not have any problem whatsoever with what Robin wants to
do, just that I consider this almost useless (but I remember when I
became JServ release coordinator for 1.0b and I shared Robin's vision
completely... you just have to learn it yourself how things go)

Moreover, my time will be reduced in the following months and I don't
want to be the release bottleneck like I've been in the past few months
(I also want to dedicate completely to get C2 finished)

It's time this project stands on its own feet: it won't be insulting for
me, rather the opposite, it will show how successful the community is
today.

And believe me, software or not, this is the most important thing this
project has: a strong, friendly and powerful community of great people.

And I'm definately proud of having been the one that started it :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message