Ben Reser <[EMAIL PROTECTED]> writes:
[...] > >> * improved bugzilla to have a easy mail interaction system, and a more >> friendly interface. And to have a last known problems page. > [...] > > Problems: > a) Various places have inconsistent reporting instructions and > requirements. Some people/sites tell people to post to mandrake expert, > others to bugzilla or even the cooker mailing list. There abounds > confusion as to where to report and what to include in your report. Yes, I would like to have only one advertised bug reporting method for 9.1, bugzilla. However to face too many or not meaningful bug reports, they will default in UNCONFIRMED states and will need 2, or more if needed confirmation before becoming new. I would like to forward them to cooker and make cooker guy able to answer to them via mail and confirm them, invalid them and maybe even close them. > b) The mailing list is not easily searchable for people who aren't > maintaining their own archives. Before everyone starts pointing me off > to the web archives at theaimsgroup hear me out here. I often have > difficulty finding messages there that I know were posted. Frankly the > search on that site is not all that effective. But even considering > that, Mandrake doesn't even link to it anywhere that I know of. No > mention of online archives are made on the cookerdevel.php3 page. You > can find an archive listing on the Lists page but that only goes to > Mandrake's archive that isn't searchable. We criticize posters for > reposting the same bugs time and time again yet we don't provide them > easy access to find out if their bug has been reported and even possibly > fixed. Thierry even states repeated bug reports are a source of > irritation for him and I'm sure he isn't alone. Gael, Ben is right on this point our archives are less usable than the one at http://marc.theaimsgroup.com/?l=mandrake-cooker. Maybe could we link to them on the cooker page? Regarding the search, I fix the quick search on the bugzilla main page, and it would be nice, as Pixel suggested, to have a ligther complex search page, so that anyone prefer searching for bugs instead of posting new ones. [...] > Strengths: > a) The list is wonderful at back and forth interactions. > b) We've developed methods of dealing with large amounts of email and > work around that. > c) Bad reports are easy to get rid of. You just hit the delete key. > d) It's a push system rather than pull. Meaning the reports come to us > rather than requiring us to go get them. > > Solutions: > [...] > Now that I've covered the general arguments regarding bugzilla, let's > cover how it solves the problems... > > (a) Just make it the only place to post. > (b) bugzilla provides us with good searching. Duplicates can be closed > by volunteers and linked to the open bug report, freeing developers to > pay attention to the real bug reports. > (c) KDE reduced bad bug reports > by asking lots of questions and trying to walk a person through a search > of the bug database before posting. Simply requiring users to enter > relevant package versions, hardware information etc... would decrease > developer's having to go back and ask for more information constantly. > Poor bug reports could be moderated, closed, etc by volunteers, leaving > developers with more time to deal with the issues that filter up to > them. Plus, if bugzilla is setup to route bugs only to the maintainer > of the package, we decrease the number of bad bugs developers have to go > through. Bugzilla, however, does still allow for interactive question > and response via email... Developer posts a response. The reporter and > people who are interested in the issue get an email. Someone replies to > the email and their response goes back in bugzilla. Everyone else gets > a copy of it in their email box. Basically the same as the mailing > list, except it's stored in a database and only truly interested parties > get it (though there could be a list with *ALL* the traffic for > masochists). > (d) This would be solved too. The list would become a discussion area > for just developers. Users wouldn't feel the need to come here much. > The list would be easier to read and more relevant. Specifics to > certain packages would stay on bugzilla. The few bug reports that > showed up on the list could be told to report it on bugzilla. > (e) Followup is built into the process. Reporters would get emailed as > to the status of their bug(s) and all comments or changes made to it. > (f) Not an issue. The list is less important. Users get instant > feedback via email showing their bug report id(s) and URL(s) to look at > their report. They can see their report in the searches. > (g) It's easy to get a report of overall bug count. Even with bad bug > reports we'll eventually get an idea of how many bugs we should get down > to before we think things are looking stable. Yes, this is sensible. Create a [EMAIL PROTECTED] mailing list, where bugs are sent and volunteers asked to subscribe and confirm/invalid/closed bug if they can. Cooker slow down in traffic and focused more on development and tricky bugs fixing. > On a simple development issue, can we get "good" changelog entries in > both CVS and in rpms? Things like "fix bug" or "cvcp commit from..." > are not useful entries. Many people are making really poor changelog > entries with their commits and packages. That makes it all that much > harder to track things down 6 months from now when we're looking at what > was done for security issues. Not to mention it means sometimes I have > to go into CVS and look at the diff to get any idea of what was done. > Further, some changes didn't get marked in the changelog at all. The > Konqueror bug on Copy Link Location never showed up in the changelog. I > know it got pulled in because, well, it works on my machine. But I have > no idea when it got pulled in. Possible Laurent updated from CVS but > there doesn't seem to be a matching changelog entry. This is up to the maintainers but we can make some guidelines in beta or freeze period where changelog must contains the bugs it fixes. -- Warly
