Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
I'm surprised you find SuSE and RedHat better tested than Mandrake. One of my biggest problems with SuSE (which I used for over two years as my preferred distro) is that they have a closed beta program. Perhaps they haver very strict testing, but as long as it doesn't get real world testing, you have a lot more chance of shipping major bugs. Off the top of my head, I can think of the problem in SuSE 6.4 that made Netscape crash on startup on most installs, the auto detection of sound cards that it didn't support (which it then attempted to install), not to mention the fact that SuSE's upgrade tool regularly nukes partitions for everyone's enjoyment. There are two major problems I see that cause this - (1) the closed beta process, which unlike Mandrake the users have absolutely no say about how the new release is coming untill release. (2) The MS-style Shared Source(TM) license of YaST/YaST2 which prevents most contributions to fix/improve the installer except by SuSE employees (unless they are willing to give up all rights to their improvements). Frankly, RedHat isn't much better - they've always been willing to ship buggy things, like RH 7 (IIRC) which included a horrible copy of GCC, or just in RedHat 7.2, I had to launch the RedHat Network tool three seperate times to get it to work (it kept crashing at various stages of initial update setup). Mandrake certainly isn't perfect, but I think their style of testing - which is much like Debian's - is definately the best method out there. They may not listen to users *all* the time, but they certainly do it a lot more than SuSE does. -Tim -- Timothy R. Butler[EMAIL PROTECTED] Universal Networks http://www.uninet.info Christian Portal and Search Tool: http://www.faithtree.com Open Source Migration Guide: http://www.ofb.biz = Christian Web Services Since 1996 ==
[Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Ron - keep up the good work. Mandrake folks - ditto, but either let's have a deep freeze or let's get Cooker fixed - you can't deep freeze a wildly moving target. As a quality engineer, I think Ron has a legitimate complaint about the response to his defect report - one of his drives is rendered unusable by rogue modifications to lilo.conf via an action that no reasonable user would expect to modify lilo.conf. IN THE ABSENCE of documented defect classification, life cycle and escalation/resolution policies, and in the absence of documented target-user profiles eliminating users with multiple optical drives, this does sound like a defect that could affect a potentially significant population of users. Personally, I'd be willing to bet that at least one reviewer will be bitten by this - and Mandrake really needs as smooth sailing in the review press as we can possibly get. 8.2 CAN be the best Mandrake ever - if not the best Linux ever. I've been using Mandrake since 7.1 and have NOT been happy with the intervening releases' stability on any of my systems. It's great to have the latest and greatest kernel and packages - and people will put up with a certain amount of fit and finish polishing... but to have what (to the user or reviewer) appear to be casual and obvious inconsistencies is not the way to effectively compete against Red Hat - let alone Windows. Thanks, everybody! Jeff Dickey Seven Sigma Software and Services Phone: +1 661 588 2917 Phone: +1 425 885 6280 Pager: +1 800 931 4233 Email: mailto:[EMAIL PROTECTED] (preferred) Email: mailto:[EMAIL PROTECTED] Home page (with résumé): http://www.seven-sigma.com/ PGP key fingerprint: 6BAC 8806 2480 BC1B 0388 2521 CB5B 552F ---Original Message--- From: [EMAIL PROTECTED] Date: Friday, March 15, 2002 03:41:55 To: [EMAIL PROTECTED] Subject: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER! Pixel wrote: - this is much too late, we're in deep freeze Judging by the rate of changes to Cooker, you most certainly are not in any deep freeze. - bug report must give more information to be helpful That is not possible, and not a way out for you. Find the problem fix it. - please choose an appropriate Subject: - this is of course not a show stopper, even if I agree it would be nicer if this kind of bug would be fixed (I tried some upgrades and my fstab was correct after upgrading) me too, over 50 of them for 8.2 so far. You see that 49 is not a sufficient number to uncover all the bugs. The simplest explain is that the partition number is occasionally corrupted (5 changed to 7 in this case) on the earliest /etc/fstab read, but not for the writeback. BTW, thanks for the package only update option. - your messages are much too agressive = i usually don't read your mails Ho hum. I an just honestly reflecting back to you what it is like out here with Cooker so far. That is a fair service. I regret your attitude, but it is field reality, is it not? -- Ron. [au]
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
--- Jeff Dickey [EMAIL PROTECTED] wrote:
Ron - keep up the good work.
Mandrake folks - ditto, but either let's have a deep
freeze or let's get
Cooker fixed - you can't deep freeze a wildly moving
target.
As a quality engineer, I think Ron has a legitimate
complaint about the
response to his defect report - one of his drives is
rendered unusable by
rogue modifications to lilo.conf via an action that
no reasonable user would
expect to modify lilo.conf. IN THE ABSENCE of
documented defect
classification, life cycle and escalation/resolution
policies, and in the
absence of documented target-user profiles
eliminating users with multiple
optical drives, this does sound like a defect that
could affect a
potentially significant population of users.
Personally, I'd be willing to
bet that at least one reviewer will be bitten by
this - and Mandrake really
needs as smooth sailing in the review press as we
can possibly get.
8.2 CAN be the best Mandrake ever - if not the best
Linux ever. I've been
using Mandrake since 7.1 and have NOT been happy
with the intervening
releases' stability on any of my systems. It's
great to have the latest and
greatest kernel and packages - and people will put
up with a certain amount
of fit and finish polishing... but to have what (to
the user or reviewer)
appear to be casual and obvious inconsistencies is
not the way to
effectively compete against Red Hat - let alone
Windows.
I am in complete agreement on this. I think that 8.2
is ready for beta now, not release. There are plenty
of small (and some not so small things) left that need
to be addressed. I love Mandrake, but I have yet to
have a version I can call stable. If I try to put this
out on a corporate desktop, it will create the
opposite effect that I would want, more calls from
users claiming that the system is broken. The
non-technical masses really just want something that
works properly. I feel this version is the closest to
date to getting stable, but it is still not there yet.
There are enough unresolved issues on this mailing
list to call for another release candidate. I know
that it is boring and exhausting for creative types to
get locked up in debugging, but releasing 8.2 as is
will be missing the polish that I feel is necessary
for an effective release geared towards the desktop.
The biggest issue, as I see it, is that once 8.2 is
released, most of the attention returns to cooker.
This leaves 8.2 bugs and annoyances pretty much
abandoned. If you are going to release now, then I
believe that there should be a continued updateng of
8.2 until it reaches that polished state. Then, you
could develop the reputation that your newest releases
are for home users and others with non-critical
systems that get the latest and greatest, while
Corporate users and other systems that depend on
stability and flawlessness for wide implementation
(generally to moderate to novice users). In short,
whenever a new version is close to release, then one
would know that the prior version has had all of its
bugs resolved and annoyances fixed and is safe for
wider deployment. Unfortunately, I can not say this
about any prior version. :-{
I don't mean to come off sounding so harsh. I actually
feel that this version has many major improvements in
speed and usability, and a lot of major bugs have been
squashed during beta. It seems so close (to me, at
least) to reaching what I would consider a release
candidate. I wish that Mandrake would take those extra steps...
=
SI Reasoning
[EMAIL PROTECTED]
A requirement of creativity is that it contributes to change. Creativity keeps
the creator alive.
-FRANK HERBERT, unpublished notes
__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Jeff Dickey wrote: Ron - keep up the good work. Mandrake folks - ditto, but either let's have a deep freeze or let's get Cooker fixed - you can't deep freeze a wildly moving target. As a quality engineer, I think Ron has a legitimate complaint about the response to his defect report - one of his drives is rendered unusable by rogue modifications to lilo.conf via an action that no reasonable user would expect to modify lilo.conf. IN THE ABSENCE of documented defect classification, life cycle and escalation/resolution policies, and in the absence of documented target-user profiles eliminating users with multiple optical drives, this does sound like a defect that could affect a potentially significant population of users. Personally, I'd be willing to bet that at least one reviewer will be bitten by this - and Mandrake really needs as smooth sailing in the review press as we can possibly get. Well, Jeff, my problem reports all refer to the newly introduced Packages update only installer option. I do not know whether they would crop up for other users of the installer. On the assumption that this feature was added to help beta testers (for which a big thank you G) it may or may not be valid to generalise to all installer users. Re wildly moving target and we are in deep freeze, cooker received 1025 new or changed RPMs in the last 24 hours. Mandrake 8.2 is plainly still in Alpha test and they are improperly co-opting us outside users to assist that process, which should be an internal function. I am looking forward to when Alpha has been completed and Beta and then Gamma testing can commence, but regretfully (and foolishly) that has not happened for any Mandrake release so far. -- Ron. [au]
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Ron Stodden [EMAIL PROTECTED] writes: Re wildly moving target and we are in deep freeze, cooker received 1025 new or changed RPMs in the last 24 hours. AFAIK re-signing packages doesn't imply re-testing. AFAIK there has been 17 new packages in the last 24 hours, with mainly small changes. In fact, there are quite many uploads because each very small change is uploaded ASAP. Mandrake 8.2 is plainly still in Alpha test and they are improperly co-opting us outside users to assist that process, which should be an internal function. I am looking forward to when Alpha has been completed and Beta and then Gamma testing can commence, but regretfully (and foolishly) that has not happened for any Mandrake release so far. It won't happen. If you want this kind of slow release, go to Debian. No offense to Debian of course, our time to release/market are quite different (FYI, I have a chroot 'unstable' debian on my box)
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Ron Stodden [EMAIL PROTECTED] wrote: Re wildly moving target and we are in deep freeze, cooker received 1025 new or changed RPMs in the last 24 hours. Re-signing packages does not require re-testing. As for why Mandrake doesn't take you seriously, read the following as if it were directed at you - such offensiveness can only come from a child regardless of the time you spent carefully picking insults: Mandrake 8.2 is plainly still in Alpha test and they are improperly co-opting us outside users to assist that process, which should be an internal function. I am looking forward to when Alpha has been completed and Beta and then Gamma testing can commence, but regretfully (and foolishly) that has not happened for any Mandrake release so far. -- Murray J. Root [EMAIL PROTECTED] - email (404) 978-1262 x2646 - voicemail/fax __ Voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Hi, Re wildly moving target and we are in deep freeze, cooker received 1025 new or changed RPMs in the last 24 hours. Mandrake 8.2 is plainly still in Alpha test and they are improperly co-opting us outside users to assist that process, which should be an internal function. I am Hmm... if it's an Alpha/unstable release, then it is only an Alpha/unstable release in the sense that Debian unstable is unstable (i.e. it isn't). I've been running Mandrake 8.2 RC1 on my laptop for a week now, and I must say I haven't had a single problem beyond a few segfaults in the control panel's FontDrake. If this is your idea of an alpha-quality program, go give Windows a try. Trust me, I've run alpha quality operating systems before, and this ain't one of them. -Tim -- Timothy R. Butler[EMAIL PROTECTED] Universal Networks http://www.uninet.info Christian Portal and Search Tool: http://www.faithtree.com Open Source Migration Guide: http://www.ofb.biz = Christian Web Services Since 1996 ==
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Yes, but "very small changes" are the leading cause of project
failures in my experience dealing with software. People almost
always test the flagrantly obvious big changes - but I know of a
missile-defence test that wrote off a $200-million-plus launch vehicle for
what turned out to be a single typo in a single line of code - on a
project with far tighter formal validation and verification procedures
than I have seen in any civilian software project. Saying something
is "too small to be tested" is the same thing as saying "it doesn't
matter" - and reviewers and corporate evaluators will pick up on that
attitude, and go elsewhere.
I'm trying to resolve my present ethical difficulties in recommending
Mandrake to clients. I think it's a lot of fun - certainly more so
than Red Hat or SuSE ("Have a lot of fun") but I expect to continue
recommending those distributions for servers and desktops for the next
year or so, at the rate that Mandrake is improving. 8.2 is a
near-great release - we're almost back up to the standard set by
7.1. I'd like very very much to believe that that release was not a
fluke; that there can be a Red-Hat-compatible release that uses the best
available mix of packages and value add to ship a killer distro. I
am personally in awe of Warly and Pixel and the rest of the team - I've
been using Linux for years but I'd certainly not take on doing an entire
distro - but if Mandrake is going to try to appeal to the general user
looking to escape the DLL hell that is Windows, and to the corporate IT
group evaluating Linux on the desktop, then you HAVE to ship a world-class
product. "Close" only counts in horseshoes and hand grenades; I'd
much prefer this not to blow up in my clients' faces. Or mine.
:)
Jeff DickeySeven Sigma Software and Services
Phone: +1 661 588 2917Phone: +1 425 885 6280Pager: +1 800 931
4233Email: mailto:[EMAIL PROTECTED]
(preferred)Email: mailto:[EMAIL PROTECTED]
Home page (with résumé): http://www.seven-sigma.com/
PGP key fingerprint: 6BAC 8806 2480 BC1B 0388 2521 CB5B
552F
---Original Message---
From: [EMAIL PROTECTED]
Date: Saturday, March
16, 2002 07:23:38
To: [EMAIL PROTECTED]
Subject: Re: [Cooker]
Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586
20020313 3:06 - SHOW STOPPER!]
Ron Stodden [EMAIL PROTECTED]
writes: Re "wildly moving target" and "we are in deep freeze",
cooker received 1025 new or changed RPMs in the last 24
hours.AFAIK re-signing packages doesn't imply
re-testing.AFAIK there has been 17 new packages in the last 24
hours, with mainly smallchanges.In fact, there are quite many
uploads because each very small change isuploaded ASAP.
Mandrake 8.2 is plainly still in Alpha test and they are
improperly co-opting us outside users to assist that process,
which should be an internal function. I am looking forward to when
Alpha has been completed and Beta and then Gamma testing can
commence, but regretfully (and foolishly) that has not happened
for any Mandrake release so far.It won't happen. If you want this
kind of slow release, go to Debian. Nooffense to Debian of course, our
time to release/market are quite different(FYI, I have a chroot
'unstable' debian on my box).
IncrediMail -
Email has finally evolved - Click
Here
Re: [Cooker] Defect Handling Defects [Was: Re: [Cooker] Mandrake Linux Cooker-i586 20020313 3:06 - SHOW STOPPER!]
Pixel wrote: Ron Stodden [EMAIL PROTECTED] writes: Mandrake 8.2 is plainly still in Alpha test and they are improperly co-opting us outside users to assist that process, which should be an internal function. I am looking forward to when Alpha has been completed and Beta and then Gamma testing can commence, but regretfully (and foolishly) that has not happened for any Mandrake release so far. It won't happen. If you want this kind of slow release, go to Debian. No offense to Debian of course, our time to release/market are quite different (FYI, I have a chroot 'unstable' debian on my box) Then start your whole release cycle 2 (or 6?) months earlier and make a point of ensuring all reported bugs are corrected. This should eliminate the great rush at the end and mistakes made by tired people. It would also make an enormous difference if you Mandrake people actually started USING the software you deliver and ran networked development and QA areas so that the networking problems would show up. Simple example: There is a bad bug in nfs that I have just verified is still present between two 8.2 network nodes. The binary exportfs list gets screwed up quite frequently. When in this state access to only 1 or 0 files is made available to the requester without any warning or error messages whatsoever, and with the result that whole partitions can be quietly lost when rsyncing. If you happen to notice it, the fix is very simple, just rerun exportfs -r on the machine that has the source files and redo the rsync. But this not trivial bug has been with us since at least 7.2! -- Ron. [au]
