Rajko M. wrote:
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
It is attempt to find the way around basic problem how to get more testers involved and have something that is very usable, and needs fewer patches during lifetime. Creating patches is developer time. From openSUSE/Novell perspective there is very small difference between that time used before release, and after, but user experience is very different.
Well, here is what I see.
Problems in development release that scare 99% of todays users: 1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else) 2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden. 3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode") 4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu, 6) ...
Uaesrs need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed.
Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now.
It is nice to have many new kernel features included, but if that means broken result, what is use of those features?
Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows.
Then slow down a bit whole process, please. I barely had time to download and install some releases and it already was time for a new one, before I had setup to test with. I don't think that I'm special in this respect.
In another thread "release as an add-on" we ended up talking about changing the release cycle to something like 12.0 major revamp and early adopter aka factory = full dvd 12.1 version updates,bug fixes,security = upgrade dvd and\or patch cd 12.2 major bug fixes and security updates = upgrade dvd and\or patch cd 12.3 stable lts version and SLE RC1= full dvd How about we work towards the 3 goals at once. We could do this: 12.0 major revamp and early adopter aka factory = "1-click" upgrade repository or upgrade cd\dvd -no full dvd 12.1 version updates,bug fixes,security = "1-click" upgrade repository or upgrade cd\dvd -no full dvd 12.2 major bug fixes and security updates = dvd or patch cd and "1-click". End all feature changes, spend next nine months on stabilization 12.3 stable lts version and SLE RC1 = full dvd \ Boxed release with 24 months of updates. This reduces time spent on building DVD's , increases openSUSE functionality testing by producing an online upgrade for "bleeding edge" components and produces a Boxed version to give to Grandma or "insert computer illiterate person's name here". What I read with every release is the review that starts " I've been a SuSE fan since (insert 1.0 - 9.3), and I've tried all the releases since Novell bought them, yet I run (insert other distro here) because I have to fix(insert fiddled with component here) to get (insert component name here) running." We need to get the idea out there that, the community aka bleeding edge versions are just that, and that the x.3's are what Novell is considering as SLE replacement's. (Make public references to SLED which could even drive SLED sales) This tells the average "Joe Plumber" that if He downloaded or purchased x.3, He's getting some really well "polished" stuff and he gets 24 months of updates which takes him to the next SLE /_*candidate*_/(never committing to an inevitable SLE status), He says "That is some cool stuff. Enterprise quality software at bargain pricing." This is the kind of reputation Ubuntu is building. example: My brother (MCSE) was so sick of Windows he bought a MAC, he asked me what I would do with his old PC hardware. I said "I would build an openSUSE server for music and videos and put a copy on the laptop too" He decided to try it out. openSUSE 10.3 , would not load on his Toshiba laptop. He installed Ubuntu then called me and said "Hey, I couldn't get that stuff you suggested to boot after install, but, I found this Ubuntu distro and it did. A few weeks later he said, "I wanted more multimedia stuff so I installed Linux Mint, man this Ubuntu stuff is cool. what do you think of MythBuntu?" Imagine my heartbreak. Now I know with a few minutes on the phone I probably could have gotten him running, but, he isn't that weak of a computer guy so He just Googled his way onto Ubuntu. JT -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org