On 8/5/05, Bryce Harrington <bryce@...260...> wrote:
- A more recent example was when I expressed interest in testing cairo
in Inkscape. This was quite actively discouraged, because developers didn't want to think at all about cairo issues until cairo was sufficiently perfect that they could plug it in. Ironically, the cairo developers themselves don't want to think about those issues until it is plugged into an application. A group dedicated to testing would be able to conduct this analysis without getting so directly dismissed by developers.
I'm pretty sure that Cairo will succeed only when they have several serious applications running on top of it. Testing on tranclucent butterflies won't give us decent perfomance and a mature renderer.
The real question is who among developers has enough time to deal with Cairo stuff, which means at least
a) patching the code in a separate branch; b) communicating with testers and their bug reports.
Quality improvement has been a long objective of mine.
Well, I think many people have noticed an increased number of brown paper bag releases over last year. Lots of really nice software projects release some, say, x.x.x version, which is followed by a x.x.x.x one within several days: K3B, Evolution, The GIMP, Scribus and, sadly, Inkscape.
This happens, because the more people use some application, the more bugs are discovered. Within current approach to FOSS development this will never change.
This I personally would definitely like to see a brider merging of Quality & Assurance into FOSS development model. It does help to release less buggy software.
If we have human resources to go through the full Q&A cycle before each release, then some inkscape-testing@ will be a good place. If we don't, we need to find some other safe ways to improve quality of releases and communication between users and developers within inkscape-devel@ and inkscape-users@...233...
Alexandre