Gerv,
In general I agree with most of what you said. However I wanted to comment
regarding some areas you did not say much if anything about in the area of
Footprint, Performance, and Stability.
Over all page rendering is good, but our UI still is sluggish on slow machines
or machines with many other apps running. I would encourage our focus of
Performance to be in areas that help the over all UI. naturally the why
mozilla works helping the UI may also help other areas also.
Memory usage and memory leaks are also still a problem that needs to be
addressed. I know from reading .porkjockies that it is something that is
being worked on. Again that should be an area of focus for our Footprint
Performance and Stability people.
You mentioned dataloss.... unless is it is in very odd place that won't be
seen often and not going to lose anything important dataloss is a show stopper
like a topcrash bug in by book.
thanks for gettign this conversatoin going with a good document.
Gervase Markham wrote:
>
> Footprint, Performance and Stability
> ------------------------------------
> I want to start by making a controversial statement: we should have no, or
> very little criteria in these categories for Mozilla 1.0.
>
> Why? Recently, we have been going through a stable period, and people are
> generally pleased with the levels of stability and performance Mozilla has
> reached. Work continues, as it always does, and is an incremental process.
> We have had big jumps, like Hyatt's style landing, but in general these
> three issues are a case of chipping away at a block. My point is that we
> should be happy with current levels - i.e. just make sure things don't get
> worse. Given what is below, no "crash landing" period is anticipated
> before 1.0, so there should be no opportunity for major regressions in
> these areas.
>
> I know jrgm can produce stats about how Mozilla's performance is
> improving, but any line drawn on those graphs as "acceptable for 1.0"
> would be, to a greater or lesser extent, arbitrary. We can't compare to
> 4.x - because we do so much more. We can't compare to NS 6.0, because it
> sucked, perf-wise :-) We can't compare to IE, because it doesn't run on
> all the platforms Mozilla does.
>
> Saying we will have no official targets is not the same as saying we will
> not do any work in this area, of course. I fully expect work to continue,
> and for Mozilla to improve. It's just that because meaningful targets (as
> opposed to hard targets) are hard to define, this has to be assessed on
> gut feeling.
>
> The one exception to this is in the case of topcrashes. In this case, I
> think we should (nearer the time) name a cutoff date, such that "all bugs
> reported before this date and then assessed to be topcrashes will be fixed
> for Mozilla 1.0." This doesn't stop us fixing big crashes after that date,
> it just puts a sensible lid on things. There will always be unfixed bugs.
>
> Hmm... do we also need to do something similar with dataloss bugs?
>
