>>>>> "B" == Buchan Milne <[EMAIL PROTECTED]> writes:
B> FYI, my Thinkpad 600X runs either acpi or apm just fine on
B> 2.4.21.0.13mdk (sorry, can't give definitive answers for other
B> kernels, as I have so many installed on it now for other
B> reasons).
Good -- that's what I needed to know ;)
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,
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.
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 ;)
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.
if you reverse that process, dump everything in the bug-jar by
default, the bug-jar becomes so muddied, you might as well be working
on Mozilla ;)
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; it is extremely
useful for many people to have the option to pick from the cooker, 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 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.
--
Gary Lawrence Murphy <[EMAIL PROTECTED]>: office voice/fax: 01 519 4222723
Business Advantage through Community Software - http://teledyn.com
"what I need is a job that doesn't interfere with my work" -gary murphy
