Mandag den 2. august 2010 10:43:43 skrev Stephan Kulow:

Am Mittwoch 28 Juli 2010 schrieb Stephan Kulow:

...

Hi,

Not much news, but I put a first scretch of an 11.4 roadmap here: http://www.suse.de/~coolo/opensuse_11.4/

But I'm thinking about leaving out Milestone1 (which of course would actually mean Milestone7 is Milestone6 ;) - mainly because I'm on vacation in august, but I know many more are.

As the feedback for the 11.3 release was pretty small I did the 11.4 roadmap very much based on the 11.3 data - with a bit more room around new year. We'll see how this works out - KDE 4.6 should at least fit perfectly for the last milestone and I have not yet seen plans for the release after GNOME 3.0, so I don't know - but I guess 11.4 will have GNOME 3.0.X.

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

I think no feedback is good feedback in this case :-) 11.2 did well, and 11.3 would have been very good if X and the kernel hadn't been so buggy (for which I blame upstream, until proven wrong). So I think the fixed 8 month cycle is working well, same for the freeze periods etc. For 11.4 I'd personally sleep a bit better at night if final release could be moved back a couple of weeks. Because from a KDE perspective the schedule is a biiiit too tight for my liking. Does the 8 month schedule force us to a specific release date, or is it just "March"? And maybe an extra effort should be made to shove the roadmap in the faces of SLE centric Novell employees - since they have a tendency to get a lot of good ideas _after_ feature freeze. Maybe there's some form of internal calendar every Novell developer shares, in which the roadmap could be entered? Regarding GNOME3. Did you write the original mail before or after the latest delay of GNOME3 was announced? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 02 August 2010 11:11:44 Martin Schlander wrote:

For 11.4 I'd personally sleep a bit better at night if final release could be moved back a couple of weeks. Because from a KDE perspective the schedule is a biiiit too tight for my liking. Does the 8 month schedule force us to a specific release date, or is it just "March"?

We decided: Thursday <= 15 of release month. If we open the discussion for moving because of project X, then project Y needs to be considered etc. - and we're back at where we started with no reliable schedule :-/ Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On 02.08.2010 10:43, Stephan Kulow wrote:

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

Greetings, Stephan From an end-user point of view, it would be nice if the closed source graphics drivers packages could be pushed to their repositories/vendor sites upon release, not 2 weeks after that. It doesn't have to be the latest cutting edge version, but one that provenly works and gets the system up and running. Updating it later when there is more time is fine.

I know some people could care less about this, but as openSUSE can be considered as not primarily targeted at servers, it stains the whole experience. R. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Aug 2, 2010 at 5:41 AM, Stephan Kulow wrote:

Am Montag 02 August 2010 schrieb madworm_de.novell@spitzenpfeil.org:

...

  On 02.08.2010 10:43, Stephan Kulow wrote:

...

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

Greetings, Stephan

 From an end-user point of view, it would be nice if the closed source graphics drivers packages could be pushed to their repositories/vendor sites upon release, not 2 weeks after that. It doesn't have to be the latest cutting edge version, but one that provenly works and gets the system up and running.

That highly depends on having maintainers for those.

But doesn't it also depend on the allowed calendar time? The building of external repos other than packman doesn't appear to start prior to GM being nailed in OBS. For 11.3, it took about 3 weeks after GM in OBS for the nvidia external repo to get the latest nvidia driver compiled against 11.3. Thus allowing 3 weeks between GM naildown in OBS and formal release would give the teams updating the external repos time to do it. Along the lines of having a more extended period of time between GM in OBS and formal release, there was a discussion on the -project mailing list to allow openSUSE members a period of early access to the GM release. The only way to achieve that is also to delay formal public release. So if both of the those objectives could be achieved, I'd vote to lengthen the time between GM tagging in OBS and formal public release. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 03, 2010 at 10:08:39AM +0200, Stephan Kulow wrote:

Am Montag 02 August 2010 schrieb Greg Freemyer:

...

On Mon, Aug 2, 2010 at 5:41 AM, Stephan Kulow wrote:

