-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Lawrence Murphy wrote:
> B> Of course it is all valid, but the points you are missing out > B> are: 1)What relevance is a bug in the previous ditro to the > B> next one if it's already fixed in cooker? > > ah, yes, but, that assumes it _is_ 'fixed' in the cooker. > > If we only depend on cooker-members to test the cooker, we're doomed, That's why we have snapshots, betas, and pre-releases. > we've reduced our quality control to the same inadequate model used by > proprietary software and we will fail to find most bugs. This gets > back to Warly's comments about the bug-reports --- even if it's a bug > being reported on 6.0 ... if we've been overlooking it for a dozen > releases, that doesn't mean we shouldn't fix it, it means that someone > finally found it. > But it could also mean it was fixed upstream before 6.1 was released, and it may take too much effort for someone else to replicate the problem, only to discover it is fixed. Instead, the reporting user could confirm it is still an issue on cooker/snapshot/beta/pre with much less effort. > B> 2)Cooker can't support people running a mix of a stable release > B> and cooker > > True; my question was if an option was off (which it could because > it's an old technology) and you confirmed by your experience that it > is not. _Now_ it becomes an installation issue ;) No, by default (ie, unless the user chose to use acpi by checking the box in the bootloader setup) it will use apm, by passing 'acpi=off' via lilo. There is an issue with drakboot automatically setting ACPI on *after* installation, if the user doesn't watch closely. I am not sure if this is fixed in cooker .. > > B> ... If you are absolutely sure (ie it's a config file, and you > B> have checked Mandrake's latest package in cvs) it's still > B> applicable in cooker, then file a bug in bugzilla. > > I disagree; that model always leads to such bug-bloat, no one ever > goes in because they have to wade through so much garbage. If someone > reports an issue, our first responsibility is to ensure it's not a > design problem with the cooker we'd just released as "stable"; if > someone can confirm that it's not a flaw, then it becomes an install > issue, an issue of educating the customer in how to properly configure > an otherwise essentially correct distribution component. If these > (volunteer) "customer service reps" cannot resolve the issue _then_ > it's a bug and needs to be logged so it's not forgotten. > And the current determination is that it was not a bug. Most people have problems *enabling* acpi! If acpi were enabled by default, we would have seen many more bug reports on 9.1 installation (from machines that would not boot with acpi enabled). > > B> Sorry, but it's just too difficult to debug cross-release > B> stuff, for instance there was someone who complained that > B> libsmbclient packages were wrong (since it wanted him to > B> install samba-common-2.2.7a-8mdk and uninstall > B> libsmbclient0). But 2.2.7a-8mdk *is* only in 9.1, and in 9.1 > B> there *is* no libsmbclient package. Having to track this down > B> only to find what the user has done is simply a waste of time > > Disagree with you there -- in this case, the proper customer education > is not to throw their report away, but to have told them when they > downloaded cooker RPMs that there may be problems; No, the correct answer is "don't use binary rpms from cooker on a stable release". Doing so is asking for trouble. It may work just after a stable release, but if it doesn't work, please don't waste the maintainers time filing a bug report, until you have either rebuilt the source package, or tried full cooker. > it is extremely > useful for many people to have the option to pick from the cooker And how much effort is it to rebuild the package? It yields better results in most cases. >, I > have clients who only use Mandrake because the cooker saved their skin > _but_ as you point out, _our_ response to missing packages is so > cryptic, it confuses those who have not been following the > discussions. > > What the pre-install scripts of the samba-common needed to do was to > _tell_ them what it "wanted" (fyi, Dykstra would fail anyone who used > anthropomorphisms about computers such as "feeding" a computer data) The problem was that he wanted libsmbclient0-devel. There was never such a package in 9.1. So, he installed the cooker one, but it required libsmbclient.so.0, which in 9.1 was provided by samba-common. So, since he had a 9.1 source, and a cooker package, urpmi was wanting to install samba-common-2.2.7a-8mdk and libsmbclient0-2.2.8a-5mdk, which will not work (dependencies not met). > > The error was not with the user, but with the package, so his reporting > the glitch to the cooker is a Good Thing -- you're under no obligation > to help him, but as you illustrate above, the /story/ of the situation > is generally instructive and belongs in the archives. > There's nothing wrong with the package. Instead, the user could have used binaries of 2.2.8a-2mdk for 9.1 with the libsmbclient0-devel -3mdk packages which I provide on my site: http://ranger.dnsalias.com/mandrake/9.1/libsmbclient0-devel-2.2.8a-3mdk.i586.rpm (the fact that libsmbclient0-devel -3mdk will install alongside samba - -2mdk is intentional, to allow this without requiring an upgrade of all samba packages, as I was not prepared to rebuild two sets of samba for 5 Mandrake releases in case someone wanted this). But rebuilding the src.rpm from cooker would also have fixed it. We have just now proven why it is useless to take bug reports from people mixing cooker and stable. I have much better things to do than answer these kinds of questions all the time, such as getting bugs fixed in samba source, ensuring it is trivial to rebuild packages on older releases, providing binaries for all recent releases, and maintaining the cooker packages. BTW, I will happily take a patch to fix the issue (if you think it's possible). Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/FC0wrJK6UGDSBKcRAj4jAKDC5QHfiyGIHplFl/Y7RuISo+J2igCfRHYP XDzxYPENm3dy8GHOcCkVLnM= =1bPl -----END PGP SIGNATURE----- ****************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. ******************************************************************
