Jeremy Katz wrote:
On Thu, 2008-10-23 at 15:40 +0200, Hans de Goede wrote:
I agree lets start doing this for F-11, I think we also need to write something
up how the process will look (something like 10-20 lines of text, no prose
please) does anyone have a suggestion how to shape this?
I'll try to write up something basic in one of the breaks between
sessions of the conference I'm at today
If there be a patch queue that can be used for "urgent" rebuilds, that
the review team has to okay before firm committal, that might address
your concern Jeremy, while ensuring that they don't fall through the cracks.
In support of the idea, let may say that there are many errors in
writing a program.
Errors that the compiler picks up cause little trouble and little cost,
Ordinarily, they will be picket up and fixed in a run or two.
Errors the coder picks up, mostly those where the program always
segfaults, produces incorrect output also cause little trouble, mostly
they are picked up in a day or two and involve one person.
From here, they get more expensive:-(
If the team does code reviews (an idea that's been around 20 and more
years I know of), and finds errors, those errors have already involved a
few people and taken longer to fix.
However, errors can slip past, and if there's a QA team testing the
software, then there is an opportunity to do exhaustive (and expensive)
testing. Everyone developing important software should to this, though
my experience with websites (including big stockbrokers and banks)
suggests they don't.
Errors getting past QA (and I will include "Alpha" and "Beta" testing as
later phases of QA) get shipped to customers.
From this point they get serious because they interfere with customers'
work, maybe seriously, and the process of getting them fixed is very
expensive: they may only occur is peculiar circumstances, maybe with
obscure hardware or timing, there may be lots of going back and forth,
and in extreme circumstances lawyers and courts may be involved.
And, ordinarily, fixes have to go through all the above processes before
being ready for distribution.
Bear in mind too that bugs might not be coding errors, they can be
problems in documentation, or even design (specification) problems:
maybe the designers' understanding of the problem was flawed.
If all patches are reviewed before being committed, that will improve
the quality of the code that ships to the next stage. How much depends
on the effort applied in the review process, and in any event is
impossible to gauge. It might be interesting though to record how many
are found, and maybe occasionally review problems found (and not found
until later) to see whether procedures can be improved further.
.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