...

Am Montag 02 August 2010 schrieb madworm_de.novell@spitzenpfeil.org:

...

On 02.08.2010 10:43, Stephan Kulow wrote:

...

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

Greetings, Stephan

From an end-user point of view, it would be nice if the closed source graphics drivers packages could be pushed to their repositories/vendor sites upon release, not 2 weeks after that. It doesn't have to be the latest cutting edge version, but one that provenly works and gets the system up and running.

That highly depends on having maintainers for those.

But doesn't it also depend on the allowed calendar time?

The building of external repos other than packman doesn't appear to start prior to GM being nailed in OBS.

For 11.3, it took about 3 weeks after GM in OBS for the nvidia external repo to get the latest nvidia driver compiled against 11.3.

That's a nice theory, but I have another one: it took 2 weeks after formal release to update the nvidia repos.

That's just wrong. 11.3 has been released on July 15th. July 16th-18th I joined Novell's outdoor event near Prague. July 19th I could prepare the packages, which then were online I believe on July 20th. NVIDIA is pretty fast with that. Remember NVIDIA is *not* ATI/AMD! I never prepared the NVIDIA/ATI packages before release since what usually happens is that kABI still changes for GM/final release. Which is fatal for KMPs as you know for sure.

The time between GM and release should be short, because at that time we're 100% frozen and everyone has to stand still. I don't want to have a whole project stand still just because the maintainers of the nivida binary repos aren't able to compile the drivers for RC1.

You can make sure that kABI doesn't change between RC1 and GM? We even didn't manage that for our latest SLES product! For openSUSE just forget about that!

I'm using nouveau just fine

Bugzilla is full of nouveau driver bugs. Many of these can be workarounded by using 'nomodeset'. These are already closed. But then you basically rely again on the nvidia driver.

and my prediction is that nvidia binary only drivers are even less a factor for 11.4 release.

Hopefully. We'll see. CU, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

You can make sure

On Tuesday 03 August 2010 10:45:09 Stefan Dirsch wrote: that kABI doesn't change between RC1 and GM? We even

didn't manage that for our latest SLES product! For openSUSE just forget about that!

All you need is a stable aPi, then you can work out the build problems with plenty of time left before final release, and when GM is done all you need is to trigger a rebuild I believe the kernel aPi has been relatively stable. If there are late changes to it, then something is seriously wrong with the release process Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tuesday 03 August 2010 11:16:33 Stefan Dirsch wrote:

kABI not API. We're talking about KMPs here.

I realize that, but as long as the kernel's API for the module hasn't changed, it isn't so important if the ABI changes. You can still work out all the build problems, and then when the final ABI is in place you just trigger a rebuild, which for a KMP shouldn't take more than a few minutes Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 03, 2010 at 11:25:54AM +0200, Marcus Meissner wrote:

On Tue, Aug 03, 2010 at 11:23:44AM +0200, Anders Johansson wrote:

...

On Tuesday 03 August 2010 11:16:33 Stefan Dirsch wrote:

...

kABI not API. We're talking about KMPs here.

I realize that, but as long as the kernel's API for the module hasn't changed, it isn't so important if the ABI changes. You can still work out all the build problems, and then when the final ABI is in place you just trigger a rebuild, which for a KMP shouldn't take more than a few minutes

There also is a freeze time between the actual finishing of the distribution and the public release of it.

This was 4? 5? days this time(?).

In this time we could have got NVIDIA drivers ready.

It just needs Coolo to trigger the responsible people I guess.

.. which he obviously didn't. Also for me openSUSE has the lowest prio you can imagine. Best regards, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tuesday 03 August 2010 12:29:14 Stefan Dirsch wrote:

Of course it's important if the kABI changes. If the kABI for which the KMP has been built no longer matches the kABI of the installed/updated kernel the module of the KMP simply cannot be loaded. We do not rebuild KMPs on the user's machines when kABI has changed. That's not how KMPs work. Instead for using KMPs kABI *must not* change.

