[opensuse-factory] Status: distribution
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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Mittwoch 28 Juli 2010 schrieb Stephan Kulow:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2 August 2010 10:43, Stephan Kulow <coolo@novell.com> wrote:
Isn't it a bit risky to leave out a Milestone ? Or do I not understand well what it means ? beyond that, I tihnk that the schedule used for 11.3 was quite good, so... I don't have many suggestions, sorry ;-) Greetings, Agemen. -- OrbisGIS supporter. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Mandag den 2. august 2010 10:43:43 skrev Stephan Kulow:
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 02/08/2010 19:11, Martin Schlander wrote:
Be realistic. It could also mean that nobody gives a damn :-) . BC -- If nothing happens, nothing can go wrong. -- 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:
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
Le lundi 02 août 2010, à 11:53 +0200, Andreas Jaeger a écrit :
Is this (and the 8 months development cycle) documented somewhere? It'd probably be useful to have a wiki page about this to make sure we don't forget this kind of information in case some new people will work on the schedule in the future :-) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 02.08.2010 10:43, Stephan Kulow wrote:
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 <coolo@novell.com> wrote:
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
Am Montag 02 August 2010 schrieb Greg Freemyer:
That's a nice theory, but I have another one: it took 2 weeks after formal release to update the nvidia repos. 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. Greetings, Stephan -- 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:
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.
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
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 Tue, Aug 03, 2010 at 11:06:16AM +0200, Anders Johansson wrote:
kABI not API. We're talking about KMPs here. That's all about politics in kernel development here. Always try to break kABI (also API if possible) to make things difficult for 3rd party modules. Especially for modules which use binary blobs. 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 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:23:44AM +0200, Anders Johansson wrote:
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. Ciao, Marcus -- 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:
.. 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 Tue, Aug 03, 2010 at 11:23:44AM +0200, Anders Johansson 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. 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:
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 Tue, Aug 03, 2010 at 12:45:51PM +0200, Anders Johansson wrote:
Rebuilding the packages against openSUSE 11.3 took me about an hour or something like that. It has been built against Factory all the time anyway. This wasn't an issue at all. Adjusting the specfiles for 256.35 was done at a later point.
Obviously if the ABI changes after the final release, it becomes more of a problem.
That's an unsolvable one for KPMs. 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: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:
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. :-( Thanks, 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 13:06:41 Stefan Dirsch wrote: the KMP can "require", and it can require the kernel version number
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, Anders Johansson wrote:
The standard is for the package manager (zypper/YaST2, whatever) to warn the user about the broken dependency. The user decides if that shall happen or not. The package will never automatically break the system. It will simply refuse to install the new kernel.
The only changed names for KMPs that I'm aware of is that we have one name per kernel flavour.
And that gets autogenerated during package build and therefore only requires the packager to use the right macros. The dependencies on kernel symbols also get added automatically. I don't understand the big fuzz here. Daniel -- 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:
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.
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, Aug 3, 2010 at 10:08, Stephan Kulow wrote:
Are you using KDE4 and the nouveau drivers? They do not mix well on 11.3. Using nouveau results in graphics corruptions (eg icons in the taskbar get scrambled), and you can't use composite - well, that's my experience anyway (and discussed by many other users in various mailing lists and forums). I never tested Nouveau with Gnome in 11.3 before I bumped to the nVidia proprietary drivers. On other discussion points... testing, and the fact that the majority of "real" user testing starts around RC1 or RC2... I'm somewhat guilty of that myself. I cannot afford to bring down my computers for an install - especially if it's a potentially broken Milestone install. Now, even with the final releases I wait 2 or 3 weeks post release to do the actual install... gives time for those last annoying bugs to hopefully be fixed via online updates. I have a feeling a significant number of us are in the same situation... the only testing we can do is in VirtualBox.... which, while is a nice testing platform doesn't equal a real install with all the oddities that come with that... and these oddities start coming out when the real installs start shortly before release. i don't know of a solution to this... it's just an observation. C. -- 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:
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
Am Freitag 13 August 2010 schrieb Hans Witvliet:
11.3 was available very early in the build service and you could build against it, but basically only built against factory. But only very few projects found it worthy to duplicate the build. Greetings, Stephan -- 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:
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 Mon, 2 Aug 2010 10:43:43 +0200, Stephan Kulow <coolo@novell.com> wrote:
How about getting the existing packages updated to the latest stable release on each package eg kernel kde Cheers Glenn -- 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:
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
We did have a GNOME 3.0 preview since openSUSE 11.2 and it's dead easy to install and is consequently offered as a possible DE during Login. It's unfortunate that we slip the GNOME 3.0 release, an online update MIGHT be a possibility, but it might also be way too intrusive (think GTK2 -> GTK3 switch for example). Luckily we do have some time to sort it all out until March. I'm sure the GNOME Team will come up with the best solution there is (hint: everybody can participate in the GNOME team and be part of the solution) Dominique -- 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:
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
On Mon, 2010-08-02 at 10:43 +0200, Stephan Kulow wrote:
Is this the right place to discuss focus points for openSUSE 11.4 or is that a new thread? Bye -- Atri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Le mercredi 28 juillet 2010, à 12:06 +0200, Stephan Kulow a écrit :
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... 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?). 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. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- 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:
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.
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.
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
On Mon, Aug 02, 2010 at 11:49:09AM +0200, Stephan Kulow wrote:
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? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2010-08-02 at 11:49 +0200, Stephan Kulow wrote:
Hi! I like the countdown idea, but being markedly different from how other distributions do it, it might confuse new testers don't you think? 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? Bye -- Atri P.S.: I am sorry if I am messing up the mail thread here, but I somehow lost all my mails, and I could only reply after I received the referenced mail. -- 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:
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
Am Montag 02 August 2010 schrieb Atri:
I have a SHIP_STOPPER flag we use to highlight these bugs. And 6 days are really enough, because we shouldn't release RC2 if there are bugs that need 10 days. The distribution is frozen for a long time by then, so new bugs at that point of time are usually only hitting a minority or are a regression that can be fixed quickly. We can move RC2 earlier, but then we get complaints that the time is too long and that we need yet another release in the middle - and all we'll do is downloading. Another small problem is that the week of RC2 is a special one for me personally ;) Greetings, Stephan -- 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 :
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
Am Montag 02 August 2010 schrieb jdd:
That won't work. We try to limit the things in one checkin round, so that a e.g. FTP tree is published before we take the new kernel - but milestones are too infrequent to limit them so strictly. 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. Greetings, Stephan -- 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 :
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
Am Montag 02 August 2010 schrieb jdd:
Well, I'm sure it was listed as known bug. Bugs happen and bugs take their time to get fixed. Milestones can't be perfect, but they all have a live cd that boots and a DVD that can be installed on a "good enough" set of hardware. Virtualbox is just a random PC in that definition. Greetings, Stephan -- 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
Am Montag 02 August 2010 schrieb jdd:
Yeah, but VB is only #5: http://www.cyberciti.biz/tips/linux-virtualization-software.html Greetings, Stpehan -- 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
participants (23)
-
Alexis "Agemen"
-
Anders Johansson
-
Andreas Jaeger
-
Atri
-
Basil Chupin
-
C
-
Daniel Rahn
-
doiggl@velocitynet.com.au
-
Dominique Leuenberger
-
Greg Freemyer
-
Hans Witvliet
-
jdd
-
Larry Finger
-
madworm_de.novell@spitzenpfeil.org
-
Marcus Meissner
-
Martin Schlander
-
Peter Nikolic
-
Robert Kaiser
-
Stefan Dirsch
-
Stephan Kulow
-
upscope
-
Vincent Untz
-
Will Stephenson