James Sparenberg wrote: > > On Thu, 2003-02-13 at 01:16, Chuck Burns wrote: > > On Friday 14 February 2003 3:09 pm, Lea Gris wrote: > > *snip* > > > > > > Ok, but ... > > > > > > How man is supposed to upgrade to 9.1 when it is out if it was not a > > > fully tested process ? > > > > > > Aren't we supposed to test cooker and report bugs ? > > > > > > I think the upgrade process is *a very important feature* that *should* > > > be *deeply tested* here. > > > > > > How are we able to get reliable upgrade process if it is not tested > > > though all along the cooker maturation ? > > > > > > regards, > > You do a FULL upgrade to cooker, making sure that ALL packages are cooker > > packages.. > > Which begs the question. Is cooker an extension of the previous distro > or is it a distro in and of itself. The former IMHO is the preferable > situation and I might add the more profitable alternative. The latter > yields more problems and more disgruntled users. (I'm having the same > argument at work BTW.) > > James
I think you need to define your terms, because I don't know what you are saying. The cooker starts out being the previous release, 9.0 in the current case. It ends up being the next release, 9.1 being the target. If you have watched the list, some of the changes along the way, like updating glibc, can break huge amounts of code. Others, like updating the font rendering, may not break code, but they can make some old code very painful to use. If you do an update from 9.0 to 9.1, you don't care how broken cooker may have been at some point, because you now have 9.1. Mixing code between 9.0 and cooker makes it impossible for the developers to duplicate your running code, and is often the cause of problems. Just my two cents worth. Paul Misner
