[1.8] Let's get this right

[Robin Green <gr...@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.

Re: [1.8] Let's get this right

[Stefano Mazzocchi <st...@apache.org>]

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Re: [1.8] Let's get this right

[Stefano Mazzocchi <st...@apache.org>]

Donald Ball wrote:
> 
> 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.

I totally agree with Donald. 1.8 should be one in a week not more.
Everything that doesn't get in will be in 1.8.1. 

That's how we worked in the past and the thousands of people subscribed
to this list tend to confirm we have been doing a pretty decent job.

But if you think you can do better, now you have the ability to show us
about it :)

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

Re: [1.8] Let's get this right

[Donald Ball <ba...@webslingerZ.com>]

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