When I logged on I was really heartened to so much constructive feedback and so many good ideas have been posted on this thread. Thank you everyone
Puppy is a
really important project, and its important that people take responsibility to ensure that it is as good as it can be. I agree that it does need to fun, and done in a pleasant, blame and flame free environment for our programmers/packager/compilers to produce their best work. Lets face it no one is here for the money, but even
Micro$oft recognise this. Im by no means saying I havnt been guilty of this myself, but I am doing my best to learn from my mistakes.
Comparing open source with commercial development (Ive been commercial developer) there is always a pressure to get something "working" as quickly as possible and get the code (and the invoice) out. Development time is a "cost" that eats into "profit", so there is an incentive to make ugly hacks and patches that build up problems and inefficiencies for the future. This is one reason why Windows i think has become so bad. If you put programmers under pressure then they make mistakes...its just not productive to do it. Open source has no commercial pressures and doesnt need to suffer with set release deadlines....thats why its so much BETTER!
Puppy has always had a breakneck development speed, Barryk used to release versions every couple of months, and sometimes they had some quite big bugs and a new version released (wireless was broken in one version around 2.1x?). Generally speaking he did set aside a reasonable proportion of each "cycle" to testing though, and each change was small and incremental on the last.
Looking back on the events of puppy 4.2 development, Whodo chose to issue lots of small incremental versions which worked very well I thought. First released were quite a few Alphas with different packages in to try. Ok they were buggy, but they gave people the chance to try different potential packages (i.e. firepup) before a final package list was defined...great! There were then several betas to give the maintainers of those packages the time to refine their work and improve the look and the feel (pWidgets got a lot better over this time for example, and the themes were worked on). There were still a lot of issues being identified at this stage, which is why i got a bit worried when Whodo announced Release Candidate 1. I was worried there wasnt going to be enough time to finish testing, but whodo assured us it was merely a title to get more people to test it...fine. I did get the impression though whodo by this stage you were very keen to get 4.2 released and signed off? I did actually think of suggesting a pre-release checklist then and I really wish I had sorry.
@ Patriot - good points, none of them "lame". I assume because you produce the JWM window manager (which has been given the opportunity to really shine in 4.2...its so much better when its not coloured grey!) youve got a lot of experience in taking part in many different development efforts from many different open source projects. Thank you for taking the time to pass on your experience of them.
From what Ive seen of different packages, whether something is "ready" to be included is merely semantics. Im using aMSN 0.98 beta in a big cybercafe install, because Ive tested it and it seems pretty stable, as well as having the extra features. 0.97.x was stable too, 0.96 was very buggy and we had to revert back to 0.95 which we used for a long time. On the other hand you would think that Abiword 2.6.6 final would be relatively bugless, but it wasnt. The thing to learn from the future here is that we shouldnt assume/consider ANYTHING bugless or "bugless enough" until weve actually tested it ourselves. Part of the job of producing a "Distro" is to make sure we test and distribute only the best applications and the best quality version of that application? Thats the point.
Many hands make light work, and different people have different skills, and different packages they use. Assigning "Experts" to different packages (a maintainer/compiler, and a tester), who know the ins and outs of that package and can research it thoroughly is an excellent idea Splitting up the distro on the basis of its component applications is an excellent way of doing it.
The puppy community is growing as puppy becomes more popular. When I joined it, it was at number 20 in Distrowatch, now its at number 8! Ive oticed about people that when they come over to puppy at first they are very grateful they have been given something, and are more than happy to do a little bit back and be part of the project.
A first draft of a potential test checklist...
Puppy version 4.2.1
App. Ver Packager compiled yn? Tester Tested (Y/N) Submt(Y/N)
Abiword 2.6.5 Fred Yes Frank no no
Blinky 0.9.8 Boris Yes Charles yes yes
etc etc
Perhaps a column in there as well to state if the package was an upgrade on a previous version (and therefore needed testing) would be handy...but you get the idea.
How can this be kept up to date?
@James
Theres no reason we cant learn from Windows as well...they are for some reason quite successful, at least for the moment. You are saying with the windows 7 testing program, they have the facilities for collecting bug reports actually built into the program itself? How could this concept be implemented (better) in Puppy?
How about in future, making the default home page in Seamonkey refer to a page in the Puppy Wiki. This would change depending on the release (alpha/beta/RC)...
The alpha could have a page detailing the programs being tried out
The betas could have a lits of known bugs, and what needs to be tested
The Release candidates would have the checklist above to keep track of all of the final bugs, and ensure everything was checked thoroughly before release.
As I say, this is just one general idea and open to a lot of refinement.
Thank you for your continued reading if youve made it this far...
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]
Sorry, my server is down atm!