If you want to know what 1.0 is going to be, all you need to do is look at the
requirements specifications for the product and its compomnents, which should
spell it all out. If you want to see where we are towards meeting these
requirements, you only need to look at the progress that has been made so far
against the planned schedules, which came out the detailed design (which
followed from the requirements specs), and combine this with the current results
from the test plans, which were created, in concert with the detailed design, to
evaluate our progress towards the implementation. As for bugs, historical bug
fix rates can be applied to the number of open bugs (bugs which, if not fixed,
mean we can't meet the goals spelled out in the requirements specifications),
and a projected incoming rate, to determine about how long (roughly) it will
take to fix the problems (modulo time for testing, vacations, attrition, etc.)
My point is, don't worry -- as long as we follow a well established engineering
process, we have nothing to worry about.
syd
Christopher Blizzard wrote:
> Mama Cass Elliot wrote:
>
> > In netscape.public.mozilla.seamonkey the people heard Asa Dotzler say
> > these wise words:
> >
> >
> >>>IMHO, 1.0 quality = all implemented features working to an acceptably
> >>>high standard, and released as a finished product.
> >>>
> >>
> >>This kind of comment does nothing to help the discussion. This thread
> >>is about defining the "acceptably high standard". Saying 1.0 needs to
> >>meet the standard we've defined for 1.0 is a little silly, no?
> >>
> >
> > The acceptable standard is - "free of known bugs"!
> >
> > Make Mozilla free of known bugs, then - and only then - add new features
> > intended for a new release!
> >
> > Intil the code is free of known bugs the project won't can't be considered
> > completed.
> >
> > This is, to me, quite logical. Work on a product's faults before creating a
> > new version of the product with additional features and more faults.
> >
> >
> >
>
> I would love to live in an ideal world but there no way that we could
> release a product that was completely free of bugs. It's just not
> possible in any kind of sense.
>
> It's enough to have fixed the serious bugs that you can identify. In a
> multi-million line chunk of code there will always be bugs. As the
> complexity of any piece of software increases so does the chance of
> bugs. Ever wonder why NASA still uses computers with 64k of memory?
>
> --Chris
>
> --
> ------------
> Christopher Blizzard
> http://people.redhat.com/blizzard/
> Mozilla.org - we're on a mission from God. Still.
> ------------
