Re: [Cooker] Frustration
Isaac [EMAIL PROTECTED] writes: On 19 Mar 2002, Pixel wrote: FYI, you submitted your bug report on the 16 march. The 2 people (flepied and fpons) that could help you on this are pretty busy/tired. And cooker has been fairly noisy those days. You may have better luck mailing them directly, and choosing a better date to post bugs (when in deep freeze only big problems are taken into account others are devnulled) I submitted bug reports on 2 March, 6 March, and 9 March. This was during the 8.2 beta test period. I posted my reports here after trying (unsuccessfully) bugzilla, mandrakeforum, mandrakeexpert. The bug prevented the install kernel from booting (or, if one supplied the pci=conf2 argument, the kernel would boot, but the installer died at the second stage). I suggested the fix (remove the buggy ali15x3 driver from the instal kernel, since it provides no features necessary for installation and the generic IDE support works fine). this a kernel pb, and we don't have many kernel people. Chmouel is off for some time, Juan is overloaded with various bigger pbs, Jeff is working next kernel (?) Ask them again, you may have an answer...
Re: [Cooker] Frustration
On Mon, 2002-03-18 at 18:33, Pixel wrote: Joshua Newton [EMAIL PROTECTED] writes: so far no one at Mandrake has bothered to say, Okay, we'll look into it, or even, Thanks for the report. choosing a better date to post bugs (when in deep freeze only big problems are taken into account others are devnulled) Cut-n-paste after me: Thanks for the report, we've seen it and it will be looked into. You'd probably cut 20% of the entire cooker traffic. -- Brad Felmey
Re: [Cooker] Frustration
michal == Michal Bukovjan [EMAIL PROTECTED] writes: michal Brad Felmey wrote: On Mon, 2002-03-18 at 18:33, Pixel wrote: Joshua Newton [EMAIL PROTECTED] writes: so far no one at Mandrake has bothered to say, Okay, we'll look into it, or even, Thanks for the report. choosing a better date to post bugs (when in deep freeze only big problems are taken into account others are devnulled) Cut-n-paste after me: Thanks for the report, we've seen it and it will be looked into. You'd probably cut 20% of the entire cooker traffic. michal Or set up and use and make people use Bugzilla system for cooker. michal Otherwise you forget / lose / duplicate a lot of information on this list ! I can speak for other MandrakeSoft employees, but for me mails on this list is _way_ better than bugzilla. Reasons: - you can easily answer and ask for more information - it is trivial to find the me too messages (in bugzilla they can also happen, but people normally: * don't report that they alsa have the same problem if there is already a bug report * They use a different bug ticket - bugzilla is too slow, I can fix quite a lot of problems in one kernel update (ok, in frozen state I only do minimal modifications), but during cooker development, I fix several problems on each new release. Using cooker list: - users send mail - I read meal - I fix errors - I can send a single mail (or only a few mails) telling that the error is supposed to be fixed. - people ack that the error is fixed or not. Using bugzilla: - have to go there to read it - have to read each bug report - fix errors - go to _every_ single error that I fix, and answer that it should be fixed - wait for users to ack or nack the fix - go through the bug reports mark them as fixed :((( My experience is that bugzilla is very good for small packages, or packages that don't have a lot of bug reports (a lot is more that 1/2 daily). For bigger packages, email is easier/better in my experience. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Frustration
Juan Quintela [EMAIL PROTECTED] writes: Just to answer on this particular subject. Using bugzilla: - have to go there to read it No, you receive the new bug per mail - have to read each bug report You can just answer the mail, the comment are added into bugzilla and the bug poster receive the mail too. - fix errors - go to _every_ single error that I fix, and answer that it should be fixed you can just reply the mail with @resolution=fixed - wait for users to ack or nack the fix he can reply per mail too - go through the bug reports mark them as fixed you can send a mail for that. :((( My experience is that bugzilla is very good for small packages, or packages that don't have a lot of bug reports (a lot is more that 1/2 daily). For bigger packages, email is easier/better in my experience. Bugzilla is not perfect yet, mainly because nobody takes care of it, I try to when I heve some free time, not so often I must admit. It lacks some faster browsing and a more powerful mail interface, but most of the thing to use it via mail are there. -- Warly
Bugzilla (Was Re: [Cooker] Frustration)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In light of this, is it not worthwhile giving bugzilla another shot, and require all cooker bug reports to be put into bugzilla (whether by the reporter, or by a more trusted cooker member who has bigzilla write access, or by the maintainer). The other thing that I think needs to be done is that test suites (or at least procedures) should be setup for all the critical software, and that such software is not accepted as stable until it has passed all those tests. This might have helped prevent the smbfs issue, since it would have been evident that kernel 2.4.18 broke smbfs (which is quite an important feature of the linux kernel, considering that it is the only unix which can do this). I know thie may cause a lot of work, but it may save a lot of work, and the testing needn't be done by one person. Whenever we put a new samba release into cooker, I try and confirm that some of the features work: - - First my home samba test box to check the basics. - - I normally try and get the RPMs onto our production PDC after hours and test all the domain controlling features (authentication, profiles, login scripts), - - Then our production print server to test printing functions - - Then my home desktop box to test winbind and ACLs etc. However, I always wonder what would happen if one feature was broken, and I never managed to test it ... something should be done to ensure this does not happen. Buchan Warly wrote: | Juan Quintela [EMAIL PROTECTED] writes: | | Just to answer on this particular subject. | | |Using bugzilla: |- have to go there to read it | | | No, you receive the new bug per mail | | |- have to read each bug report | | | You can just answer the mail, the comment are added into bugzilla and | the bug poster receive the mail too. | | |- fix errors |- go to _every_ single error that I fix, and answer that it should be | fixed | | | you can just reply the mail with @resolution=fixed | | |- wait for users to ack or nack the fix | | | he can reply per mail too | | |- go through the bug reports mark them as fixed | | | you can send a mail for that. | | |:((( | |My experience is that bugzilla is very good for small packages, or |packages that don't have a lot of bug reports (a lot is more that 1/2 |daily). For bigger packages, email is easier/better in my experience. | | | Bugzilla is not perfect yet, mainly because nobody takes care of it, I try | to when I heve some free time, not so often I must admit. | | It lacks some faster browsing and a more powerful mail interface, but most | of the thing to use it via mail are there. | - -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/gpg.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE8l6FYrJK6UGDSBKcRAiuGAJ94dKuvZEnoj7JhOAxLexIIFttl3gCdHaVB 4dCdPlGnFGDNmPrV7obL/hs= =ND5f -END PGP SIGNATURE-
Re: [Cooker] Frustration [long!]
Some points were answered by Warly, but here is my (long) answer: Juan Quintela wrote: michal == Michal Bukovjan [EMAIL PROTECTED] writes: michal Brad Felmey wrote: On Mon, 2002-03-18 at 18:33, Pixel wrote: michal Or set up and use and make people use Bugzilla system for cooker. michal Otherwise you forget / lose / duplicate a lot of information on this list ! I can speak for other MandrakeSoft employees, but for me mails on this list is _way_ better than bugzilla. Reasons: - you can easily answer and ask for more information You can do that with Bugzilla, too. In fact, it is open to much more people if you do that via Bugzilla. Anyone interested in a particual bug can add himself as CC and keep being informed. Just try to go to Mozilla.org and see new checkins, browse their Bugzilla a bit. I do this for my reported bugs on Mozilla project and always know what is going on, who cares about what, and even if my or others suggestion is postponed or rejected, I know that it is in there and that it was decided so and why. Anyone else from the community making such suggestion knows that as well or can find and don't bug mailing list or developers directly. And there is this voting stuff, which, for example, could be one of the perks of the Mandrake club, i.e. the ability to actually have your share in controlling Mandrake;s future. The voting stuff is used for example in Abiword's Bugzilla. - it is trivial to find the me too messages (in bugzilla they can also happen, but people normally: * don't report that they alsa have the same problem if there is already a bug report * They use a different bug ticket Then there must be somebody who does bug triaging, who marks duplicates, etc. But then again, you need this anyway, as some Mandrake developers said. if there is a lot of (duplicate or not) bug reports, they are flooded by cooker mail and eventually stop reading it! - bugzilla is too slow, I can fix quite a lot of problems in one kernel update (ok, in frozen state I only do minimal modifications), but during cooker development, I fix several problems on each new release. Hmm, Mozilla Bugzilla now tracks around 13 issues, has a lot of users (thousands), and is fast, so I guess it must be a hardware prob more than anything else. Using cooker list: - users send mail - I read meal - I fix errors - I can send a single mail (or only a few mails) telling that the error is supposed to be fixed. - people ack that the error is fixed or not. Now this is the problem. You may read the mail, but the cooker traffic is very heavy and most Mandrake developers actually stopped reading the cooker mail (and they admit it!). That is the source of frustration (the original thread) people have here. They invest time in bug reporting, trying to make the distro better, and they are being ignored. Do you have a QA department? How do you automate their work? By personal mails? Let's say we have the following scenario (this is an example): I use Mandrake 8.2 beta 3 and have a problem with Alcatel modem (whatever kind). Can I: - find out somebody reported that? How? by searching archives? Was the problem resolved? How can I find out if the communication between original reporter and package maintainer took off the list? - I find in cooker mailing list that the Mandrake developer said he will look into that later, as he has other issues on his plate. Period. Did he? When? Is it considered showstopper? Not? Do they release 8.2 without this bug fixed? Do they postpone this because it depends on another issue (say modem setup in *drake tool) to be resolved? - I want to be informed when my Alcatel modem issue is resolved. How? No go. Using bugzilla: - have to go there to read it - have to read each bug report - fix errors - go to _every_ single error that I fix, and answer that it should be fixed - wait for users to ack or nack the fix - go through the bug reports mark them as fixed :((( No. In Bugzilla, you design components (kernel, GNOME, KDE, X, etc.), every component has a default owner that is assigned to the new bug. Thus, if you are a 'owner' of kernel component. you only receive mail about new bugs regarding / assigned to this component. For every change in the bug (submission, change, duplicate report, new patch), you get a mail informing you about the change. You can ignore it, or go to Bugzilla, it's your choice. In every Bugzilla mail, you have a link into the system, that takes directly into a bug, so you can quickly navigate and change params. Further reasons touse Bugzilla: - milestone designation. I read everyday questions like this: will this make it into RC1? Final? Is this 9.0 material? What else is 9.0 material? Are there any showstoppers for release x.y? How can I help? - priority / severity : every bug can have a priority and severity assigned : blocker, major bug, minor bug, enhancements. Every developer can focus on blockers
Re: [Cooker] Frustration
On Mon, 2002-03-18 at 20:41, Ben Reser wrote: Now I think we all here can understand (even if we don't agree with) Mandrake's time crunch for producing this distribution. They have committments to meet. For what it's worth... I have worked as a technical lead and as a product manager for commercial software. The pressures on a company to release a product at a set time are very strong. Investers, directors, financers all want to see it; retail channel firms such as Ingram or Microage want to see it, so they get your product stocked on store shelves; and frankly, users want to see it, because they want to be able to say, I'm running Mandrake Linux 8.2 and it's really great!. I also know that a small company can't afford to have a whole lot of people dedicated to release engineering. Which means that communication becomes very hard. It seems to me that Mandrake is doing a superb job of communicating with a large developer community, overall. If there are frustrations at times, if things get dropped in the last couple of weeks, I don't think anyone should be surprised. So, it is a time for patience, tranquility and strength. And now, with a release uploading, for congratulations. Perhaps in a week or two, the Mandrake people will have recovered enough to think about process improvements and changes! Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Ankh: irc.sorcery.net www.valinor.sorcery.net irc.gnome.org www.advogato.org Author, Open Source XML Database Toolkit, Wiley August 2000 Co-author: The XML Specification Guide, Wiley 1999; Mastering XML, Sybex 2001
Re: [Cooker] Frustration
On Mon, 2002-03-18 at 13:41, Ben Reser wrote: That's my 2 cents on the issue and all I'm going to say... Much agreed... So much, that I really don't have anything to add. As I said before, cooker used to be lots of fun (e.g., prior to 8.x). That fun has seemed to be stripped... Then again, you have to look at it from the mdksoft perspective, that they do have a deadline to meet, and I think there's quite a bit of frustration on both ends. Where does my frustration lie? Ideas that I expounded that I have never gotten credit for, fixes I have never gotten credit for, fixes/idea that were never even acknowledged, etc... However I buried the hatchet, so to speak, what's done is done. On 8.2 devel... As I said in a private email with one of the mdksoft developers, I do admit during this release, I came in a bit late, emailing in quite a few false-positives, this surely caused frustration on the mdksoft side (e.g., hunting for bugs that were not there). For this I apologize... With that said, we begin again... A clean slate. I think one thing needs to always be kept in mind... Management especially should heed to this... This is a community. Each side depends upon each other, one can not, in no way, in a right way, co-exist without the other. Understanding that development of any open-source/free software is mutual can only speed up, quality, intuitiveness, and integrity of the project. Now, let the games begin : ) (after a short break of course : p) Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] Frustration
On Mon, 2002-03-18 at 14:41, Ben Reser wrote: 2) Submissions of problems and especially fixes need to be responded to even if it is a simple. Sorry too late we will not be able to fix this in time for the distribution. I think many of us are experiencing this and it's very frustrating. I have to agree on this one. I've just found and submitted what I feel is a fairly detailed report on my very first Cooker bug, and followed up with more information (after extensive troubleshooting on my part), and so far no one at Mandrake has bothered to say, Okay, we'll look into it, or even, Thanks for the report. It's especially infuriating because it fits neatly into a trend I've noticed -- it seems that every single bug report I've ever submitted for open source software has been merrily ignored, and yet I still hear grumblings from developers that they can't very well fix bugs if users don't report them. I don't want to blithely leave it up to other people to fix things for me, and I feel like I should be doing at least this much to improve open source software, since I can't code worth a darn, and I generally don't have the time to write docs or coordinate projects. But if reporting bugs is going to be a complete waste of my time, I might as well take my ball and go home, neh?
Re: [Cooker] Frustration
On 19 Mar 2002, Pixel wrote: FYI, you submitted your bug report on the 16 march. The 2 people (flepied and fpons) that could help you on this are pretty busy/tired. And cooker has been fairly noisy those days. You may have better luck mailing them directly, and choosing a better date to post bugs (when in deep freeze only big problems are taken into account others are devnulled) I submitted bug reports on 2 March, 6 March, and 9 March. This was during the 8.2 beta test period. I posted my reports here after trying (unsuccessfully) bugzilla, mandrakeforum, mandrakeexpert. The bug prevented the install kernel from booting (or, if one supplied the pci=conf2 argument, the kernel would boot, but the installer died at the second stage). I suggested the fix (remove the buggy ali15x3 driver from the instal kernel, since it provides no features necessary for installation and the generic IDE support works fine). The problem goes back as far as at least Mandrake 7.2 in my informal testing. I wanted to help get this resolved before 8.2 went gold. No responses at all, except from one user who responded off-list to tell me he also was having problems getting noticed by mdk maintainers. I was a paying user of Mandrake since 7.1; I've switched to debian on my laptop this week because this bug prevents mdk from installing, and I don't have a spare linux machine on which I can build a custom installer boot disk (and I won't bother now that I've got a nice, working system on my laptop - I didn't buy the thing to tinker with) If Mandrake is still around to put out another version, I might switch back. If the installer boots. -Isaac
Re: [Cooker] Frustration
Joshua Newton [EMAIL PROTECTED] writes: On Mon, 2002-03-18 at 14:41, Ben Reser wrote: 2) Submissions of problems and especially fixes need to be responded to even if it is a simple. Sorry too late we will not be able to fix this in time for the distribution. I think many of us are experiencing this and it's very frustrating. I have to agree on this one. I've just found and submitted what I feel is a fairly detailed report on my very first Cooker bug, and followed up with more information (after extensive troubleshooting on my part), and so far no one at Mandrake has bothered to say, Okay, we'll look into it, or even, Thanks for the report. FYI, you submitted your bug report on the 16 march. The 2 people (flepied and fpons) that could help you on this are pretty busy/tired. And cooker has been fairly noisy those days. You may have better luck mailing them directly, and choosing a better date to post bugs (when in deep freeze only big problems are taken into account others are devnulled)
RE: [Fwd: Re: [Cooker] Frustration]
(Posted from my corporate Windows machine because mail from my Mandrake / Evolution personal account is silently rejected by the cooker list... Why? ARRRGH.) I also submitted some serious bug reports before RC1. As they never showed up on the mailing list I eventually sent them directly to Pixel and Warley. Of the 4 bugs I found (two serious) I only got a response regarding one of the minor cosmetic bugs in the installer. I appreciate the work that Mandrake does - I've paid my $60 to join the club - but this is not acceptable. If the reason was the hurry to get 8.2 out, well, the solution would be to NOT RUSH THE RELEASE. For the record, here are the two serious bugs again. My original bug reports were MUCH more detailed, but what's the point now... 1. The Beta 4 kernel hangs at Detecting Partitions when it reaches my 120 GB Maxtor drive, which has a single 120GB ReiserFS primary partition. This prevents installation. I can work around this by unplugging that drive during installation, compiling and installing my own kernel from kernel.org, and then reconnecting the drive, rebooting, and editing /etc/fstab... I can do all that in my sleep, but Joe Average User sure couldn't. 2. On a machine with two sound cards, a Sound Blaster Live! and an M-Audio Audiophile 2496, the (Beta 4) Mandrake installer correctly identifies both cards and sort of sets up sound. Unfortunately, NEITHER sound card works in the resulting configuration. Nothing works - no mixers, no sound playback, no ALSA apps, nada. Again, fixed by upgrading to a custom-compiled 2.4.18 + ALSA 0.9 - now both sound cards work. Again - I can do this but average user sure can't. These are serious bugs and I got NO response about them. I hope these bugs were fixed for release. I downloaded and burned RC1 just to test but ran out of time, as 8.2 was released so quickly. What's the rush? It just doesn't make sense to have a release candidate out for less than two weeks! Volunteer testers like me, working on our own time need several days to download and burn the ISOs and run our tests, it is very discouraging to be part way through this and then find out there is no point, 8.2 is being released anyway. Bah. I was hoping that 8.2 would be the first Linux distribution that I could just install and run on all my machines, but it looks like once again, I will have to start from 8.2 and then update the kernel, ALSA, and who knows how many other things before it will be usable. Sigh. What was the rush for 8.2 release??? I still haven't seen a good explanation of that. Disappointed... Torrey Hoffman [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Fwd: Re: [Cooker] Frustration]
I'd have thought it was fairly obvious why the releases have to be rushed out - as soon as it's announced that a product it going into beta phase, who in their right mind would buy the old, out dated release??! fairly few I'd imagine... There isn't an OS out there that can afford to hang around squashing all the bugs (well, apart from slackware, and do we really want to move to their 2 yr dev cycle and let mdk go bankrupt in the mean time? ;) Financially for mandrake, it would be a disaster to leave it much longer... 8.2 is already one of the most stable mdk distro's ever (a hard feat for a distro that prides itself on being bleeding edge) - and in the coming weeks, it's only going to get better as the last few bugs are fixed. With rpmdrake now doing updates through proxies, it's also relatively idiot proof to keep a machine upto date now I'm guessing in maybe a month or two, a freq will be released, and that'll be the 8.x line closed off with a super stable distro - you could ask why didn't they wait, but if we're really honest about it, i doubt that many people are going to notice the last few bugs (as shown by how silent the cook list has been for the last few days...) On Tuesday 19 March 2002 1:25 am, you wrote: (Posted from my corporate Windows machine because mail from my Mandrake / Evolution personal account is silently rejected by the cooker list... Why? ARRRGH.) ~snip~ ws how many other things before it will be usable. Sigh. What was the rush for 8.2 release??? I still haven't seen a good explanation of that. Disappointed... Torrey Hoffman [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Cooker] Frustration
SNIP! (when in deep freeze only big problems are taken into account others are devnulled) So, when I install Mandrake on my notebook (this isn't cutting edge here, we're talking P2/333) and the PCMCIA netcard Just Doesn't Work, that's not a big problem? Having the network Wizard foul things up, after I've spent a day getting it working, isn't a big problem? (My netcard happens to be a Linksys, but the postings I've seen suggest that many have the same problem, and not just with netcards.) This is not a kernel issue, since it _can_ be made to work, with enough tweaking of pcmcia/config (Assuming, of course, that you know enough to stay away from auto-defect.) AFAIK, this has been an issue since 8.0 (and certainly since 8.1). As of 8.2rc1 it still hasn't been addressed. I know you're stressed--try to understand that I _want_ Mandrake to succeed. I only have two hopes: 1) you'll release an 8.2.1 ISO, once things have settled down and you have time to make a stable version, 2) Next time you'll allow for a longer freeze period, so some of these issues can be resolved _before_ release. --plughead; // a paying mandrakeclub member = 'And trust no-- Trust practically no-one. All right? Except trustworthy people.' (Jingo)
Re: [Cooker] Frustration
On Monday 18 March 2002 22:12, Plug Head wrote: SNIP! (when in deep freeze only big problems are taken into account others are devnulled) So, when I install Mandrake on my notebook (this isn't cutting edge here, we're talking P2/333) and the PCMCIA netcard Just Doesn't Work, that's not a big problem? Having the network Wizard foul things up, after I've spent a day getting it working, isn't a big problem? (My netcard happens to be a Linksys, but the postings I've seen suggest that many have the same problem, and not just with netcards.) This is not a kernel issue, since it _can_ be made to work, with enough tweaking of pcmcia/config (Assuming, of course, that you know enough to stay away from auto-defect.) AFAIK, this has been an issue since 8.0 (and certainly since 8.1). As of 8.2rc1 it still hasn't been addressed. I know you're stressed--try to understand that I _want_ Mandrake to succeed. I only have two hopes: 1) you'll release an 8.2.1 ISO, once things have settled down and you have time to make a stable version, 2) Next time you'll allow for a longer freeze period, so some of these issues can be resolved _before_ release. --plughead; // a paying mandrakeclub member = 'And trust no-- Trust practically no-one. All right? Except trustworthy people.' (Jingo) Well it might be a kernel issue, but a kernel/pcmcia issue. The big problem is with plug and play handling under pcmcia. I have a Dell Inspiron 8100 and back when 2.4.whatever it was came out that dropped the pnp bios handling pcmcia was crap without tweaking the pcmcia config file, this was actually due to a fscked bios which put everything on IRQ11, but the kernel needed pnp bios resource checking to defeat this automatically, if you compile your own kernel not using the built in yentle_socket pcmcia drivers you find in the kernel, but instead compile your kernel without pcmcia support, then compile your own pcmcia-cs packages and tell it 'y' when asked about pnp bios resource checking you may find your pcmcia works fine. It was Linus' idea to drop pnp support then, and afaik the yenta_socket drivers don't do it either, and if Mandrake went a re-wrote the linux kernel for their own use it wouldn't be Mandrake Linux, Maybe mandrake Minux or something. ;) -- ^^^ Jason Straight -- President BlazeConnect Internet Services -- Cheboygan Michigan ISP: www.blazeconnect.net Products: www.blazeconnect.com Phone: 231-597-0376 -- Fax: 231-597-0393