Yes, of course. But we are talking about preparation during a beta/RC phase, not about post-release changes. It would be very possible to start working out the build issues for RC1 regardless of whether the ABI changes in RC2 or 3. The package prepared for RC1 should still build, so when the gold master becomes available, you just need to trigger a rebuild, and things should work out. In the present case I believe the biggest problem was that files had been moved around, and those issues could have been solved when RC1 was released. Obviously if the ABI changes after the final release, it becomes more of a problem. Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tuesday 03 August 2010 12:52:00 Stefan Dirsch wrote:

That's an unsolvable one for KPMs.

Why? We expose the ABI hashes as rpm "provides" which the KMP can "require", and it can require the kernel version number as minimum version. Where is the problem? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 03, 2010 at 12:59:54PM +0200, Anders Johansson wrote:

...

On Tuesday 03 August 2010 12:52:00 Stefan Dirsch wrote:

...

That's an

unsolvable one for KPMs.

Why? We expose the ABI hashes as rpm "provides" which

On Tuesday 03 August 2010 13:06:41 Stefan Dirsch wrote: the KMP can "require", and it can require the kernel version number

...

as minimum version. Where is the problem?

So you're requesting several KMPs using different package names to avoid package name conflicts for kernels, which change their kABI? I believe I have enough fun with NVIDIA. :-(

