Re: [Cooker] 9.0 and next
Warly wrote: >>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. It would be more coherent to add a search tool to our mailling-lists archives. We'll see if we can add one, and if not, we will link to the archives above. Gaël. -- < Founder Mandrake Linux > < http://mandrake.com > < Co-Founder Mandrakesoft > < http://mandrakesoft.com >
Re: [Cooker] 9.0 and next
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
Re: [Cooker] 9.0 and next
On Tue, Oct 01, 2002 at 09:38:23PM +0200, Guillaume Cottenceau wrote: > I don't agree. There are some people who don't have a permanent > net connection. Huh? What does a permanent net connection have to do with it? If you mean people submitting bug reports when not online... those people can use rpmmon. But the vast majority of these people are going to be far to lazy to download and install an application just to find out who the maintainer is. rpmmon isn't even included in the distro because you consider it to be limited usefulness for most people... It would be a different story if it was included in cooker and was installed by default. Putting the webscript up is not mutually exclusive of rpmmon. > Yep, the problem being when the percentage is very close to 0. I > think that the few persons who are willing to respect the rules > already "know" them because after all they are just plain logical > rules. Well you are far more a pessimist than I am. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
Ben Reser <[EMAIL PROTECTED]> writes: > On Tue, Oct 01, 2002 at 06:56:05PM +0200, Guillaume Cottenceau wrote: > > What percentage of ppl respect the guidelines of the current > > version? It's useless to write such things. > > This is a rather specious argument. It's like saying. "Why don't we > just not ship or update man pages. What percentage of users actually > bother to read them?" I think, far more than the cooker faq. > Nobody can read them and follow them if you don't update and publish > them. Agreed. But I don't feel it was better at the time I co-wrote it with Geoff. > The current FAQ says that it is published to the list monthly. I don't > remember the last time that was done. I'm not sure, regarding this issue, but I think it was asked and maybe admin forgot to do it, or didn't agree, or other ppl didn't agree. But I don't think it's a key point. > The current FAQ tells you to CC maintainers. Yet some Mandrake > employees don't like that. That's another problem. > Most of the FAQ has nothing to do with reporting bugs. It doesn't even > ask people to report the version of the package they are reporting. And > to get people to CC the right maintainer you're asking them to download > and install rpmmon. Putting up a small webscript to get this > information (as I've already done) would make it easier for people. I don't agree. There are some people who don't have a permanent net connection. > The harder you make it for people to do it the "right" way the far less > likely people are to do it the right way. Agreed. > You are very unlikely to get 100% compliance with anything you put up. > But every person that you do get to do it "right" will ease your > workload and make for a more relaxed environment on this list. Yep, the problem being when the percentage is very close to 0. I think that the few persons who are willing to respect the rules already "know" them because after all they are just plain logical rules. > Doesn't that make it worth the few minutes to fix the FAQ. Heck Leon > Brooks actually wrote one that I'm sure you can borrow some of it from. > > To improve on the FAQ I'd do the following: > > a) Get rid of the information on how to submit packages. Put a small > mention of it and point people to the RPM howto. Then make sure the > rpm howto has the correct information on submitting them in it. Most > users don't submit RPMs so the information is useless to them. > > b) Expand the explanation of how to make a good bug report. Explain how > to find out the version of the package that someone is running. Explain > not to reply to existing threads to start new ones. Explain how and > where to search for duplicate bugs. > > c) Actually post it on the list and link to it from everywhere. Hell > put it in the installer to give newbies something to read why they > install. I'll study your suggestions if/when I have time (of course, other mandrake employees are welcome to fix it but I'm unsure they want to do it). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] 9.0 and next
On Tue, Oct 01, 2002 at 06:56:05PM +0200, Guillaume Cottenceau wrote: > What percentage of ppl respect the guidelines of the current > version? It's useless to write such things. This is a rather specious argument. It's like saying. "Why don't we just not ship or update man pages. What percentage of users actually bother to read them?" Nobody can read them and follow them if you don't update and publish them. The current FAQ says that it is published to the list monthly. I don't remember the last time that was done. The current FAQ tells you to CC maintainers. Yet some Mandrake employees don't like that. Most of the FAQ has nothing to do with reporting bugs. It doesn't even ask people to report the version of the package they are reporting. And to get people to CC the right maintainer you're asking them to download and install rpmmon. Putting up a small webscript to get this information (as I've already done) would make it easier for people. The harder you make it for people to do it the "right" way the far less likely people are to do it the right way. You are very unlikely to get 100% compliance with anything you put up. But every person that you do get to do it "right" will ease your workload and make for a more relaxed environment on this list. Doesn't that make it worth the few minutes to fix the FAQ. Heck Leon Brooks actually wrote one that I'm sure you can borrow some of it from. To improve on the FAQ I'd do the following: a) Get rid of the information on how to submit packages. Put a small mention of it and point people to the RPM howto. Then make sure the rpm howto has the correct information on submitting them in it. Most users don't submit RPMs so the information is useless to them. b) Expand the explanation of how to make a good bug report. Explain how to find out the version of the package that someone is running. Explain not to reply to existing threads to start new ones. Explain how and where to search for duplicate bugs. c) Actually post it on the list and link to it from everywhere. Hell put it in the installer to give newbies something to read why they install. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
Ben Reser <[EMAIL PROTECTED]> writes: > > * improve the cooker cooker FAQ pages, about cooker etiquette and > > everything when reporting a bug > > (http://www.mandrakelinux.com/en/cookerfaq.php3) > > Agreed 100%. What percentage of ppl respect the guidelines of the current version? It's useless to write such things. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] 9.0 and next
On Tue, 1 Oct 2002, Thierry Vignaud wrote: > > notification of translators in due time. The way the Gnome > > Translation Project works, can be used as a model. > > well, the latest 2 weeks were extremely freezed and during the last > week, gc and me posts which strings were changed on cooker-i18n Well, then there's something wrong with the cooker-i18n distribution because I haven't received those mails. Now that you mention it I do see more traffic in the cooker-18n archives than I've actually read. If only I'd known. :) -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] 9.0 and next
Reinout van Schouwen <[EMAIL PROTECTED]> writes: > From a translator perspective, I'd like to comment that the > continuing string changes in the Mandrake tools sometimes are > driving me up the wall. Up until this weekend there have been string > changes without the translators even being notified in any way (I > wonder how many developers know about the cooker-i18n list?). This > is making the "Mandrake experience" a less pleasant to non-English > users because they get confronted with mixed english/own language > interfaces. > > To make a long story short: next time I would like to see a string > freeze that can only be broken in special cases and with > notification of translators in due time. The way the Gnome > Translation Project works, can be used as a model. well, the latest 2 weeks were extremely freezed and during the last week, gc and me posts which strings were changed on cooker-i18n
Re: [Cooker] 9.0 and next
On Wed, Sep 25, 2002 at 07:35:24PM +0200, Warly wrote: > Thanks to you all for your precious help. And thank you to all of the Mandrake employees for their hard work in producing 9.0. > During last 6 months period, and especially in the last beta period, > some of you give some advice/critic/flame regarding Mandrakesoft > development process. I'll admit I'm one of those advisors, critics and flamers. Before I go into what I think will be my analysis of the development process I want to make it clear this isn't personal. I really do appreciate the hard work that the Mandrake crew puts in. My criticism is aimed at an imperfect process which I think could be improved. And the improvements really should help the developers, Mandrake as a company, contributors and IMHO end product quality. However, I don't think that there is a perfect process. Only a possibly better process. :) > * send a mail to the changelog disk when packages are removed with > the reason This is an excellent suggestion. I couldn't agree more. > * improve the cooker cooker FAQ pages, about cooker etiquette and > everything when reporting a bug > (http://www.mandrakelinux.com/en/cookerfaq.php3) Agreed 100%. > * improved bugzilla to have a easy mail interaction system, and a more > friendly interface. And to have a last known problems page. This demands some flushing out. While the above issues I think pretty much everyone will agree with, people seem to be on various sides of the fence on this and it seems (at least from your comments in the past) that Mandrake's employees are dead set against this. So to flush it out in what will likely be a very long response - A response which I hope will lay out the problems with the current situation, the strengths with the current situation and perhaps a way to get the best of both worlds. I want to start with looking at the status quo before I go into how to solve the problem (an obvious starting place, but nonetheless lots of people seem to be spewing solutions without considering the problems). 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. 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. c) Bug reports are consistently "bad." This usually means one thing. That the report didn't contain enough information to do anything about. Bug reports come in about X11 not working right without listing the video card. Users report problems with packages without reporting the versions they are using. Users report an error message is displayed without telling what the error message is. Random crashes get reported without any details regarding what was going on at the time. I would imagine that a considerable amount of developer time is spent writing emails requesting further details that probably should have been included in the original email. d) The mailing list has too many posts to it. Some people think the list has too much unnecessary chatter and discussion of things that don't matter. I'm not sure I agree. But I'm listing it here for completeness. However, I can certainly see that reporting a bug by a newbie seems rather overwhelming when they are told to report it here. Most of these people do not have time to read the list for replies to their issues. Nor do they have sophisticated email filtering that allows them to pull out what is important. Nor should they necessarily have to. e) There is not enough followup. Many users, myself included, feel there is not enough follow up on bug reports. While I understand a lot of them are poor, even good reports with fixes get neglected at times. This is bound to happen when developers receive, as Thierry put it, "thousands of messages a day," especially when many of them are irrelevant to what they work on. Some are bound to be lost in the hustle. As it stands, the only way to be sure your bug got fixed is to test again or possibly see it on the changelog list. However, most novi
Re: [Cooker] 9.0 and next
On Saturday, September 28, 2002, at 02:48 AM, Guillaume Rousse wrote: >> Except that Bugzilla's written in perl and the last time I looked at >> it, was very very messy code. >> >> Anthill, on the other hand, is written in PHP. > You're forgotting the tags here, Vincent :-) well, I didn't want anyone to think I was blowing my own horn... my name isn't *that* prominent in Anthill... =) -- MandrakeSoft Security; http://www.mandrakesecure.net/ "lynx - source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} PGP.sig Description: PGP signature
Re: [Cooker] 9.0 and next
Le Jeudi 26 Septembre 2002 07:23, Vincent Danen a écrit : > Except that Bugzilla's written in perl and the last time I looked at > it, was very very messy code. > > Anthill, on the other hand, is written in PHP. You're forgotting the tags here, Vincent :-) -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] 9.0 and next
Le Jeudi 26 Septembre 2002 22:04, Todd Lyons a écrit : > Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 : > > Maybe we need a Cooker FAQ... > > http://www.mandrakelinux.com/en/cookerfaq.php3 The FAQ from Leon Brooks deserve a link also http://leon.brooks.fdns.net/Mandrake/bugFAQ.html -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] 9.0 and next
Le Thu, 26 Sep 2002 23:04:51 +, Steve Fox a ecrit : > On Thu, 2002-09-26 at 04:46, Frederic Crozat wrote: >> >> I'm not sure having assigned people per package is really a good idea => >> it will require a lot of people.. But your idea is somehow a variation >> on the same theme as my idea :) > > Very true, but then again having just you to manage ALL of GNOME is > tremendous pressure on you. Would you benefit from having lieutenants to > assist you with packaging? I think having groups of reliable volunteers to > assist (and help keep Mandrake's costs low) would be very beneficial. I am > officially volunteering to help with GNOME packaging if you are receptive > to this idea. Well, I already have one unofficial lieutenant for some GNOME packages : Götz Waschk (thanks Götz) :)) I'll be happy if other people want to help me (or other maintainers), both for package maintainance or bug triagging/fixing.. I tend to more focus on "core" GNOME package (ie the "desktop" platform) than extra packages (ie applications).. If you (or others) want to help, that is great.. Maybe we should try to add a "pending queue" on contrib compilation system which would send a mail to package maintainer when a package from main is "contributed" by cooker folks. Lenny, Warly, WDYT ? -- Frédéric Crozat MandrakeSoft
Re: [Cooker] 9.0 and next
On Thu, 2002-09-26 at 04:46, Frederic Crozat wrote: > > I'm not sure having assigned people per package is really a good idea => > it will require a lot of people.. But your idea is somehow a variation on > the same theme as my idea :) Very true, but then again having just you to manage ALL of GNOME is tremendous pressure on you. Would you benefit from having lieutenants to assist you with packaging? I think having groups of reliable volunteers to assist (and help keep Mandrake's costs low) would be very beneficial. I am officially volunteering to help with GNOME packaging if you are receptive to this idea. -- Steve Fox http://k-lug.org
Re: [Cooker] 9.0 and next
Le Jeudi 26 Septembre 2002 20:04, Todd Lyons a écrit : > Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 : > > Maybe we need a Cooker FAQ... > > http://www.mandrakelinux.com/en/cookerfaq.php3 > > Blue skies... Todd All email link are broken: send your email to Lenny -> the link is http://www.mandrakelinux.com/en/lennyREMOVEatmandrakesoft.com I notice on lot of page... Maybe to have on this page the state of cooker: Something like: Cooker is open Last release Dolphin, Sept 2002 Next on Mar 2003 If someone only want purpose a nex package. Another things, maybe add link to Voluntaries Club, and having a way for lenny to ask to contributors if someone is interrest to make/fix/upload a package submit by ftp. -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] 9.0 and next
Levi Ramsey ([EMAIL PROTECTED]) wrote: > On Thu Sep 26 15:11 -0700, Ben Reser wrote: > > On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote: > > > > > Wow, you're suggesting that a developer use something other than > > > emacs to read mail. Do you realize that could be considered > > > sacriligious by some? :) Not me, but most... > > > > Emacs? What are you talking about a real email client is mutt. :P > > Especially since mutt defaults to using vim as its editor :o) export EDITOR=emacs put that in your profile and be amazed. :) Groetjes, Han. -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] 9.0 and next
Warly wrote: >Please comment on what you liked, disliked in the 9.0 building, testing >and problem reporting process. > > This is my first time to participate in the beta cycle so I cannot compare this with the past. But to me things generally seemed to go well. I was impressed at the very quick response time and with the generally helpful attitude found here on the Cooker e-mail list. I would agree with the comment that it would be good to get at least an automated response to our bug reports and problems from the Mandrake team. In this way we know we have been herd even if what we had to say is then being summarily ignored. Hey there must be priorities and everyone knows that deep down. We cold also be told that this has already been addressed or that more information is needed. There is one thing that I would like most to to see added. This is a sort of daily or at least weekly progress report. The old Cooker newsletter reborn I guess. This letter would give those of us participating as guinea pigs, ah beta testers, some understanding of our role and perhaps even some focus so that we could be even more helpful with certain key issues. And if for some reason a particular problem is being ignored for the moment due to Mandrake priorities we could be notified and we would not then keep banging our heads against the proverbial wall by reporting the same bug over and over again. For me at least, this sort of news would be very helpful. It would let me know what bugs have already been found and fixed, it would tell me how the things I am doing fall with in the scheme of things. It would provide me with a place to catch up when I join the effort midstream or when I have been out of touch for several days. In my opinion, it would make the overall effort much more organized. We, all of us, would feel more like a team if we were thus informed. Just my two cents, Kim -- --- Registered Linux user #264340 Mandrake Linux 9.0 (Dolphin) - Kernel 2.4.19-16mdk XFree86 4.2.1 - KDE 3.0.3 and Gnome 2.0
Re: [Cooker] 9.0 and next
On Thu Sep 26 15:11 -0700, Ben Reser wrote: > On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote: > > Wow, you're suggesting that a developer use something other than emacs > > to read mail. Do you realize that could be considered sacriligious by > > some? :) Not me, but most... > > Emacs? What are you talking about a real email client is mutt. :P Especially since mutt defaults to using vim as its editor :o) -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Love lies in pools of questions. GPG Key Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: 19990522 - Breadfan.ogg Linux 2.4.19-9mdk 7:30pm up 1 day, 2:34, 6 users, load average: 0.91, 0.89, 0.64
Re: [Cooker] 9.0 and next
At 11:39 AM 9/26/02 +0200, you wrote: >you have to understand that we receive lots of mails (i mean several >thousands per day). >we use scorring and the like to reduce the text volume to read but it >still takes time. First thanks for the answer. All right, I understand it's a big load... how about making it lighter ? I decided to subscribe to cooker after reading on MandrakeForum that it was a possible way to report problems. After reading it for a few weeks, I think that it is a bad idea. Cooker should be a list for developers only. That is, it should be possible to report a bug on it *only if one has a fix* (a real one, a patch, or a significant work around, not just saying 'it works in Windows or with RedHat or Mandrake version N') Do this a firm and explicit policy for everyone and cooker will be much easier to read. Warn infringers, including people responding to non-developer posts. If it does not work, cast them out of the mailing list. An indirect advantage is that newcomers will be much less frequent, so you could then ask firmly for well formatted mails (no html, no top-posting, correct quoting - snipping the irrelevant parts), giving more readable posts. Also warn and take action against chatters. As per the Netiquette, personnal or irrelevant discussions should be done by private email. There is way too much noise on this list. If you have a strict policy on Cooker, bugzilla *has* to work - non-developers can also have interesting input. If possible a community moderation could be useful to cut the time wasted by Mandrake developers on bugzilla. With a vote system (Apache like), an uninteresting bug report could be deleted by negatives votes from 2 different people, for example. The moderators would be selected by Mandrake of course. If no decision occurs in a specified time, the bug is automatically escalated to a higher level to be seen by Mandrake people. Anyway, Mandrake _has_ to have a _good_ bugmaster, whose *primary* responsibility is to handle bugzilla, move problems to cooker when appropriate, and move workarounds and fixes posted on cooker to bugzilla bugs. To sum up the argument : - Cooker should be the place where contributors bring _solutions_ to Mandrake. - Bugzilla should be the place where people bring _problems_ to Mandrake. Finally, congrats and take some good time now, you all deserved it. RC3 works much better for me than 8.2 (and I was happy with 8.2). Next time expert mode in drakconnect will work I'm sure :-) Gerard
Re: [Cooker] 9.0 and next: list server
On Thu, Sep 26, 2002 at 04:34:21PM +0800, Leon Brooks wrote: > * this leaves one of: > >* bandwidth; or > >* hardware (I'm inclined to discount this since most messages seem > to get through eventually); or > >* the software on Moseisley (neither Moseisley nor Smtp admit to > being PostFix, nor do they generate PostFix-looking message queue > IDs). 4th possible option: * Poor configuration or system administration. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote: > Wow, you're suggesting that a developer use something other than emacs > to read mail. Do you realize that could be considered sacriligious by > some? :) Not me, but most... Emacs? What are you talking about a real email client is mutt. :P -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
On Thu, Sep 26, 2002 at 10:34:31AM -0700, Curtis H wrote: > I would think that modifying rpmmon is what your thinking of. Running > 'rpmmon.pl -p could show the mandrakesoft maintainer and bug > triager Wouldn't be too hard. Would take a change in the maints file format though... -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
On Wed, 2002-09-25 at 12:35, Warly wrote: > 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. > * improve the cooker cooker FAQ pages, about cooker etiquette and everything > when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3) GOD yes, this thing is horrendously out-of-date. > * improved bugzilla to have a easy mail interaction system, and a more > friendly interface. And to have a last known problems page. Good. Two more: 1) A reliable listserver. 2 a) The volunteer triage idea is excellent. I volunteer! b) Acknowledgement, acknowledgement, acknowledgement. -- Brad Felmey
Re: [Cooker] 9.0 and next
Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 : > > Maybe we need a Cooker FAQ... http://www.mandrakelinux.com/en/cookerfaq.php3 Blue skies... Todd -- MandrakeSoft USA http://www.mandrakesoft.com Easy things should be easy, and hard things should be possible. --Larry Wall Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-16mdk msg77075/pgp0.pgp Description: PGP signature
Re: [Cooker] 9.0 and next
Leon Brooks wrote on Thu, Sep 26, 2002 at 05:55:43PM +0800 : > > Would an adaptation to KMail (or whatever y'all use) to do boilerplate > replies help? I'm talking about something like a toolbar: Wow, you're suggesting that a developer use something other than emacs to read mail. Do you realize that could be considered sacriligious by some? :) Not me, but most... Blue skies... Todd -- MandrakeSoft USA http://www.mandrakesoft.com Mandrake: An amalgam of good ideas from RedHat, Debian, and MandrakeSoft. All in all, IMHO, an unbeatable combination. --Levi Ramsey on Cooker ML Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-16mdk msg77073/pgp0.pgp Description: PGP signature
Re: [Cooker] 9.0 and next
On Thu, 2002-09-26 at 04:17, Leon Brooks wrote: > On Thu, 26 Sep 2002 17:56, Thierry Vignaud wrote: > > Buchan Milne <[EMAIL PROTECTED]> writes: > >> So, I think it would be feasible (depeding on how easily Bugzilla > >> can be hacked to do this) to have at least one non-mandrakesoft > >> bug-triager per package, who would be able to answer the easy > >> questions (fixed in -Xmdk, known bug in original package, fix in > >> progress etc), thus removing a lot of the noise from the list. > > > that's quite an nice idea > > Mandrake Valued Professionals? (-: > > Or just Rueben's Angels? As in the `I have hired thee with my son's mandrakes' > occasion in Genesis chapter 30. (-: > > Each package would have two owners, the Mandrake employee and their lay > adoptee. Would it be feasible to tuck that away in the RPMs somewhere so it > could be found by Cooker denizens but not widely advertised (e.g. doesn't pop > out in rpm -qi) for the Mandrake-using public at large? > > Cheers; Leon > > I would think that modifying rpmmon is what your thinking of. Running 'rpmmon.pl -p could show the mandrakesoft maintainer and bug triager -- /curtis ><> Mandrake Linux 9.0 (cooker) Kernel Version 2.4.18-22w4l Uptime 18 days 0 hours 5 minutes
Re: [Cooker] 9.0 and next
On Thu, 2002-09-26 at 23:40, Guy.Bormann wrote: > [snip] > > 2. a trust metric system for bug reporters. > > > > (2) would be useful because it would give a fast indication of where the > > problems lie (I'm thinking of tying this into drakbug or something), and > > automatically filter out "noise" > How would you handle aging of the trust metric? When there is aging, it > relieves the problem of "quality" posters turning "crappy" due to lack of > time, lost interest, ... On the other hand, it punishes "quality" posters > that irregularly send consistently good reports. Ahhh, now this is where it would be helpful if I knew a bit more about AI and statistics. The points you raise are indeed valid. I don't know that it will be a huge problem. I don't think that frequency of posting should be considered. I mean, if someone doesn't have time, they won't post :) - that doesn't mean that their competence with mandrake somehow decreases over that time. I think you are talking about a system where there is a theoretically infinite level of "goodness". That's not what I had in mind. Something more like a number between 0 and 1 - say (good posts) / (total posts) How do other systems handle this? James.
Re: [Cooker] 9.0 and next
[snip] > 2. a trust metric system for bug reporters. > > (2) would be useful because it would give a fast indication of where the > problems lie (I'm thinking of tying this into drakbug or something), and > automatically filter out "noise" How would you handle aging of the trust metric? When there is aging, it relieves the problem of "quality" posters turning "crappy" due to lack of time, lost interest, ... On the other hand, it punishes "quality" posters that irregularly send consistently good reports. Guy
Re: [Cooker] 9.0 and next
On Thu, 2002-09-26 at 03:35, Warly wrote: > Please comment on what you liked, disliked in the 9.0 building, testing > and problem reporting process. I think there were far too many posts to the cooker list about issues that were user problems. Now, these are important certainly because if there's too many user problems then the software isn't simple enough. However, I really think there needs to be a way to separate these from "real" issues. I mentioned two ways in a post I made a little while ago. I'll make them again, but briefer this time. 1. a "testing" system, kinda like debian. Basically just a cooker mirror of packages that haven't changed in a week or so and are thus in some sense "stable". 2. a trust metric system for bug reporters. (1) would allow these people who just became frustrated with cooker to still make useful contributions about the usability of the system (this should have a separate mailing list) (2) would be useful because it would give a fast indication of where the problems lie (I'm thinking of tying this into drakbug or something), and automatically filter out "noise" Just a thought. James.
Re: [Cooker] 9.0 and next
On Thu, 26 Sep 2002 17:56, Thierry Vignaud wrote: > Buchan Milne <[EMAIL PROTECTED]> writes: >> So, I think it would be feasible (depeding on how easily Bugzilla >> can be hacked to do this) to have at least one non-mandrakesoft >> bug-triager per package, who would be able to answer the easy >> questions (fixed in -Xmdk, known bug in original package, fix in >> progress etc), thus removing a lot of the noise from the list. > that's quite an nice idea Mandrake Valued Professionals? (-: Or just Rueben's Angels? As in the `I have hired thee with my son's mandrakes' occasion in Genesis chapter 30. (-: Each package would have two owners, the Mandrake employee and their lay adoptee. Would it be feasible to tuck that away in the RPMs somewhere so it could be found by Cooker denizens but not widely advertised (e.g. doesn't pop out in rpm -qi) for the Mandrake-using public at large? Cheers; Leon
Re: [Cooker] 9.0 and next
On Thu, 26 Sep 2002 11:39:36 +0200 Thierry Vignaud <[EMAIL PROTECTED]> wrote: > what's more sometimes we can be in mad mood because of multiples > identical reports or "support requests disguised as reports", invalid > bug reports, ... > > these 3 items may explain why sometimes people can think we don't care > about them or their reports: this is just because we're not perfect. > this was not planned. > > anyway we're sorry if you (the communauty) can get annoyed by feeling > we don't care about you (ie by not get enough feedback from your > feedback, ideas, ...). Personally, I expected no explicit feedback at all (having come across this problem many times before - if developers spent much of their time saying "done" less would be "done") and the best feedback was to see something I'd reported fixed. There's considerable good faith involved which was duly repaid; for example, I felt the problems I had with RC3, USB and solid state devices were obvious enough and had been reported sufficiently clearly, I knew that things were happening to the kernel and was sure those problems would be fixed by kernel changes for 9.0 final: they were! I understand there's a problem with this implicit contract, though, when people feel they're being ignored. In quite a number of cases the resolution was from someone not from Mandrakesoft to take the problem on and solve it on the list, but I'm struggling to come up with a general solution; my initial suggestion was for an obvious "tag" (eg REPOST) in an email header but, if that were done, everyone would use it to try to flag their own favourite problem and real problems would be drowned out in the shouting. The problem with bad-quality bug reports is also very difficult to tackle. Granted, you need people who are expert in the internal workings of Linux, but you also need people like me who tackle softer issues (eg glitches with the Gnome UI). Given this diversity there are always going to be inappropriate reports made; the problem with making bug reporting difficult is that bugs will be missed. (I would prefer too many reports, with redundancy and irrelevancy, rather than too few, with incomplete coverage). Also, as someone who has developed with Unix (Solaris, AIX) extensively in the past and who is uncovering a brave new world in the handling of hardware, I believe it would be very useful if the type of output considered helpful for various types of bug was listed. For example, I wouldn't have known of lspcidrake -v had I not subscribed to this list. Alastair PS The idea that people sign up to looking after certain packages is excellent.
Re: [Cooker] 9.0 and next
On Thu, 26 Sep 2002 17:39, Thierry Vignaud wrote: > Gerard Patel <[EMAIL PROTECTED]> writes: >> I got the impression that some developers were reluctant to use the >> mailing list; for example, I posted a message about net_monitor, got >> invited to post code, did it, got absolutely no answer, reposted in >> case the code had been lost, in vain, gave up, then noticed that the >> code had been indeed added to net_monitor. > you have to understand that we receive lots of mails (i mean several > thousands per day). > we use scorring and the like to reduce the text volume to read but it > still takes time. > so when an adknowledgment (such as "ok", "thanks", "won't do it", > "we'll do that after the release", ...) would be fine, we sometimes > don't do it. Would an adaptation to KMail (or whatever y'all use) to do boilerplate replies help? I'm talking about something like a toolbar: +-+ +---+ +-+ +---+ +---+ +---+ +---+ | | | | | | | After | | Need | | Fixed | | Wash | | Yes | | Sorry | | No! | | this | | more | | in| | mouth | ... | | | | | | | relse | | input | | curnt | | out | +-+ +---+ +-+ +---+ +---+ +---+ +---+ It wouldn't be too hard to rig KMail for this. That way it takes under a second to do a standard response like `Has anyone else seen this?' or `Bug referred upstream'. Cheers; Leon
Re: [Cooker] 9.0 and next
Buchan Milne <[EMAIL PROTECTED]> writes: > And, there also need to be people who use the software in question > daily. As an example (not to dis Fred), I don't think Fred Crozat > uses Mozilla mail, but he is the packager. I do use mozilla-mail > daily (and have about 30 people, increasing daily, using it on > windows atm). > > I am quite sure that between the non-Mandrakesoft employees on this > list, and the MandrakeExperts, that there could be approx 1 > volunteer per major package. > > So, I think it would be feasible (depeding on how easily Bugzilla > can be hacked to do this) to have at least one non-mandrakesoft > bug-triager per package, who would be able to answer the easy > questions (fixed in -Xmdk, known bug in original package, fix in > progress etc), thus removing a lot of the noise from the list. that's quite an nice idea
Re: [Cooker] 9.0 and next
On Wednesday 25 September 2002 01:35 pm, Warly wrote: > 9.0 is (likely to be) finished. > ... > Please comment on what you liked, disliked in the 9.0 building, testing > and problem reporting process. > The best part of the process was accessibility - I felt I was part of the "team". When one approach stalled there were always a few others to try. I'd like to see a cooker web site run on cooker snapshots. I realize there will be sometimes when cooker is so broken that running on the latest cooker is impossible but running on frequent snapshots would help set real priorities, mainitain focus and set realilstic expectations. Next I'd like to see explicit priorities. Not so much a management view but a developer view of where resources are likely to applied. We would all like to have everything but knowing that is impossible, I would settle for a sense of direction. I would also like to see hardware compatibility split from software functionality. I can solve hardware compatibility issues at finite cost, some software issues can not be solved by any amount of money. Many projects have test suites. Many users have test applications. Many of us have limited coding capability but we could all volunteer to test a few packages promptly and carefully. It would be reassuring to know that some people could get some functionality out of a package. Linux is the best game on the planet and Mandrake is the best team. Thanks, Jim Tarvid
Re: [Cooker] 9.0 and next
Le Thu, 26 Sep 2002 00:17:02 +0200, Buchan Milne a écrit : > On Wed, 25 Sep 2002, Ralph F De Witt wrote: > >> First of I would like to say that all at Mandarke and volunteers and >> developers did very well with 9.0. It is going to be a great release. I >> am pleased that the beta cycle was a little longer than 8.2. This has >> certainly helped to eleminate most bugs. >> I have no comments as to the building and testing phases. But I have >> comments on the reporting phase. I liked that there were three ways to >> report bugs, but I think that needs to be limited to one way. I really >> got mad when reporting 3 or 4 bugs during the RC3 portion via >> MandrakeExpert when I was told to get a Bugzilla account and report them >> myself, as the expert told me he ws told not to do any more bug reports >> because they were all usless. This really angered me. I agree that there >> are a lot of bad bug reports with a open beta like we do. I have probbly >> done a few my self. But I liked the MandrakeExpert way of doing it >> because I had someone more knowledgeable than me to look at it and say, >> hey how about doing this and this and sending the info. Or send the >> contains of such and such file. This allowed me to turn a bad bug report >> into a useful one, and one that was taken away from me I got very angry. >> I think bug reporting should have only one way to report, and that it >> should be a two step process. One submitte a report, get feed back as to >> other things that are need, when useful, it is submitted. I think that >> some sort of feed back needs to be given to the person reporting the bug >> when it is actioned and completed. >> Any way just my $.02, I hope it helps make the next beta testing go >> round smoother. > > I would agree with this sentiment. > > In the end, what needs to be accomplished for the next beta cycle is to > increase the number of bug reports dealt with successfully, while reducing > the time developers/packages spend doing so. > > One aspect is ensuring that all bugs are reported in some way. I have done > a bit of mining other sites (MandrakeForum and PCLinuxonline) to try and > get bugs that were compained about there reported (and I think I got at > least one bug report to cooker). Thanks for that.. But usually, bugs reported on forums are very bad quality bug reports or hardware specific bugs.. It means we need "direct" contact with the reporter (eitheir with email or bugzilla..) > Also, accurate summaries of the number of unresolved bugs etc need to be > available (watch the errata for some bugs that were known but not resolved > that could have been ...). > > Other projects (OO.o, Mozilla, RH) seem to be able to use Bugzilla > effectively, so I don't think Bugzilla is the problem. It is not part of the problem, it is part of the solution.. A well maintained bugzilla can be a very useful tool : Let's share my work with GNOME 2. During GNOME 2.0 development, one bugmaster (Louie Villa, who is a Ximian employee but who was paid by Sun for this task) was triaging bugs all day long (even during night :)) Thanks to Louie, GNOME 2.0 has not slipped too much and GNOME release team had a way to monitor project status.. We currently have NO bugmaster here at MandrakeSoft (our QA team has already too much work with hardware testing and other things)... This is why we didn't open fully our bugzilla like before (we did that with 8.0 IIRC and it was a mess, mainly because of bad quality of bug reports..) MandrakeExpert bug forwarding was an experiment for 9.0 but I (this is a personal opinion) think it has failed somehow, because not of quality of bug reports and often missing email to ask for details.. I suggested to Warly why we should try "plug" bugzilla to cooker mailing-list, ie when a new bug is created on bugzilla, an email is be send to cooker for review by Cooker community (either triagged as duplicate, or more info added by other folks having the same problem..). Replies on this email would be archived on bugzilla. This is not a easy thing to do since registration on bugzilla is needed to be able to add comments on bug but Warly told me he will investigate after 9.0 is out.. WDYT of this proposal ? > The other issues is that there is a substantial amount of free labour > available, and this should be taken advantage of. > > And, there also need to be people who use the software in question daily. > As an example (not to dis Fred), I don't think Fred Crozat uses Mozilla > mail, but he is the packager. I do use mozilla-mail daily (and have about > 30 people, increasing daily, using it on windows atm). Agreed.. One of the strengh of Debian is the high number of packagers : usually, packager uses their software.. But I package Evolution, Mozilla and Galeon and I can only use one mailer and one web browser :(( > I am quite sure that between the non-Mandrakesoft employees on this list, > and the MandrakeExperts, that there could be approx 1 volunteer per
Re: [Cooker] 9.0 and next
Gerard Patel <[EMAIL PROTECTED]> writes: > I got the impression that some developers were reluctant to use the > mailing list; for example, I posted a message about net_monitor, got > invited to post code, did it, got absolutely no answer, reposted in > case the code had been lost, in vain, gave up, then noticed that the > code had been indeed added to net_monitor. you have to understand that we receive lots of mails (i mean several thousands per day). we use scorring and the like to reduce the text volume to read but it still takes time. so when an adknowledgment (such as "ok", "thanks", "won't do it", "we'll do that after the release", ...) would be fine, we sometimes don't do it. i understand this can be frustating but we cannot yet clone ourselves to work 72h a day :-( if we get something just right, we just commit it :-) or we just package it :-) (and then it get reported in changelog ml) you can see that a confiance evidence in your posts or reliability proof into our reports we've an internal ml called install that get "spammed" with cvs commits. maybe should we make publically availlable a cooker-cvs ml. you must understand that releasing time is very stressing time for us. on the other hand, we're humans like everybody and we're not perfect. what's more sometimes we can be in mad mood because of multiples identical reports or "support requests disguised as reports", invalid bug reports, ... these 3 items may explain why sometimes people can think we don't care about them or their reports: this is just because we're not perfect. this was not planned. anyway we're sorry if you (the communauty) can get annoyed by feeling we don't care about you (ie by not get enough feedback from your feedback, ideas, ...). we can do better and will try to do better :-) we'll still try to give you the better we can do :-)
Re: [Cooker] 9.0 and next
Gary Lawrence Murphy <[EMAIL PROTECTED]> writes: > - A 'gripe' button that will compose a message to send > to cooker-bugs while also capturing essential system > information (kind of like the old windows dr watson. drakbug let you post a bug report to bugzilla
Re: [Cooker] 9.0 and next
Hi Leon, On Thu, 26 Sep 2002, Leon Brooks wrote: > Would a regular (nightly + cumulative weekly?) automated global string diff > posted to the i18n list help? I don't think string diffs are very relevant; but posting to the list which packages (are expected to) have string changes and making sure that each translator is subscribed to that list would help already. And like I said; observe a complete string freeze a certain period before final release so that translators have enough time to catch up. Such a string freeze may only be broken after explicit permission from the translations coordinator. my 2 eurocents, -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] 9.0 and next: list server
On Thu, 26 Sep 2002 10:40, Levi Ramsey wrote: > Perhaps it might make sense to segment the cooker list. Have > cooker-kde, cooker-gnome, and cooker-apache in addition > to a general cooker list. Don't like that very much. Some problems can strike across boundaries (e.g. X bug gets both KDE and Gnome). AFAICT, the existing list manager (yavin and/or moseisley.mandrax.org) is just plain wonky and needs taking out and shooting. * My own copies of Sympa just don't do that; and * I've never had PostFix do anything bizarre or even unexpected (contrast that with MS-Exchange), which lets out the software on Yavin; and * AFAICT no non-list Mandrake mail goes walkies, which lets out smtp.mandrakesoft.com unless it's dedicated to Cooker traffic; and * this leaves one of: * bandwidth; or * hardware (I'm inclined to discount this since most messages seem to get through eventually); or * the software on Moseisley (neither Moseisley nor Smtp admit to being PostFix, nor do they generate PostFix-looking message queue IDs). The only other oddity I can see in the headers is that some clocks are evidently off by a few minutes (mail arriving at the next hop before it's sent, that kind of thing). Cheers; Leon
Re: [Cooker] 9.0 and next
Le Wed, 25 Sep 2002 22:40:36 +, Levi Ramsey a écrit : > On Wed Sep 25 19:20 -0700, Quel Qun wrote: >> I think the mailing list has reached its limit. It was very frustrating >> to send problem reports and see them vanish in cyberspace because the >> list suddenly collapsed. We complain about incomplete reports, but it >> takes time to write a detailed message, cutting and pasting standard out >> and co. I cannot afford keeping several terminals per problem open for >> hours. > > Was it hardware overload that took the lists down? Or software overload > at lists with too much traffic? It was a DNS resolving issue on our mail server, which was affecting not only cooker mailing list but all mandrakesoft emails :(( I think it is "murphy's law" in release team... Usually we had problem with our compilation cluster.. This time, it was the mailing list :) > Perhaps it might make sense to segment the cooker list. Have cooker-kde, > cooker-gnome, and cooker-apache in addition to a general cooker list. > Users who have no interest in running Apache can decide not to subscribe > to cooker-apache but instead get a daily digest, and so forth. Fred > Crozat could then spend most of his time on the cooker-gnome list and > ignore the KDE list. Developers who only work on Apache can stick to that > list. This is not needed.. I don't read mails which are about KDE or Install (well, I read them but very quickly).. If only people were using real topics and split their mails, it would be easier to track :) -- Frédéric Crozat MandrakeSoft
Re: [Cooker] 9.0 and next
On Thu, 26 Sep 2002 03:13, Reinout van Schouwen wrote: > To make a long story short: next time I would like to see a string freeze > that can only be broken in special cases and with notification of > translators in due time. The way the Gnome Translation Project works, can > be used as a model. Would a regular (nightly + cumulative weekly?) automated global string diff posted to the i18n list help? Cheers; Leon
Re: [Cooker] 9.0 and next
On Wednesday, September 25, 2002, at 01:25 PM, J. Greenlees wrote: >> If bugzilla would be enhanced in a way that you only have to paste the >> package name (+version) in it and then see all open problem reports >> and >> could create a new problem report for it with one more click, it would >> be probably used... >> > > not so hard, I think I have a phpscript that would do this. ( from a > book on php/mysql apps ) > actually coded as a bug reporting app. Except that Bugzilla's written in perl and the last time I looked at it, was very very messy code. Anthill, on the other hand, is written in PHP. -- MandrakeSoft Security; http://www.mandrakesecure.net/ "lynx - source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} PGP.sig Description: PGP signature
Re: [Cooker] 9.0 and next
> "B" == Ben Reser <[EMAIL PROTECTED]> writes: >> - A MandrakeUpdate-like ability to incrementally or selectively >> upgrade a cooker installation B> It already exists. urpmi --auto-select. How do you think we B> update our boxes? You learn something new every day! Thanks for the tip. Maybe we need a Cooker FAQ... -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.auracom.com/~teledyn - biz: http://teledyn.com/ - "Computers are useless. They can only give you answers." (Picasso)
Re: [Cooker] 9.0 and next
Excellent. That's what I meant to suggest with all my rambling, exactly. Good one. -AEF On Wednesday 25 September 2002 10:08 pm, Jonathan Drews wrote: > On Wednesday 25 September 2002 12:35, Warly wrote: > > 9.0 is (likely to be) finished. > I think bug reports should contain, at a minimum, the rpm package and > the ISO version of mandrake (beta 3, RC1, etc.). That is in the upper > left hand corner of the e-mail it should give the output of rpm -q > package or rpm -qf /path/to/package. > Package No. of testers already > Nautilus18 > Open office 11 > Kword 3
Re: [Cooker] 9.0 and next
On Wednesday 25 September 2002 12:35, Warly wrote: > 9.0 is (likely to be) finished. > 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. Hello Warly and others: I think bug reports should contain, at a minimum, the rpm package and the ISO version of mandrake (beta 3, RC1, etc.). That is in the upper left hand corner of the e-mail it should give the output of rpm -q package or rpm -qf /path/to/package. Also it may be a good Idea to have a sign up sheet, poll or "to do" list where people can designate which apps they will test. That way no packages are left untested and redundant bug reports are not filed from over tested packages. Something like the polling schemes, in Mandrake Club, on a web page: Package No. of testers already Nautilus18 Open office 11 Kword 3 and so on That is people click on the apps they intend to test and a poll is then generated showing how many folks intend to test that app. -- Cheers, Jonathan "Easy things should be easy, and hard things should be possible." --Larry Wall
Re: [Cooker] 9.0 and next
On Wed Sep 25 19:20 -0700, Quel Qun wrote: > I think the mailing list has reached its limit. It was very frustrating > to send problem reports and see them vanish in cyberspace because the > list suddenly collapsed. We complain about incomplete reports, but it > takes time to write a detailed message, cutting and pasting standard out > and co. I cannot afford keeping several terminals per problem open for > hours. Was it hardware overload that took the lists down? Or software overload at lists with too much traffic? Perhaps it might make sense to segment the cooker list. Have cooker-kde, cooker-gnome, and cooker-apache in addition to a general cooker list. Users who have no interest in running Apache can decide not to subscribe to cooker-apache but instead get a daily digest, and so forth. Fred Crozat could then spend most of his time on the cooker-gnome list and ignore the KDE list. Developers who only work on Apache can stick to that list. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Love lies in pools of questions. GPG Key Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Monster Magnet - Tractor Linux 2.4.19-9mdk 10:34pm up 5:39, 4 users, load average: 0.19, 0.25, 0.18
Re: [Cooker] 9.0 and next
First of all, congratulations for this new release. One thing I really appreciated was the smooth roll in of Gnome2. Really impressive! > * improved bugzilla to have a easy mail interaction system, and a more > friendly interface. And to have a last known problems page. > I think the mailing list has reached its limit. It was very frustrating to send problem reports and see them vanish in cyberspace because the list suddenly collapsed. We complain about incomplete reports, but it takes time to write a detailed message, cutting and pasting standard out and co. I cannot afford keeping several terminals per problem open for hours. When it was working, however, the mandrake page was nearly showing the message in real time and that was really nice. Now, what about making these page searchable with advanced search engine allowing complex queries (contain this and not that, no older than, etc)? On the other hand, I don't know if you can afford contempt, but this is exactly how it looks when a question is asked or a fix is provided and they receive no echo whatsoever. It would be nice if at least the package maintainer could acknowledge, even by a message saying: 'Irrelevant' or 'postponed'. A Bugzilla-like system would certainly be better for that. Finally, some messages have been posted in Spanish or French. Although I can understand why the list should be limited to one language only, it would be nice to provide some help to those who really don't know it. Maybe a link to babelfish on the cooker page would be a start? Once again, congrats to all Mandrake people for releasing a good looking Dolphin in the wild. =o= kk1 signature.asc Description: This is a digitally signed message part
Re: [Cooker] 9.0 and next
On Wed, Sep 25, 2002 at 07:29:55PM -0400, Gary Lawrence Murphy wrote: > - A MandrakeUpdate-like ability to incrementally > or selectively upgrade a cooker installation > so you can first ensure you are using the very > latest software before you submit the bug. It already exists. urpmi --auto-select. How do you think we update our boxes? -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org Never take no as an answer from someone who isn't authorized to say yes.
Re: [Cooker] 9.0 and next
> > > >If bugzilla would be enhanced in a way that you only have to paste the >package name (+version) in it and then see all open problem reports and >could create a new problem report for it with one more click, it would >be probably used... > not so hard, I think I have a phpscript that would do this. ( from a book on php/mysql apps ) actually coded as a bug reporting app.
Re: [Cooker] 9.0 and next
On Wednesday 25 September 2002 12:35 pm, Warly wrote: > Please comment on what you liked, disliked in the 9.0 building, testing > and problem reporting process. 1. I feel like I contributed at least a little bit, that's good. 2. I feel like mysterious people in a basement somewhere did all the work and I never got to know what they "were about to do" before they did it. Not fun, no "meatware" interactivity in this category. Therefore, the whole thing feels like it was "shoot from the hip" meanwhile what happened to all the "strategery" points behind all that was actually done ? 3. I somehow feel like little or no effort was made to explain choices that were made in foundational elements like particular kernel version, c, c++ compiler, libc, glibc, etc., and also what the known consequences are... and therefore the strategies are... and all packages must conform to x.y.z standards... Feels like "shoot from the hip... to completion" whether or not that's the deal, that's what it feels like. This kind of feedback ? THX -AEF
Re: [Cooker] 9.0 and next
I have run several beta testing during this present years including Microsoft.net, but Manadrake has improved a lot in only four or 5 years, I remembered the first Mandrake that I purchased that really gave a hard time to install and configure but Mandrake 9.0 is very good even so that It is not final version and it is incomplete without the commercial packages, I do not know If Mandrake will be using Star Office 6.0, but I have not seen the great improvement from 5.2 to 6.0, I prefer to use KDE office, it run much better than 6.0, maybe I am mistaken but that is my impression using Mandrake 8.2 and Suse 8.0, even so Suse is not using SO 6.0 on its 8.1 version. The Mandrake 9.0 has very nice color, and it is very friendly to be used, I had some difficulties with the new video cards, and it did not want to install on the new AMD chipset for dual processors, I had to install it on a single processor motherboard, many home users are building dual processor computers as file servers, and many home offices are using servers and powerfull workstations even gamers are using dual processors motherboards, when I installed the printers I had a couple of errors but it was able to fix them, besides all that the 9.0 is a very good operating systems, let see what will happen , because many good Linux are coming out on October thru December, even better than Microsoft.net that I have tested both the Standard and the Enterprise. The connection for updating was improved on this version, because I had many difficulties with 8.2. I would like to congratulate Mandrake developers for the job that they have done and I think that in the future we will see Linux dominating the desktop market because it is getting bigger and bigger everyday Tom Brinkman <[EMAIL PROTECTED]>wrote: On Wednesday September 25 2002 12:35 PM, 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've been runnin 8.3/9.0 since June (previous cooker before that), the only 9.0 bug I reported was fixed before my post showed up ;) Mostly I'm a lurker.> I already collect on various mandrake IRC channels:http://www.mandrakeforum.org/article.php?sid=2284&lang=en"If you want help, use MandrakeExpert or the mailing lists or the alt.os.linux.mandrake newsgroup, the various #mandrake IRC channels etc."Actually there's even cooker bug reports posted to various other linux newsgroups. Y'all might note that 'mailing lists' in the above quote is a link to all the Mdk lists, newbie, expert, cooker, etc. I don't think this should change, nor do I believe it ever will. Most users are more intimidated by the cooker list than tryin to run cooker. Many don't want to subscribe or even be bothered to check the cooker ML archive. Most are discouraged if they don't get acknowledged.Still they don't have any hesitation to discuss cooker problems or bugs on the other lists or newsgroups. There they do often get acknowledged, even helped. So, seems to me, those of us that do run and subscribe to the cooker list, and other lists, could help a lot by coaxing these reports from 'other sources' into a usable form and report them to the cooker list ourselve! s. It would entail an effort by some cooker volunteers (my hand is up).OTOH, a policy of discouraging bug reports to this list only, other sources as inappropriate, not only would mostly fall on deaf ears, but also foster the 'useless' or obsolete (ie, already fixed in current cooker) reports many of y'all have been complaining about. (Maybe those persons should volunteer also ;)-- Tom Brinkman Corpus Christi, TexasDo you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Re: [Cooker] 9.0 and next
I second the idea to acknowledge bug reports posted to the cooker list, or how about this: We open a new public-postable mailing list called cooker-bugs where you get an acknowledgement of the submission, but you're told not to expect a response; this lets us keep a record of every novice contribution that may become valuable when we later discover more information through other sources -- sometimes the addition info submitted by a novice can shed critical light. If I were in the development/QA crew, I wouldn't want the bug tracker filled up with bad reports, I'd want to control what gets tracked by assigning someone to sift cooker-bugs for repeated reports that can perhaps be put together into a proper bug report worth tracking. Then, like Mozilla, we put the names of the original submitters on the ticket so they are informed of the progress on their bug. it's extra work, but I think it would pay off in the long run. Further to this, it would be nice if the cooker had two new cooker-only utilities: - A 'gripe' button that will compose a message to send to cooker-bugs while also capturing essential system information (kind of like the old windows dr watson. - A MandrakeUpdate-like ability to incrementally or selectively upgrade a cooker installation so you can first ensure you are using the very latest software before you submit the bug. More or less I'd like to open up Cooker QA testing to include more people; the size and complexity of the Mandrake distro is ever-increasing and it's becoming difficult for the core workers to test every possible combination. It's /nice/ to get bug reports from experienced developers, but sometimes by knowing too much, I think developers can forgive a bug that was "too easy to fix" only because they were actively monitoring the lists, irc and all, or just because they have a lot of mandrake experience. More novice users, but those still willing to take a chance on the cooker, could be useful, but I think they might get a little discouraged if the process is too complex (like the Universe, it should be simple, but not too simple ;) -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.auracom.com/~teledyn - biz: http://teledyn.com/ - "Computers are useless. They can only give you answers." (Picasso)
Re: [Cooker] 9.0 and next
On Wed, 25 Sep 2002, Ralph F De Witt wrote: > First of I would like to say that all at Mandarke and volunteers and > developers did very well with 9.0. It is going to be a great release. I am > pleased that the beta cycle was a little longer than 8.2. This has certainly > helped to eleminate most bugs. > I have no comments as to the building and testing phases. > But I have comments on the reporting phase. I liked that there were three ways > to report bugs, but I think that needs to be limited to one way. I really got > mad when reporting 3 or 4 bugs during the RC3 portion via MandrakeExpert when > I was told to get a Bugzilla account and report them myself, as the expert > told me he ws told not to do any more bug reports because they were all > usless. This really angered me. I agree that there are a lot of bad bug > reports with a open beta like we do. I have probbly done a few my self. But I > liked the MandrakeExpert way of doing it because I had someone more > knowledgeable than me to look at it and say, hey how about doing this and > this and sending the info. Or send the contains of such and such file. This > allowed me to turn a bad bug report into a useful one, and one that was taken > away from me I got very angry. > I think bug reporting should have only one way to report, and that it should > be a two step process. One submitte a report, get feed back as to other > things that are need, when useful, it is submitted. I think that some sort of > feed back needs to be given to the person reporting the bug when it is > actioned and completed. > Any way just my $.02, I hope it helps make the next beta testing go round > smoother. I would agree with this sentiment. In the end, what needs to be accomplished for the next beta cycle is to increase the number of bug reports dealt with successfully, while reducing the time developers/packages spend doing so. One aspect is ensuring that all bugs are reported in some way. I have done a bit of mining other sites (MandrakeForum and PCLinuxonline) to try and get bugs that were compained about there reported (and I think I got at least one bug report to cooker). Also, accurate summaries of the number of unresolved bugs etc need to be available (watch the errata for some bugs that were known but not resolved that could have been ...). Other projects (OO.o, Mozilla, RH) seem to be able to use Bugzilla effectively, so I don't think Bugzilla is the problem. The other issues is that there is a substantial amount of free labour available, and this should be taken advantage of. And, there also need to be people who use the software in question daily. As an example (not to dis Fred), I don't think Fred Crozat uses Mozilla mail, but he is the packager. I do use mozilla-mail daily (and have about 30 people, increasing daily, using it on windows atm). I am quite sure that between the non-Mandrakesoft employees on this list, and the MandrakeExperts, that there could be approx 1 volunteer per major package. So, I think it would be feasible (depeding on how easily Bugzilla can be hacked to do this) to have at least one non-mandrakesoft bug-triager per package, who would be able to answer the easy questions (fixed in -Xmdk, known bug in original package, fix in progress etc), thus removing a lot of the noise from the list. Since some of these volunteers may be "experts" at Mandrakeexpert, it may be convenient to be able to turn a bugzilla bug report into a support question. Similarly, a support question may need to be turned into a bug report. Then, all confirmed bug reports would go to the cooker list (since this is probably one of the quickest ways of dealing with real bugs). Unfortunately, that means people will have to make 'value judgements'. Now, we have a problem of who may thus write to Bugzilla, since we don't want to overrun the volunteers either. I would propose that users be given a rating, based on the quality of their bug reports, and the number of bug reports they could post would be dependant on that rating. Thus, if they have a number of bugs they want to report, they would have to ensure that the first bug reports are of high enough quality to warrant them posting more bugs. Customers (boxed set buyers or MandrakeClub members) may be given more bug reports for the same rating (50% more?), since this would give (for example) a corporate Club member significant influence on bugfixing to make membership more worthwhile. Then, we need to make sure that we have sufficiently motivated volunteers. Mandrakeexpert seems(ed?) to work well (although I haven't really 'experted' there for 6 months or more), but maybe volunteers would get twice the score for a resolved bug (based on the reporters rating and the developers rating maybe) at Mandrakeexpert (since resolved bugs in a beta/RC cycle must be worth more than explaining how to fix that same bug later). Since by now we have almost integrated Mandrakeexpert and bugzilla and MandrakeClub, I also see
Re: [Cooker] 9.0 and next
I enjoyed the beta process -- it works amazingly well. The first improvement I can think of is better integration between the bug tracker and the cooker list. It would be nice if bugzilla reports relevant to the betas where automatically forwarded to the list or such. Rich On Wed, 2002-09-25 at 13:35, Warly wrote: Please comment on what you liked, disliked in the 9.0 building, testing and problem reporting process. -- ars Cognita Richard Tango-Lowy - President [EMAIL PROTECTED] 603 424-0713 signature.asc Description: This is a digitally signed message part
Re: [Cooker] 9.0 and next
On Wednesday September 25 2002 12:35 PM, 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've been runnin 8.3/9.0 since June (previous cooker before that), the only 9.0 bug I reported was fixed before my post showed up ;) Mostly I'm a lurker. > I already collect on various mandrake IRC channels: http://www.mandrakeforum.org/article.php?sid=2284&lang=en "If you want help, use MandrakeExpert or the mailing lists or the alt.os.linux.mandrake newsgroup, the various #mandrake IRC channels etc." Actually there's even cooker bug reports posted to various other linux newsgroups. Y'all might note that 'mailing lists' in the above quote is a link to all the Mdk lists, newbie, expert, cooker, etc. I don't think this should change, nor do I believe it ever will. Most users are more intimidated by the cooker list than tryin to run cooker. Many don't want to subscribe or even be bothered to check the cooker ML archive. Most are discouraged if they don't get acknowledged. Still they don't have any hesitation to discuss cooker problems or bugs on the other lists or newsgroups. There they do often get acknowledged, even helped. So, seems to me, those of us that do run and subscribe to the cooker list, and other lists, could help a lot by coaxing these reports from 'other sources' into a usable form and report them to the cooker list ourselves. It would entail an effort by some cooker volunteers (my hand is up). OTOH, a policy of discouraging bug reports to this list only, other sources as inappropriate, not only would mostly fall on deaf ears, but also foster the 'useless' or obsolete (ie, already fixed in current cooker) reports many of y'all have been complaining about. (Maybe those persons should volunteer also ;) -- Tom Brinkman Corpus Christi, Texas
Re: [Cooker] 9.0 and next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 25 September 2002 12:13 pm, Reinout van Schouwen wrote: > Hi Warly, > > On Wed, 25 Sep 2002, Warly wrote: > > Please comment on what you liked, disliked in the 9.0 building, testing > > and problem reporting process. > > From a translator perspective, I'd like to comment that the continuing > string changes in the Mandrake tools sometimes are driving me up the > wall. Up until this weekend there have been string changes without the > translators even being notified in any way (I wonder how many developers > know about the cooker-i18n list?). This is making the "Mandrake > experience" a less pleasant to non-English users because they get > confronted with mixed english/own language interfaces. > > To make a long story short: next time I would like to see a string freeze > that can only be broken in special cases and with notification of > translators in due time. The way the Gnome Translation Project works, can > be used as a model. > > regards, Hi all: First of I would like to say that all at Mandarke and volunteers and developers did very well with 9.0. It is going to be a great release. I am pleased that the beta cycle was a little longer than 8.2. This has certainly helped to eleminate most bugs. I have no comments as to the building and testing phases. But I have comments on the reporting phase. I liked that there were three ways to report bugs, but I think that needs to be limited to one way. I really got mad when reporting 3 or 4 bugs during the RC3 portion via MandrakeExpert when I was told to get a Bugzilla account and report them myself, as the expert told me he ws told not to do any more bug reports because they were all usless. This really angered me. I agree that there are a lot of bad bug reports with a open beta like we do. I have probbly done a few my self. But I liked the MandrakeExpert way of doing it because I had someone more knowledgeable than me to look at it and say, hey how about doing this and this and sending the info. Or send the contains of such and such file. This allowed me to turn a bad bug report into a useful one, and one that was taken away from me I got very angry. I think bug reporting should have only one way to report, and that it should be a two step process. One submitte a report, get feed back as to other things that are need, when useful, it is submitted. I think that some sort of feed back needs to be given to the person reporting the bug when it is actioned and completed. Any way just my $.02, I hope it helps make the next beta testing go round smoother. - -- Yours, Ralph. It said Use Windows XP or better, so I installed MandrakeLinux 8.2 Register Linux User 168814 ICQ #49993234 AIM ralphdewitt jabber.org ralphdewitt GPG Public Key available at http://www.keyserver.net Key fingerprint = 6426 1CFF 0987 9D51 76D6 06BC F22A CFF4 559A 03E7 Kernel version 2.4.18-6mdk Current Linux uptime: 2:45, days user hours minutes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9kiBi8irP9FWaA+cRAqf6AJ4w/j5hEsLN3HguwK1DH2nWac+WvwCgrcDY i7Cuqr3WZIuuKuTr1AThB5A= =LX8b -END PGP SIGNATURE-
Re: [Cooker] 9.0 and next
On Wed, 2002-09-25 at 19:55, [EMAIL PROTECTED] wrote: > Here's an idea you might like. > A lot of inexperienced users throw some pretty crappy bug reports onto the > cooker list. We don't have enough info to figure it out, and Mandrake people > probably don't have enough time to answer them all. If none of us (volunteers) > try to help these people out, they just get ignored. I see a LOT of "I got > ignored" or "this is the third time I've reported this bug" posts. Maybe you > (Mandrake people) could make up a form-letter type response, and make a policy > that all bugreports get answered, even if the answer is just a form-letter > saying something like: > -we got your report > -we want your report > -we can't figure out what is happening to you > -please read the cooker faq > -please send us a more detailed report (hardware, example case, logs... etc) > That way, newbies to the list won't feel ignored and they can learn. Then they > can join us. Then we will be indestructable and we will take over the world... > Austin > First of all - Kudos and congratulations to the hard working Mandrake staff - the 9.0 release is truly a milestone! I agree wholeheartedly with the above post. As a frequent contributer to this list, I found myself at times getting frustrated because of lack of feedback on some of my posts. I never took it personally, but it would have been nice to at least acknowledge the receipt of the information. The suggestions above are enough to keep frequent contributers and newcomers coming back for more . . . Sometimes I questioned the value of posting a problem or "bug" because it felt like it was falling on deaf ears . . . I think every post should at least be acknowledged (even if it's an automated response). Even better when the problem is quickly resolved! Keep up the fantastic work, and many thanks for an exceptional product! R.Fox
Re: [Cooker] 9.0 and next
At 07:35 PM 9/25/02 +0200, you wrote: >Please comment on what you liked, disliked in the 9.0 building, testing >and problem reporting process. I have followed cooker since beta3 and I have been badly surprised by the lack of reliability of the mailing list. Maybe replace it by a private news server as suggested by another poster would be a good idea. I got the impression that some developers were reluctant to use the mailing list; for example, I posted a message about net_monitor, got invited to post code, did it, got absolutely no answer, reposted in case the code had been lost, in vain, gave up, then noticed that the code had been indeed added to net_monitor. No discussion, no question, no one but myself and (I hope) the Mandrake developer had the occasion to test my code. Very strange. Bad communication is usual in open source but I have never seen something like that until cooker. Gerard
Re: [Cooker] 9.0 and next
Sounds like something more useful for Shoemaker to do. --- [EMAIL PROTECTED] wrote: > Here's an idea you might like. > A lot of inexperienced users throw some pretty > crappy bug reports onto the > cooker list. We don't have enough info to figure it > out, and Mandrake people > probably don't have enough time to answer them all. > If none of us (volunteers) > try to help these people out, they just get ignored. > I see a LOT of "I got > ignored" or "this is the third time I've reported > this bug" posts. Maybe you > (Mandrake people) could make up a form-letter type > response, and make a policy > that all bugreports get answered, even if the answer > is just a form-letter > saying something like: > -we got your report > -we want your report > -we can't figure out what is happening to you > -please read the cooker faq > -please send us a more detailed report (hardware, > example case, logs... etc) > That way, newbies to the list won't feel ignored and > they can learn. Then they > can join us. Then we will be indestructable and we > will take over the world... > Austin > __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Re: [Cooker] 9.0 and next
why not, as Alan suggests, only one route for reporting bugs, use bugzilla or something similiar and this list used more for communication between steady testers. with a public report from the bugzilla system being made available for those on this list? but not solely a public bugzilla, one for registered cooker members, reguardless of thier participation on this list. that way all bugs are reported on, and in, the same forum, with the list acting as a tool to facilitate communication between the testers when needed. the reasons for using a bug reporting system are simple, a specified format for the bug report, and with verification, avoiding duplication of bugs being reported / worked on through this list. newsgroups, while they work, are even more open than the list, allowing more not very usefull postings than happen here. Alan Hughes wrote: >I think one positive point is that the Beta/RC cycle was much longer this >time round, giving people a lot more time to find problems and report them. >With 8.2 the Beta/RC cycle was very quick, so a lot of problems made it >through to the final release that franckly should not have been there. >Hopefully the greater care that was taken this time around should be >reflected in a better quality release - watch this space for further >comments. > >I've already seem some of the responses, can I add my voice to those saying >that having multiple error reporting routes is not helpful. Personally I >think the Cooker list is the best place for this sort of thing, particularly >since many of the people who post here will also continue to play a role >in-between releases. Continuity and continuous testing is the theme I'm >trying to get at here. > >Another issue is feedback. If someone has gone to the trouble of reporting a >bug then a simple acknowledgement can go a long way to keeping them >motivated. In addition acknowledging help in the change logs would also be a >good thing - I noticed Pixel doing this, but I can't remember anyone else >doing so. > >Whether BugZilla should continue to be used I don't know - used properly it >could be a powerful problem reporting and monitoring tool, but I don't think >its been used properly by anyone (and that goes for the user community as >well as Mandrake people). What is needed is discipline - the user community >needs to be more careful reporting bugs, and Mandrake needs to use BugZilla >to provide feedback w.r.t. problem status and solution. Can we get that sort >of discipline? I don't know. > >Finally can I say that the impressions I've had of 9.0 indicate that >Mandrake has done a tremendous job. As a software professional I am more >than aware of the problems you can get on handling a project of that scale, >the fact that you have achieved so much speaks very highly of everyone >concerned. Early this year I was actually thinking of switching to another >distro (due to the problems with 8.2), but you have gone a long way to >renewing my confidence in Mandrake. > >Well done, now get some rest (and a large drink). > >Alan > >- Original Message - >From: "Warly" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, September 25, 2002 6:35 PM >Subject: [Cooker] 9.0 and next > > >>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. >> >>-- >>Warly >> > > > >
Re: [Cooker] 9.0 and next
Hi! On Wed, 25 Sep 2002 19:39:34 +0100 "Alan Hughes" <[EMAIL PROTECTED]> wrote: > Whether BugZilla should continue to be used I don't know - used > properly it could be a powerful problem reporting and monitoring tool, > but I don't think its been used properly by anyone (and that goes for > the user community as well as Mandrake people). What is needed is > discipline - the user community needs to be more careful reporting > bugs, and Mandrake needs to use BugZilla to provide feedback w.r.t. > problem status and solution. Can we get that sort of discipline? I > don't know. Well, I guess it would be used instead of the cooker mailing list if it would have advantages for the reporters. The one big disadvantage of a mailing list: You don't see all reports for a package. So you have to search (not always easy) or remember the one mail for the problem you currently have found. This can by already done with bugzilla, but it currenlty takes much to many steps to get to that point and even more the then create a new problem report - so searching the mailing list is currently easier. If bugzilla would be enhanced in a way that you only have to paste the package name (+version) in it and then see all open problem reports and could create a new problem report for it with one more click, it would be probably used... -- Michael Reinsch <[EMAIL PROTECTED]> http://mr.uue.org
Re: [Cooker] 9.0 and next
Hi Warly, On Wed, 25 Sep 2002, Warly wrote: > Please comment on what you liked, disliked in the 9.0 building, testing > and problem reporting process. >From a translator perspective, I'd like to comment that the continuing string changes in the Mandrake tools sometimes are driving me up the wall. Up until this weekend there have been string changes without the translators even being notified in any way (I wonder how many developers know about the cooker-i18n list?). This is making the "Mandrake experience" a less pleasant to non-English users because they get confronted with mixed english/own language interfaces. To make a long story short: next time I would like to see a string freeze that can only be broken in special cases and with notification of translators in due time. The way the Gnome Translation Project works, can be used as a model. regards, -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] 9.0 and next
I think one positive point is that the Beta/RC cycle was much longer this time round, giving people a lot more time to find problems and report them. With 8.2 the Beta/RC cycle was very quick, so a lot of problems made it through to the final release that franckly should not have been there. Hopefully the greater care that was taken this time around should be reflected in a better quality release - watch this space for further comments. I've already seem some of the responses, can I add my voice to those saying that having multiple error reporting routes is not helpful. Personally I think the Cooker list is the best place for this sort of thing, particularly since many of the people who post here will also continue to play a role in-between releases. Continuity and continuous testing is the theme I'm trying to get at here. Another issue is feedback. If someone has gone to the trouble of reporting a bug then a simple acknowledgement can go a long way to keeping them motivated. In addition acknowledging help in the change logs would also be a good thing - I noticed Pixel doing this, but I can't remember anyone else doing so. Whether BugZilla should continue to be used I don't know - used properly it could be a powerful problem reporting and monitoring tool, but I don't think its been used properly by anyone (and that goes for the user community as well as Mandrake people). What is needed is discipline - the user community needs to be more careful reporting bugs, and Mandrake needs to use BugZilla to provide feedback w.r.t. problem status and solution. Can we get that sort of discipline? I don't know. Finally can I say that the impressions I've had of 9.0 indicate that Mandrake has done a tremendous job. As a software professional I am more than aware of the problems you can get on handling a project of that scale, the fact that you have achieved so much speaks very highly of everyone concerned. Early this year I was actually thinking of switching to another distro (due to the problems with 8.2), but you have gone a long way to renewing my confidence in Mandrake. Well done, now get some rest (and a large drink). Alan - Original Message - From: "Warly" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 25, 2002 6:35 PM Subject: [Cooker] 9.0 and next > > 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. > > -- > Warly >
Re: [Cooker] 9.0 and next
Hi Alastair, On Wed, 25 Sep 2002, Alastair Scott wrote: > Seeing something you reported being fixed brings you very close to the > software, something you very rarely get with commercial software. That is true; however I have my doubts with the decision to let the "deep freeze" prevale above fixing a bug which causes a complete system freeze; which involves nothing more than using a different sound driver. (https://qa.mandrakesoft.com/show_bug.cgi?id=236) > I really think bugzilla should be scrapped, for external use at least. The There's already a system in place where not everyone may submit reports in bugzilla. regards, -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] 9.0 and next
On Wed, 25 Sep 2002 13:55:06 -0400 [EMAIL PROTECTED] wrote: > I see a LOT of "I got ignored" or "this is the third time > I've reported this bug" posts. Maybe you(Mandrake people) could make > up a form-letter type response, and make a policy that all bugreports > get answered, even if the answer is just a form-letter saying > something like:-we got your report > -we want your report > -we can't figure out what is happening to you > -please read the cooker faq > -please send us a more detailed report (hardware, example case, > logs... etc) That way, newbies to the list won't feel ignored and they > can learn. Then they can join us. Then we will be indestructable and > we will take over the world... Austin good idea, but how to tell bugreports apart from other things like Guido posted a problem with gcc3.2 and didn't get much attention. He was mighty pissed about the problem (not the attention ;) and will probably exclude at least mdk's gcc from his list of valid compilers for his projects. He's not bashing mandrake as he still doesn't know where the fault originated but a mail along "we'll look into that, need more info, etc" would certainly have eased his mind. Anyway, cooker drowns in support questions and useless policy discussions like for proprietary drivers. Though, admittedly, one cannot be sure whether a prob qualifies as bug or support-problem, see my problem with Mach64 cards. my personal experience with the few small probs I've found was excellent, everything was fixed pretty fast. - Mark
Re: [Cooker] 9.0 and next
On Wed, 25 Sep 2002 19:35:24 +0200 Warly <[EMAIL PROTECTED]> 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. First of all, congratulations to everyone at Mandrakesoft. A phenomenal, unbelievable effort ... and I feel I and many others made a difference too. Seeing something you reported being fixed brings you very close to the software, something you very rarely get with commercial software. I don't have anything to say on the building and testing process, but problem reporting is quite the opposite :) The problem reporting is very difficult to get right. My opinion is that there should be only one method of communication between beta testers and developers ... this mailing list, or possibly a dedicated newsgroup. The developers can cut and paste the valid bugs raised there into their own _internal_ database and have a read-only view of that made visible to the outside world (which would solve the 'last known problems' issue); the one exception to read-only would be the ability for the beta testers to add comments. After all: - the flexibility of a mailing list or newsgroup is unparalleled as posters can attach files, respond to other posts, be asked for and provide information, and get feedback on the spot; - I hate Web-based interfaces (and suspect I'm far from alone) as they're too slow and awkward: they also tend to be hostile to those with special needs (as someone with severe osteoarthritis who likes his keyboard I think I write with some authority ;) I really think bugzilla should be scrapped, for external use at least. The process whereby bug reports were pasted by Alan into this mailing list was dreadfully disjointed; in my estimation 80-90 per cent of those bug reports were worthless as the reporter was reporting 'cold' (with a mailing list there is a lot of precedent, in the form of previous postings, on how and what to post and what the current issues are) and, if there was any feedback from list members, it was difficult to get it back to the original bugzilla contributor. Doubtless doing all this will have, as a response, a howl that beta testers will be bombarded with emails. Such is life; I would prefer a small group of committed people who can cope with such things and keep going from beginning to end rather than 'occasional testers'. Alastair
Re: [Cooker] 9.0 and next
On Thu, 26 Sep 2002 01:55, [EMAIL PROTECTED] wrote: > I see a LOT of "I got ignored" or "this is the third time I've > reported this bug" posts. Amen! (-: ...and having everyone prefix their second try with REPOST: probably wouldn't be helpful, either. (-: > Maybe you (Mandrake people) could make up a form-letter type > response, and make a policy that all bugreports get answered, even if the > answer is just a form-letter saying something like: > -we got your report > -we want your report > -we can't figure out what is happening to you > -please read the cooker faq > -please send us a more detailed report (hardware, example case, logs... > etc) Very much agree. And nominate someone(s) who must triage and respond. And an email template and/or simple web form for reporting bugs with would be good. `Please attach/upload the following, if available, else send what you have', exact version number with directions for discovering it, list of RPMs (with versions) you suspect of being involved, with exact versions number, instructions for discovering same, etc etc. > That way, newbies to the list won't feel ignored and they can learn. > Then they can join us. Then we will be indestructable and we will take > over the world... As per the original plan. (-: Cheers; Leon
Re: [Cooker] 9.0 and next
Here's an idea you might like. A lot of inexperienced users throw some pretty crappy bug reports onto the cooker list. We don't have enough info to figure it out, and Mandrake people probably don't have enough time to answer them all. If none of us (volunteers) try to help these people out, they just get ignored. I see a LOT of "I got ignored" or "this is the third time I've reported this bug" posts. Maybe you (Mandrake people) could make up a form-letter type response, and make a policy that all bugreports get answered, even if the answer is just a form-letter saying something like: -we got your report -we want your report -we can't figure out what is happening to you -please read the cooker faq -please send us a more detailed report (hardware, example case, logs... etc) That way, newbies to the list won't feel ignored and they can learn. Then they can join us. Then we will be indestructable and we will take over the world... Austin
[Cooker] 9.0 and next
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. -- Warly