Warly wrote: > 9.0 is (likely to be) finished. > Thanks to you all for your precious help. > During last 6 months period, and especially in the last beta period, some > of you give some advice/critic/flame regarding Mandrakesoft development > process. > It is now the right time to debrief all this. > Please comment on what you liked, disliked in the 9.0 building, testing > and problem reporting process. > I already collect on various mandrake IRC channels: > * send a mail to the changelog disk when packages are removed with the reason > * improve the cooker cooker FAQ pages, about cooker etiquette and everything > when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3) > * improved bugzilla to have a easy mail interaction system, and a more > friendly interface. And to have a last known problems page. Has anyone at Mandrake been an active user of Bugzilla for Mozilla? Recently, as opposed to at the beginning of open source Mozilla development? I filed my first non-duped bug there about 1.6 years ago. I've filed 131 in total, 45 currently either NEW or ASSIGNED, 15 RESOLVED FIXED, 5 RESOLVED INVALID, 8 RESOLVED WONTFIX, 18 WORKSFORME, and the remainder 38 if I counted right, dupes. I'm also CC'd on 129 bugs, many of which were automatic via dupes.
I think Bugzilla works very well for Mozilla, and can do the same for Mandrake. I think I know plenty about the way it works there, even though I'm not a programmer. The problem of spam, or invalid reports, from newbies or the careless, is handled in several ways. First, new registrants are limited to making comments in existing bugs, or filing new bugs. They have no power to change any important information about any particular bug except if it is one they filed. Whether there is another method to advance beyond newbie power I don't know, but I was advanced through a mass mailing invitation. I was asked to provide three bug numbers where the bug was resolved fixed for evaluation, and subsequently approved for increased power. New bugs by lowest level registrants are given the status UNCONFIRMED, while those with advanced power have their new bugs given the status NEW. This is a good filtering method for those with limited time to avoid wasting time on poor or invalid bugs, but nevertheless provides in the database something for others who have experienced like misbehavior to use Bugzilla search to find, and thus not file a dupe. By default, everyone who files a bug automatically gets bugmail on their bugs when any change or comment is made. This way they are apprised of status change, including resolution, or of deficiencies in their original report or followup comments. Bug component owners also get bugmail, as well as others, and, in particular, those who have requested same for individual bugs of interest. Bugmail is user configurable to limit. Spam need not reach everyone. I'm only on one Mozila mailing list, Wishlist. Most of the rest of my discussion about the product either goes on in individual bugs, or in the newsgroups. Mailing lists and newsgroups are good for discussing behavior and hashing out the definition or recreate scenarios on new bugs, or proposed product changes. However, as the Cooker list has proven, a mailing list is greatly deficient in database search and control functions. The key things about Bugzilla are that it is a central database reachable by anyone to see 1-if a bug encountered has already been filed (known issues); 2-screenshots or other attachments; and 3-status, not the least of which includes fixes implemented and possible workarounds. This is why Mandrake should switch focus to Bugzilla before starting the next beta rounds, or sooner. -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/
