|
Warly,
Thanks for clarifying this. It should have been blindingly
obvious to anyone with any experience in software production (myself
included) that distribution and so on depends on fixed dates communicated
well in advance. In that regard, any development, open source or
proprietary, has to deal with the realities of the market.
Of course we need deadlines; and nobody (should) doubt the level of
effort that's going into getting 8.2 out the door. Perhaps what
ought to be looked at for 9.0 is not so much a reworking of the
development model, but, rather, a more conspicuous and complete
articulation of it. I suspect that many of the people commenting on
various aspects of the distro have development experience limited to
either commercial development or, at best, single, smaller Open Source
projects that have greater immediate control over their own
schedule. There is a level of assumption present, fed by comments
from the public face of Mandrake (you) like "No final until all bugs are
squashed ;)" -- that leads people to lose sight of the fact that Mandrake
is, in fact, a commercial venture that has to ship product (8.2) on or
very closely about a fixed date in order to keep food on the table.
When the schedule is fixed, stakeholders (e.g., Cooker folk, testers)
need to know. When outside people are testing, it helps to have some
idea what priorities are, and those are expected to get tighter as we
progress from Beta 1 through Beta N to RC1 to RC M. It is my
impression that what has raised a lot of people's blood pressure on the
list is not konwing what the real priorities and selection criteria
are. If we do indeed have a fixed date, a (relatively) fixed amount
of resources that we can allocate to fixing problems, and a non-fixed
feature/defect matrix, it's obvious that features are not going to ship
and/or defects are not going to get fixed before the ship date.
That's life in commercial development; anybody who says "But
WhizBang-0.9.9 just shipped - can we include that too?" - is cordially
invited to patch the distro with WB, build and fully regression-test the
entire distro, and describe what other changes ripple out - without
affecting others' work or delivery schedules. It can't be done,
folks - what CAN be done is better communication.
Ship dates should be articulated. Defect-classification and
-prioritization should be communicated, probably through this list and/or
Mandrake Expert. It would be nice to see basic statistics like
defect open and close counts and rates, mean time to repair for various
categories and priorities of defects, and so on. There's no obvious
communication of prioritization or severity at all in Mandrake Expert -
THAT needs to be fixed for 9.0, and all this is basic statistics that any
self-respecting defect- or problem-reporting system should handle out of
the box.
Mandrake has a great resource here - the great volunteer army of
testers and users willing to test and poke and prod the software on a far
greater variety of systems and configurations than Mandrake could ever
have direct control of; but it will take some improvements in
communication and process to make truly effective use of them. If we are
to make Linux a more credible alternative to Windows - and Mandrake the
preeminent Linux on the desktop.
How can we help?
Jeff Dickey
Seven Sigma Software and Services
PGP key fingerprint: 6BAC 8806 2480 BC1B 0388 2521 CB5B
552F
-------Original Message-------
Date: Sunday, March 17,
2002 01:12:46
Subject: [Cooker]
Mandrake way of life
Mandrake Linux is based on a fixed date releasing due to
market
constraints (distributor/supplier schedules). As a consequence
the
release date was scheduled 3 months ago. On this date we have a
very little margin of 2 or 3 days, but not more.
So the datum
is: "release date is March the 15th".
Now we need to do it in this
timeframe (and we are the 17th), and
we have no other choice.
In
a few days 8.2 updates will be released, and them you will have
the
real stable and polished distro you want.
Debian has no real
realease date, as a consequence doing a stable
release is just a piece
of cake, anybody can do it.
Maybe our model is not
good.
Thinking of a better model, I am not sure what I could
choose. No
deadline means no hurry, and "if the last moments didn't
exist,
nothing good would be done".
Moreover if we wait too
much, new versions of nearly all the tools in
the distro will be
released, and their respective authors will not
care anymore fixing
bugs in the old version we would have included.
I do think that our
model is not so bad, and that we are reaching a
good compromise between
cutting edge and stability, but /this/
compromise _is
needed_.
--
Warly
. |
IncrediMail -
Email has finally evolved - Click
Here
