Conclusions
- Pre-release ticklist - Ecomoney
- Whole Forum "sandbox" section for bugs, with "bug per thread" approach, rather than one thread for all bugs -Ttuxxx
- Recruit "Package use experts" (not the compilers) and ask them to take part in testing before development begins - Patriot
- Have a "Testing Manager" to keep track of the testing process, only release when theyre happy too do so...no rush! - Ecomoney
- Make it easy to collect bug reports (default homepage) - James C
- Keep changes/package updates to only the ones needed by Users - Ecomoney
Origional Post
Ok, The puppy linux team Have just released the first official version without BarryK. Lots of new features and upgrades were added, and its received glowing praise from distro critics and even a brief #2 Ranking at Distrowatch.
Although we had a long and ardious testing process, with plenty of pre-releases, Betas and Alphas, 4.2 was released with still quite a few bugs present, and also one particularly nasty one thats been very well discussed and eventually conclusions drawn from. I dont want to go back into any of that here, this is looking forward rather than back.
What can we learn from the successes and failures of 4.2? Here are some things that have already been mentioned.
from rcrsn511. Using a full release of Puppy as a test bed for individual pieces of software is a mistake.
2. Each package should be thoroughly tested using some systematic procedure before it ever gets near the overall build.
3. Introducing a new package or attempting to upgrade a package in the middle of the development process is asking for trouble.
4. Third-party criticism is an important part of the process.
There was also some discussion that a separate group/team of "test pilots" be created at the inception of each release. These should generally be separate from the developers, which would free their time for compiling etc. and need not necessarily have/need any coding skill whatsoever.
The "test should have a single person as a central co-ordinator who the developer informs of changes/upgrades/new features and packages they have implemented that need testing, and also what other areas this migh effect (say in the case of an upgraded library) That person can then assign the job of testing to an individual with experience of that package, and keep track of what has been tested. Only when that person is happy that everything is ticked off the list will the Puppy Build be released.
If we are discussing events/mistakes in the past, please try not to assign blame. Constructive comments only please.