Gervase Markham wrote:
>Footprint, Performance and Stability
>Architecture
>Standards Support
>Features
>I18n / L10n
>Timeframe
>Modularisation and Documentation
>
What I'm missing here are good, old, normal bugs. We have a lot of bugs,
places where Mozilla behaves unexpected, weird or plain wrong. Some are
minor and can be ignored, others are highly visible or are very
annoying. Some of them we might not even realize anymore, because we got
to know them and instinctively work around them.
It is very hard to measure them. My personal opinion is that *every* bug
in Bugzilla must be fixed in 1.0, unless we decided that it's not worth
fixing. This policy makes sure that we look at each filed bug and we
don't loose the valueable time countless testers spent for finding,
analysing and filing these bugs. After all, that's one of the largest
advantages of an open-source project.
As an absolute minimun, I had an idea for a hard rule, that can be
measured easily and achieved relatively easily. Take the current release
notes, and fix every bug there until the release-notes are only 1 page
long (when printed on letter paper).
Rationale:
* If a bug is worth to tell a tester of a development build about
it, it is worth fixing it for a final release.
* The current release-notes are useless, because they are way too
long. Hardly everybody reads them (I don't know, if I ever did).
Just cutting them is no solution, because there is a reason why
each note is there.
* Assuming the release-notes are well-managed, they give a rational
overview over the worst bugs.
I say, we can leave 1 page, because
* That's the amount a user can read, and some users will. (But most
won't, see below.) And this is the amount a normal user can
remember when using the product.
* It allows us to leave some bugs (or missing features) in, which
would cost an unjustifyable amount of time to fix.
But we must still assume that the user won't read the release-notes
(because that is what will happen in most cases), so the bugs left on
the release-notes must not be severe, or must be ones which are found in
the last minute before release and not severe enough to hold back the
release considerable time.
I say, we should take the *current* release-notes, so bugs don't get
added to the release-notes just to get them fixed. Of course, we need a
procedure for adding bugs to the "must be fixed" list.
(With "user", I mean end-user here, the guy eventually browsing with
Mozilla. That's because users of the Mozilla source code (i.e.
distributors, embedders etc.) will take the Mozilla source as-is and
incorporate it in their own products. They most likely cannot and will
not fix Mozilla bugs outside of the Mozilla project, because that just
makes no sense. (It would run completely counter the idea of the MPL.))
