On Sun, 2003-09-28 at 01:19, Warly wrote: > It may be a good idea, before cooker opens again, to take these days to > have some brainstorm. > > May you give your opinion on : > > - What was wrong in 9.2 development process? > > - We though a bit late in the 9.2 developement process to split cooker ml, we > should do it now. > > - What could we do to improve 9.3/10.0 development. > > - What should we do to improve the Wiki. > > - Should we have cooker snapshot ISOs? > > - What could we do, as a community, to increase the acceptance of mandrakelinux? > > - How to have more contributors? > > And anything related to the mandrakelinux distro.
In answer to all of the above. How about splitting the development along 2 lines. Mandrake tools and packages. The idea here from my thought is that these really are two separate areas, with separate goals. The next step would be to make the development of tools a continues project rather than a point/major release function. Create a fourth area called testing on the mirrors. This area differs from updates in that it isn't a bug fix but a known alpha product that is based on a stable release (in this case 9.2) and those power users who chose to can participate in the continuous testing of new ideas and directions. PLF and Ranger showed that a new "Disk 1" can be created to allow testing of just the installer with an existing set of disks. (There used to be, and may still be, an iso you could download of all of the PLF rpms. You would boot from it and begin the install instead of from the normal disk 1.) This would allow testing of MDK's tools in a stable and isolated environment. Then, when the next release cycle began the beta stage, MDK could decide what from this arena would become the tool set for the next release. We could then concentrate on just the package area for heavy debugging. This would also allow for the testing of "what if's" a lot more so that MDK would have a better idea of what flies and what doesn't as far as usability goes. The tools and installers from 9.0 to 9.x for example should remain pretty consistent anyway since it is a point release. Parallel attempts at usability could be tried (debug statements left in and operational etc.) Users would have to specifically chose to use the area called testing so that, hey, if it breaks your box... sorry. So no one would be able to complain beyond bug reports. (if you don't like it don't try it.) We also wouldn't have to waste so much time "discussing" things like the UI change in MCC etc. Then if MDK monitored the experts and newbie lists and kept seeing everyone recommend a certain tool to solve a problem they'd know for sure they have a winner. Finally when the MDK team chooses the final tool set from updates and this area, they become the tool set for the next release and then the crunch time would be able to concentrate on packages. Overall it would yield a much more stable release process IMHO. James
