On Sun, 2003-09-28 at 09:19, Warly wrote:
> - What was wrong in 9.2 development process?
The beta/RC process is flawed as heavy development continues during the
beta/RC process.
If Mandrake tools have to change (new features, fix incorrect behaviour,
etc) then they should be changed based on a set of requirements for the
release. These changes should be implemented before the test cycle
starts.
Also one of the very important step is the installation. From the 1st
beta/alpha we should be using updated boot images so that early in the
test cycle we catch hardware pbms.
For example, 9.2 beta1 I believe was using boot images from 9.1...
The mirrors were a pain in the backside...
> - We though a bit late in the 9.2 developement process to split cooker ml, we
> should do it now.
Not sure spliting the ML will improve things. People will end up posting
to all MLs raising the signal to noise ratio for all lists.
> - What could we do to improve 9.3/10.0 development.
- Complete all developments before the test cycle begins
- Start with an alpha release (1w)
- then beta1 (2w)
- then beta2 (2w) - last chance to include new software releases
- then beta3 (2w) - only bug, security fixes maybe a new software
release (after approval) + polish
- then RC1 (2w) - bug and security fixes only + polish
- then RC2 (2w) - bug and security fixes only + polish
RC status should be given when no major/blocker bugs remain in CVS.
Period for beta/RC should be flexible from 1w to 3w.
For each beta/RC it would be nice to have a summary of what bugs were
fixed, how much remains etc...
A nice changelog/errata to indicate what is known to not work.
That may be a different subject but the MandrakeSoft web sites need a
serious change of look...
Can I say fedora and gentoo?
> - What should we do to improve the Wiki.
Contains its messy spreading. Make sure the information is valid.
> - Should we have cooker snapshot ISOs?
If it allows some users to do more testing then why not.
> - What could we do, as a community, to increase the acceptance of mandrakelinux?
Show that the QA is top-notch by allowing sufficient time for the test
cycle to change your strategy if/when more testing is required.
Make sure that developers update bugzilla properly with indication of
packages version where a fix was made so that we can re-test the fix.
> - How to have more contributors?
>
> And anything related to the mandrakelinux distro.
--
Frederic Soulier <[EMAIL PROTECTED]>
