Are "burn-in" periods really required for milestone drops?

[ru...@us.ibm.com]

Half-way through the burn-in period for this 3.1M1, I can't help but wonder
if asking developers to hold back for a week or so is really a good idea.
We've certainly gotten a bit more feedback than we would have gotten had we
not had the milestone, but nothing yet in my opinion that would couldn't
wait until the next milestone.

I'm not advocating the elimination of the burn in period for final
releases, but I do think we should seriously consider eliminating them for
milestones.  My plans are to keep with the current plan for this cycle (and
doing a last build on Saturday), and fold in any feedback on the plan in
the next cycle.

Thoughts?

- Sam Ruby

Re: Are "burn-in" periods really required for milestone drops?

[Jason Hunter <jh...@acm.org>]

Hans Bergsten wrote:

> I agree; burn in for milestones seems like overkill and slows down
> the process. My suggestion is to drop them, but keep the burn in for
> the final release.

The answer to this depends mostly on what quality people expect from
milestones.  People probably expect Mn to be better than M(n-1).  If
that's true, then we need some burn-in so we can be sure that the
check-in done right before the milestone snap didn't break something
big.

Plus, if people appear willing to do a little testing of the proposed
milestone and give good feedback (as Sam says has happened), then that's
reason enough to keep the burn-in.  Tomcat needs all the testing it can
get!

If we can do a milestone on its own branch and continue checking in to
the root, then there's not much harm in having burn-in.

-jh-

-- 
Jason Hunter
jhunter@acm.org
Book:    http://www.servlets.com/book
2.0 to 2.1: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
2.1 to 2.2: http://www.javaworld.com/jw-10-1999/jw-10-servletapi.html

Re: Are "burn-in" periods really required for milestone drops?

[Hans Bergsten <ha...@gefionsoftware.com>]

rubys@us.ibm.com wrote:
> 
> Half-way through the burn-in period for this 3.1M1, I can't help but wonder
> if asking developers to hold back for a week or so is really a good idea.
> We've certainly gotten a bit more feedback than we would have gotten had we
> not had the milestone, but nothing yet in my opinion that would couldn't
> wait until the next milestone.
> 
> I'm not advocating the elimination of the burn in period for final
> releases, but I do think we should seriously consider eliminating them for
> milestones.  My plans are to keep with the current plan for this cycle (and
> doing a last build on Saturday), and fold in any feedback on the plan in
> the next cycle.
> 
> Thoughts?

I agree; burn in for milestones seems like overkill and slows down
the process. My suggestion is to drop them, but keep the burn in for
the final release.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: Are "burn-in" periods really required for milestone drops?

[James Duncan Davidson <ja...@eng.sun.com>]

on 1/19/00 8:55 AM, rubys@us.ibm.com at rubys@us.ibm.com wrote:

> 
> 
> Half-way through the burn-in period for this 3.1M1, I can't help but wonder
> if asking developers to hold back for a week or so is really a good idea.
> We've certainly gotten a bit more feedback than we would have gotten had we
> not had the milestone, but nothing yet in my opinion that would couldn't
> wait until the next milestone.

+1 -- imo, the burn in on a milestone is verging on too much process.

.duncan

James Davidson                                     duncan@eng.sun.com
Java + XML / Portable Code + Portable Data                 !try; do()