Ben Bucksch wrote:
> Scott Putterman wrote: > >> Determine the criteria we think we need to meet > > > I assume below that you want our input to that and the other decisions. That's why I used "we". I want to be involved, but Mozilla's all of our products. My reason for writing this email was to point out that there needs to be some kind of criteria and process to determine what's important. The worst thing that could happen is 500 bugs could get nominated and there is no way to determine which are the ones that are must fixes and then 1.0 never happens! > > >> determine what level of severity bugs need to be fixed for that item > > > Given that it's 1.0, I'd say that the criteria should be lower, much > lower than for previous releases of Netscape. > >> (for example, I'd argue that normal footprint bugs don't need to be >> fixed) > > > You are aware that footprint is one of the top reasons for people not > using Mozilla (Netscape 6.1)? Not sure, if Mailnews is at fault here > too or if the footprint of Mozilla in general is the only thing hurting. > > However, for me, footprint comes after correctness in importance (not > necessarily in time, because footprint/perf work can regress > correctness). Right, so somehow there has to be consensus on what are the most important things. My assumption is that Brendan's doc was posted to make 1.0 happen sooner than later. I've seen some postings in the past that make it sound like the things people want in a 1.0 build are 3-4 years worth of work. If we want to ship 1.0, then that can't happen. So if you really believe that all of the normal and higher footprint bugs need to be fixed, then you will have to trade off some place. > > >> then start finding bugs that meet the criteria. > > > How do we do that? > > Adding keywords doesn't work. For example the "Sent copy fails" bug > has all relevant keywords, but has effectively been ignored for a > quarter year. So this is where things become difficult. In addition to determining what bugs are important, you have to find someone to fix them. The triaging is a bit hard because unless you have someone who will fix the bugs you consider important, you can't force someone else to fix them by a given milestone. My suggestion is to look through the list of nominated bugs and just start adding them to the meta bugs (or better yet, create a mail 1.0 meta bug and add it to the main 1.0 meta bug) when they are considered necessary for 1.0. Then, we just need to find people to work on them. > >> That said, I'll post what our criteria has often been at Netscape for >> the mail client: >> >> Performance/Footprint >> Stability >> Useability >> Correctness >> Features > > > For me, the criteria Security/Privacy comes first, dataloss directly > after it. I argue that every severe bug in that section is a stop-ship > at any time. Importance of bugs in that "criteria" is much higher than > bugs in other "criterias". > > Otherwise, I agree with your list, in that order of decreasing > importance, but I would sort perf/footprint before features, after > correctness. > >> In addition we generally order the importance of the areas which I >> think is a good exercise as well. Unless you have an indefinite >> amount of time, you may not have the ability to concentrate on >> everything: >> >> Mail related areas. >> Compose Window >> Search/Filters >> Address Book >> News > > > Agreed. > > putterman, what do you think about my concrete "sub-criterias" listed > below? I think the categories are good. We just need more consensus that these are the right categories and get ideas for more categories. Then you need to fill in the categories and get buy in from everyone that they are being filled by the right bugs given the amount of time. Regarding GNKSA, I don't think it's necessary, but you probably knew that given that Netscape has shipped a few times without it being fulfilled. Scott > >>> * Standards >>> * GNKSA - at least bug 76449 better yet bug 12699 >>> * Stability >>> * dataloss >>> * Sent copy fails sometimes/often - bug 89285 >>> * Footprint >>> * Mailnews never unloads - bug 95130 >>> * Security/Privacy >>> * No server hits at HTML mailnews reading - bug 28327 >>> * Maybe "Review" and its dependencies - bug 40756 >> >> > > >
