[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: the logistics of beta release management



On Fri, 10 Jan 2003, Robert P. J. Day wrote:

> 
> i didn't mean to turn this into such an issue, but what
> the heck ...
> 
> On Fri, 10 Jan 2003, Michael Schwendt wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Thu, 9 Jan 2003 12:59:10 -0500 (EST), Robert P. J. Day wrote:
> > 
> > > let me put it another way -- once a new beta comes out, in 
> > > an *ideal* world, anyone who was interested in being a beta
> > > tester would drop that older version completely, and move
> > > on to the new version.
> > 
> > Yes. And the ideal beta tester would go through his list of reports
> > one by one and close all bugs that are no longer reproducible.
> 
> i'll take issue (sort of) with this contention for the following
> reason.  i claim that *my* ideal world is the one that is the
> best approach for beta testing.  after a company accepts a slew
> of bug reports, fixes/patches/resolves as many of them as they
> think are appropriate and releases a newer beta, there is no
> discernible value (IMHO) for any testing or bug reports against
> the earlier beta.  given that those bugs may not exist in the
> newer beta, all those bug reports are doing is potentially
> clogging up the database.
> 
> if someone is willing to go to the trouble to be a responsible
> and productive beta tester, and take the time to file bug reports,
> it's not unreasonable to ask them to at least do this against
> the latest beta.
> 
> however, there is a limit to what beta testers should be asked
> to do, and i think asking them to go through their list of 
> previous reports and close them if they're resolved is *way*
> beyond the call of duty.


A reason I propose a weekly refresh is to help those of us willing to
make a decent job of beta testing to do our testing on the latest
versions with all known fixes applied.

Some of us do lots of ks installs, and testing and evaluating and
especially learning what's changed is important. The only way to beta
test fixes is for a refresh to be issued.

The use of jigdo will help those of us who want ISO images to get
refreshed ISO images without downloading another 3 Gbytes or so.

I've recently decide I can happily install of the Internet, though I've
not done so with RHL, if I configure Squid to cache stuff for a long
time. However, to do this sensibly requires an updated install tree to
work off.

With the Limbo/(null) betas, getting updates was a mess. We need better
beta support from RH so we can help RH beta better.



 

-- 

John






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]