I think it�s time we all took a look at the cooker release policy.
What we appear to be doing now is releasing daily cookers. Each day, a new
Distro for public testing, tinkering and revision.
I have a few concerns about this policy.
First, the core value of the cooker; testing. We (the public) only get 24
hours (time zone dependent, because none of us are up or available for that
whole 24 hours�) to test a distro. We're seeing all the bugs haphazardly
reported into the Cooker mailing list, not bugzilla. We also don't get a lot
of time to do anything with "the latest cooker" and submit our works.
Not all bugs can be properly addressed through the cooker. Once a bug gets
reported, it is almost distinctly date dependent (for a certain day�s cooker),
and by the time it�s even noticed (most likely the next business day) the bug
could have very well been addressed.
And promptly renewed again in the next, next cooker.
Even the guys at Mandrakesoft can�t possibly detect, address, and fix 26 (or
more) component bugs in the 8, 16 or even 20 hours they have before another
cooker is produced and released.
We often see a lot of reoccurring bugs (that are sometimes called �today�s
distro, with �today� being a relative term) that keep appearing, even though
some times we are sure they are fixed, someone complains.
I propose this; A weekly cooker.
Our Five cookers-a-week could be slimmed down into just one. On Monday (or
Sunday) , a cooker could be released, then, for the seven days proceeding,
Mandrakesoft staff and cooker fans can install, hack, crack and best of all
REPORT problems.
Problems reported would have days to be addressed instead of just hours (or
maybe even a full day if it�s a weekend) before the next cooker. And, because
cooker problems could be limited into just four a month, an entry for the
weekly cooker could be placed into Mandrakesoft�s bugzilla system. After all,
using bugzilla unquestionably makes it easier to manage your bug reports.
Having seven days to hack, crack and break a distro also can provide more bug
reports, reports that aren�t currently being addressed because they aren�t
being raised. People who download cooker have less than a full day to report
problems. Unless they�re installing every day with a notepad and pencil in
hand to write down encountered bugs, (and they DO encounter bugs) then they
might not feel so inclined to report a bug, no matter how serious.
And a weekly cooker doesn�t mean a featureless one. We can throw all the new,
bleeding and hemorrhaging edge technology we want into the weeks cooker, and
spend the week not only addressing the regular components, but also the new-
technology ones.
If a weekly cooker sounds too sparse, how about two weekly cookers? One at the
beginning of the week, one at the end?
Just thought this might be a good idea.
