How close 'till release?

["Wills, Mike N. (TC)" <MN...@taylorcorp.com>]

How close is Tomcat 4.1 to release? I won't install 4.1 on our production
system until it has gone to release.

Mike Wills
IT Corporate Support

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: How close 'till release?

[Craig Longman <cr...@begeek.com>]

On Fri, 2002-08-23 at 12:27, Craig R. McClanahan wrote:
> 
> The best way for Tomcat *users* to help get Tomcat 4.1 to general release
> state is trying it on your real apps, and reporting bugs so we can swat
> them.

i was trying very hard to do just that, but couldn't reliably get the
rpm installed, nor get the mod_jk or mod_jk2 compiled.  it seems like it
is very dependent on a specific configuration to be able to work.  i
could try simply using the non-rpm, but i'm a programmer, not a sysadmin
(by preference), so i tend to stay with the rpms which at least offer
some sort of control/administration for installations.

anyway, i don't mean to only bitch, i appreciate the work everyone puts
into this project a huge amount.  but, when its that difficult to just
get the code running, its hard to do too much testing.

-- 

    CraigL->Thx();
    Be Developer ID: 5852



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: How close 'till release?

[Will Hartung <wi...@msoft.com>]

From: "Milt Epstein" <me...@uiuc.edu>
Sent: Friday, August 23, 2002 10:11 AM


> I mean, I understand (and sympathize with what you're saying), but I
> also understand the position of those who want to wait until there's
> "release"-quality code available.  I mean, what will the typical
> manager say after the production system breaks down and you tell them
> that you went with "beta"-quality code instead of "release"-quality
> code.

It's all a matter of expectations. I find that most people want the system
to work and aren't really caught up on release numbers and labels.

Now, through probably painful experience, people have lower expectations of
1.0 code, "Beta" code, etc. They pretty much expect it to fail in some,
perhaps critical, way. They may use the label as an indicator whether the
code is worth testing.

But the real problem is not necessarily whether its Beta or Release quality,
it is the testing facilities available to the consumers.

If you had a deployed application and a solid, thorough feature and load
test suite of your application, then it shouldn't matter what the back end
code is labeled. If your test is complete and robust enough and thus
confirms that your application will behave as designed, then Release or Beta
are irrelevant.

The dark side of this is that folks will say "Well, gee I don't have to
'test' release code, it's already tested!".

To wit everybody falls over on the floor in hysterics.

The acceptance process for the software should be the same whether Beta or
Release. No matter how thorough the testing by the folks developing the
application, no doubt they have NOT tested their software on YOUR
application with YOUR load conditions on YOUR hardware.

And it should go without saying that this applies to any major infrstructure
component in your application, not just Tomcat. Don't just blindly upgrade
your system to Solaris 9, Oracle 9i and new Firewall software and then throw
the application live because it's all "release quality" software.

There are disclaimers in those licenses for a reason. Caveat Emptor and all
that.

Regards,

Will Hartung
(willh@msoft.com)




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: How close 'till release?

[Milt Epstein <me...@uiuc.edu>]

On Fri, 23 Aug 2002, Craig R. McClanahan wrote:

> On Fri, 23 Aug 2002, Wills, Mike N. (TC) wrote:
[ ... ]
> > I won't install 4.1 on our production
> > system until it has gone to release.
>
> I know lots of IT folks who follow this policy, but I have to smile
> when people say it.  Given the above release policy, think about
> what you'd be doing if 4.1.9 had been voted as "release" quality
> instead of "beta" quality.  You'd have installed it, right?  And it
> would have been *exactly* the same code ...

Yeah, but the vote of "release" vs. "beta" is not arbitrary -- it
reflects the quality of the code.  I'd hope people don't vote based on
getting people to use the code, rather than on their perception of the
quality of the code.


> The best way for Tomcat *users* to help get Tomcat 4.1 to general
> release state is trying it on your real apps, and reporting bugs so
> we can swat them.

Again, it's a bit of a circular/chicken-egg problem.

I mean, I understand (and sympathize with what you're saying), but I
also understand the position of those who want to wait until there's
"release"-quality code available.  I mean, what will the typical
manager say after the production system breaks down and you tell them
that you went with "beta"-quality code instead of "release"-quality
code.

Milt Epstein
Research Programmer
Systems and Technology Services (STS)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: How close 'till release?

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 23 Aug 2002, Wills, Mike N. (TC) wrote:

> Date: Fri, 23 Aug 2002 09:59:35 -0500
> From: "Wills, Mike N. (TC)" <MN...@taylorcorp.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: 'Tomcat Users List' <to...@jakarta.apache.org>
> Subject: How close 'till release?
>
> How close is Tomcat 4.1 to release?

As others have mentioned, Tomcat 4.1 is following the release policy that
is used for Apache's httpd web server and many other projects.  Basically,
it goes like this:

* Periodically, cut a milestone by incrementing the third part of the
  version number (we're up to 4.1.9 so far).

* Make the milestone available for testing (they get announced on
  TOMCAT-DEV and TOMCAT-USER only) but with no claims for quality.

* If a showstopper problem is found, the milestone is abandoned
  (this has happened several times in 4.1 so far).

* After a while, a vote takes place on TOMCAT-DEV about labelling
  the quality of that milestone (typically, the options are
  Alpha, Beta, or Release).  This label is attached to the version
  number when the milestone is announced more widely.

It took Apache 2.0 roughly 35 milestones (and over two years) to get to
the point where the developers were satisfied with the quality.  I'm sure
it won't take that long for Tomcat 4.1 because we weren't starting from
scratch -- it's mostly incremental improvements on 4.0 code.  But it's
going to take as long as it takes.

> I won't install 4.1 on our production
> system until it has gone to release.
>

I know lots of IT folks who follow this policy, but I have to smile when
people say it.  Given the above release policy, think about what you'd be
doing if 4.1.9 had been voted as "release" quality instead of "beta"
quality.  You'd have installed it, right?  And it would have been
*exactly* the same code ...

The best way for Tomcat *users* to help get Tomcat 4.1 to general release
state is trying it on your real apps, and reporting bugs so we can swat
them.

> Mike Wills
> IT Corporate Support
>

Craig



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>