> On Thu 2003 Oct 23 at 13:01, "Buchan Milne" <[EMAIL PROTECTED]> wrote, > > in part: > > ... > > But, I don't think anyone on this list qualifies as a newbie. > > People on this list should be testing at least half the betas > > on at least one machine, and/or running cooker full-time on a > > box (if you don't, you're most probably a lurker ;-)).
I'd love to run cooker and am more than competent to test it but there are some minor issues that I think you'll find common among most of the lurkers like me. 1) I only have one computer (University Student) it's an oldish system (k6-2 500Mhz) that runs everything alright if abit slowly. But it's my only computer and is used daily. I'd like to run cooker on it but, I need it to be useable I can not risk having it go down for a day or two due to a bug in cooker or one of the apps I use being unusable for a day or two while bugs are sorted out. I know there are ways to install multiply versions of linux on the same machine and this would work quite well having the current stable version on one partion and cooker on the other would allow cooker to be used all the time while giving me a method to use my computer if the cooker install stuffed up due to bugs. How ever I don't know enough about how to set this up and have never been interested enough to find or work it out due to the second and Major problem. 2) Bandwidth or datacap/international data costs. This I think is the biggest problem many Lurkers I think you'll find are using either 33.6K, 56k modem's or Broad band or semi broad band (eg I've 128Kbps ADSL) with a datacap eg 500MB-5GB a month of international traffic. Those with standard Modems simply can not keep up with the rate at which changes are made with new versions coming out before they've even finished downloading the previous ones. While those with the Broadband and datacaps either simply can't afford to download (eg only 500MB international traffic) all the changes or are unsure about how much data updating is going to take and can't risk going over their cap, As over the cap people tend to get charged rather high prices for every extra MB. In NZ it's about $0.20 a MB which if you go over the cap by a fair amount say a couple of GB works out to a fair amount of money. 3) Bugzilla It's big it's and it's slow and there nearly allways seems to be some sort of problem with it. There are ways around these problems and working them out I think would significantly increase the number of testers. Some of these Ideas would help quite alot I think. 1) Develop a guide or utility for installing cooker easily along side another Distro or release. Or simply away to install two separate copies of the current release on too separate partions, urpmi can then update it easily enough. 2) Provide a guide or a tool to use rsync to maintain a mirror of those packages you've currently got installed using cooker. Most people will not install every thing on the various cooker tree's. If urpmi or some other tool could make a mirror of just those packages you've installed from cooker on the drive and maintain it using rsync alot of bandwidth and time could be saved making it easier for those with limited datacaps or bandwidth to maintain their cooker install. 3) Have weekly, biweekly or monthly branches. Demi freezes. Again those with limited bandwidth or data limits would find this easier to work with. If they could download a branch of cooker that would remain stable for a couple of weeks or months they'd be able to heavily test out cooker finding valid bug with out having to update daily combined with an rsync mirror util this would allow the amount of bandwidth required to keep up with a usefull version of cooker reasonable. This would be especially usefull for those with 56k connections. As they would not have to worry about version changes when updating using this source. and would only have to update once or twice a month. This would also probably help to find and ID bugs better with multiply users using exactly the same versions of cooker bug's could be Id and tracked much better. It would probably also allow more in depth testing of new feature allowing more bug's to be found .As if they found a bug unless it made the system unusable they'd stay with that package and continue to test it looking for other bugs rather than straight away downloading a new package that while fixing the current bug with a patch introduced half a dozen new patches and bugs. 4) Test Install ISO's Small 100-200MB isos that contained just a minimum install and A desktop allowing detailed testing of CORE packages and installation. eg KDE + the main apps oo.org gimp etc. Produced monthly or biweekly again updateably by rsync. Most likely 2 or three would be needed. KDE + OO.org + Gimp + Mozilla. Gnome + OO.org + Gimp + Mozilla. And say. Icewm + Server apps. NO "development packages" NO "extra libs" just a small neat Desktop install the kind that most USERS use which as far as I'm concerned should work perfectly in all releases. People can like with RANDOM-APP-XXX not working but they'll never support a distro can't get the install + basic desktop working. This could also be used to test out the upgrade feature properly. 5) A small "fast easy" to use client side front end for Bugzilla! With a nice simply understandable name and Description so that non developers testing can understand it. eg. BUG-Reporter >> Used to report bugs to Mandrake. Possibly with some scanning ability to grab system details (with the users permission of course) about the computer from /proc/ and package versions for any apps that the one reported to have a bug in has listed as a dependency. Chad
