Re: [Cooker] Mandrake 9.1 Should be Delayed
Danny Tholen wrote: On Monday 10 March 2003 21:33, George Mitchell wrote: I have nothing against proprietary software in general or soundfonts in particular. I only find it odd that cards that provide /dev/sequencer support under free software should see that support discontinued when the source is freely available. So now the question becomes 'Does anybody out there have /dev/sequencer support without having to use soundfonts?' You have it backwards. AFAIK: On the sblive, you *have* to use soundfonts. It cannot synthesise notes itself. AFAIK it is a hardware limitation. On other cards, it might be different. Well, if I install an old ISA sound card with a Cirrus Logic or ALS chipset, and load Mandrake 7.1 and run sndconfig, it will first configure sound, and THEN midi, and presto, I will have FREE /dev/sequencer support without soundfonts. You could do it with Mandrake 7.1 and free software, but now there apparently is no way to do it anymore, so that feature has been effectively taken away.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Sun, 9 Mar 2003, George Mitchell wrote: I would be delighted to see a few posts by people who actually have /dev/sequencer (soundcard midi) working with such apps as Rosegarden and kmid, revealing what sound card they are using and what there /etc/modules.conf file looks like. So far I have seen no evidence on the web that anyone has this working with the 2.4 kernel. I challenge anyone who does to come forward and say so. For me it works with snd-emu10k1. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: On Sun, 9 Mar 2003, George Mitchell wrote: I would be delighted to see a few posts by people who actually have /dev/sequencer (soundcard midi) working with such apps as Rosegarden and kmid, revealing what sound card they are using and what there /etc/modules.conf file looks like. So far I have seen no evidence on the web that anyone has this working with the 2.4 kernel. I challenge anyone who does to come forward and say so. For me it works with snd-emu10k1. Works for me also with emu10k1 on 9.0, but remember you have to load a soundfont. Works cool with noteedit. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bJmrrJK6UGDSBKcRAtUfAKDKTNzs0mJta4v2YeadOloBjdbcAQCcCi9U YJksOZizCAQJXtD/rxgq/9k= =hWks -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne [EMAIL PROTECTED] writes: I thought the idea was that if a bug gets voted to a confirmed state than the developer would have a pretty good idea that the bug is in fact valid. Sure, but you still want him to be able to reproduce it easily. I was also under the impression that if the bug is not in a NEW state that most developers (pixel, and fcrozat being an exception for sure) don't even look at it. Is this not the case? I can't tell you for sure, afaic most bugs i fixed were unconfirmed but I would guess developers look at confirmed bugs first. afaic, sometimes, i look at interesting bug reports subjects, i do a pass on bugs on drakXYZ, ... sometimes, i just reassign bugs or close them as duplicated bugs having good product, self (still short) explanation subject, instantenous to understand body helps fixing bugs. as for tools, try running them from console and reporting errors (real ones such as exceptions, not perl warnings) help a lot.
Re: [Cooker] Mandrake 9.1 Should be Delayed
[EMAIL PROTECTED] wrote: On Sun, 9 Mar 2003, George Mitchell wrote: I would be delighted to see a few posts by people who actually have /dev/sequencer (soundcard midi) working with such apps as Rosegarden and kmid, revealing what sound card they are using and what there /etc/modules.conf file looks like. So far I have seen no evidence on the web that anyone has this working with the 2.4 kernel. I challenge anyone who does to come forward and say so. For me it works with snd-emu10k1. d. Thanks Danny! Which Sound Blaster card are you using if I may ask? And it would really be nice if these capabilities were outlined in Mandrake's hardware compatibility documentation.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: On Sun, 9 Mar 2003, George Mitchell wrote: I would be delighted to see a few posts by people who actually have /dev/sequencer (soundcard midi) working with such apps as Rosegarden and kmid, revealing what sound card they are using and what there /etc/modules.conf file looks like. So far I have seen no evidence on the web that anyone has this working with the 2.4 kernel. I challenge anyone who does to come forward and say so. For me it works with snd-emu10k1. Works for me also with emu10k1 on 9.0, but remember you have to load a soundfont. Works cool with noteedit. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bJmrrJK6UGDSBKcRAtUfAKDKTNzs0mJta4v2YeadOloBjdbcAQCcCi9U YJksOZizCAQJXtD/rxgq/9k= =hWks -END PGP SIGNATURE- Ah, so this is a proprietary technology using non-free 'soundfonts'. What happened to the old synthesizer OPL3 method used back in the 7.1 days? That was totally free and worked without a hitch. When the 2.4 kernel came along, it went away. And now the only posts so far confirming /dev/sequencer allude to a proprietary thing from Creative. Sounds to me like we are going backward. Does anyone else out there have a totally free solution for /dev/sequencer or has that been taken away from us?
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Mitchell wrote: [EMAIL PROTECTED] wrote: Thanks Danny! Which Sound Blaster card are you using if I may ask? Don't know about Danny, but I have a SB Live! Value Digital And it would really be nice if these capabilities were outlined in Mandrake's hardware compatibility documentation. Well, first it would be nice for any user input to be possible in the hardware database ... Of course, if people filed bugs on these things, then at least they would exist somewhere, currently some of them exist in the hardware section of Mandrake Club. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bOUcrJK6UGDSBKcRAtkdAKCGOegcoqtkRX4o9Hi1bM90xVoXdgCguSE1 ffgTiwvLEvsDFKiZ1u5nJeQ= =2Khc -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Mitchell wrote: Buchan Milne wrote: Ah, so this is a proprietary technology using non-free 'soundfonts'. What happened to the old synthesizer OPL3 method used back in the 7.1 days? Well, you are always free to develop free sound fonts (there are free tools out there to do this), just as we need to develop more realy good screen fonts. That was totally free and worked without a hitch. When the 2.4 kernel came along, it went away. I am sure you can still do it, if you swap to oss and use the emu10k1 tools, but AFAIK the sound-font method produces much better quality. And now the only posts so far confirming /dev/sequencer allude to a proprietary thing from Creative. And what proprietary software would that be (besides the sound fonts). Sounds to me like we are going backward. Does anyone else out there have a totally free solution for /dev/sequencer or has that been taken away from us? Search for free (speech) sound fonts. In the meantime, use the ones that come on your windows driver CD. Of course, if you are to continue your crusade for replacing this sort of thing with free software, please start reverse-engineering firmware (ie the software for another device) for things like USB scanners etc. The only difference between them and (say) your BIOS, or firmware for CD-Writers etc is the fact that they are uploaded into volatile (instead of flashable) memory. So, please replace your BIOS with an open-source one first ... (since that is one your computer, not on a peripheral device, hence restricts your freedom more than your sound card). Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bOdGrJK6UGDSBKcRAlOEAKCPrXt6G1sBSiRtaCIjkSI0uuq9LQCfZ+V0 V7JwDd+pPLBn0hWgERxjMTc= =7hqV -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Mitchell wrote: Buchan Milne wrote: Ah, so this is a proprietary technology using non-free 'soundfonts'. What happened to the old synthesizer OPL3 method used back in the 7.1 days? Well, you are always free to develop free sound fonts (there are free tools out there to do this), just as we need to develop more realy good screen fonts. That was totally free and worked without a hitch. When the 2.4 kernel came along, it went away. I am sure you can still do it, if you swap to oss and use the emu10k1 tools, but AFAIK the sound-font method produces much better quality. And now the only posts so far confirming /dev/sequencer allude to a proprietary thing from Creative. And what proprietary software would that be (besides the sound fonts). Sounds to me like we are going backward. Does anyone else out there have a totally free solution for /dev/sequencer or has that been taken away from us? Search for free (speech) sound fonts. In the meantime, use the ones that come on your windows driver CD. Of course, if you are to continue your crusade for replacing this sort of thing with free software, please start reverse-engineering firmware (ie the software for another device) for things like USB scanners etc. The only difference between them and (say) your BIOS, or firmware for CD-Writers etc is the fact that they are uploaded into volatile (instead of flashable) memory. So, please replace your BIOS with an open-source one first ... (since that is one your computer, not on a peripheral device, hence restricts your freedom more than your sound card). Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bOdGrJK6UGDSBKcRAlOEAKCPrXt6G1sBSiRtaCIjkSI0uuq9LQCfZ+V0 V7JwDd+pPLBn0hWgERxjMTc= =7hqV -END PGP SIGNATURE- I have nothing against proprietary software in general or soundfonts in particular. I only find it odd that cards that provide /dev/sequencer support under free software should see that support discontinued when the source is freely available. So now the question becomes 'Does anybody out there have /dev/sequencer support without having to use soundfonts?'
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Monday 10 March 2003 21:33, George Mitchell wrote: I have nothing against proprietary software in general or soundfonts in particular. I only find it odd that cards that provide /dev/sequencer support under free software should see that support discontinued when the source is freely available. So now the question becomes 'Does anybody out there have /dev/sequencer support without having to use soundfonts?' You have it backwards. AFAIK: On the sblive, you *have* to use soundfonts. It cannot synthesise notes itself. AFAIK it is a hardware limitation. On other cards, it might be different.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Problems with ATI and nVidea products. Only the two most popular video cards on the market. .. And the two that prefer to make proprietary drivers rather than, if they want the speed and quality, making their work fully open.. -- okay so start running down the chipsets on boxed computers (the former M$ market) Dell, Compaq ,HP all use either Nvidia or ATI chipsets mostly. This means that the biggest market for Linux will also A Not care about free -(L,G) B Know the least about the pain part of Linux These folks just want it to work after M$ decides that M$ doesn't Kernel , X, Multimedia and basic office/network should be Stop Presses level bugs by default. If Joe Luser can boot the system with X, play cds/mp3s, type notes, surf and go online it can ship but if those things can't be done DO NOT SHIP (or plan on shipping a patch disc)
Re: [Cooker] Mandrake 9.1 Should be Delayed
Robert L Martin wrote: Problems with ATI and nVidea products. Only the two most popular video cards on the market. .. And the two that prefer to make proprietary drivers rather than, if they want the speed and quality, making their work fully open.. -- okay so start running down the chipsets on boxed computers (the former M$ market) Dell, Compaq ,HP all use either Nvidia or ATI chipsets mostly. This means that the biggest market for Linux will also A Not care about free -(L,G) B Know the least about the pain part of Linux These folks just want it to work after M$ decides that M$ doesn't Kernel , X, Multimedia and basic office/network should be Stop Presses level bugs by default. If Joe Luser can boot the system with X, play cds/mp3s, type notes, surf and go online it can ship but if those things can't be done DO NOT SHIP (or plan on shipping a patch disc) And the real irony here of course is that ATI chipsets are NOT closed source. My ATI Radeon in fact works splendidly with OPEN SOURCE XFree/DRI software under Red Hat 8.0. But what kind of answer do you get when you bring that up on the cooker list? That they are proprietary of course and nobody challenges it because it is an easy answer and much preferable to admitting that it might be Mandrake that is failing to adequately QA their product. So Mandrake is learning to FUD their way along just like Microsoft and avoid facing the hard questions. The same is true of /dev/sequencer support under a number of cards that used to work with OPEN SOURCE drivers but no longer do. When you ask questions you face silence, or some wise one chiming in with 'Oh thats because its proprietary'. The world will forgive Linux companies for NOT supporting closed source products like nVidia, but OPEN SOURCE hardware that does not work simply because the priorities are elsewhere will not play well with potential desktop consumers and attempting to paint known open source products as being closed will not play well either.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Sat 08 Mar 2003 05:26, Giuseppe Ghibò posted as excerpted below: Consider also that NVidia drivers contains modules built with obsolete compilers like egcs 1.1.2 (see for instance libGLcore.so.1.0.4191) that any distribution no longer uses since two years... I'm not yet into development enough to do much source diving, but I do know that when I changed to the 2.4.20 kernel (I compile the official kernel.org sources), and tried to recompile the NVidia driver so I could launch X again, then tried to load it, it warned about an old compiler, even tho I'd used the same then-current cooker gcc on both. I guessed that it must be what they used to compile the binary only part with. However, after fetching their latest (at the time) driver srpms from NVidia, I was able to recompile them and load them w/o incident. Again, I don't do a lot of source diving yet, and don't know enough about it to know if that means they removed all their old compiler done stuff or not, but in any case, it worked. (And.. they FINALLY added the ability to treat each of the outputs as a separate device and screen sections in XF86Config, meaning a FAR simpler layout, rather than the NVidia only Twinview specific stuff they'd had in the screen sections before. It is SO much simpler and more flexible, now! What I wouldn't do to get both outputs activated in the libre nv driver tho!) -- Duncan They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Sun, 9 Mar 2003, George Mitchell wrote: And the real irony here of course is that ATI chipsets are NOT closed source. Some are, some are not. My ATI Radeon in fact works splendidly with OPEN SOURCE XFree/DRI software under Red Hat 8.0. But what kind of answer do you get when you bring that up on the cooker list? That they are proprietary of course and nobody challenges it because it is an easy answer and much preferable to admitting that it might be Mandrake that is failing to adequately QA their product. So Mandrake is learning to FUD their way along just like Microsoft and avoid facing the hard questions. I don't think that is the case. The problem is that some cards work great (apparently) with 9.0, while some other cards with the same chipset do not. I did not ever see Mandrake say that GLX was broken on the 7500 due to proprietary software/drivers. And I think if GLX does not work on the Radeon 7XXX cards, it should be fixed, and even worse is the blank screen you get with some Radeon's on Mandrake (8.2 and 9.0), where Knoppix gets it right ou-the-box with GLX! The same is true of /dev/sequencer support under a number of cards that used to work with OPEN SOURCE drivers but no longer do. Sorry, but I do not believe posts like this until I see the bug numbers, please post them.Or at least give details on the cards that are affected. Buchan (who has no hardware Mandrake does not support out-the-box) -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Sun, 2003-03-09 at 15:25, Robert L Martin wrote: These folks just want it to work after M$ decides that M$ doesn't Kernel , X, Multimedia and basic office/network should be Stop Presses level bugs by default. If Joe Luser can boot the system with X, play cds/mp3s, type notes, surf and go online it can ship but if those things can't be done DO NOT SHIP (or plan on shipping a patch disc) Yup. With the DHCP stuff fixed the nvidia stuff looks like one of the most serious remaining problems. Many, many, many people use Nvidia cards / integrated chips, and it seems that XFree 4.3.0's nv driver has serious trouble with many. Is there going to be any kind of satisfactory fix for this before release? -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne wrote: On Sun, 9 Mar 2003, George Mitchell wrote: The same is true of /dev/sequencer support under a number of cards that used to work with OPEN SOURCE drivers but no longer do. Sorry, but I do not believe posts like this until I see the bug numbers, please post them.Or at least give details on the cards that are affected. Buchan (who has no hardware Mandrake does not support out-the-box) I would be delighted to see a few posts by people who actually have /dev/sequencer (soundcard midi) working with such apps as Rosegarden and kmid, revealing what sound card they are using and what there /etc/modules.conf file looks like. So far I have seen no evidence on the web that anyone has this working with the 2.4 kernel. I challenge anyone who does to come forward and say so.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Le Thu, 06 Mar 2003 21:09:31 -0800, Curtis Hildebrand a écrit : On Thu, 2003-03-06 at 08:52, Guillaume Cottenceau wrote: N Smethurst [EMAIL PROTECTED] writes: Le Jeudi 6 Mars 2003 16:47, Guillaume Cottenceau a écrit : Well that depends. Most non-kernel and non-install bugs are looked at even in unconfirmed state - most of them are real and fixable. I know this is frustrating for reporters to get ignored, but as for the aim of bugzilla, e.g. track fix bugs, it's now in a state where it's really usable and helping us much to fix bugs. Maybe there should be a someone has had a look at this bug status for bugs that developers do look at but don't want to officially commit to ? IMO it's not needed. With the mail interface, it's very easy for us to comment on it, if we want to. I like GNOME's NEEDMOREINFO status. It nicely tells the reporter that their bug report wasn't all it could be, and lets the package maintainer ignore the bug until they do get more info. VERY GOOD IDEA... Warly, any hope to add this on our bugzilla ? -- Frédéric Crozat MandrakeSoft
Re: [Cooker] Mandrake 9.1 Should be Delayed
Duncan wrote: On Fri 07 Mar 2003 21:18, George Mitchell posted as excerpted below: Non productive work? How about 3D accelleration that doesn't work on Radeon cards? Is that one of the things you consider trivial and not which Radeon cards? There are 27 kinds of Radeon cards, starting from R100 to R300 and now also R350 with Radeon 9800. To me on Radeon 7500 mobility of cooker 4.3.0 works fine with full DRI 3D acceleration (apart a small problem at 1600x1200x24, but #2634), and was working since 8.2. worth correcting? I have a Radeon VE that works flawlessly on install with Red Hat 8.0. It is a screaming mess on install with Mandrake 9.0 and still is not working with Cooker which is just about ready to release. Problems with ATI and nVidea products. Only the two most popular video cards on the market. .. And the two that prefer to make proprietary drivers rather than, if they want the speed and quality, making their work fully open.. Have you tried the software proprietare drivers from ATI on it? I have to run NVidia's software proprietare drivers because I am running dual video out on that card, and the software libre drivers don't work. I'd be extremely surprised if Mdk could or even would choose to put the software proprietare drivers on the freely downloadable disks. It's possible AFAIK the ATI 2.5.1 closed drivers, right now needed for 3D on ATI 9500/9700, compiles but doesn't work on current cooker. Furthermore they are built on top of and old XFree 4.2.X. they might put it on the extra software proprietare disks they have in the commercial distrib versions, but obviously, that's not going to be in the main code base. You basically have to go d/l the software proprietare from yep, apart licenses, we don't place in main, things for which there aren't sources. AFAIK remember latest one was netscape 4.79. For instance NVidia drivers contains libGLcore.so.1.0.4141 binary only libraries, NVidia-kernel contains some sources, but the nv-kernel.o is binary only. Ditto for winmodems (lt, conexant), etc.: they have glue .C code, but often a binary only object file. the manufacturer's site yourself, and install it yourself. Of course, keep in mind that if ATI is like Nvidia in that regard, the ABI to the kernel is what they must use, and that changes with each version. Thus, there are limited kernel matches, one each for standard and enterprise kernel for each official release, but nothing for each cooker kernel update, or if you and not even for official kernel updates. compile your own kernel. For those, you have to get the SRPM or tarballs and compile the kernel wrapper interface to the proprietary binary module yourself, so it matches the kernel you have deployed. Despite the additional cost for Matrox cards in particular based on their 3D performance (they tend to be good 2D performers, but not so good @ 3D), I'm seriously considering getting only them from now on.. Well, either that, or Matrox G450/G550 are well supported on 3D, although they even have a closed source module (not included in XFree86, but supported changing some compilation %define flag in the SPEC file): the HALLib. SiS/Via/whatever gpu/chipset cards, that have software libre drivers that exploit the full power of the card, low tho that might be, as at least then I'm not blowing $$ on features I can't use w/o serious hassle on Linux, due to their software proprietare policies. Matrox would have good 3D performance on Parhelia, but they don't release even closed source drivers for it. (I should mention that in NVidia's case at least, they claim the reason they don't fully support software libre drivers is that they have licensed intellectual property from other holders, and those licenses don't allow them to go the software libre route. That's a potentially valid arguement, but seems things got from Silicon Graphics per libGL or proprietary texture compression techniques. IMO, I'd rather simply do w/o those features then, and use a card a bit more plain jane, if necessary. Yes, it WILL affect my purchasing decisions from here on out. The reason I have the Nvidia now is because I got it b4 I switched to Linux, and while I checked that drivers were available for Linux as I was thinking about switching, I didn't realize there was this particular angle of it to worry about until I switched, and by then I already had the card.) Consider also that NVidia drivers contains modules built with obsolete compilers like egcs 1.1.2 (see for instance libGLcore.so.1.0.4191) that any distribution no longer uses since two years... Bye. Giuseppe.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Danny Tholen [EMAIL PROTECTED] writes: But, what I would have liked more is that you provided an alternative solution. Because you do not dispute that a (small) problem exists. And there is some truth in your critic, however, without alternative solution, why not try it. Than again, perhaps you will do something internally, and do not want it on the list. That is also ok. Well, one can at the same time grant that a problem exists, but still don't provide a solution.. that's my situation. I confess to not having a miracle solution to the problem. Our organization is not very effective, but considered the amount of paid developers we are, the amount of bugs there is, and the human nature of people, it's probably not so bad (and I'd say again that I can't come up with a better one - maybe others could, of course). Concerning your requested why not try it, I confirm that I think your solution would be counter-productive, so indeed I'd vote for not trying it, that's just as simple as that :). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 03:40 pm, James Sparenberg wrote: Do you honestly think one of the largest firms in the industry (who is now using our product) would like it if we told them We'll fix your bug when we get enough votes. Yes. They'd institute a twice-daily bug-voting-for rota among their staff and have instant priority. But some of the smaller ones might think that sucks. Cheers; Leon
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 22:00, Paul Dorman wrote: Or what about some kind of p2p solution? Where -light machines are networked to and updated from other -light machines across the net? Checksumming and other tools could be used to address security concerns. You know, I almost took a job working for a company that thought the time for this had come a year and a half ago Maybe it is more doable now, at least for open source software (you don't have to worry about how to bill people, how to force users to stay online whenever possible, etc.), but there is still a major project, and there are problems that nobody's yet solved. On the one hand, an open source project can just use an existing protocol (say, gnutella) rather than building something new from scratch, and doesn't need to worry about billing, etc. And just distributing SHA URI's on official mirrors would be enough to search for the file online and verify that you've downloaded the right one (and of course RPM signatures provide security on top of that). But on the other hand, where does the network come from? If you build a new p2p network from scratch, you need to get people online. Most users won't be connected to the network except when they're in the middle of their own upgrade. If you use, say, the existing gnutella network, you have the advantage that every Mandrake user who's using gtkg, qtella, limewire, etc. (assuming they've added their package repository to their p2p upload directory list) is available--but the disadvantage that most of the people on the network don't have the files you want. Either way, you'll probably still need mirror sites--and I'm guessing it's much easier to find someone who will run ftp, rsync, and/or http mirrors than finding someone who will attach their mirror server to either a brand-new p2p network or the existing gnutella network Oh, and I think that packages should be revertable on installed systems as well. Users should be protected against unstable software wherever possible, but at the same time they will demand the very latest releases. It would be nice to be able to downgrade through urpmi and the GUI tools (of course you can already downgrade today--just download and force-upgrade--but it's not as easy as installing or upgrading). If I try to downgrade kdebase, it would tell me you also need to downgrade kdelibs and kdegames and uninstall kdevelop, and (if I approve) it would go get the relevant versions of kdebase, kdelibs, and kdegames and so on. I think that being able to deal with the same package groups as the installer when upgrading, installing, or downgrading would also be helpful. A beginning user knows that he installed KDE Workstation, and wants to upgrade that, or that he skipped LAN Filesharing (or whatever that option is called) but now he wants it, but probably doesn't know what packages that involves. Maybe something like Microsoft's restore points in XP, but done right, would be useful as well. I mark a system restore point, then upgrade to the new version of Mandrake, install a bunch of new packages through rpmdrake, whatever; then, if it doesn't work, I just restore to the last point. Unfortunately, I think it would be even harder to get this right under linux than under XP. Anyway, I think that all of these ideas deserve looking into. Of course these kinds of suggestions always come up at the worst possible time, because that's when people think about them. Certainly you don't want anyone at Mandrake, or anyone who could be contributing to the 9.1 effort, putting much time into anything like this for the next few days. So, remember the ideas that are most important to you, wait until 9.1's out the door and everyone's had a little breathing time, then start a discussion when it's still months to go before the next freeze.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Andi Payn wrote: On Thursday 06 March 2003 22:00, Paul Dorman wrote: Or what about some kind of p2p solution? Where -light machines are networked to and updated from other -light machines across the net? Checksumming and other tools could be used to address security concerns. You know, I almost took a job working for a company that thought the time for this had come a year and a half ago Maybe it is more doable now, at least for open source software (you don't have to worry about how to bill people, how to force users to stay online whenever possible, etc.), but there is still a major project, and there are problems that nobody's yet solved. That's interesting. There seem to be a bunch of projects applying p2p in interesting and imaginative ways, so perhaps any problems wouldn't last for long... The Linux community is getting bigger all the time; there has to be some threshold past which p2p could be effective. On the one hand, an open source project can just use an existing protocol (say, gnutella) rather than building something new from scratch, and doesn't need to worry about billing, etc. And just distributing SHA URI's on official mirrors would be enough to search for the file online and verify that you've downloaded the right one (and of course RPM signatures provide security on top of that). Good, good. I was thinking something based on Gnutella. Many of the clients have built in discussion and chat facilities, as well as administrative tools. Lots to build off there. But on the other hand, where does the network come from? If you build a new p2p network from scratch, you need to get people online. Most users won't be connected to the network except when they're in the middle of their own upgrade. If you use, say, the existing gnutella network, you have the advantage that every Mandrake user who's using gtkg, qtella, limewire, etc. (assuming they've added their package repository to their p2p upload directory list) is available--but the disadvantage that most of the people on the network don't have the files you want. I think MandrakeSoft would be the ones to do it. The installer *is* looking pretty slick -- perhaps they have some spare developers looking for something to do ;oP The network, the tools needed to make it work, and the active community would be a great asset for the company. There's a lot of people using this distro, and the number of potential participants is growing all the time. Your CPU cycles, storage, and bandwidth could be a way of giving back to the community... I think a separate network would be required - as then specialist functions particular to the purpose (such as developers flagging bugs they are working on, checking package integrity, etc.) can be done without the restrictions imposed by the capabilities of current Gnutella clients. Perhaps as the generic clients get more modular MandrakeNetwork plugins would be the thing... Either way, you'll probably still need mirror sites--and I'm guessing it's much easier to find someone who will run ftp, rsync, and/or http mirrors than finding someone who will attach their mirror server to either a brand-new p2p network or the existing gnutella network Clearly the more machines the better Oh, and I think that packages should be revertable on installed systems as well. Users should be protected against unstable software wherever possible, but at the same time they will demand the very latest releases. It would be nice to be able to downgrade through urpmi and the GUI tools (of course you can already downgrade today--just download and force-upgrade--but it's not as easy as installing or upgrading). If I try to downgrade kdebase, it would tell me you also need to downgrade kdelibs and kdegames and uninstall kdevelop, and (if I approve) it would go get the relevant versions of kdebase, kdelibs, and kdegames and so on. True about the force-upgrade, but this doesn't restore the machine to the former state. When you upgrade, the packages you are replacing should be archived somewhere on your network if possible, so you have everything right there if something doesn't work right. Remember that storage is getting cheaper all the time. A big install on my systems now uses less than 5% of my disk space. My personal feeling is that reverting should be done using a separate micro install somewhere on the system, accessed through the bootloader, so that even fatal upgrades can be easily undone (and oh, haven't we all been there!). And if you are going from one green light system to a yellow or green, then there isn't a lot that you'd have to store... All people will need is reasonable assurance that the changes were successful and not detrimental to the functionality of thier machines. I think that being able to deal with the same package groups as the installer when upgrading, installing, or downgrading would also be helpful. A beginning
Re: [Cooker] Mandrake 9.1 Should be Delayed
Danny Tholen [EMAIL PROTECTED] writes: However, there is one thing that I sometimes see and which annoys me a bit. Some mandrakesoft people have a habit of not, or only rarely reply on emails, even when there are patches for the problem in it. Some people (like Maybe more overworked than I am? People may also have different views on how cooperation must happen with external contributors.. Or maybe they use ineffective mail client programs? :) yourself) are very cooperative. This shows. There are components of the Thanks, appreciated. distro which are buggy only (IMO) because of this fact. I perfectly understand that reading/answering a 1000 mails a day is not something you generally like doing. Certainly not when you are already stressed with trying to fix your packages bugs. Not everybody can handle that. That's fine. But, I would like to propose. For the people that hate reading all their mail/answering it. Appoint some volunteer from this list to be the interface between the packager and the users. If someone sends a patch to fix, lets say, ugly colors in frozen bubble, and sends a fix to this list. I can than pick it up, and forward it to Guillaume. And he will perhaps reply to me, saying: ok, or simply :no way. And I than can try to explain it again to the reporter. It sounds a bit cumbersome I agree, but it is better than waiting in vain to see your patch being lost. Well, the initiative shows your support for Mandrake. But I think it would be uneffective. First, here at Mandrake we are paid for what we're doing, so it enforces a behaviour and assume some tasks that are sometimes not immediately pleasant (again, that's only my point of view). Second, I think time from external contributors is precious (especially concerns the talented external contributor), and it's better spent doing real tests/patches/suggestions/etc (not counting the fact that what you describe demands much motivation). Third, we can't rely on external contributors as much as employees, for the simple fact that people are free to stop contributing, anytime. I'd like to thank you again for this proposal, which shows how much you want Mandrake to be a good distro. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 07 March 2003 02:56, Maks Orlovich wrote: What you're also forgetting is that Mandrake is not the only group that's affected. Changes Mandrake makes to KDE, Gnome, Mozilla, etc., reflect on people's opinion of the respective software; and cause maintenance hassles. I already had to close 2 reports of galaxy-kde's broken masking (including spending time explaining to the user why this was happening; quite a bit of time, I must add, time which could be better spend trying to fix actual bugs in KDE); and that bug is only scratching the surface, there are multiple major problems there. Yes, that's true. But is more a problem for Mandrake as a vendor, then e.g. for KDE. If something doesn't work on Mandrake's KDE but works elsewhere (even because the packager made a hack to get it to work), it will make Mandrake look bad, not KDE, at least not that much. People go and complain to their vendor, they didn't buy KDE, they bought/downloaded Mandrake Linux. But otherwise I agree, Mandrake is not the only party affected here. That's known regression on the 3.1.x branch (marked release critical show stopper for KDE3.1.1); IMHO a sane solution is to back out the patch -- the problem it was trying to solve is pretty minor anyway (what is it with merging 99% of branch patches, anyway? ;-) ) Finaly somebody told me what's going on here. There is yet another bug about this in Bugzilla - 2861. Could you have a look at that, please ? Maybe it is the same issue and should be closed/resolved the same way. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aJCun11XseNj94gRAhU3AKDnRu8y1sCDxbUb98rLlE7YgFVImwCeODwK lqW7nx0YO/2Odfe8UXj83ho= =u16B -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Sparenberg wrote: On Thu, 2003-03-06 at 07:17, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lissimore wrote: Yes more bugs are being reported. But also keep in mind the bugs that were reported, and nothing done about them. So they get reported again...and...again...and again. People should *search* bugzilla before reporting again ... ( e.g. The SMP kernel installer bug was reported back in beta1 (Bug 1553) then again (bug 1823), then again (bug 2101), and then again (bug 2218). ) So, why did the reporters not search first? So it's not a simple mater of people crawling out of the woodwork... some bloody bugs get reported, and then not worked on for a long time (or even declared as verified on bugzilla). Instead of making a duplicate bug, users should *vote for* or *confirm* the existing entries! Since when are bugs and bug shooting a popularity contest? There is a difference between a bug, and a bug report. Bug reports can be, and often are incorrect. I work hand in glove daily with both our QA division and our Consumer Support Divisions. Bug is Bug When it comes in the door We evaluate them immediately. They get moved from confirmed to assigned within 24 hours (and I have the nag in Bugzilla set to start e-mailing the heck out of personnel if needed.) Yes I know large numbers of bugs get reported ... Yes I know it's a hassle. Yes I get developers yelling I can't do anything else but fix bugs to which I generally reply Yes? And yes 90% of the bugs we get hit with are actually problems with the distro not our product, and mostly do to changes to improve things that break what the consumer is used to. Fine ... that's part of doing business. But let me ask you this Do you honestly think one of the largest firms in the industry (who is now using our product) would like it if we told them We'll fix your bug when we get enough votes.. *sigh* All your software is open source, and you provide it all for free to your customers? Remember that the proprietary model and open-source model differ slightly. In the proprietary model, someone is paying you to read and validate bug reports ... in the open source model, if you aren't paying, and you want your bug fixed, you need to ensure it can be validated easily, or ensure that someone does it for you. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aJ+2rJK6UGDSBKcRAh13AJ4nvVsYkwYziR+uff+A9FLBZksGLQCgsVJK OWbKVXJ/IyMxuVS0/av3nuM= =01Tp -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Yes, that's true. But is more a problem for Mandrake as a vendor, then e.g. for KDE. If something doesn't work on Mandrake's KDE but works elsewhere (even because the packager made a hack to get it to work), it will make Mandrake look bad, not KDE, at least not that much. Don't underestimate abilities of vendors to break things. When KDE3.0 first came out, first cuts of packages from both SuSE and Mandrake had aRts sound broken. For entirely different reasons, I might add, both of which were pretty weird/flukey packaging bugs. RH8.0 shipped with vendor modification that resulted in the KDE window manager crashing quite frequently with some applications[1]. Yet I didn't see RH taking any responsibility or flack because of that; in fact all they got was midndless adulation because they were marketing themselves as pioneers. Of course, RH and MDK both have reputations WRT to quality already which don't neccesserily reflect reality. That's known regression on the 3.1.x branch (marked release critical show stopper for KDE3.1.1); IMHO a sane solution is to back out the patch -- the problem it was trying to solve is pretty minor anyway (what is it with merging 99% of branch patches, anyway? ;-) ) Finaly somebody told me what's going on here. There is yet another bug about this in Bugzilla - 2861. Could you have a look at that, please ? Maybe it is the same issue and should be closed/resolved the same way. George Staikos has addressed that on the KDE3.1.1 branch. See: http://lists.kde.org/?l=kde-cvsm=104701980622556w=2 http://lists.kde.org/?l=kde-cvsm=104701957322386w=2 http://lists.kde.org/?l=kde-cvsm=104702055522978w=2 http://lists.kde.org/?l=kde-cvsm=104702343924965w=2 http://lists.kde.org/?l=kde-cvsm=104702353725032w=2 http://lists.kde.org/?l=kde-cvsm=104702676927501w=2 Basically, the original problem was that Konqueror's iconview, when you have previews on and set to a larger size than basic icons, doesn't resize the grid to accomodate the previews until it's entirely done; which means the previews overlap; this can be problematic on huge dirs.. The patch to fix it apparently introduced worse regressions; so it was reverted and the increase in the preview size was set to be off by default.. A couple of the other patches here are only somewhat related.. One disables CSV previews so they don't bug people with popups (previews requiring user interaction aren't very useful). The other patch also disables the sound previews; this is a weird one; the bug is basically dependent on some dynamic linker mode settings, enabling which causes things to just blow up on app start for some people (it seems to be connected with something peculiar on SuSE, too, or something like this, but I am not sure)[2]; but outside some conditions it's not reproducible at all; thus this is more a let's be extra careful move than anything else. However, since it takes quite a while (1/3 sec hiccup on my box) to load the sound preview lib, I am personally far more in favor of this happening than otherwise. (Note: this disclaimer should have applied to the first message too): The opinions expressed here are purely my own, and should not be taken to reflect those of any organization. [1] More specifically, their bluecurve deco did; decorations for KWin are plugin into the KWin process. [2] The same symptoms also happen due to some fun with libvorbisenc versions for Debian and Slackware users. Oh joy.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I first though that having only one person to confirm a bug will not be enough, so I set the minimum number of vote to confirm a bug to 2, but it may be more intelligent to lower it to 1. -- Warly
Re: [Cooker] Mandrake 9.1 Should be Delayed
Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I reduce it to 1. -- Warly
Re: [Cooker] Mandrake 9.1 Should be Delayed
George Mitchell [EMAIL PROTECTED] writes: And this exactly illustrates the problem with the current development model. Come hell or high water the product WILL ship, even if it turns out to be the buggiest ever. Mandrake and other distributors are entering a period where they are merely replicating proprietary vendors by becoming slaves of a ship date and shipping the whole unfinished mess out for consumers to choke on. That is why it is time to change the development model. Development should be modularized, with each major compenent following a separate development path maintained in sync with the external free software developers. These components should be folded into the distribution ONLY when bulletproof while the distribution itself gets released periodically. This would decentrallize the development of the distribution and sharpen quality control. It would also focus resources on the problems rather than on continuing to persue enhancements at the expenses of stability. A big part of the problem is that Cooker spends most of its life as a mish mash of incomplete and buggy code and then ends up in a big rush to stabalize everything simultaneously as time runs out. Releasing a distro with the current flow of complaints on bugzilla is nuts. But then, as before, I wil somehow make it work by regressing various components backward to previous versions in order to come up with a better functioning whole. I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. Strict release date are good because it is worthless to correct all the very single bug that will be ignore by 95 percent of the customers and will be fixed in an update before the CD are on the shelves. Stabilizing a distro too much is mainly a non productive work, and we are supposed to develop and create new pieces of software and innovative things, not replacing any _very_unprofessionnal_ spelling mistakes or titlebar color in the 4000 packages of the distributions -- Warly
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 9:51 am, Warly wrote: Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I first though that having only one person to confirm a bug will not be enough, so I set the minimum number of vote to confirm a bug to 2, but it may be more intelligent to lower it to 1. Well it is not a problem requiring 2 votes per bug to confirm it. It is the fact that if I want to vote for 2 bugs that are in the Installation component I can't. So if I am doing my bug hunting, find 2 bugs in the installation, search in bugzilla and find that other people have already discovered these bugs, I can only confirm one of them. The other bug I can't vote for. This seems counterintuitive to me. -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Staikos has addressed that on the KDE3.1.1 branch. See: http://lists.kde.org/?l=kde-cvsm=104701980622556w=2 http://lists.kde.org/?l=kde-cvsm=104701957322386w=2 http://lists.kde.org/?l=kde-cvsm=104702055522978w=2 http://lists.kde.org/?l=kde-cvsm=104702343924965w=2 http://lists.kde.org/?l=kde-cvsm=104702353725032w=2 http://lists.kde.org/?l=kde-cvsm=104702676927501w=2 Let's hope this makes it into the Mandrake KDE :-( Not holding my breath, though. Basically, the original problem was that Konqueror's iconview, when you have previews on and set to a larger size than basic icons, doesn't resize the grid to accomodate the previews until it's entirely done; which means the previews overlap; this can be problematic on huge dirs.. The patch to fix it apparently introduced worse regressions; so it was reverted and the increase in the preview size was set to be off by default.. I switched the increased preview size off and that cured it. Cool. Probably this is the default anyway, so not that many people saw it, except when they fiddled with the settings as I did. However, since it takes quite a while (1/3 sec hiccup on my box) to load the sound preview lib, I am personally far more in favor of this happening than otherwise. The sound previews are fine, but you have to wait without any feedback, that something is going on, and then BOOM, speakers blare ... Should be probably off by default, it was pretty confusing before I realized what is going on :-) Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aMTxn11XseNj94gRAhlWAKCYyG+K9jYc5EqBF3Z2fCqjxE5wIACgiIml HTBpU761QLkPG4uM/YsxKQY= =cw2G -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 10:15 am, Frederic Crozat wrote: I think the BIG problem with UNCONFIRMED bug is their test case scenario : If you check all the bugs I replied to this week, more than 500f reply are : give me reproducible facts, give me testcase, etc... And when I think bug are fixed, I ask people to test and I get no answer in 250f case.. This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) PS. What does 500f and 250f mean? -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 6 Mar 2003, Timothy R. Butler wrote: What about using the three tier approach of Debian? New stuff goes in unstable, after a few weeks of qa, it goes into stable Cooker (that is, testing), and then the releases are stable. As it stands, Cooker at any particular moment can be anywhere inbetween those three stages. Hell, in my experience Cooker is less b0rked than the betas, RCs, or final releases. I'd have no compunction about using Cooker in a real live production system. Levi Ramsey [EMAIL PROTECTED]
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 6 Mar 2003, Andi Payn wrote: A compromise might be to do a QA'd sub-release of Cooker every two months, rather than every six months. A single team can work on a project with release dates this short, spending a couple of weeks in freeze every two months. I think most Cooker users would put up with these freezes in exchange for an even-more-usable Cooker. And, more importantly, both Mandrake's team and the user community would have more experience getting together a solid release; it would require less work to tie together two months' worth of development than six; and there'd be a solid way to back-track any subset of the distro, if necessary, without going all the way back to the last major release. I would say that it should be made monthly, without formally freezing Cooker per se (ie a fork 10 days before). As release time approaches, the target final version would be based on which one of those snapshots seemed to be the most stable (and thus on squashing as many bugs as possible in that snapshot). Levi Ramsey [EMAIL PROTECTED]
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bret Baptist wrote: On Friday 07 March 2003 10:15 am, Frederic Crozat wrote: I think the BIG problem with UNCONFIRMED bug is their test case scenario : If you check all the bugs I replied to this week, more than 500f reply are : give me reproducible facts, give me testcase, etc... And when I think bug are fixed, I ask people to test and I get no answer in 250f case.. This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) Bug reports that cannot be reproduced are much less useful than ones that can be reproduced. PS. What does 500f and 250f mean? I think it was 50% and 25% - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aM6OrJK6UGDSBKcRAnRaAKCdk+jvj4iW4ajdAl+EUUlU0sUqtwCgmUic F2ubW4ROdwu4/hZUb48RyLo= =LRVe -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 7 Mar 2003, Paul Dorman wrote: That's interesting. There seem to be a bunch of projects applying p2p in interesting and imaginative ways, so perhaps any problems wouldn't last for long... The Linux community is getting bigger all the time; there has to be some threshold past which p2p could be effective. I just figured I'd pop in and say that I share out a reasonably updated Cooker on OpenFT (though with my b0rked voltage converter, it will be a few more days before I'm back online...) Levi Ramsey [EMAIL PROTECTED]
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 10:39 am, Frederic Crozat wrote: So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) I can only speak for myself but since there isn't enough bug triaging (UNCONFIRMED bug tagged as NEW), I have to dig in UNCONFIRMED bugs to see if I can reproduce them here... If you find a testcase for an UNCONFIRMED bug, post it, it will always help people fixing bugs.. (this is not Mdk specific.. :) The moving from UNCONFIRMED to NEW is what I would like to do. One of the issues I have is that I test a component for bugs (say kdebase). I can only vote for one bug out of that component. So that means that I can only really confirm one bug in the system. I can post Me too's to a comment on a bug, but I can not vote for multiple bugs and move them to a NEW or CONFIRMED state in the system. Does this make any sense? PS. What does 500f and 250f mean? grrr, this is our news2mail gateway which is broken, it means 50percent and 25percent :)) Ahhh I see. Makes more sense now. -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 7 Mar 2003, Paul Dorman wrote: On the one hand, an open source project can just use an existing protocol (say, gnutella) rather than building something new from scratch, and doesn't need to worry about billing, etc. And just distributing SHA URI's on official mirrors would be enough to search for the file online and verify that you've downloaded the right one (and of course RPM signatures provide security on top of that). Good, good. I was thinking something based on Gnutella. Many of the clients have built in discussion and chat facilities, as well as administrative tools. Lots to build off there. We could just use OpenFT/giFT which has the advantages of being Free Software (although at its current state, they discourage binary distribution). Using it as a means of updating software may also provide Mandrake with enough plausible deniability to allow distribution of OpenFT in the main distro, though IANAL. Levi Ramsey [EMAIL PROTECTED]
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 7 Mar 2003, Guillaume Cottenceau wrote: Well, the initiative shows your support for Mandrake. But I think it would be uneffective. First, here at Mandrake we are paid for what we're doing, so it enforces a behaviour and assume some tasks that are sometimes not immediately pleasant (again, that's only my point of view). Second, I think time from external contributors is precious (especially concerns the talented external contributor), and it's better spent doing real tests/patches/suggestions/etc (not counting the fact that what you describe demands much motivation). Third, we can't rely on external contributors as much as employees, for the simple fact that people are free to stop contributing, anytime. The contributor who serves a buffer would not have to be an extremely active contributor (in the sense of submitting patches and packages). How many people are there who only post occasionally to the list? By simply posting occasionally, they're demonstrating a desire for Mandrake to be a better distro; this gives them more of an opportunity to assist towards that goal. Levi Ramsey [EMAIL PROTECTED]
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 07 March 2003 10:54, Warly wrote: Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I reduce it to 1. Why? I raised this issue in bug #878 (https://qa.mandrakesoft.com/show_bug.cgi?id=878) already. I understood the reason you gave then that it was not your priority. Perhaps after the 9.1 release. Also, vote for #878 if you feel it is important ;-) Best, Sascha Noyes - -- Please encrypt all correspondence. PGP key available from: http://individual.utoronto.ca/noyes/snoyes.asc - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aNA/gzJdfX+cTW8RAh/PAJ96GFL+RqriMioWeBQISLuJAbJuCACgnGyu 0yXsLHGeM6/GiqHrexwhyOY= =DIK6 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 07 March 2003 11:09, Warly wrote: George Mitchell [EMAIL PROTECTED] writes: And this exactly illustrates the problem with the current development model. Come hell or high water the product WILL ship, even if it turns out to be the buggiest ever. Mandrake and other distributors are entering a period where they are merely replicating proprietary vendors by becoming slaves of a ship date and shipping the whole unfinished mess out for consumers to choke on. That is why it is time to change the development model. Development should be modularized, with each major compenent following a separate development path maintained in sync with the external free software developers. These components should be folded into the distribution ONLY when bulletproof while the distribution itself gets released periodically. This would decentrallize the development of the distribution and sharpen quality control. It would also focus resources on the problems rather than on continuing to persue enhancements at the expenses of stability. A big part of the problem is that Cooker spends most of its life as a mish mash of incomplete and buggy code and then ends up in a big rush to stabalize everything simultaneously as time runs out. Releasing a distro with the current flow of complaints on bugzilla is nuts. But then, as before, I wil somehow make it work by regressing various components backward to previous versions in order to come up with a better functioning whole. I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. Strict release date are good because it is worthless to correct all the very single bug that will be ignore by 95 percent of the customers and will be fixed in an update before the CD are on the shelves. Stabilizing a distro too much is mainly a non productive work, and we are supposed to develop and create new pieces of software and innovative things, not replacing any _very_unprofessionnal_ spelling mistakes or titlebar color in the 4000 packages of the distributions I agree with Warly here. People do not seem to notice that Mandrake has a certain development philosophy: 1. Release every 6 months 2. Include the latest stable versions of popular software, irrespective whether it might be unpolished. This has always been the case with Mandrake, and that is why they also have such a large following with power-users (not guru's but not complete newbies). Anybody who thinks that the above two points are new has not been around to see many of Mandrake's releases. I think if you want to get Mandrake to change their policy (like the Debian-like 3-phase suggestion) you are going to have to have pretty good arguments for why this would be better (and not lead to eg. Debian-like outdatedness in the stable version) Best, Sascha Noyes - -- Please encrypt all correspondence. PGP key available from: http://individual.utoronto.ca/noyes/snoyes.asc - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aM7hgzJdfX+cTW8RAvAVAKCrlb9OXLNVEHfZHAnG9h4zJJOvMACeLsbx kEazsPR2oiODFe5uEf8eAdY= =NH3j -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bret Baptist wrote: On Friday 07 March 2003 10:39 am, Frederic Crozat wrote: So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) I can only speak for myself but since there isn't enough bug triaging (UNCONFIRMED bug tagged as NEW), I have to dig in UNCONFIRMED bugs to see if I can reproduce them here... If you find a testcase for an UNCONFIRMED bug, post it, it will always help people fixing bugs.. (this is not Mdk specific.. :) The moving from UNCONFIRMED to NEW is what I would like to do. One of the issues I have is that I test a component for bugs (say kdebase). I can only vote for one bug out of that component. So that means that I can only really confirm one bug in the system. I can post Me too's to a comment on a bug, but I can not vote for multiple bugs and move them to a NEW or CONFIRMED state in the system. Does this make any sense? Not as much as it could. Saying me too, or voting/confirming a bug are not really useful unless you can add more insight to it. Better to ensure that when the developer looks at it, that he has something to work with, than to make him look at a whole bunch of bug reports that have information on how to reproduce the bug. MHO of course. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aNTxrJK6UGDSBKcRAs7sAJ9qkrofpj73NkwXtWXoQsAvrPpSjgCfYXNP UAPABggSdDJn3Mh9B16uS8E= =gzUN -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Crozat wrote: On Fri, 07 Mar 2003 10:30:55 -0600, Bret Baptist wrote: This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) I can only speak for myself but since there isn't enough bug triaging (UNCONFIRMED bug tagged as NEW), I have to dig in UNCONFIRMED bugs to see if I can reproduce them here... If you find a testcase for an UNCONFIRMED bug, post it, it will always help people fixing bugs.. (this is not Mdk specific.. :) IOW, instead of everyone discussing how the development model should be changed (long term, not going to have any effect on 9.1), rather spend your time triaging bugs. If you do not have edit_bug status, at least go and try and get a working test case for an existing bug, or comment on duplicates so developers can save time. (That is what I am doing now ...) Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aNavrJK6UGDSBKcRAngnAJ4/XvAdT1RJFg48m4huNmLdhs4V+ACeOnKO jDB2xX3l38KUfug+1v33Fd4= =2/j2 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 11:20 am, Buchan Milne wrote: Bret Baptist wrote: The moving from UNCONFIRMED to NEW is what I would like to do. One of the issues I have is that I test a component for bugs (say kdebase). I can only vote for one bug out of that component. So that means that I can only really confirm one bug in the system. I can post Me too's to a comment on a bug, but I can not vote for multiple bugs and move them to a NEW or CONFIRMED state in the system. Does this make any sense? Not as much as it could. Saying me too, or voting/confirming a bug are not really useful unless you can add more insight to it. Better to ensure that when the developer looks at it, that he has something to work with, than to make him look at a whole bunch of bug reports that have information on how to reproduce the bug. MHO of course. Buchan I thought the idea was that if a bug gets voted to a confirmed state than the developer would have a pretty good idea that the bug is in fact valid. I was also under the impression that if the bug is not in a NEW state that most developers (pixel, and fcrozat being an exception for sure) don't even look at it. Is this not the case? -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 11:28 am, Buchan Milne wrote: IOW, instead of everyone discussing how the development model should be changed (long term, not going to have any effect on 9.1), rather spend your time triaging bugs. If you do not have edit_bug status, at least go and try and get a working test case for an existing bug, or comment on duplicates so developers can save time. (That is what I am doing now ...) Buchan You are right of course. I will be doing that when I get home to my cooker machine. I just ran across the voting pecularity when trying to help out recently. Going to work around it till later. -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bret Baptist wrote: On Friday 07 March 2003 11:20 am, Buchan Milne wrote: I thought the idea was that if a bug gets voted to a confirmed state than the developer would have a pretty good idea that the bug is in fact valid. Sure, but you still want him to be able to reproduce it easily. I was also under the impression that if the bug is not in a NEW state that most developers (pixel, and fcrozat being an exception for sure) don't even look at it. Is this not the case? I can't tell you for sure, but I would guess developers look at confirmed bugs first. And of course, you can reduce the time they spend looking at confirmed bugs (to get your unconfirmed bugs looked at possibly) by ensuring that as many bugs as possible are really good. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aN0ArJK6UGDSBKcRAhAVAKDCibtVm07VeeCpJB/+FtJlfgLCZACfUq+T 21mgs9iHFkl2XWU98rQ15mU= =i1rE -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Sascha Noyes [EMAIL PROTECTED] writes: On Friday 07 March 2003 10:54, Warly wrote: Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I reduce it to 1. Why? I raised this issue in bug #878 (https://qa.mandrakesoft.com/show_bug.cgi?id=878) already. I understood the reason you gave then that it was not your priority. Perhaps after the 9.1 release. Also, vote for #878 if you feel it is important ;-) I reduce the number of vote needed to confirm a bug to 1. -- Warly
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 11:54 am, Sascha Noyes wrote: I agree with Warly here. People do not seem to notice that Mandrake has a certain development philosophy: 1. Release every 6 months 2. Include the latest stable versions of popular software, irrespective whether it might be unpolished. This has always been the case with Mandrake, and that is why they also have such a large following with power-users (not guru's but not complete newbies). Anybody who thinks that the above two points are new has not been around to see many of Mandrake's releases. I think if you want to get Mandrake to change their policy (like the Debian-like 3-phase suggestion) you are going to have to have pretty good arguments for why this would be better (and not lead to eg. Debian-like outdatedness in the stable version) You have just described exactly why I chose Mandrake. I am willing to put up with some issues to have the latest and greatest. -- Greg
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Meyer wrote: You have just described exactly why I chose Mandrake. I am willing to put up with some issues to have the latest and greatest. Of course, the idea is to try and reduce that number of issues ... anyway, seems like Fred just fixed one of the dhcp issues (not yours ... yet). 1 down, about 1000 to go ;-). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aOY/rJK6UGDSBKcRAnPpAJ471v58dboV/y17jZacB6Y3Kn4daACfUCBN J+/aUke8ZCHBV2VD1BYDlJM= =vyW0 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 05:33, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Sparenberg wrote: On Thu, 2003-03-06 at 07:17, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lissimore wrote: Yes more bugs are being reported. But also keep in mind the bugs that were reported, and nothing done about them. So they get reported again...and...again...and again. People should *search* bugzilla before reporting again ... ( e.g. The SMP kernel installer bug was reported back in beta1 (Bug 1553) then again (bug 1823), then again (bug 2101), and then again (bug 2218). ) So, why did the reporters not search first? So it's not a simple mater of people crawling out of the woodwork... some bloody bugs get reported, and then not worked on for a long time (or even declared as verified on bugzilla). Instead of making a duplicate bug, users should *vote for* or *confirm* the existing entries! Since when are bugs and bug shooting a popularity contest? There is a difference between a bug, and a bug report. Bug reports can be, and often are incorrect. I work hand in glove daily with both our QA division and our Consumer Support Divisions. Bug is Bug When it comes in the door We evaluate them immediately. They get moved from confirmed to assigned within 24 hours (and I have the nag in Bugzilla set to start e-mailing the heck out of personnel if needed.) Yes I know large numbers of bugs get reported ... Yes I know it's a hassle. Yes I get developers yelling I can't do anything else but fix bugs to which I generally reply Yes? And yes 90% of the bugs we get hit with are actually problems with the distro not our product, and mostly do to changes to improve things that break what the consumer is used to. Fine ... that's part of doing business. But let me ask you this Do you honestly think one of the largest firms in the industry (who is now using our product) would like it if we told them We'll fix your bug when we get enough votes.. *sigh* All your software is open source, and you provide it all for free to your customers? Both... it' revolves around a MySQL style system... Remember that the proprietary model and open-source model differ slightly. In the proprietary model, someone is paying you to read and validate bug reports ... in the open source model, if you aren't paying, and you want your bug fixed, you need to ensure it can be validated easily, or ensure that someone does it for you. Actually no one is paying me right now... the hassles of a startup. Problem here is you can't vote. I used up my vote a while back and although I could confirm a number of bugs... I can't ...no vote left. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aJ+2rJK6UGDSBKcRAh13AJ4nvVsYkwYziR+uff+A9FLBZksGLQCgsVJK OWbKVXJ/IyMxuVS0/av3nuM= =01Tp -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 08:15, Frederic Crozat wrote: On Fri, 07 Mar 2003 10:03:48 -0600, Bret Baptist wrote: On Friday 07 March 2003 9:51 am, Warly wrote: Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I first though that having only one person to confirm a bug will not be enough, so I set the minimum number of vote to confirm a bug to 2, but it may be more intelligent to lower it to 1. Well it is not a problem requiring 2 votes per bug to confirm it. It is the fact that if I want to vote for 2 bugs that are in the Installation component I can't. So if I am doing my bug hunting, find 2 bugs in the installation, search in bugzilla and find that other people have already discovered these bugs, I can only confirm one of them. The other bug I can't vote for. This seems counterintuitive to me. I think the BIG problem with UNCONFIRMED bug is their test case scenario : If you check all the bugs I replied to this week, more than 500f reply are : give me reproducible facts, give me testcase, etc... And when I think bug are fixed, I ask people to test and I get no answer in 250f case.. This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. Frederic You're right... and I'd like to propose an idea on how this could be made better for you and the community. If Warly and others at MDK (or from the community) would look at the bug reporting page at mozilla you'll see a number of required fields there, such as ones related to reproducibility, installed OS (9.1rc1 cooker current 9.1rc2 etc) What you did to get the bug, what did you expect. suggested solution etc. Nobody in the world had a worse situation than Mozilla did around 0.6, Now although it's not perfect their system seems to work really well (most of the time if I do a bug report there I get an e-mail back within 24 hours compared to 2 weeks pre 0.6) it will make a submit a more lengthy process (by a minute or two) but I think you'll get more of what you need. Second... I guess I need to submit a patch to the howto Greg is assembling on this very point ... (and make better use of this myself *grin*) James
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 08:39, Frederic Crozat wrote: On Fri, 07 Mar 2003 10:30:55 -0600, Bret Baptist wrote: On Friday 07 March 2003 10:15 am, Frederic Crozat wrote: I think the BIG problem with UNCONFIRMED bug is their test case scenario : If you check all the bugs I replied to this week, more than 500f reply are : give me reproducible facts, give me testcase, etc... And when I think bug are fixed, I ask people to test and I get no answer in 250f case.. This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. So what you are saying is voting for bugs is not as important as commenting on a bug that someone files and making the test case more clear? I would like to be able to do both. :-) I can only speak for myself but since there isn't enough bug triaging (UNCONFIRMED bug tagged as NEW), I have to dig in UNCONFIRMED bugs to see if I can reproduce them here... If you find a testcase for an UNCONFIRMED bug, post it, it will always help people fixing bugs.. (this is not Mdk specific.. :) PS. What does 500f and 250f mean? grrr, this is our news2mail gateway which is broken, it means 50percent and 25percent :)) Dang and I just thought it was you getting extremely hot under the collar (think Fahrenheit) *grin*
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 08:15, Frederic Crozat wrote: On Fri, 07 Mar 2003 10:03:48 -0600, Bret Baptist wrote: On Friday 07 March 2003 9:51 am, Warly wrote: Bret Baptist [EMAIL PROTECTED] writes: It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. I first though that having only one person to confirm a bug will not be enough, so I set the minimum number of vote to confirm a bug to 2, but it may be more intelligent to lower it to 1. Well it is not a problem requiring 2 votes per bug to confirm it. It is the fact that if I want to vote for 2 bugs that are in the Installation component I can't. So if I am doing my bug hunting, find 2 bugs in the installation, search in bugzilla and find that other people have already discovered these bugs, I can only confirm one of them. The other bug I can't vote for. This seems counterintuitive to me. I think the BIG problem with UNCONFIRMED bug is their test case scenario : If you check all the bugs I replied to this week, more than 500f reply are : give me reproducible facts, give me testcase, etc... And when I think bug are fixed, I ask people to test and I get no answer in 250f case.. This is really an area where YOU (cooker community) can help.. If I can't reproduce crash/bugs, I can't fix them.. Frederic You're right... and I'd like to propose an idea on how this could be made better for you and the community. If Warly and others at MDK (or from the community) would look at the bug reporting page at mozilla you'll see a number of required fields there, such as ones related to reproducibility, installed OS (9.1rc1 cooker current 9.1rc2 etc) What you did to get the bug, what did you expect. suggested solution etc. Nobody in the world had a worse situation than Mozilla did around 0.6, Now although it's not perfect their system seems to work really well (most of the time if I do a bug report there I get an e-mail back within 24 hours compared to 2 weeks pre 0.6) it will make a submit a more lengthy process (by a minute or two) but I think you'll get more of what you need. Second... I guess I need to submit a patch to the howto Greg is assembling on this very point ... (and make better use of this myself *grin*) James
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Sparenberg wrote: On Fri, 2003-03-07 at 05:33, Buchan Milne wrote: Problem here is you can't vote. I used up my vote a while back and although I could confirm a number of bugs... I can't ...no vote left. Give your bug id's, and what they cover, and I will see if I can take a look. People posting lists of possible dupes really helps, please continue! I just sorted about 6 dhcp-related ones (I hope). Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+aOy4rJK6UGDSBKcRAm6pAJ4rf46F80Sej3kRJ8+zUTSCeSUNlQCfQ1f7 55HEWpWzrXx9UDX00BkW5Xg= =SA69 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. There is something quite different to be said about including entirely new, distro-written software of alpha quality at best at the RC stage 2 weeks before release, however.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 23:40, James Sparenberg wrote: Do you honestly think one of the largest firms in the industry (who is now using our product) would like it if we told them We'll fix your bug when we get enough votes.. *sigh* Well, when you're doing corporate development, you usually bias things, something like one licensing seat, one vote, so the fact that your largest-by-far client is complaining about a bug pretty much automatically means that it has enough votes. But the principle is the same; a bug that's only affecting a few smaller clients is probably not going to get fixed right away.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 16:54, Sascha Noyes wrote: I agree with Warly here. People do not seem to notice that Mandrake has a certain development philosophy: 1. Release every 6 months 2. Include the latest stable versions of popular software, irrespective whether it might be unpolished. Yes, and their argument is that this is a *bad* development philosophy. It means Mandrake often release stable versions with very serious bugs. This is not a good thing. This has always been the case with Mandrake, and that is why they also have such a large following with power-users (not guru's but not complete newbies). Anybody who thinks that the above two points are new has not been around to see many of Mandrake's releases. I think if you want to get Mandrake to change their policy (like the Debian-like 3-phase suggestion) you are going to have to have pretty good arguments for why this would be better (and not lead to eg. Debian-like outdatedness in the stable version) Debian's outdatedness in release versions has little to do with the stable / testing / sid split. Rather it's because they do a lot of work - they have to support many architectures, many more than Mandrake supports - and they have very long release cycles. You could certainly use the same structure on a much shorter release cycle. -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 16:09, Warly wrote: I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. Strict release date are good because it is worthless to correct all the very single bug that will be ignore by 95 percent of the customers and will be fixed in an update before the CD are on the shelves. Stabilizing a distro too much is mainly a non productive work, and we are supposed to develop and create new pieces of software and innovative things, not replacing any _very_unprofessionnal_ spelling mistakes or titlebar color in the 4000 packages of the distributions Sorry, but this characterisation is wrong. There's some trivial bugs currently; there's also some that ought to delay the distribution on their own. See the bug which means anyone who has a PPP connection and tries to activate Mandrake's own firewall will lose their internet connection with no explanation...which has been marked as WONTFIX. This is NOT a spelling mistake or wrong titlebar colour. -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri, 2003-03-07 at 02:25, Andi Payn wrote: On Thursday 06 March 2003 06:17, Adam Williamson wrote: If the problem is contractual obligations, perhaps the 9.0 experience ought to indicate that such contracts should not be made. How do you propose that Mandrake release their software, then? If they wait until there is a stable release before signing contracts, it will be at least a month before that release hits the shelves, and even longer before most of the advertising supporting that release appears. And that's assuming that they have good relationships with everyone involved (and are willing to pay for rush work in some cases). You can't just call someone and say, OK, our release is ready, and get it in stores the next day. Now, in the long run, they'd still get out the same number of releases per year, it's just that there'd be a gap of a couple of months when they first switched to this new strategy. That doesn't sound too bad, but think about what it means--it means a couple of months with significantly reduced revenue, which isn't such a great thing for a company in Mandrake's financial situation (or, really, any company). But as someone has pointed out, the current strategy runs the equal risk of producing a stinker release which sells poorly. Buggy releases COST MONEY - if you read all the Mandrake stuff on various Linux sites, you'll *STILL* find comments from people who didn't buy Mandrake 9.0 because they tried the free version and the supermount kernel bug broke their CD-ROM access. Sorry to keep harping on that one bug, but one sufficiently serious bug can be crucial. -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 20:32, Adam Williamson wrote: Sorry, but this characterisation is wrong. There's some trivial bugs currently; there's also some that ought to delay the distribution on their own. See the bug which means anyone who has a PPP connection and tries to activate Mandrake's own firewall will lose their internet connection with no explanation...which has been marked as WONTFIX. This is NOT a spelling mistake or wrong titlebar colour. very true. But I think I also learned in the past that it is useless to keep trying to convince mdk of this. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 12:37, Guillaume Cottenceau wrote: Danny Tholen [EMAIL PROTECTED] writes: Maybe more overworked than I am? People may also have different views on how cooperation must happen with external contributors.. Or maybe they use ineffective mail client programs? :) yes ofcourse, I hope it was clear it was *not* an attack on these people. I was merely stating that I think it is counterproductive. And I tried to come up with a possible solution. Well, the initiative shows your support for Mandrake. But I think it would be uneffective. First, here at Mandrake we are paid for what we're doing, so it enforces a behaviour and assume some tasks that are sometimes not immediately pleasant (again, that's only my point of view). Ok, so you are basically saying that everybody should be responsive. Well, perhaps restate that policy next meeting:) Also note that this statement does not say anything about the proposed remedy. Second, I think time from external contributors is precious (especially concerns the talented external contributor), and it's better spent doing real tests/patches/suggestions/etc (not counting the fact that what you describe demands much motivation). true enough. But, perhaps some people will be more suitable for replying to emails than for writing patches. Certainly considering the volume of this list. Third, we can't rely on external contributors as much as employees, for the simple fact that people are free to stop contributing, anytime. Yes ofcourse. But debian is still a distro. I'd like to thank you again for this proposal, which shows how much you want Mandrake to be a good distro. thanks ;-) But, what I would have liked more is that you provided an alternative solution. Because you do not dispute that a (small) problem exists. And there is some truth in your critic, however, without alternative solution, why not try it. Than again, perhaps you will do something internally, and do not want it on the list. That is also ok. ok..i think i'm ranting- go to sleep now. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Warly wrote: George Mitchell [EMAIL PROTECTED] writes: And this exactly illustrates the problem with the current development model. Come hell or high water the product WILL ship, even if it turns out to be the buggiest ever. Mandrake and other distributors are entering a period where they are merely replicating proprietary vendors by becoming slaves of a ship date and shipping the whole unfinished mess out for consumers to choke on. That is why it is time to change the development model. Development should be modularized, with each major compenent following a separate development path maintained in sync with the external free software developers. These components should be folded into the distribution ONLY when bulletproof while the distribution itself gets released periodically. This would decentrallize the development of the distribution and sharpen quality control. It would also focus resources on the problems rather than on continuing to persue enhancements at the expenses of stability. A big part of the problem is that Cooker spends most of its life as a mish mash of incomplete and buggy code and then ends up in a big rush to stabalize everything simultaneously as time runs out. Releasing a distro with the current flow of complaints on bugzilla is nuts. But then, as before, I wil somehow make it work by regressing various components backward to previous versions in order to come up with a better functioning whole. I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. Strict release date are good because it is worthless to correct all the very single bug that will be ignore by 95 percent of the customers and will be fixed in an update before the CD are on the shelves. Stabilizing a distro too much is mainly a non productive work, and we are supposed to develop and create new pieces of software and innovative things, not replacing any _very_unprofessionnal_ spelling mistakes or titlebar color in the 4000 packages of the distributions Non productive work? How about 3D accelleration that doesn't work on Radeon cards? Is that one of the things you consider trivial and not worth correcting? I have a Radeon VE that works flawlessly on install with Red Hat 8.0. It is a screaming mess on install with Mandrake 9.0 and still is not working with Cooker which is just about ready to release. Problems with ATI and nVidea products. Only the two most popular video cards on the market. Should I just go out and buy yet another video card. Oh wait, lets check supported hardware on Mandrake site. Ah yes, all video cards are 'known to work'. Lets look at the 'tested' category. Whoopee, no cards in that category. So face it, Mandrake QA is failing, and Mandrake refuses to own up to it. I really don't know whether stable/unstable is the answer, but for sure something needs to be done. I appreciate Mandrake enough to put up with this nonsense, but how many new users will? This is no way to win the desktop and you should admit it and be open to new ideas.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Levi Ramsey wrote: On Thu, 6 Mar 2003, Andi Payn wrote: A compromise might be to do a QA'd sub-release of Cooker every two months, rather than every six months. A single team can work on a project with release dates this short, spending a couple of weeks in freeze every two months. I think most Cooker users would put up with these freezes in exchange for an even-more-usable Cooker. And, more importantly, both Mandrake's team and the user community would have more experience getting together a solid release; it would require less work to tie together two months' worth of development than six; and there'd be a solid way to back-track any subset of the distro, if necessary, without going all the way back to the last major release. I would say that it should be made monthly, without formally freezing Cooker per se (ie a fork 10 days before). As release time approaches, the target final version would be based on which one of those snapshots seemed to be the most stable (and thus on squashing as many bugs as possible in that snapshot). Levi Ramsey [EMAIL PROTECTED] If people are prepared to do this, then why not use a per-package flag in line with the regime I mentioned earlier? The snapshot could be packages which are stable (ie, 'green light'). If something people want misses out because there's some problems with it, then people might push to get it ready for the next snapshot, just one month away. And in that time it could be relegated to orange light as people test and debug it. Salut! Paul
Re: [Cooker] Mandrake 9.1 Should be Delayed
Sascha Noyes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 07 March 2003 11:09, Warly wrote: George Mitchell [EMAIL PROTECTED] writes: And this exactly illustrates the problem with the current development model. Come hell or high water the product WILL ship, even if it turns out to be the buggiest ever. Mandrake and other distributors are entering a period where they are merely replicating proprietary vendors by becoming slaves of a ship date and shipping the whole unfinished mess out for consumers to choke on. That is why it is time to change the development model. Development should be modularized, with each major compenent following a separate development path maintained in sync with the external free software developers. These components should be folded into the distribution ONLY when bulletproof while the distribution itself gets released periodically. This would decentrallize the development of the distribution and sharpen quality control. It would also focus resources on the problems rather than on continuing to persue enhancements at the expenses of stability. A big part of the problem is that Cooker spends most of its life as a mish mash of incomplete and buggy code and then ends up in a big rush to stabalize everything simultaneously as time runs out. Releasing a distro with the current flow of complaints on bugzilla is nuts. But then, as before, I wil somehow make it work by regressing various components backward to previous versions in order to come up with a better functioning whole. I do not agree. There is no point spending 4 months in stabilizing a already deprecated distribution. Strict release date are good because it is worthless to correct all the very single bug that will be ignore by 95 percent of the customers and will be fixed in an update before the CD are on the shelves. Stabilizing a distro too much is mainly a non productive work, and we are supposed to develop and create new pieces of software and innovative things, not replacing any _very_unprofessionnal_ spelling mistakes or titlebar color in the 4000 packages of the distributions I agree with Warly here. People do not seem to notice that Mandrake has a certain development philosophy: 1. Release every 6 months 2. Include the latest stable versions of popular software, irrespective whether it might be unpolished. This has always been the case with Mandrake, and that is why they also have such a large following with power-users (not guru's but not complete newbies). Anybody who thinks that the above two points are new has not been around to see many of Mandrake's releases. I think if you want to get Mandrake to change their policy (like the Debian-like 3-phase suggestion) you are going to have to have pretty good arguments for why this would be better (and not lead to eg. Debian-like outdatedness in the stable version) Best, Sascha Noyes - -- Please encrypt all correspondence. PGP key available from: http://individual.utoronto.ca/noyes/snoyes.asc - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+aM7hgzJdfX+cTW8RAvAVAKCrlb9OXLNVEHfZHAnG9h4zJJOvMACeLsbx kEazsPR2oiODFe5uEf8eAdY= =NH3j -END PGP SIGNATURE- I am not referring to issues of polish. I am referring to major things that do not work. I am not suggesting that a Debian system be employed to make Mandrake spot perfect like Debian, only that it be employed to make sure that major bugs are erradicated. I have no problem with the 6 mo release cycle either if it were buffered by a Debian like system. And Mandrake has released unstable versions of popular software in the past including KDE. That should not happen.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 2003-03-06 at 08:52, Guillaume Cottenceau wrote: N Smethurst [EMAIL PROTECTED] writes: Le Jeudi 6 Mars 2003 16:47, Guillaume Cottenceau a écrit : Well that depends. Most non-kernel and non-install bugs are looked at even in unconfirmed state - most of them are real and fixable. I know this is frustrating for reporters to get ignored, but as for the aim of bugzilla, e.g. track fix bugs, it's now in a state where it's really usable and helping us much to fix bugs. Maybe there should be a someone has had a look at this bug status for bugs that developers do look at but don't want to officially commit to ? IMO it's not needed. With the mail interface, it's very easy for us to comment on it, if we want to. I like GNOME's NEEDMOREINFO status. It nicely tells the reporter that their bug report wasn't all it could be, and lets the package maintainer ignore the bug until they do get more info. /curtis
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Fri 07 Mar 2003 21:18, George Mitchell posted as excerpted below: Non productive work? How about 3D accelleration that doesn't work on Radeon cards? Is that one of the things you consider trivial and not worth correcting? I have a Radeon VE that works flawlessly on install with Red Hat 8.0. It is a screaming mess on install with Mandrake 9.0 and still is not working with Cooker which is just about ready to release. Problems with ATI and nVidea products. Only the two most popular video cards on the market. .. And the two that prefer to make proprietary drivers rather than, if they want the speed and quality, making their work fully open.. Have you tried the software proprietare drivers from ATI on it? I have to run NVidia's software proprietare drivers because I am running dual video out on that card, and the software libre drivers don't work. I'd be extremely surprised if Mdk could or even would choose to put the software proprietare drivers on the freely downloadable disks. It's possible they might put it on the extra software proprietare disks they have in the commercial distrib versions, but obviously, that's not going to be in the main code base. You basically have to go d/l the software proprietare from the manufacturer's site yourself, and install it yourself. Of course, keep in mind that if ATI is like Nvidia in that regard, the ABI to the kernel is what they must use, and that changes with each version. Thus, there are limited kernel matches, one each for standard and enterprise kernel for each official release, but nothing for each cooker kernel update, or if you compile your own kernel. For those, you have to get the SRPM or tarballs and compile the kernel wrapper interface to the proprietary binary module yourself, so it matches the kernel you have deployed. Despite the additional cost for Matrox cards in particular based on their 3D performance (they tend to be good 2D performers, but not so good @ 3D), I'm seriously considering getting only them from now on.. Well, either that, or SiS/Via/whatever gpu/chipset cards, that have software libre drivers that exploit the full power of the card, low tho that might be, as at least then I'm not blowing $$ on features I can't use w/o serious hassle on Linux, due to their software proprietare policies. (I should mention that in NVidia's case at least, they claim the reason they don't fully support software libre drivers is that they have licensed intellectual property from other holders, and those licenses don't allow them to go the software libre route. That's a potentially valid arguement, but IMO, I'd rather simply do w/o those features then, and use a card a bit more plain jane, if necessary. Yes, it WILL affect my purchasing decisions from here on out. The reason I have the Nvidia now is because I got it b4 I switched to Linux, and while I checked that drivers were available for Linux as I was thinking about switching, I didn't realize there was this particular angle of it to worry about until I switched, and by then I already had the card.) -- Duncan They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Wednesday 05 March 2003 22:41, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [snipped] - - issues with the Nvidia cards with XFree and Nvidia drivers - contrary to the reports of others, I had problems with the proprietary drivers, started to happen only after upgrade to Cooker, wasn't broken with the same drivers in 9.0. Well I'm using the 1.0-4191 drivers and they are fine on TNT2 M64, and gForce4 MX440. -- John Allen, Email: mailto:[EMAIL PROTECTED] MandrakeClub Silver Member.
Re: [Cooker] Mandrake 9.1 Should be Delayed
From: Greg Meyer [EMAIL PROTECTED] | This package was missing from 9.0 also. I think it is a feature, not a bug. | The package is huge, and since everyone wnats 650MB iso's, it's going to get | left out. Easily fixed with a web download, it would be nice if this was | documented though. | Actually there are more space now than with 700MB CD:s Now you have: 3 x ~650 = ~1950MB (and AFAIK one additional disk in the boxed set) Before it was: 2 x ~700 + ~450 = ~1850MB (since ~250MB on the last disk was reserved for files only in boxed sets) so this release will have about 100MB more... Thomas
Re: [Cooker] Mandrake 9.1 Should be Delayed
Le Jeudi 6 Mars 2003 03:19, Greg Meyer a écrit : I think the distro would be much better served all of use that are testers, to test the hell out of this thing, not just by saying something does not work, but by really going the extra mile and trying to figure out why something does not work. For instance, if the network does not work, install it a couple of times trying different settings, note how the contents of the config files change. And all this criticism over something that cannot really be controlled is fruitless and makes the people working 7day/80hour weeks feel negative and prevents high levels of productivity. Help them, don't hurt them. What do you think most of us are doing? The real problem seems to be that there just aren't enough Mandrake developers to address most bugs. Out of the 6 bug reports I have filed, none of them have moved from UNCONFIRMED. Some of these bugs are not critical, but others, such as the mess 9.1RC1 made of trying to configure the Sagem ADSL modem are very important. (This is the modem that everyone in France on free.fr uses for adsl. One would have thought it was kind of important for a French distribution to make sure their French customers on adsl can actually connect to the internet.) There's very little point in us trying to report even more bugs if the developers are so understaffed that they cannot keep up with even a fraction of the bugs being reported at the moment. The only short term solution would be to give them more time to address the more critical bugs.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Timothy R. Butler [EMAIL PROTECTED] writes: The first is that no matter which xserver config I choose KDE 3.1 locks up on me several times a day, requiring a reset button. which may be a hardware problem Secondly, 9..2 insists on installing the mobo AC97 sound chip even though I have a mobo jumper set to disable it. the only way to really disable it would be to hide it on the pci bus, which is not done if lspcdirake -v show it. I was able to get sound as root, but not as user. classic bug sound tester: lspcidrake -v | fgrep AUDIO will tell you which driver your card use by default grep sound-slot /etc/modules.conf will tell you what driver it currently uses /sbin/lsmod will enable you to check if its module (driver) is loaded or not /sbin/chkconfig --list sound and /sbin/chkconfig --list alsa will tell you if sound and alsa services're configured to be run on initlevel 3 aumix -q will tell you if the sound volume is muted or not /sbin/fuser -v /dev/dsp will tell which program uses the sound card.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Palmer, Hilary [EMAIL PROTECTED] writes: Yes... Please do not release if there are still bugs floating around. We don't need the same reputation as M$. Linux is better than that. I am pretty much green here, but I have to agree - let's push the release date few days. There are bugs, which are pretty bad/annoying and will earn pretty bad image to Mandrake. Why is a mid-March release so critical? we've to release one day. having a fixed date force you to fix bugs. you've to understand that there'll always be some bugs. increasing this process will only make you adding more bugs while fixing other one (yes this do happen). with a fixed date, you've to fix most bugs before. then, while books are printed and boxes and cds are produced, you can prepare updates. just my 2cents.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 06 March 2003 08:05, Jaco Greeff wrote: On Thursday 06 March 2003 12:41 am, Jan Ciger scribbled on a piece of papyrus: - annoying message about kfm_client pops up from time to time, when trying to open directories on desktop Do you have a bug number for this one? I noticed thgis myself on links I created myself, thought it might have been something I broke on my side. Greetings, Jaco There are two bugs filled in the bugzilla for this right now (there were at least four, but probably they were closed as dupes already) : 1471, 1548 Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZzG+n11XseNj94gRAgM2AJ0ZW4tx48INAY7osZqsotxDPemqbgCfWirx Z78LRI+bXa6cLXdBfBUuwq8= =wohU -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well Mandrake cant do anything about Nvidia proprietary drivers, that's all up to nVidia... thomas I know, that Mandrake could not do much, because of the nature of the drivers, but something went wrong IMHO, because the same version of drivers worked fine with 4.2.x series of XFree on Mandrake 9.0, but screws my display up after few minutes on Mandrake 9.1. That reason should be identified and either fixed or reported to Nvidia as bug. If the Mandrake user has only two choices to have reasonable 3D on Linux and both of them are buggy (screen corruptions, crashes etc.), it is a pretty sorry state of the affairs ... Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZzKQn11XseNj94gRAlxTAJ9890oDWPovJOZ+9hFBflte/RkcIACgs7oP ir11q1avsDL8B9Ef5ECpBx4= =V0pQ -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...Mandrakesoft has to make the release date. It is negotiated into contracts for pressing CDs, for example, and a day's slippage may cause a month's delay and extensive penalties. That is one of the realities of making this software. The only thing that would stop the release date is a showstopper bug that keeps the product from working on a significant number of computers... One may debate whether existing bugs qualify as showstopper bugs, but point is the release date is important because Mandrake has contractual obligations that have financial consequences if violated. Miark Thanks for clarification. But still, one has to ask the question, whether to make short term savings on not being penalized for late release, but lose a lot of customer base because of the buggy product, or bite a bullet in the short term, but retain (and/or increase) the customer base in the future with good product. Honestly, I do believe that Mandrake 9.1 will be a great product. It just needs polishing and if it hits shelves in this half-baked state as it is now, it could do more harm to Mandrake than good. Well, I am not envious of the Mandrake CEO's job now :-( Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ZzQun11XseNj94gRAvB1AKCyfOMMf6Z5gSlv6gPS66XrgdXSDQCfSKpf 9vTjRT5IbmYHLsL97Ik7lvs= =RVQz -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
From: Jan Ciger [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well Mandrake cant do anything about Nvidia proprietary drivers, that's all up to nVidia... thomas I know, that Mandrake could not do much, because of the nature of the drivers, but something went wrong IMHO, because the same version of drivers worked fine with 4.2.x series of XFree on Mandrake 9.0, but screws my display up after few minutes on Mandrake 9.1. That reason should be identified and either fixed or reported to Nvidia as bug. Some of theese problems may be because we have newer gcc/glibc, than the version ysed to compile the binary-only parts of nVidias drivers... This we can't do anything about... We just have to wait for nVidia to make updated drivers... I have been sending bug reports / support requests to nVidia once a week for the last couple of months ... BUT NO ANSWER... :-( I have even requested nVidia developer account to get some attention, but so far... nothing ... (and the next question... if I get this account, how much of this info is legal to add to GPL software...) If the Mandrake user has only two choices to have reasonable 3D on Linux and both of them are buggy (screen corruptions, crashes etc.), it is a pretty sorry state of the affairs ... There is an other problem here that is very hard to address, and that is quality differencies in different manufacturers cards... Some people report that their Geforce4 screws up big time with some drivers, but for others they are the best drivers ever... Now there is no way for MDK to address this problem, as it should be adressed by nVidia, since they keeps the specs/driver source well guarded... ;-) We'll have to try to make the best of what we have, and hopefully nVidia will roll out new drivers for MDK 9.1 Thomas
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Some of theese problems may be because we have newer gcc/glibc, than the version ysed to compile the binary-only parts of nVidias drivers... This we can't do anything about... We just have to wait for nVidia to make updated drivers... I honestly do not think, that glibc could have affected that, since the drivers are in kernel space (no glibc is used there) and the GLX module does not use glibc neither, most probably. The difference is probably new kernel and/or new version of XFree - the drivers were made for version 4.2.x, we use 4.3.x now. I have been sending bug reports / support requests to nVidia once a week for the last couple of months ... BUT NO ANSWER... :-( Duh, sorry to hear that. Obviously, they do not give a damn about Linux users, since most gamers (their market) are Windows users. I have even requested nVidia developer account to get some attention, but so far... nothing ... (and the next question... if I get this account, how much of this info is legal to add to GPL software...) Hmm, unless they ask you to sign an NDA, that shouldn't be a problem. There is an other problem here that is very hard to address, and that is quality differencies in different manufacturers cards... That's true also. But why the cards work mostly well under windoze and not under Linux, with supposedly the same drivers (as NVidia claims) ? Something is fishy there, even when the quality differences between the cards are huge. Some people report that their Geforce4 screws up big time with some drivers, but for others they are the best drivers ever... E.g. with Mandrake 9.0, I couldn't even get the installer to work, since the frame buffer caused the machine to hang each time on this card. I had to install in the text mode. Then there are plenty of issues with OpenGL support, dual head setups and SMP with these. Since this kind of setup is not so common, the drivers are buggy. The only consolation in this case is, that the same setup has big problems even on Windows (screen corruptions, hangs etc.) Now there is no way for MDK to address this problem, as it should be adressed by nVidia, since they keeps the specs/driver source well guarded... ;-) Yes and no, IMHO. One thing is, to pressure nVidia to open their code (not going to happen any time soon), second thing is to pay a close attention to problems - if some change in the distro breaks rendering, I should have a look and try to fix the problem or revert the change, even if it means, that I will ship with older version of something or some feature off by default. The problem may be because of the Nvidia bug, but the user does not care about that and even worse if the software used to work OK before. Then Mandrake gets the blame for breaking it. And that is bad. We'll have to try to make the best of what we have, and hopefully nVidia will roll out new drivers for MDK 9.1 I hope for that too - the last release was horrid. I had to downgrade to a previous release to get rid of the problems. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z06hn11XseNj94gRAjljAJ4m1hZXeK4zKv6OAT1S9wFChfY9jQCcCtm0 fireTjIQNCXE+HYkBvlGiN0= =n5nw -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Timothy R. Butler [EMAIL PROTECTED] writes: Quite frankly, Mandrake 9.1 has a LOT of showstopper/serious bugs still. One long time Linux user I know who I sold on Mandrake 8.2, but couldn't get 9.0 to install on several machines, has already posted on another list that he is There are two kinds of bugs: hardware and software. People who can't install mostly experience hardware problems, and for this kind of problems we have little influence for fixing.. resigning himself to not upgrading to 9.1, because of all the problems he had with RC1. He quite resonably realized that nine days just isn't enough to fix Funny :). A guy who resign using a stable release only because the beta release contained bugs :). - Bug #2268: Every wheel mouse I try is not detected properly. This includes an IntelliMouse and a Logitech MX 700 (both using PS/2). We *cannot* detect PS/2 wheel mice. Now, this is what I ask. Mandrake, as I understand it, still has major financial problems (I think that goes without saying since it is still in bankruptcy protection). It may be that things should go better this year, but if Mandrake 9.1 comes out with all kinds of annoying and/or showstopper problems (like an SB Live! card being impossible to install), then it probably won't get good reviews or sell well. I would think a bad sales period for a distribution release right now could make creditors a lot less favorable about Mandrake's situation. Let it clear: we all want the most bug-free release possible. Though, there are several parameters in the equation: - by ourselves, we can't extensively test the distribution; hence, we need external testers: mostly people from cooker, and non-cooker people who test betas/rcs; this has limits because of mirror courtesy, mirroring time, and testers' motivation - we have little chance to fix hardware problems ourselves - when you go down fixing smaller and smaller software bugs: - developers's motivation decreases - you increase the probability to break larger things (because many things interact w/ each other), thus you still need to test all, and testing all needs time and motivation (both internal and external) - the distro becomes more and more outdated - not all bugs are important; people who experience bugs worry about it but sometimes they are nearly the only ones having it, and they not all deserve delaying a release - we provide updates -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Mandrake 9.1 Should be Delayed
Jan Ciger wrote: I have been sending bug reports / support requests to nVidia once a week for the last couple of months ... BUT NO ANSWER... :-( Duh, sorry to hear that. Obviously, they do not give a damn about Linux users, since most gamers (their market) are Windows users. I'm not a gamer, but I specifically bought a nvidia card because I read it was well supported under Linux. Now I don't really think so, won't get burnt by nvidia again. Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS or other RBL. They arbitrarily IP addresses not related in any way to spam, disrupting Internet connectivity. See http://slashdot.org/article.pl?sid=01/05/21/1944247 and http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html pgp0.pgp Description: PGP signature
Re: [Cooker] Mandrake 9.1 Should be Delayed
Jan Ciger [EMAIL PROTECTED] writes: I am pretty much green here, but I have to agree - let's push the release date few days. There are bugs, which are pretty bad/annoying and will earn pretty bad image to Mandrake. FYI we are still working. And while working, we happen to fix a few bugs.. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timothy R. Butler wrote: For instance, since he has an integrated AC97 sound card, Mandrake won't let his SB Live! work properly that has worked in every other GNU/Linux distro he has tried (including 8.2). Please file a bug. And have someone vote for it / confirm it. It will not be fixed unless it is know, even *if* release is delayed! My own bug list includes: - Bug #2107: Kio_smb/Kio_lan doesn not work, leaving Mandrake/KDE lagging behind Lycoris and Lindows for absolutely no reason. This functionality normally works... so it seems like something that should be investigated. kio_lan works for me, kio_smb does not work well. I confirmed your bug, since you had not marked it as new. If you care about your bugs, you *must* ensure they are confirmed ... - Bug #2793: This bug makes it so that if you accidentally type in an incorrect IP address in Scannerdrake's scanner sharing utility, that you can no longer get into scannerdrake. It just hangs waiting for a response from a non-existant IP address. Not confirmed, would you like to confirm it, and provide a config file (/etc/sane.d/saned.conf IIRC) and some debugging (such as getent hosts IP in file). - Bug #1859: For some unexplainable reason MandrakeSoft is not providing users with KDE screensavers beyond its basic one. Why? Why didn't anyone ask Club users? (most probably didn't vote for KDE-Artwork since you weren't suppose to need to vote for basic packages, and it seems pretty basic!) Not confirmed, and 12MB of junk is a lot of wasted space, we can fit a lot of really important things in that space. I feel your sentiment, but please, do your part to try and have your bugs fixed (ensure they are confirmed, otherwise developers may not have time to look at them, and the bug summary in bugzilla will look better than the distro really is). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2DdrJK6UGDSBKcRAj2uAJ9UicE0gp0xRdEy9ixW91+KgYhUrQCgv2Mb +c040MEzI4NPBaHYicEVADw= =av1I -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What about my laptop that I use for server testing and therefore have almost all servers installed, which I also use for multimedia purposes. I think it would be better to have mandrake just focus on getting 1 good distro out, instead of 3 or 4. Rather than have multiple sub distro's I like the idea of having one distro with all the options. The distrobution itself doesn't chose what I install, I do. If I want multimedia I install multimedia apps and kernels, if I want server I install server, but if I want both I don't have to mix and match from different CD sets, or go compiling. The reason I chose mandrake above all others is really nothing more than their excellenct choice of packages in the distro. The guys at Mandrake seem to package almost every title I use, and that saves me a lot of compile time. On Wednesday 05 March 2003 10:27 pm, Levi Ramsey wrote: On Wed, 5 Mar 2003, Andi Payn wrote: Provide, in addition to the 3-CD distribution, a mini version that provides just enough to get you up and running and install other packages. You could download, say, a 150MB ISO for English, or a 180MB ISO for some other language (if there were people interested in maintaining a mini-distro for that language), instead of 2GB with everything. You'd have a basic KDE desktop only, everything needed to get on a LAN or cable/DSL connection, all of the packaging tools, the core development packages, and some of the setup/configuration tools, but few applications, no servers, etc. I've thought of creating separate sub-distros for various uses. For instance, there could be a Mandrake Laptop Edition, with a kernel and pacakge set optimized for laptops (possibly with fewer servers), a Mandrake Multimedia Edition (for A/V work) with multimedia kernels by default and a selection of packages that would normally be in contribs in the main distro. Each of the 9.2 editions would be compatible (ie you could take a Standard Edition package and install it on a Laptop Edition install) and stem from the same Cooker process. Levi Ramsey [EMAIL PROTECTED] - -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBPmdfqxFHZPcobeHxAQJ95gQAoe9Ii7mB+DgVTWuM5NcGM9FssItOHUK9 QH6kVsm5B7jjJ7bSF8hHVl3sGhgqtEGN7zPd1LDWWu8qmZLL3sd58hpBj7L7geYg DA5aamhHmigZXfme+6nkOqkmqORSNGYQcaQ3yvBf31CY2z2f43OLXjz83uo9c17a eMX4LSn5nkg= =43IS -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Dorman wrote: Timothy R. Butler wrote: [Rant on] Whilst I am confident that the Mandrake developers can get this version pretty polished by the current release date, I do think that Tim has an important point with regards to calling these things release candidates. Clearly the current .iso's aren't release candidates, they are betas. Calling them release candidates seems to be a convenient way of getting more people to try out the distro and thus report bugs. Note here that you are saying people shouldn't be testing betas ... but The logic is sound (people avoid the betas, and flock to the rc's), but the message is very flawed. Reviewers report on release candidates. People get pissed off when they download almost 2 gigs of distro they can't use. I would like to propose two alternative approaches for future releases: 1. Tweak the beta program Keep the beta program running until there are basically no bug reports, ... WHERE DO THE BUG REPORTS COME FROM IF NO-ONE TESTS THE BETAS? There were very few bugs before rc1 was released. then shift to rcs, where only tweaks can be made (graphics, rcX - release package updates, etc.). Maybe you haven't been following, but after rc1, no package upgrades can be done in main without release manager approval (ie security fix). When the release candidate comes out, people should be able to test it on production machines (in the case of workstations), and on sandboxed servers. Why? Because they are /release candidates/ and not betas. Many people run cooker on production machines. rc1 is find on my laptop (after one or two tweaks). ***REWARD*** beta bug busters and reporters. With what? Why? Many of them get the distro for free, and fixing their bugs is in their own interest. And if bug reporters get rewards, what do the people who run cooker and maintain packages get? 2. What the hell is a distro anyhow? Why is it that companies like MandrakeSoft, RedHat, etc., are putting all this effort into syncronising the release of 3000 or so software packages at once?(!) Why not split the distro? Make a bunch of mini-distros which can be managed separately (Down to per-package level if desired)? So that all the packages actually work. One could be for the installer framework, one could be base libraries, one could be for the development stuff, one for servers, etc., etc. (ooh, I'm feeling nostalgic for my old Slackware days!). Have a management system which keeps the components for up to date over the 'net according to each user's preference. One that can configure and burn a custom set of iso's, ready to install like a regular distro (great for OEMS, or people maintaining different machines). Tell the system to prepare Joe-user's desktop distro and you get one CD, tell the system you want Mel's-multimedia-mayhem and out pops another. Even add processor-specific compiles to the mix! Each section would have it's own users working towards optimum stability, features and performance. That does not help in sycning packages, since all the packages still need to build on the same compiler, same libraries. Waiting a month to release a subset of packages does not help anyone. Surely something's got to change. Creating megalithic multi-CD distros is archaic and is going to get harder and harder. Lindows (Click'n'run), Ximian (RedCarpet), and others have worked it out, so why can't we? And *we* can do it with strong community participation! So, download network.img, and do a network install. Much more advanced than Lindows. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2KErJK6UGDSBKcRAnutAJ90wyou/2es0/qo475FQZj9CPkpLQCeMDEv 3BHUs4/OIaUqlmH1JSPoEPo= =6lji -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 06 March 2003 15:32, Guillaume Cottenceau wrote: Jan Ciger [EMAIL PROTECTED] writes: I am pretty much green here, but I have to agree - let's push the release date few days. There are bugs, which are pretty bad/annoying and will earn pretty bad image to Mandrake. FYI we are still working. And while working, we happen to fix a few bugs.. That's great and thanks for it. But do you *honestly* think, that huge amount of outstanding issues (even when focusing on the most critical, like crashes etc.) could be fixed and tested in one-week time ? Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z2Jnn11XseNj94gRAtD3AKCb0dTCW1RkVVoEc9/Hq/MIWOWMuQCgvTFx JxyQeWywXD8jL5Yogag4G/I= =nEau -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Payn wrote: Meanwhile, Paul Dorman's idea of sub-distributions is interesting, but I think there's a better solution: Provide, in addition to the 3-CD distribution, a mini version that provides just enough to get you up and running and install other packages. You could download, say, a 150MB ISO for English, or a 180MB ISO for some other language (if there were people interested in maintaining a mini-distro for that language), instead of 2GB with everything. You'd have a basic KDE desktop only, everything needed to get on a LAN or cable/DSL connection, all of the packaging tools, the core development packages, and some of the setup/configuration tools, but few applications, no servers, etc. Then, provide an easy way to pull in groups of packages. Each of the groups you can choose in the installer would be available, and would install the exact same packages--except that it would only have to download the appropriate language, and it would download the most up-to-date version, from the mirror you chose. Even simpler, you could allow running that tool as part of the installation process. An alternative solution is the way linuxppc used to work a few years back. You download and burn an 80MB ISO that contains the installer, which can grab packages off a mirror instead of off a CD. (In fact, I never even burned the CD; they provided MacOS-based and linux-based installer bootstraps so you could just leave the .iso file at the root of an HFS or ext2 partition; that was nifty.) Making this fool-proof is difficult, but making it work 95% is easy--and good enough for the intended audience: people who know Mandrake, know what they want, and have broadband connections. I think either would provide everything Paul's looking for, and be very easy to put together. In fact, making a mini-distro out of the full 9.1 is something a single user could easily do shortly after 9.1 is released. By the way, as things are today, you can just download CD 1, install a bare-minimum configuration, then rpmdrake/urpmi all the packages you want off the net. 650MB is still pretty big, but it's a lot less than 2GB. How about 1) instead you download just network.img, and either a)dd it to a floppy under linux b)put it on a floppy with rawrite in windows c)loopback mount the floppy to extract the kernel and initrd image, and use them in a new lilo entry 2)Boot the image of choice (floppy or lilo) 3)Do a standard network install. No need for special images etc. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2S6rJK6UGDSBKcRArW+AKCMh7PlpbncwVl/mC5kh7rH5Lb+ZgCgxzb6 o22T509LDGLW53xGwYRzPKg= =pFWM -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 N Smethurst wrote: Le Jeudi 6 Mars 2003 03:19, Greg Meyer a écrit : What do you think most of us are doing? The real problem seems to be that there just aren't enough Mandrake developers to address most bugs. Out of the 6 bug reports I have filed, none of them have moved from UNCONFIRMED. That is not a developer responsibility. If you want the bug fixed, ensure it gets confirmed. There's very little point in us trying to report even more bugs if the developers are so understaffed that they cannot keep up with even a fraction of the bugs being reported at the moment. The only short term solution would be to give them more time to address the more critical bugs. There is little point in a developer looking at a bug if it is not confirmed, if he has many other confirmed bugs. If no-one has confirmed your bug, post on cooker asking if it affects anyone else. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2c4rJK6UGDSBKcRAoCNAJ4j/kpb0Q7zjTb8KcDQAQpESI4YqACfXICS 7To1uLcylkvwBWycxZVkoUk= =JEKt -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
What do you think most of us are doing? The real problem seems to be that there just aren't enough Mandrake developers to address most bugs. Out of the 6 bug reports I have filed, none of them have moved from UNCONFIRMED. Some of these bugs are not critical, but others, such as the mess 9.1RC1 made of trying to configure the Sagem ADSL modem are very important. (This is the modem that everyone in France on free.fr uses for adsl. One would have thought it was kind of important for a French distribution to make sure their French customers on adsl can actually connect to the internet.) I had one person e-mail me about the SAGEM modem, but I haven't seen any bug report, nor does bugzilla report anything on a seach for sagem. Can you provide me with the bug number?
Re: [Cooker] Mandrake 9.1 Should be Delayed
On 2003.03.05 23:35 Leon Brooks wrote: An awful lot of people, despite a very long lead time and plenty of notice, suddenly leapt out of the woodwork in the last week crying `oh, bugger, a release candidate!' and waving their pet bug or update. Would have been a lot more effective two weeks ago. It's because 90% of the bug reporters ONLY install linux from ISO's. We should teach them about urpmi and/or network installs. Austin -- Austin Acton Hon.B.Sc. Synthetic Organic Chemist, Teaching Assistant Department of Chemistry, York University, Toronto MandrakeClub Volunteer (www.mandrakeclub.com) homepage: www.groundstate.ca
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lissimore wrote: Yes more bugs are being reported. But also keep in mind the bugs that were reported, and nothing done about them. So they get reported again...and...again...and again. People should *search* bugzilla before reporting again ... ( e.g. The SMP kernel installer bug was reported back in beta1 (Bug 1553) then again (bug 1823), then again (bug 2101), and then again (bug 2218). ) So, why did the reporters not search first? So it's not a simple mater of people crawling out of the woodwork... some bloody bugs get reported, and then not worked on for a long time (or even declared as verified on bugzilla). Instead of making a duplicate bug, users should *vote for* or *confirm* the existing entries! The current cooker is no where near release quality right now. And I think this is in part due to the sheer number of apps that get bundled into the distro. And partly due to people not using bugzilla correctly. - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2aHrJK6UGDSBKcRAhAKAJ9H5lWsHDYpzhAHLUApOFMIT6C41ACePxPL 7072hv0fjza/k1l8F/JO0L4= =XNgA -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 9:17 am, Buchan Milne wrote: Lissimore wrote: Yes more bugs are being reported. But also keep in mind the bugs that were reported, and nothing done about them. So they get reported again...and...again...and again. People should *search* bugzilla before reporting again ... ( e.g. The SMP kernel installer bug was reported back in beta1 (Bug 1553) then again (bug 1823), then again (bug 2101), and then again (bug 2218). ) So, why did the reporters not search first? So it's not a simple mater of people crawling out of the woodwork... some bloody bugs get reported, and then not worked on for a long time (or even declared as verified on bugzilla). Instead of making a duplicate bug, users should *vote for* or *confirm* the existing entries! It is a bit hard to confirm bugs if you only have 1 vote per component. I have tried to vote for a ton of bugs but can not because of the one vote limit. The current cooker is no where near release quality right now. And I think this is in part due to the sheer number of apps that get bundled into the distro. And partly due to people not using bugzilla correctly. This is partly caused by restrictive bugzilla settings. See above. -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 2003-03-06 at 02:19, Greg Meyer wrote: I have followed Cooker for 4 releases now, 8.1, 8.2, 9.0 and now 9.1. The first two, I pretty much lurked and just tried to learn about the bug reporting and development process, and also pick up some tips for how to deal with some technical issues for final. 9.0 I got a little more courage to try and contribute some bug reports, and this time I have been actively testing and reporting and at this point interacting with the main development staff and contributors (I hope to positive result). If I may make an observation based on my experiences to date. Every single release, as it gets closer to release time, someone makes a post like this and then everybody piles on. You'll notice that none of the Mandrakians or core contributors ever take part in it. Why, because they are busy trying to find the bugs and squash them before the release has to go gold. My understanding is that there are contractual requirements for hitting the release date. From the publisher of the boxes, to the retailer and wholsalers that ordered boxes. Not to mention this time, the financial issues that present themselves this year. And for the last release at least - and, it seems, this one - they've been absolutely right. In addition to numerous other bugs, 9.0 shipped with a critical kernel bug that broke access to many people's CD-ROM drives. You surely can't think this was a good idea? If the problem is contractual obligations, perhaps the 9.0 experience ought to indicate that such contracts should not be made. Example from 9.0 http://marc.theaimsgroup.com/?l=mandrake-cookerm=103264057205311w=2 I remember the thread. It highlighted the fact that 9.0 was in danger of being released with a number of bugs that would infuriate users and reviewers and lead to a negative impression of 9.0. This is exactly what happened. -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 2003-03-06 at 12:47, Thomas Backlund wrote: I have even requested nVidia developer account to get some attention, but so far... nothing ... (and the next question... if I get this account, how much of this info is legal to add to GPL software...) There'll presumably be an agreement you have to agree to in order to get your account. Read it *VERY CAREFULLY*, particularly the bits about disclosure. This will be the relevant thing, I'd guess. -- adamw
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Austin wrote: On 2003.03.05 23:35 Leon Brooks wrote: An awful lot of people, despite a very long lead time and plenty of notice, suddenly leapt out of the woodwork in the last week crying `oh, bugger, a release candidate!' and waving their pet bug or update. Would have been a lot more effective two weeks ago. It's because 90% of the bug reporters ONLY install linux from ISO's. We should teach them about urpmi and/or network installs. IIRC there were beta ISOs more than two weeks ago ... - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2yyrJK6UGDSBKcRAuHpAKC2sEBXEHTECGL+9g8D0J/YeGvVFgCfdHtJ FqwMsFyw/bz3xPLrxwOX1yg= =z1gS -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon Brooks wrote: On Thursday 06 March 2003 06:34 am, Todd Lyons wrote: Paul Dorman wrote on Thu, Mar 06, 2003 at 11:17:54AM +1300 : Surely something's got to change. Creating megalithic multi-CD distros is archaic and is going to get harder and harder. Lindows (Click'n'run), Ximian (RedCarpet), and others have worked it out, so why can't we? And *we* can do it with strong community participation! You're assuming that everybody has broadband. Mandrake has to cater _some_ to those that don't have that kind of access. True. But there doesn't seem to be *any* serious attempt to allow for doing things the Ximian/Debian way. Huh? urpmi.addmedia ? dd if=network.img of=/dev/fd0 ? Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2VTrJK6UGDSBKcRAroVAJ9Ej5ujRe/91sW0ofYfQkD0e65z8ACffi0M ozWuFEALd5zdREanT2UXt5c= =vMH4 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
and don't forget urpmi.setup :) - Original Message - From: Buchan Milne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 4:12 PM Subject: Re: [Cooker] Mandrake 9.1 Should be Delayed -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon Brooks wrote: On Thursday 06 March 2003 06:34 am, Todd Lyons wrote: Paul Dorman wrote on Thu, Mar 06, 2003 at 11:17:54AM +1300 : Surely something's got to change. Creating megalithic multi-CD distros is archaic and is going to get harder and harder. Lindows (Click'n'run), Ximian (RedCarpet), and others have worked it out, so why can't we? And *we* can do it with strong community participation! You're assuming that everybody has broadband. Mandrake has to cater _some_ to those that don't have that kind of access. True. But there doesn't seem to be *any* serious attempt to allow for doing things the Ximian/Debian way. Huh? urpmi.addmedia ? dd if=network.img of=/dev/fd0 ? Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2VTrJK6UGDSBKcRAroVAJ9Ej5ujRe/91sW0ofYfQkD0e65z8ACffi0M ozWuFEALd5zdREanT2UXt5c= =vMH4 -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Jan Ciger [EMAIL PROTECTED] writes: On Thursday 06 March 2003 15:32, Guillaume Cottenceau wrote: Jan Ciger [EMAIL PROTECTED] writes: I am pretty much green here, but I have to agree - let's push the release date few days. There are bugs, which are pretty bad/annoying and will earn pretty bad image to Mandrake. FYI we are still working. And while working, we happen to fix a few bugs.. That's great and thanks for it. But do you *honestly* think, that huge amount of outstanding issues (even when focusing on the most critical, like crashes etc.) could be fixed and tested in one-week time ? Well yes I think we have enough time compared with the remaining real outstanding issues there is. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Mandrake 9.1 Should be Delayed
That makes sense. In science they say that gases expand to fill any available space. Since the advent of office computing, it's been said that work always expands to fill any available time. You can take that one step further and say that software bugs always expand to fill any available time. Miark On Thu, 06 Mar 2003 10:56:50 +0100 Thierry Vignaud [EMAIL PROTECTED] wrote: we've to release one day. having a fixed date force you to fix bugs. you've to understand that there'll always be some bugs. increasing this process will only make you adding more bugs while fixing other one (yes this do happen). with a fixed date, you've to fix most bugs before. then, while books are printed and boxes and cds are produced, you can prepare updates. just my 2cents.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 15:22, Austin wrote: On 2003.03.05 23:35 Leon Brooks wrote: An awful lot of people, despite a very long lead time and plenty of notice, suddenly leapt out of the woodwork in the last week crying `oh, bugger, a release candidate!' and waving their pet bug or update. Would have been a lot more effective two weeks ago. It's because 90% of the bug reporters ONLY install linux from ISO's. We should teach them about urpmi and/or network installs. Austin How about having people sign up as official beta testers. These people would have to conform to certain criteria. 1) Have at least one spare box/hard disk to do test installs 2) Agree to do previous version upgrades 3) Agree to do full installs 4) Agree to do partial updates to see if bugs are fixed (followed by a complete install to see if that works also) 5) List the specs of the machines used, including manufacturer info, this can be stored in a database by Mandrake which can then be accessed by the masses. 6) Lots of other things I have not thought of. We could all then see how many *REAL* beta testers there are, and what areas specifically they test? Optional extra criteria 1) Multiple spare boxes 2) Lots of different hardware -- John Allen, Email: mailto:[EMAIL PROTECTED] MandrakeClub Silver Member.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That's great and thanks for it. But do you *honestly* think, that huge amount of outstanding issues (even when focusing on the most critical, like crashes etc.) could be fixed and tested in one-week time ? Well yes I think we have enough time compared with the remaining real outstanding issues there is. OK, good luck then. I am glad to hear this. But I am reasonably skeptical, judging from my own software development experience. Looking forward for the release :-) Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z3A9n11XseNj94gRAoPrAJsFyIn8QRSdX9JEeQlhr+Ouom/I1gCgsf4d tqbei2aMJXwOWY+bg0vARP4= =dpCG -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, 06 Mar 2003 14:57:25 +0100 Luca Olivetti [EMAIL PROTECTED] wrote: I'm not a gamer, but I specifically bought a nvidia card because I read it was well supported under Linux. Now I don't really think so, won't get burnt by nvidia again. nVidia _is_ well supported. Have you ever looked at nVidia's page of drivers? nVidia isn't obligated to do anything for the Linux community, but they have released many versions of their drivers. And instead of just posting a tarball, they've made release-specific RPMs for dozens of set-ups, including all the stock kernels of Mandrake's last four releases. I'm not in the habit of defending nVidia--believe me--but you ought to be a little more thankful for what you've got and quit talking nonsense. What do you think you'll switch to? Miark
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne [EMAIL PROTECTED] writes: What do you think most of us are doing? The real problem seems to be that there just aren't enough Mandrake developers to address most bugs. Out of the 6 bug reports I have filed, none of them have moved from UNCONFIRMED. That is not a developer responsibility. If you want the bug fixed, ensure it gets confirmed. Well that depends. Most non-kernel and non-install bugs are looked at even in unconfirmed state - most of them are real and fixable. For kernel problems, first we lack kernel resources, second it's nearly impossible to fix or workaround if we don't have the same hardware here, third even if we have it there are a large number of them for which the ratio between importance and available resource is not good. For install problems, many of them are duplicate: some we set as duplicate, some we ignore; many don't provide enough information, some of them we ask info some we ignore because we suppose it would cost too much time to get the information; many are non important or design issues, we don't have time to explain each and every minor/design point; many of them are already fixed. I know this is frustrating for reporters to get ignored, but as for the aim of bugzilla, e.g. track fix bugs, it's now in a state where it's really usable and helping us much to fix bugs. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
