On Sun, 28 Sep 2003, 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?
I think compared to previous releases, there wasn't as much feature-planning (as in 9.0 and 9.1). This may just be my perception since I was involved in some planning for features in 9.0 ... > > - We though a bit late in the 9.2 developement process to split cooker ml, we > should do it now. Please, this *must* be done. Why? Most people interested in the server development work will have production servers, and may not run cooker themeselves. Having the >95% of the traffic that is related to GUI stuff discourages people interested in improving server-side stuff from subscribing to cooker. I don't think Mandrake will be taken seriously on the server (though there is no reason why it shouldn't) unless you can get those running Mandrake servers in production involved in the development. Some have said that this will not be effective, but please tell me why a user will send a mail to a cooker-kde list for breakage in cyrus-imapd or apache or openldap. I think there should be a general list, that applies to Mandrake-specific software (DrakX, urpmi, drakxtools) and generic cooker issues. Then there should be lists for: -server software -KDE and KDE/Qt-based apps -GNOME and GTK-based apps -Other desktop software (OpenOffice.org, Mozilla etc) -Hardware (/kernel here too?) > - What could we do to improve 9.3/10.0 development. One big issue is that users sometimes don't know if an issue that irritates them is a bug or a feature. The reason for this is that there is no documentation on the design of features. Also, since there is no documentation on the design of features, bug reports/suggestions/criticism can only be given when significant time has been invested in it. The aspect that is going to be used for many problems is going to be used again here: drakconnect. Some fundamentals are wrong, and by the time people used it/filed bugs on it, it was too late. > > - What should we do to improve the Wiki. Make it more visible on Mandrake web sites. Do more "concept design" work on the wiki. > - Should we have cooker snapshot ISOs? IMHO, no. I believe there should be a mini ISO specifically for hardware testing that any user can run without a large download or any risk of messing up any installation. Boot it, see if your hardware works for installation purposes, and some basic tools for reporting hardware problems. > - What could we do, as a community, to increase the acceptance of mandrakelinux? There it too little press on the community aspects of Mandrake. Redhat hasn't got a development community, but probably most non-Mandrake users would think they do. > - How to have more contributors? We need clear documentation/instructions on how to contribute. At present, contributor status seems random (he who bugs Lenny the most gets an account). There are a number of contributors who don't have accounts yet (IMHO Luca Olivetti at least should have one), but no process for becoming a contributor. Also, some contributors aren't subscribed to the lists they should be (even though they have aksed to be subscribed). One thing that oculd be done would be to make more of the inrastructure of thow accounts etc work public, and possibly appoint community members who can add accounts or fix some things (yes, I know this could be a problem for Mandrakesoft, but you trust me not to trojan samba, so why would you not trust me to add accounts). Part of this may be due to ad-hoc setups for authentication etc, and I think Mandrake needs to sort these issues out using the tools that are provided in the distro (ie get single-sign-on across all mandrake websites, using ssl where appropriate, including logins on development machines). More official development status needs to be given to the ports, and we need to make it easy for contributors to fix bugs on arches they don't have access to (like at present the only tool I have to fix the samba3 build on amd64 is using slbd output which isn't used/supported by Mandrakesoft but by the development extranet). > And anything related to the mandrakelinux distro. Mandrakesoft needs to find a market that is more profitable (I believe there is one), and ensure the next disto blows any other out-the water in this market). I believe that is in the corporate desktop, with totally integrated client/server solutions. Basically, Mandrakesoft should try and be the first to offer seemless authentication support using the tools in the distro. We can feasibly have authentication servers and setup tools supporting every client OS. A big issue here is managing large (>5000) numbers f desktops. MS does this with AD-integration on the clients, which allows software installation, software settings etc etc to be managed by groups of machines instead of individually. IMHO, it's feasible for Mandrakesoft to have >60% of that functionality in under 6 months. You need to be able to sell an IT infrastructure solution. At present, only one (maybe 2 soon with SUN's linux desktop, though I haven't seen anything on enterprise client integration) competitor can do that, and they are making a lot more money ... Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ***************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *****************************************************************