I'm not requesting anything. I'm telling you how it is done today for ofed and other KMPs we deliver for SLES and SLED through the maintenance process. There is no need for different names, just updated version/release numbers. The standard is to use the kernel version/release number that has the changed ABI as part of the KMP release number. If people update their kernel, they will automatically get the KMP updated as well (or it gets uninstalled because of missing dependencies, in case it hasn't been updated yet), and if they want to keep the old kernel by installing the new with "rpm -i" then they can do the same with the kmp. The only changed names for KMPs that I'm aware of is that we have one name per kernel flavour. Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 03, 2010 at 01:12:38PM +0200, Anders Johansson wrote:

...

On Tue, Aug 03, 2010 at 12:59:54PM +0200, Anders Johansson wrote:

...

On Tuesday 03 August 2010 12:52:00 Stefan Dirsch wrote:

...

That's an

unsolvable one for KPMs.

Why? We expose the ABI hashes as rpm "provides" which

On Tuesday 03 August 2010 13:06:41 Stefan Dirsch wrote: the KMP can "require", and it can require the kernel version number

...

...

as minimum version. Where is the problem?

So you're requesting several KMPs using different package names to avoid package name conflicts for kernels, which change their kABI? I believe I have enough fun with NVIDIA. :-(

I'm not requesting anything. I'm telling you how it is done today for ofed and other KMPs we deliver for SLES and SLED through the maintenance process. There is no need for different names, just updated version/release numbers. The standard is to use the kernel version/release number that has the changed ABI as part of the KMP release number.

You would like to see KMPs with the same package name and just different version/release numbers for the different kABIs in the same repo? I'm not sure whether this is going to work with NVIDIA's repo. Maybe, nobody ever tried so far AFAIK. And honestly I would like to avoid that.

If people update their kernel, they will automatically get the KMP updated as well (or it gets uninstalled because of missing dependencies, in case it hasn't been updated yet), and if they want to keep the old kernel by installing the new with "rpm -i" then they can do the same with the kmp.

The only changed names for KMPs that I'm aware of is that we have one name per kernel flavour.

Sure, that suffix is autogenerated. Best regards, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, 2010-08-03 at 10:08 +0200, Stephan Kulow wrote:

The time between GM and release should be short, because at that time we're 100% frozen and everyone has to stand still. I don't want to have a whole project stand still just because the maintainers of the nivida binary repos aren't able to compile the drivers for RC1. I'm using nouveau just fine and my prediction is that nvidia binary only drivers are even less a factor for 11.4 release.

just a final drop... Perhaps it might help if version (n+1) was enabled earlier on the OBS??? (yes, i know about factory. Perhaps it is just psychological barrier) It always surprised me that a new version is weeks earlier available on packman and that packages on the OBS only start to apear after GM. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

madworm_de.novell@spitzenpfeil.org schrieb:

From an end-user point of view, it would be nice if the closed source graphics drivers packages could be pushed to their repositories/vendor sites upon release, not 2 weeks after that.

I disagree somewhat, as I think that from an end-user point of view, it would be nice if top-class open drivers would be shipped right with the product and nobody would need to care about botched binary blobs from elsewhere. ;-) While we are rolling out the wishlist, let's do it right! :) Of course, things only really change, if we put in our own work - and that we obviously need to leave to those areas we understand or are able to learn. What are you up for? Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 02 August 2010 10:43:43 Stephan Kulow wrote:

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

I started replying on Saturday but binned it because I had nothing to add apart from lame puns about stretching/sketching the release schedule. Looks fine for me - with KDE SC 4.6 tagged the day before M7 we then have a good month to knock the major bugs out of the desktop, if we can organise earlier testing. I'm playing with the idea of asking for a late update to 4.6.2 since there will be plenty of fixes after a .0 release. Maybe GNOME can ship a 3.0 preview as an option and online update to 3.0 final after release? Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 02 Aug 2010 09:43:43 Stephan Kulow wrote:

Am Mittwoch 28 Juli 2010 schrieb Stephan Kulow:

...

Hi,

Not much news, but I put a first scretch of an 11.4 roadmap here: http://www.suse.de/~coolo/opensuse_11.4/

But I'm thinking about leaving out Milestone1 (which of course would actually mean Milestone7 is Milestone6 ;) - mainly because I'm on vacation in august, but I know many more are.

As the feedback for the 11.3 release was pretty small I did the 11.4 roadmap very much based on the 11.3 data - with a bit more room around new year. We'll see how this works out - KDE 4.6 should at least fit perfectly for the last milestone and I have not yet seen plans for the release after GNOME 3.0, so I don't know - but I guess 11.4 will have GNOME 3.0.X.

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

Greetings, Stephan

Hi .. Hows about a couple more RC releases before going GM fix some of the last minuet frell up's prior to release Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34-12-desktop KDE Development Platform: 4.4.4 (KDE 4.4.4) "release 2" 13:30 up 5:32, 3 users, load average: 0.15, 0.14, 0.09 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 02 August 2010 schrieb Atri:

On Mon, 2010-08-02 at 10:43 +0200, Stephan Kulow wrote:

...

There is really no feedback or suggestions? Come on guys, when the last RC is released, everyone wants to be release manager, but now I'm alone again?

Greetings, Stephan

Is this the right place to discuss focus points for openSUSE 11.4 or is that a new thread?

That's a new thread clearly. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 02 August 2010 schrieb Vincent Untz:

If we do Milestone 1, I guess that means we need to submit things before this Friday, is that right? My gut feeling is that we should do it to make sure that what we have in Factory today actually works, but if vacation makes it harder, that's another story...

We build live cds in any case day by day - the KDE one is currently stuck because of KDE 4.6, but the GNOME one builds fine.

I must admit I'd like to push the feature/version freeze for the base system and the complete distro a month later (or maybe just a few weeks?) since it feels a bit early to me, and I had the impression that many people were pushing to include new upstream versions after the freeze for 11.3.

Given the amount of valid bugs received during RC1 and RC2 (compared to the rest of the cycle), I wonder if there's something we can do here: either a bit more time between RC1 and GM, or maybe get more people testing Milestone 7 (by giving it a Beta label?).

A month for a RC freeze is already a lot of time - I wouldn't want to enlarge this or we get even more "we have to take this" changes. Changing the label of Milestone 7 is something we can discuss, but then we're back at "why only one Beta?" and I don't want to go there really. With the work flow we have and the hard to predict upstream developments, it's very hard to follow typical expectations of "Beta" and "Alpha". Perhaps someone has a better idea? Or count the milestones back to 0? This would make the count down character more clear and give milestone 0 some speciality.

Since GNOME 3.0 has slipped to March, we'll miss it anyway (it'll likely be released at the end of March, and unless we release in April or May, it'll be hard to ship it for 11.4). The current plan is to put it in a specific project in the build service, so people can easily upgrade to it when it's ready after 11.4 gets out.

That sounds like a good plan. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 02 August 2010 schrieb Marcus Meissner:

On Mon, Aug 02, 2010 at 11:49:09AM +0200, Stephan Kulow wrote:

...

Changing the label of Milestone 7 is something we can discuss, but then we're back at "why only one Beta?" and I don't want to go there really. With the work flow we have and the hard to predict upstream developments, it's very hard to follow typical expectations of "Beta" and "Alpha". Perhaps someone has a better idea? Or count the milestones back to 0? This would make the count down character more clear and give milestone 0 some speciality.

Counting down sounds like a good idea ... It gives a sense of urgency. :)

