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 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
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
-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
-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
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
[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 <[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 drak, ... 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
-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
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
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
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
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 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
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
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
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
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
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
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
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 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
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
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
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
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
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 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 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 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 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
> > 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
-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
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
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
-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 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
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
-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
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
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
-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
-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 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 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
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
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 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: > 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
-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 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
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 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > George Staikos has addressed that on the KDE3.1.1 branch. > See: > http://lists.kde.org/?l=kde-cvs&m=104701980622556&w=2 > http://lists.kde.org/?l=kde-cvs&m=104701957322386&w=2 > http://lists.kde.org/?l=kde-cvs&m=104702055522978&w=2 > http://lists.kde.org/?l=kde-cvs&m=104702343924965&w=2 > http://lists.kde.org/?l=kde-cvs&m=104702353725032&w=2 > http://lists.kde.org/?l=kde-cvs&m=104702676927501&w=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 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
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
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
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
> 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-cvs&m=104701980622556&w=2 http://lists.kde.org/?l=kde-cvs&m=104701957322386&w=2 http://lists.kde.org/?l=kde-cvs&m=104702055522978&w=2 http://lists.kde.org/?l=kde-cvs&m=104702343924965&w=2 http://lists.kde.org/?l=kde-cvs&m=104702353725032&w=2 http://lists.kde.org/?l=kde-cvs&m=104702676927501&w=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
-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
-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
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
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
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
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? 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* > > > 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
Andi Payn wrote: And no development project can stay in "release mode" all the time, without separate branches for blue-sky/experimental/unstable work. So really, you'd need to split Mandrake development into three branches instead of two: 9.1 upgrades, a mostly-stable "pre-9.2" Cooker, and a like-today's-Cooker "experimental" branch, with solid QA on both of the first two branches. In fact, the first two could share much of the same team: close to a release, both would be working primarily on getting 9.2 ready to go out the door, while shortly after a release, both would be working on figuring out what can be hammered into 9.2 as an update and what has to wait for the future. And this does in fact work for some other projects (including Debian, I believe). But still, it would require more Mandrake resources, and more user involvement, than the current system. And, while you would probably attract new people to the Cooker effort if it were a more stable system, you'd also find that many of the people who help today would prefer to work on the blue-sky branch. 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. But I'm not sure the system really needs to change. Is it really working that badly? The consensus on this list seems to be that there are major problems with the releases. And, to be honest, people I know who've been using Mandrake for a long time complain that each release is worse than the last. But people I know who've switched from other linux distros, or from Windows, have mostly been happy with the stability of Mandrake 9.0. (True, people who came from MacOS or BSD had lots of complaints, but you can't make those people happy) This is good. enormous task of managing a distribution might be made more effective. I don't think that the kinds of issues discussed in this current thread are likely to be resolved with the current system, which is likely to become harder and harder as development gets faster and faster. It will come to pass that some projects will go through several version changes in the time it takes to get the iso's out the door. Some projects are almost at that point now.> Red light : non-stable/non-functioning - developers and packagers only Orange light: testing. Will work on increasing majority of machines over an increasingly long time period Green light: installs and functions on all systems with Green light packages installed. Within each there could be directories containing binaries for the major architecture flavours, and source. Storage and bandwidth will eventually become cheap enough to make this feasible. 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. Bug reports could be communicated through the same networks, accumulating in number and providing an automated statistical basis for prioritizing developer attention, and directing to developers possessing the right hardware. Using the same p2p networks, developers, bug reporters and users could discuss whatever affects or interests them and coordinate their activities. 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. What MandrakeSoft and the Cooker community do is extremely impressive. It's the biggest and most complex kind of open source project there is. Peole's imaginations should be hard at work here, exploring how the advantages presented by all those connected with this distro can be leveraged to improve things for the community as a whole. This is free/open source software after all! Well, that's about it. Apologies if this is of no interest to people - seems that this is a reasonable forum to raise these kinds of issues. Ciao, Paul.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > But I still think that the current Cooker system is actually useful. I have > a Cooker-based workstation that's stable enough to rely on for all of my > daily work. I have a server that I wouldn't put even a "stable Cooker" > release on. I don't really have much need for something in between. I think the nice thing about a middle ground is that it serves to prevent buggy stuff from getting mixed in with an almost stable release. By the time stuff is able to get into "testing" you really don't have many showstoppers or major annoyances. Really to a point, this style of development guarantees that the distribution in testing is "almost ready" for release whenever you need it to be. It also allows unstable stuff to continue to be integrated even while you are preparing a release. I think the existing Cooker works well, but that might be something worth considering in the future. > According to the headers, you're using kmail 1.5, which I don't remember > being the version in 9.0. If you're already using Cooker for your daily > email use, doesn't that say something? (And if I'm wrong, please feel free > to call me an idiot) Actually, I am running 9.0, although I do have a cooker partition. This install is 9.0 running a late december cooker kernel (since I needed a newer kernel to use DMA with my motherboard) and KDE 3.1 RC5 (call me lazy... I haven't bothered upgrading since final came out). -Tim - -- - Timothy R. Butler[EMAIL PROTECTED] Universal Networks http://www.uninet.info Christian Portal and Search Tool: http://www.faithtree.com Enterprise Open Source Journal: http://www.ofb.biz -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+aCc6K37Cns9gJ0gRArTAAJ9EJk0uHBspMyuGXmv+aC3J3r6ykQCbBrrP nGh3/KQv46lWwV1oHanbOK0= =vV0x -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 19:16, 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. I guess I should have waited a few more minutes before replying, because you stated this alternative much more clearly and succintly than I did But I still think that the current Cooker system is actually useful. I have a Cooker-based workstation that's stable enough to rely on for all of my daily work. I have a server that I wouldn't put even a "stable Cooker" release on. I don't really have much need for something in between. It may be that I'm an anomaly, and many people would use that intermediate distribution; if so, it would probably be worth the extra effort to migrate to a three-tier approach. If not, it would be extra expense that may not buy anything useful. > That might allow more people to run Cooker "testing" even on production > systems, as they would know while there might be bugs, it generally > wouldn't ever be just plain broken. In such a situation, I'd probably opt > for testing over the stable release. According to the headers, you're using kmail 1.5, which I don't remember being the version in 9.0. If you're already using Cooker for your daily email use, doesn't that say something? (And if I'm wrong, please feel free to call me an idiot)
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 19:08, George Mitchell wrote: > Andi, there is a solution to this problem. That is to maintain a stable > version of cooker. Do the actual work of upgrading and fixing various > components offline, and merge them into the stable cooker tree only when > they have been thoroughly tested. In the mean time continually use > bugzilla to QA the stable cooker tree itself. As it is, cooker is a > collection of a gazillion efforts all attempting to take place > simultaneously on the same codebase, and all attempting (or forced) to > come to maturity at the same time. And even though the software is > modular, there are cases where a problem with one component can > jeoperdize a timely fix for another. The various efforts need to be > delinked and individually debugged on a stable cooker. The existance of > a stable thoroughly QA'd cooker would mean that Mandrake could pull the > cord for a release at any time without risk of unforseen headaches. Cooker the way it works today--a not-quite-stable, not-quite-integrated repository of version upgrades and new packages that may get into a future version of Mandrake--is one of the major advantages of Mandrake over the other linux distros. I wouldn't want it eliminated. I like the fact that I can usually get a Mandrakized package of the latest version of XXX quickly after it's released, and usually it works--even though occasionally there are problems. The fact that I can't get that with any other distro is a big part of the reason that I use Mandrake. And no development project can stay in "release mode" all the time, without separate branches for blue-sky/experimental/unstable work. So really, you'd need to split Mandrake development into three branches instead of two: 9.1 upgrades, a mostly-stable "pre-9.2" Cooker, and a like-today's-Cooker "experimental" branch, with solid QA on both of the first two branches. In fact, the first two could share much of the same team: close to a release, both would be working primarily on getting 9.2 ready to go out the door, while shortly after a release, both would be working on figuring out what can be hammered into 9.2 as an update and what has to wait for the future. And this does in fact work for some other projects (including Debian, I believe). But still, it would require more Mandrake resources, and more user involvement, than the current system. And, while you would probably attract new people to the Cooker effort if it were a more stable system, you'd also find that many of the people who help today would prefer to work on the blue-sky branch. 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. But I'm not sure the system really needs to change. Is it really working that badly? The consensus on this list seems to be that there are major problems with the releases. And, to be honest, people I know who've been using Mandrake for a long time complain that each release is worse than the last. But people I know who've switched from other linux distros, or from Windows, have mostly been happy with the stability of Mandrake 9.0. (True, people who came from MacOS or BSD had lots of complaints, but you can't make those people happy)
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Andi, there is a solution to this problem. That is to maintain a stable > version of cooker. Do the actual work of upgrading and fixing various 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. That might allow more people to run Cooker "testing" even on production systems, as they would know while there might be bugs, it generally wouldn't ever be just plain broken. In such a situation, I'd probably opt for testing over the stable release. -Tim - -- - Timothy R. Butler[EMAIL PROTECTED] Universal Networks http://www.uninet.info Christian Portal and Search Tool: http://www.faithtree.com Enterprise Open Source Journal: http://www.ofb.biz -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+aA8IK37Cns9gJ0gRAjsbAJ9CVNPAIv9fvzbgh4iI5mvW4JCYBQCcC5Eo yqwPC7pYAUCFjh/i9KPSq+8= =8YM+ -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
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). Plus, this means that the releases that people buy on the shelves would no longer be up-to-date. Part of the reason that people choose Mandrake over, say, Redhat is that Mandrake usually has state-of-the-art packages. To people who switch from other distros, this is a huge difference. A friend of mine once asked, "Why should I bother upgrading to the new version of Redhat if I'll still have to install gcc and KDE myself to get recent versions?" I was able to point to Mandrake and say, "Look, they have them. Why not switch?" He did. To people who switch from Windows, this may not seem like as big a deal--but it still makes a difference. For example, part of the reason that Mandrake 9.0 looked good to Windows users than the other distros was KDE3, and part of the reason it worked well for them was konqueror/galeon, evolution/kmail, and the various office packages--all of which had only recently become good enough to sell a Windows user. In other words, Mandrake can't afford to have major releases that are two months out of date. But they can't avoid this unless they pre-schedule their releases and sign these kinds of contracts. Of course some companies sign even larger contracts and start even larger advertising campaigns and then slip releases by months, anyway (Windows 97, anyone? Rhapsody 1.0?). But most companies can't afford to pay two or three times for each release, keep the release-time ad blitz up for months on end, and fight the bad PR. Apple can just barely get away with it; Mandrake certainly couldn't. The way that software is released today stinks. It's bad for Mandrake--but it's also bad for Microsoft and Apple and Redhat, and for Symantec and Microprose and Adobe. Mandrake refusing to play by the same rules would not affect the system, it would only hurt Mandrake. Andi, there is a solution to this problem. That is to maintain a stable version of cooker. Do the actual work of upgrading and fixing various components offline, and merge them into the stable cooker tree only when they have been thoroughly tested. In the mean time continually use bugzilla to QA the stable cooker tree itself. As it is, cooker is a collection of a gazillion efforts all attempting to take place simultaneously on the same codebase, and all attempting (or forced) to come to maturity at the same time. And even though the software is modular, there are cases where a problem with one component can jeoperdize a timely fix for another. The various efforts need to be delinked and individually debugged on a stable cooker. The existance of a stable thoroughly QA'd cooker would mean that Mandrake could pull the cord for a release at any time without risk of unforseen headaches.
Re: [Cooker] Mandrake 9.1 Should be Delayed
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). Plus, this means that the releases that people buy on the shelves would no longer be up-to-date. Part of the reason that people choose Mandrake over, say, Redhat is that Mandrake usually has state-of-the-art packages. To people who switch from other distros, this is a huge difference. A friend of mine once asked, "Why should I bother upgrading to the new version of Redhat if I'll still have to install gcc and KDE myself to get recent versions?" I was able to point to Mandrake and say, "Look, they have them. Why not switch?" He did. To people who switch from Windows, this may not seem like as big a deal--but it still makes a difference. For example, part of the reason that Mandrake 9.0 looked good to Windows users than the other distros was KDE3, and part of the reason it worked well for them was konqueror/galeon, evolution/kmail, and the various office packages--all of which had only recently become good enough to sell a Windows user. In other words, Mandrake can't afford to have major releases that are two months out of date. But they can't avoid this unless they pre-schedule their releases and sign these kinds of contracts. Of course some companies sign even larger contracts and start even larger advertising campaigns and then slip releases by months, anyway (Windows 97, anyone? Rhapsody 1.0?). But most companies can't afford to pay two or three times for each release, keep the release-time ad blitz up for months on end, and fight the bad PR. Apple can just barely get away with it; Mandrake certainly couldn't. The way that software is released today stinks. It's bad for Mandrake--but it's also bad for Microsoft and Apple and Redhat, and for Symantec and Microprose and Adobe. Mandrake refusing to play by the same rules would not affect the system, it would only hurt Mandrake.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Guillaume Cottenceau wrote: 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.. So when, for example, I have problems on install with my Radeon 7500 (as in 9.0), is that a hardware or software bug? There are a large number of problems at installation that could be described as hardware bugs (problems with PDC and HPT controllers are other examples), but as other distros have found ways of dealing with the idiosyncracies of the hardware, should you count them as hardware or software bugs? I would have thought that the only bugs that are exclusively hardware are ones where all distros (and Windows) suffer from similar problems. Otherwise it is a question of how the software supports the hardware. Of course, you may not have access to the information you need to make the hardware work (although looking at other distros that have figured it out would be a good start), but that doesn't stop the problem being, at least partially, a software problem. Funny :). A guy who resign using a stable release only because the beta release contained bugs :). I agree that this is not ideal, but as every system I had was screwed up in some way by 9.0 (and the final release screwed up worse than the RCs and betas), I can understand why someone would look at another potentially bug-ridden release and decide not to touch it for a while. Personally, I'll probably take the gamble (after all, how much worse can it be than 9.0?), but I can understand why others wouldn't. We *cannot* detect PS/2 wheel mice. I have the Belkin KVM + wheelmouse problem. The simple workaround is to Ctrl-Alt-F1 to a console and then Alt-F7 back to X, after which the wheelmouse works again. I can't remember where I saw it, but I read about a program someone had written to mimic the effect this had, which you could launch from a keyboard shortcut to correct the problem. It would be a nice little add-in for Mandrake to help with this problem. 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 Exactly. And you need not just a couple of dozen active Cooker testers, but 100s or 1000s of less active and more ignorant testers. Which means allowing plenty of time for bug-testing, because most of your users will not remotely have time to keep up with the pace being set. - we have little chance to fix hardware problems ourselves So you need as many people as possible to beta-test the release, to catch as many hardware combinations as possible. And then you will need plenty of tolerance and patience with the bug-reports that will come in with incomplete, inconcise information, because if you want to spread your net widely, you will have to expect that many people testing the system will not be experts. - when you go down fixing smaller and smaller software bugs: - developers's motivation decreases I have every sympathy with the difficult position that Mandrake developers are in, but I have no sympathy with an attitude that dealing with the details is somehow beneath developers paid to do exactly that. The devil is in the details. If developers don't have the motivation to fix small problems, they are in the wrong job. - 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) Don't fix small bugs because you might break something bigger??? Try repeating that to yourself a few times and then ask yourself if that really sound like a strong argument. - the distro becomes more and more outdated It has always been a big part of Mandrake's appeal that it is "cutting edge", so I think this is your strongest argument for as short a testing period as possible. However, if you go back to the 7.x releases, Mandrake managed to combine being "cutting edge" with stability and the widest hardware support. Things have been going downhill since then, presumably partly due to the diversion of resources during the old management's interregnum. But it seems to me that there was also a change of philosophy after 7.x, where stability and wide hardware support were given steadily less and less prominence. The supermount saga of the 8.x releases was a warning (it should never have been enabled by default until it had been tested thoroughly), and 9.0 was the culmination of this philosophy - advanced but bug-ridden. 9.1 and 9.2 need to take a step back in the other direction by ironing out as many wrinkles as possible, not carr
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 08:33, Austin wrote: > On 2003.03.06 10:43 Buchan Milne wrote: > > IIRC there were beta ISOs more than two weeks ago ... > > True. But my point was that I'm sure some people download a beta, > report a bug, and then wait for the next beta to see if it's fixed. > They could just as easily (and more efficiently) keep their initial > install up-to-date with urpmi, and track their bugs every few days. > > It just seems to me that people are really stuck in the idea of ISO's > because they've never known otherwise. And there's not much that Mandrake can do about this. The reality is, Mandrake is ahead of the pack. In fact, a large part of the reason that I chose Mandrake--and a large part of the reason I was and have been happy with my choice--was because I could install 8.0, then immediately start updating packages much more easily than with Redhat, SUSE, etc. In other words, the current system, especially the way Cooker is managed, works better than anyone else's. But, at the same time, because Mandrake does such a good job attracting Windows users--people who are used to getting Microsoft's new release every 3 years, and then only minor patches until the next one--many Mandrake users have long-standing bad habits; they don't understand that when people "release early and release often," the monolithic release that you buy in a store or download as a set of ISOs isn't the whole story. In other words, it's hard to leverage large numbers of Windows converts into a large pool of useful linux bug testers, but certainly the distro (and the company) is better off with them than without them.
Re: [Cooker] Mandrake 9.1 Should be Delayed
Jan Ciger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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. 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. > - - when previews are enabled, icons are changing positions all the time - > you have to "Align to grid" *twice* to get them aligned and any change > (e.g. emptying the Trash) changes the positions again. I had to switch the > previews off, to get a clean-looking desktop :-( Same problem occurs in > inside folders from time to time (e.g. when copying files) 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? ;-) )
Re: [Cooker] Mandrake 9.1 Should be Delayed
> 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 take Mandrake 9.1 wouldn't be shipping xscreensaver and gnome-themes as well?
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 04:47, Thomas Backlund wrote: > 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 I agree. This "sorry state of affairs" is more a reflection on nVidia. Their drivers are clearly more fragile than they'd like us to believe. They're attempting to prove that their closed driver model provides at least as good results as open source driver development, and the only conclusions that the linux community can draw are that (a) they're wrong, and it can't be done, or (b) they're right, and it's possible, but they're not very good at driver development. Hopefully the end result will be a lessening of the pro-nVidia slant of the linux community, leaving room for someone else to come in and try to do it better. It should be much easier for someone at ATI, Matrox, or some other company to get more resources for linux development if it becomes obvious that nVidia's position isn't as strong as they pretend.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, Mar 06, 2003 at 10:14:54PM +0100, Danny Tholen wrote: > 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. I've tried many times to get changes put into place to *DECREASE* the volume of this list. We really ought to be using Bugzilla to get the right comments to the right people and save everyone else from getting them. Mandrake staff seem to be content reading a 1000 emails a day or at least hitting delete on 90% of them that don't relate to them... -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "America does not go abroad in search of monsters to destroy. She is the well-wisher to the freedom and independence of all. She is the champion only of her own." -- John Quincy Adams, July 4th, 1821
Re: [Cooker] Mandrake 9.1 Should be Delayed
On 2003.03.06 16:14 Danny Tholen wrote: 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 yourself) are very cooperative. This shows. There are components of the distro which are buggy only (IMO) because of this fact. Danny makes a really good point here. I've been calling you guys IgnoreDrake for a long time, because I used to get less than half of my emails answered. Things are better now because I know who/how/what to ask, but it's VERY annoying and inhibiting for a newbie to get totally ignored by the people he's trying to help. Current solution: "We can't answer 1000 email a day." Better solution: Give people more information so they don't have to ask questions. If the info is already there, make it clearer how to find it. Last Resort: Give volunteers more organizational/official power OR appoint an empoyee exclusively to organize volunteer work (Lenny currently does a lot more than that). Or something similar. Just my 2 cents. 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
On Thu, Mar 06, 2003 at 09:28:55PM +0200, Buchan Milne wrote: > Jan Ciger wrote: > > Similar thing was asked already - how ? It is not written anywhere and an > > "outsider" has no way to know it. I support the idea of the HOWTO > > mentioned in other threads, that could help a lot. > > It was somewhere in bugzilla but I could not find it now with a quick look. Warly mentioned it in an email to the list. I don't think he really meant for people to "apply" for it. I think it's given based on history of contributions. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "America does not go abroad in search of monsters to destroy. She is the well-wisher to the freedom and independence of all. She is the champion only of her own." -- John Quincy Adams, July 4th, 1821
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, Mar 06, 2003 at 11:08:54AM -0500, Levi Ramsey wrote: > The various editions would be nothing more than subsets of the whole > shebang, so to speak. Hell, most mirrors would carry, between main and > contribs, everything. The separate editions would only be different CD > images and different hdlists (if you chose to do a net-install). It would > be easy to place packages from the same generation of contribs or main > onto a custom CD image (with a custom hdlist). These would not be > separate distros, per se, merely subsets of a super-distro. You could > pick the sub-distro that best fits your basic needs and then add stuff > from the common pool to flesh out what you need. These would all be from > the same Cooker... Great more ISO images wasting more space. I really like what Debian is doing with Jigsaw Downloader: http://www.debian.org/CD/jigdo-cd/ Using something like that could eliminate the ISO images on the mirrors entirely and would make sub-distros like you suggest more realistic. But until Mandrake adopts something like this there is no way you'll get ISO images for these sub distros. The mirrors will likely just not carry them. As it stands now to carry 9.0 you end up with two copies between the expanded files and the ISOs. Your suggestion would create 4,5, maybe 6 copies of the same data... Ick. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "America does not go abroad in search of monsters to destroy. She is the well-wisher to the freedom and independence of all. She is the champion only of her own." -- John Quincy Adams, July 4th, 1821
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thu, Mar 06, 2003 at 10:43:03PM +0200, Buchan Milne wrote: > Timothy R. Butler wrote: > > How is it determined when people receive "edit_bug"? It sounds like > > a lot of regulars here don't have it... > > That is another of the mysteries of Mandrake development ;-). > > You are supposed to send a mail to an address @mandrakesoft.com (qa?), > with something like "canpostabug" in the subject. > > A search through my mail did not turn up the one I sent, only > confirmation of me being added to the group, so don't spam the address > now with bogus attempts ;-). Warly just sent me an email. Everyone who is a maintainer should have gotten edit_bugs without asking. As far as I know there is not automated process for this. It's like a lot of things. Given out on an individual bases... -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "America does not go abroad in search of monsters to destroy. She is the well-wisher to the freedom and independence of all. She is the champion only of her own." -- John Quincy Adams, July 4th, 1821
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Wed, Mar 05, 2003 at 09:24:33PM -0600, Timothy R. Butler wrote: > If Microsoft's late *betas* had this many problems, they'd get bad > press all over the place. You've obviously never participated in a Microsoft beta. a) They do have lots of problems. Lots of hardware = Lots of hard to track down problem. b) They get these same sort of discussions going on the beta newsgroups. c) Their beta testers sign NDAs so Microsoft can sue them into silence... Not to mention if you yap you don't get invited back again. People will never all agree that a product is ready to ship. I have some personal disagreements with some of the software that is included. But really. Can we check the Microsoft comparisons at the door? They are such a cliché and 90% of the time they aren't even accurate. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "America does not go abroad in search of monsters to destroy. She is the well-wisher to the freedom and independence of all. She is the champion only of her own." -- John Quincy Adams, July 4th, 1821
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 12:03 am, N Smethurst wrote: > Le Jeudi 6 Mars 2003 16:22, Austin a écrit : >> It's because 90% of the bug reporters ONLY install linux from ISO's. >> We should teach them about urpmi and/or network installs. > A HOWTO-be-mandrake-bug-tester-without-annoying-everyone would be good. > There is a lot of information available to learn about stuff, but it's not > always easy to find or presented in one place. Links from the front page > of bugzilla to such a howto could ensure that newer users deciding to help > out with some bug testing will be able to learn the ropes quickly and > easily. And a regularly posted short FAQ to direct people to (e.g.) bugzilla and the basics would be good. Volunteers? Cheers; Leon
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danny Tholen wrote on Thu, Mar 06, 2003 at 10:14:54PM +0100 : > it is perfectly understandable that the maintainer did not fix the > issues (either because he did not read his mail, or that he planned to > fix it with an update later in the process). However, it is > frustrating, and it might cause people not to send patches anymore > next time. I think this underscores another point. Patches can be slapped into bugzilla as attachments. Have a problem and the fix? Throw it into bugzilla and you've addressed: 1) bug recognition 2) bug verification 3) bug fix Now that bugzilla is running on a faster machine, it should be easier to do in the future. Blue skies... Todd - -- Todd Lyons -- MandrakeSoft, Inc. http://www.mandrakesoft.com/ Hey, I'm perfectly reasonable once you realize I'm right. -- John Buttery on Mutt Users ML Mandrake Cooker Devel Version, Kernel 2.4.21-0.12mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z9WHlp7v05cW2woRAkhxAJ0WD2cYKV4VEORbVfoI/x07FsOZ0wCdF7IU YmJHWxp2LuHuUZb3VKcAWF8= =FVWy -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 01:33 pm, Luca Olivetti wrote: > Miark wrote: > > 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 > > no, it isn't. Bug reports are ignored and each release is worse than the > previous one (for me at least it is). I've gone from spontaneous X > restarting while using xv in one release to an occasional crash in the > next to filesystem corruption in the next. I agree here. I have contacts within nvidia already and thier driver support for linux is way off. It's more like an after thought. Mind you I don't even sell thier cards in my shop anymore the failure ratio is way to high. > > > 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. > > Well, from now on I will be very thankful for being ignored, random > crashes and filesystem corruption. > > > What do you think you'll switch to? > > I don't have the sligthest idea, but I know it won't be nvidia. -- -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, [EMAIL PROTECTED], [EMAIL PROTECTED] Holiness unto the Lord -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 10:31 am, Todd Lyons wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brook Humphrey wrote on Wed, Mar 05, 2003 at 07:51:28PM -0800 : > > To be honest I just had this problem with my last install also. In my > > case I forgot the sblive was even in the box. I did however notice that > > even though I had the on-board sound shut off in the bios it was > > installed as the default sound. In my case since the sound blaster cards > > are all such garbage I just removed the card. To be honest they cause > > problems with almost every piece of hardware I've ever seen. I run a > > computer store so I have seen this quite often even with windows. All the > > creative labs cards accept for the older isa ones have problems and the > > isa ones don't sound nearly as good. > > Can you repeat the install with "acpi=on" being passed to the kernel at > the CD boot screen? (press F1). > > Blue skies... Todd > - -- Sure I could but a better question should be do I want to. Sb live/audigy as stated above are garbage. I cant even remember properly why it was installed n the system. I have not used sound on it in ages but now that the onboard is on I find I'm enjoying it. I might add that this is a kt333 chipseted motherboard and even via does not support the use of sound blaster cards on there hardware under windows. How much worse do you think it will be under linux? I tell you what I'm probably going to be busy for the rest of the day but if I have the time later tonight I will do the reinstall with that option. -- -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, [EMAIL PROTECTED], [EMAIL PROTECTED] Holiness unto the Lord -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 14:45, Guillaume Cottenceau wrote: > > Let it clear: we all want the most bug-free release possible. Generally, I agree with all your points. What you say is as far as I can just mostly right. And people on this list will probably always complains about certain desission. 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 yourself) are very cooperative. This shows. There are components of the 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. I could have given at least 2 examples in this mail. I did not because I think it is perfectly understandable that the maintainer did not fix the issues (either because he did not read his mail, or that he planned to fix it with an update later in the process). However, it is frustrating, and it might cause people not to send patches anymore next time. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 06 March 2003 02:17 pm, Greg Meyer wrote: > But that is not how release candidate is defined here. rc stage is when > cooker is frozen from feature add, not when there is a setup MandrakeSoft > thinks could go out. Clarifying what these terms mean is important. > -- Yeah, by anyone elses definition that is beta. - -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBPmfCvBFHZPcobeHxAQKfhQP/es5QzFTbjNuPLEAbsw8Wtaxe947QRa// uF6Xkksxdx/p+znxC7cWTwneBSDUCZV+WAQTsAap293AXw2geJTCi7K4ctfj7jjc wycPPwR7zPAlrFHa7tT059GPO64znp3e2lQ8NHfH2qG42+Up260Q0kTJj7kqDuvo +Vp5PhRC6S4= =wNwL -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Greenwood wrote on Fri, Mar 07, 2003 at 10:21:50AM +1300 : >Yup, that is basically what I am doing now except that I usually just >freshen (rpm -Fvh *.rpm) instead of URPMI Auto Select. I will try your >method and see how it works. I wish I could figure out how to use >rsync via an ftp client, then I wouldn't be downloading all the >packages, just the changes. Ron Stodden makes a package that does just that. I can't recall the name right off the top of my head, but it's an Aussie website address. >I understand URPMI works with rsync mirrors as well but it >doesn't seem to be working properly on my work box but I need to >investigate further. If you're investigating rsync, just use rsync manually. However, your attempts to do things are hampered by the fact that the mirrors are busy with people trying to download RC's because we just released. If you try to ftp to the same mirror 10 times in a row, you might find that you get rejected a few times because the anonymous limit has been hit. Blue skies... Todd - -- Todd Lyons -- MandrakeSoft, Inc. http://www.mandrakesoft.com/ UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn Mandrake Cooker Devel Version, Kernel 2.4.21-0.12mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z8MPlp7v05cW2woRApXJAJ4hg7UJ8nFh4Ip4DENnZANrdATnQACfeSog Su+WcnNb7xAZavyLcPdkYs4= =h1yd -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Miark wrote: 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 no, it isn't. Bug reports are ignored and each release is worse than the previous one (for me at least it is). I've gone from spontaneous X restarting while using xv in one release to an occasional crash in the next to filesystem corruption in the next. 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. Well, from now on I will be very thankful for being ignored, random crashes and filesystem corruption. What do you think you'll switch to? I don't have the sligthest idea, but I know it won't be nvidia. -- 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
Yup, that is basically what I am doing now except that I usually just freshen (rpm -Fvh *.rpm) instead of URPMI Auto Select. I will try your method and see how it works. I wish I could figure out how to use rsync via an ftp client, then I wouldn't be downloading all the packages, just the changes. I understand URPMI works with rsync mirrors as well but it doesn't seem to be working properly on my work box but I need to investigate further. Cheers Jason PS, good to see you again Todd. I was offlist for a while Todd Lyons wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Greenwood wrote on Fri, Mar 07, 2003 at 09:47:23AM +1300 : PS, I DON'T use urpmi/software manager on my cooker box at home cause I'm on dialup and URPMI doesn't resume if the connection is broken on remote sources AFAIK. As such, it is easier for me to download via FTP and then either freshen or urpmi from the updated local source. On my work box (9.0) I use mandrake update just fine. Paraphrasing, but a good way to do it is: 1) mkdir /home/rpm (only first time) 2) urpmi.addmedia Local file:///home/rpm (only first time) 3) ftp the files to /home/rpm (every time) 4) urpmi.update Local (every time) 5) urpmi --auto-select Blue skies... Todd - -- MandrakeSoft USA http://www.mandrakesoft.com Easy things should be easy, and hard things should be possible. --Larry Wall Mandrake Cooker Devel Version, Kernel 2.4.21-0.12mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z7lQlp7v05cW2woRAhXvAKCf2XdXNIwn38eR3g9/hOH4h2p8iwCgvtfR tMAUibuLpBRMuGQCUXxipIg= =Phrg -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Greenwood wrote on Fri, Mar 07, 2003 at 09:47:23AM +1300 : >PS, I DON'T use urpmi/software manager on my cooker box at home cause >I'm on dialup and URPMI doesn't resume if the connection is broken on >remote sources AFAIK. As such, it is easier for me to download via FTP >and then either freshen or urpmi from the updated local source. On my >work box (9.0) I use mandrake update just fine. Paraphrasing, but a good way to do it is: 1) mkdir /home/rpm (only first time) 2) urpmi.addmedia Local file:///home/rpm (only first time) 3) ftp the files to /home/rpm (every time) 4) urpmi.update Local (every time) 5) urpmi --auto-select Blue skies... Todd - -- MandrakeSoft USA http://www.mandrakesoft.com Easy things should be easy, and hard things should be possible. --Larry Wall Mandrake Cooker Devel Version, Kernel 2.4.21-0.12mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z7lQlp7v05cW2woRAhXvAKCf2XdXNIwn38eR3g9/hOH4h2p8iwCgvtfR tMAUibuLpBRMuGQCUXxipIg= =Phrg -END PGP SIGNATURE-
Re: [Cooker] Mandrake 9.1 Should be Delayed
Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Dorman 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 I'm sorry Buchan, but unless you snipped out the bit where I say people shouldn't test betas I can't see it in the paragraph you seem to be refering to. 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. Aside from the point that I didn't suggest people shouldn't test betas, just where did all the new bugs come from? Very few bugs in the betas, but lots of bugs in the first release candidate? Surely people didn't feel sufficiently motivated to properly test the betas, choosing to wait until the rc's started coming out and then, because oh-my-goodness-/this/-is-supposed-to-be-a-release-candidate people start flooding the list with their reports. And the reports are ...can't install, won't run, ..crashes..., ..doesn't properly support my [insert very common graphics card or other hardware device] I'm sorry, but these sound like the kinds of issues you run into during the alpha or beta stage The truth is, there were very few bug REPORTS before rc1 was released. The beta program needs more active and vocal testers. Many people are busy and might need a little incentive to get down and dirty with the betas, hence my suggestion of some kind of reward program. Use rewards to get people more active instead of coming out with 'release' candidates. 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). I have been following, and I think this is fine, as long as release managers automatically allow packages which are themselves going from beta or rc to stable. Take for instance, oh, I don't know, the kernel. Should the release have another 2.4.21pre- kernel? Or should the maintainers let the final 2.4.21 release sneak in when it comes out? Is it good marketing to come out with a major release (and given all the hubub around MandrakeSoft's financial situation I'd say this is a major release) containing a prerelease kernel? Is it wise to be building a distro around a pre-release kernel when the deadline for the distro release is likely to fall before the release of the stable kernel version? And that's without going into *why* the kernel is still in prerelease 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). Buchan, I've seen many of your posts on this list, and the vast majority of them are useful and sensible ***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. So they don't get the distro for free. They pay for it with their time. How much do you charge for your time? And they are not 'their' bugs, they are bugs in the distro that have not been squashed... And if bug reporters get rewards, what do the people who run cooker and maintain packages get? Paid. 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. But they don't, do they? 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 us
Re: [Cooker] Mandrake 9.1 Should be Delayed
It's not just the CD installer that gets tested. URPMI does not test an installer AT ALL. Therefore, having people test ISO installs/Network installs is crucial to the beta process. Cheers Jason PS, I DON'T use urpmi/software manager on my cooker box at home cause I'm on dialup and URPMI doesn't resume if the connection is broken on remote sources AFAIK. As such, it is easier for me to download via FTP and then either freshen or urpmi from the updated local source. On my work box (9.0) I use mandrake update just fine. Jason Komar wrote: On Thu, 2003-03-06 at 10:21, N Smethurst wrote: Le Jeudi 6 Mars 2003 17:33, Austin a écrit : It just seems to me that people are really stuck in the idea of ISO's because they've never known otherwise. This is so true. Personally, I use urpmi and update each day. It is good to have some people testing the ISO's though. That makes sure the cd installer gets tested as well.
RE: [Cooker] Mandrake 9.1 Should be Delayed
I agree. There wasn't a set process (or didn't seem to be) for the appropriate time to update a bug to see if it was resolved or fixed. I went on the assumption or next iteration of beta or if bugzilla went through and auto updated... Cory -Original Message- From: Austin [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 8:34 AM To: [EMAIL PROTECTED] Subject: Re: [Cooker] Mandrake 9.1 Should be Delayed On 2003.03.06 10:43 Buchan Milne wrote: > IIRC there were beta ISOs more than two weeks ago ... True. But my point was that I'm sure some people download a beta, report a bug, and then wait for the next beta to see if it's fixed. They could just as easily (and more efficiently) keep their initial install up-to-date with urpmi, and track their bugs every few days. It just seems to me that people are really stuck in the idea of ISO's because they've never known otherwise. 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
On Thu, 2003-03-06 at 10:21, N Smethurst wrote: > Le Jeudi 6 Mars 2003 17:33, Austin a écrit : > > It just seems to me that people are really stuck in the idea of ISO's > > because they've never known otherwise. > > This is so true. > Personally, I use urpmi and update each day. It is good to have some people testing the ISO's though. That makes sure the cd installer gets tested as well. -- Jason Komar <[EMAIL PROTECTED]> Lubetec
Re: [Cooker] Mandrake 9.1 Should be Delayed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timothy R. Butler wrote: > > >>These would be people who are in "edit_bug". The only issue is that this >>is not well known enough. Any cooker regulars should have this status, >>if they are willing to do the job well. > > > How is it determined when people receive "edit_bug"? It sounds like a lot of > regulars here don't have it... That is another of the mysteries of Mandrake development ;-). You are supposed to send a mail to an address @mandrakesoft.com (qa?), with something like "canpostabug" in the subject. A search through my mail did not turn up the one I sent, only confirmation of me being added to the group, so don't spam the address now with bogus attempts ;-). Regards - -- |--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+Z7LXrJK6UGDSBKcRAjhqAJ4ywuQ6UJn4IX++MYTzRJ3hUqQ/6wCgwvG5 mIMPCsW2QsG+cYe9lo3W0v0= =1Uln -END PGP SIGNATURE-