Not sure what happens if you want to insert another milestone, but that didnt happen for 11.3 AFAIK?

We didn't move numbers before either, but added e.g. Beta3plus Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 08/02/2010 09:10 AM, Atri wrote:

Also, I see there is a duration of 6 days between RC2 and GM. Though I understand that RC2 is supposed to be THE version, I think it would be good if there is a period of at least 10 days between RC2 and GM during which rough edges, solely based on the PM's discretion, can be ironed out. What I think would help is a period where the PM decides, based on inputs from testers throughout the release cycle, on marking bugs that absolutely must be fixed by when the release hits GM. This bug highlighting process could be done by the PM on RC1 release date or something like that, and I am guessing that 10 days between RC2 and GM would help fix them up. It would probably polish the experience and give it some glitter. What do you think?

My impression with 11.3 was that there was very little time between RC2 and GM being sent to the mirrors. Any bugs not caught by RC1 and not fixed by RC2 were released. If the intent is for RC2 to be GM, then the short time is OK. Is it possible to add an extra week between RC1 and RC2? @Coolo - From my perspective, the whole process improved a lot between 11.2 and 11.3. In the Forums, the majority of problems have been the usual ones with proprietary drivers (mostly graphics) and upstream difficulties with the 2.6.34 kernel. In wireless networking, so far only one minor bug has been found in a configuration that I could not test - no available hardware, and it has been fixed. We certainly had nothing like the networking difficulties in 11.2 GM. Please accept my congratulations. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 02/08/2010 11:34, Vincent Untz a écrit :

Given the amount of valid bugs received during RC1 and RC2 (compared to the rest of the cycle), I wonder if there's something we can do here: either a bit more time between RC1 and GM, or maybe get more people testing Milestone 7 (by giving it a Beta label?).

many people begin using new version only after RC, because milestone is advertised as "not to be used"!! May be milestones should be more specific. let me detail. Factory is constantly moving, and highly unstable. that's normal. Milestone should be more detailed. For example milestone 1 could be identical (as much as possible) to stock 11.3 with updates + new Gnome, and the users asked to test specifically Gnome. Milestone 2 could be milestone 1 + kde... (M3 kernel, M4 gcc...) I mean inserting new things slowly, to be able to *use* the milestone. *OR* Milestone could be reduced to a small set, for example Gnome live cd. I don't think it's really possible to test a distro without using it really to make real work. don't know if all this is possible at all :-( jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 02/08/2010 12:24, Stephan Kulow a écrit :

And while we "advertise" milestones as not ready for production systems, they have a much higher quality than a random factory snapshot. For one the most annoying bugs are usually known.

well.. I remember milestone (or beat) not being installable at all on virtualbox :-( may be the usability expected should be better advertised (if possible at all?), all this to have more testers jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 02/08/2010 12:37, Stephan Kulow a écrit :

Virtualbox is just a random PC in that definition.

yes, but it's the PC everybody can use to make a demo or get a look at the new distro. It's also the only PC you have that is the same as I have, so easier to debug. so such virtual test should always work! jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Yeah, but VB is only #5: http://www.cyberciti.biz/tips/linux-virtualization-software.html

But dead easy to use. Some of the others on the list are a no-go for normal users, or at least are too troublesome to get started with just for testing purposes. Virtualbox (and maybe VMware, at least on windoze) could get the maximum amount of (casual) testers involved with minimum effort. R. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org