On 8 July 2011 09:02, todd rme wrote:

On Thu, Jul 7, 2011 at 3:43 PM, Kim Leyendecker wrote:

...

From my point of view, it makes more sense to declare a  release that�s still very unstable and in a early development status as  "Milestone", a half-way ready release as "Beta" and a three-quarter  ready release as "RC".

 Something you would agree with?

If you are going with that route, why not just use "alpha", "beta", and "rc"?  This would send a clear message to people what level each pre-release is at.  I personally never much liked the idea of using milestones because it wasn't clear when it would be expected to be usable.  Using alpha, beta, and RC would put things in clear terms for potential testers, while I don't think milestone does.

Think that was the justification for just using "Milestone" as it depends what was ready to go into Factory, an M1 or M2 might be very useable, precisely because it has only had minor package updates, rather than system breaking things. The "Beta Pre-release" of 12.1, might be our first on Kernel 3.X, KDE 4.7, FF 7 and so on, especially if useable pre-release versions of software are permitted, so emphasising upgrade path to the RC series, then GM & final via updates, may be rather marketable. There's going to be "Release" Fever in October with Ubuntu & (presumably) Fedora releasing then. My concern with planning a "boosted launch" of a time based "Beta" MS is that the new features which are wanted in November, aren't in a shippable state in September. General issue with time based releases though, which aren't snapshots of production worthy rolling releases. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 07/08/2011 11:56 AM, Kim Leyendecker wrote:

I associate with the world Milestone a release that is the first release of the *whole* project, like the Moziila milestones were in the past.

At the same point there´s the problem that M2 maybe become more stable then M5 because ther were much more changes from M4 to M5 then from M1 to M2.

So, Alpha, Beta, RC would work out better, I think.

Perhaps. I have no strong feelings on that point. All I know is that as long as general testing starts with RC1, my observations on the last 3 releases say that some of those same bugs will end up in GM. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Friday, July 08, 2011 01:58:02 PM Karl Eichwalder wrote:

Maybe, you can fool users with "clever" naming, but only once. It is surely not worth trying.

Our only problem is to try a bit harder to be as close to conventions as possible, ie. meaning of Alpha, Beta and RC. Users didn't quit attempts to use development releases in a day, it took some time of upside down stability to run them away. I don't know how possible is to have "normal" stability taking that distro has only what upstream offers and in 8 months there is a lot of upstream development, so loading Alpha with a new software, then making only minor changes during Beta and nothing, but bugfixes in RC, will result in final version few months behind upstream. With kernel, Firefox and possibly other major projects adopting rapid release of 3 months, that can mean quite old, possibly unmaintained versions shipped with release. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE wrote:

On 9 July 2011 04:42, Rajko M. wrote:

...

On Friday, July 08, 2011 01:58:02 PM Karl Eichwalder wrote:

...

Maybe, you can fool users with "clever" naming, but only once.  It is surely not worth trying.

Our only problem is to try a bit harder to be as close to conventions as possible, ie. meaning of Alpha, Beta and RC. Users didn't quit attempts to use development releases in a day, it took some time of upside down stability to run them away.

I don't know how possible is to have "normal" stability taking that distro has only what upstream offers and in 8 months there is a lot of upstream development, so loading Alpha with a new software, then making only minor changes during Beta and nothing, but bugfixes in RC, will result in final version few months behind upstream. With kernel, Firefox and possibly other major projects adopting rapid release of 3 months, that can mean quite old, possibly unmaintained versions shipped with release.

So rather than shipping the latest automatically, have some quality control!

+1 ! -- Per Jessen, Zürich (18.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 9 July 2011 17:40, Larry Finger wrote:

Rob OpenSuSE wrote:

...

So rather than shipping the latest automatically, have some quality control!

I got a little behind in this thread, and will try to catch up now.

There is no intent to "fool" the users. If I did not think that MS6 were fully qualified to be called a "beta", then I would not have proposed this. In fact, if it is not, then openSUSE is doomed. A reputation for releasing buggy code is impossible to shake.

The scheme proposed by M. Raiko is not that different from what happens in the kernel. Anything not available by the end of the merge period has to wait for the next cycle. If openSUSE used that scheme and froze features/versions after MS2, a lot fewer bugs would make it to GM. I'm not sure that I want to go that far as we would be shipping some really old stuff. Perhaps the rolling releases of Tumbleweed will help debug many of the updates that will be in our next release.

A distro is different, because it compiles and serves in conveient form for most part the output of upstream. Rules about freezing features & versions, are inherently broken. It's intelligent pragmatic decisions that are needed not rules that appeal to bureaucrats. For instance are upstream fixing bugs and adding small features or redeveloping the whole project etc etc. Is the project directions suitable? Project should ship the best software it can, and think ahead a few months beyond release day to. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 11 July 2011 09:45, Stephan Kulow wrote:

the  very last before final. The question how to gain them is not by making the product worse in having older, buggier software on them. And don't fool yourself, it's not the openSUSE project that fixes the most bugs, but it's the upstream projects that we take the software from. And openSUSE RC phases with continued upstream integration is pointless.

...

nice and fixed after RC3 or RC4, wait two or three additional weeks and bugs will pile up. We have _4 weeks_ of RC phase, that is enough to find important bugs if people would actually test.

I think it's time to grasp that some people just don't want to test, but install the ready product. I _never_ installed beta software of something I didn't take part in developing and even many openSUSE developers install betas - and those that do very often live on factory anyway.

Whilst that's right, some ppl are just consumers of a finished product. However what I see whenever I look on the forum say, is people frequently trying out & testing "next" releases of software, many actually obviously suffer from versionitis; for instance you get ppl with say a virtualised production server environments in a tizzy Xen in the latest current release, a day or 2 after release day which they installed and then found something had broken. That seems bonkers to me, I'd rather track 4 months behind in such cases and move to a known quantity. They may however be less good about reporting bugs, it's just damn hard to file a solid bug report. Generally people get scared of (but also excited by) big changes like releases, which can go wrong and be hard to undo; yes they shold backup... Ideas to make wider early usage easier, than the painful heavyweight download DVD or Live CD! & install : 1) Providing optional upgraded packages for things in current stable release For instance like kernel eg) kernel-release-desktop, kernel-stable-desktop, kernel-testing-desktop. It's just much easier on the end user, if when a new kernel fails, they can simply choose another from menu. (I know about multiversion = provides:multiversion(kernel) in zypp,.conf, but that is harder to follow on updates etc) That helps build confidence in key components through wider usage. Similarly, you could recommend FF-5 but have fall back of FF 3.6 for "stuckists". Or kernel-fallback, to provide older distro supported kernels, for those blocked from kernel upgrades due to regressions; that allows you to move most forward whilst not dropping people entirely. This is basically done already if you subscribe to Kernel: stable or head repo. It would make openSUSE news more interesting, new application packages could be highlighted to in an "additional packages" report handled rather like Release Notes. There's no reason non-conflicting packages like kernel-release-<flavour> could not recommend kernel-stable-<flavour> either is there? Then package management can offer updates, to what could initially be just stub-packages (mainly symlinks) without YaST patches. 2) Providing a way to roll back To me that means, central copy of older rpm's, and as part of package upgrade, save old config files which are modified so they can be restored, how there were. If you are sure you can undo something simply, then you're much more willing to experiement. 3) Stumbleweed - "Solid" Tumbleweed rolling on with less churn, and lower risk than Tumbleweed as is. Change vendor to be same, so "zypper up" just works, with Packman repo Multi-media & other OBS vendor different to allow alternative package source. With that, coming up to 12.1 release time, one could issue something like "service packs" for areas, where there's high confidence in package upgrades. Now, how could a distro manage "Alpha" "Beta" & "RC" towards a time based GM release? Changes could generally trickle down; factory -> factory-tested (say Month N)-> Tumbleweed (distro Alpha roughly Month N+1) -> Stumbleweed (distro Beta Month roughtly N+2), with release managers responsible able to appeal to fast track things for Major issues. An official release simply then becomes, an installable periodic Snapshot of "Stumbleweed".. This works right now, with SuSE Studio adding the Tumbleweed repo and going straight to 11.4++. The key is to grow the funky variants within the community, via mail lists, forum; by a track record of good enough stability. Every 8 months, focus can be on getting risky core system changes right earlier in the pipeline, with a pause a few months before time based Distro release, but importantly work on Release X.Y++ can begin at the head of the pipe, if patches and packages are built at the appropriate later stages, in a flexible way. Open feedback, would help to, so people can see which things are well tried with few bug reports. That can save a lot of wasted time for someone in a hurry, but also volunteer tester's time as they can target areas likely to yield bugs. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow writes:

No, it simply means we need more users that install also other milestones than the very last before final. The question how to gain them is not by making the product worse in having older, buggier software on them.

Might work. But, of course, there are also some caveats. Major components such as "the desktop" often came late. And the older software is not necessarily buggier. This all, as always, depends ;)

And don't fool yourself, it's not the openSUSE project that fixes the most bugs, but it's the upstream projects that we take the software from.

This also depends. At least, we sometimes do "important" stuff (e.g., Gnome Main Menu or software translations).

And openSUSE RC phases with continued upstream integration is pointless.

Sure, but only as long as upstream is in bug fixing mode. Upstream often does bug fixes, changes, and enhancements at the same time...

...

nice and fixed after RC3 or RC4, wait two or three additional weeks and bugs will pile up. We have _4 weeks_ of RC phase, that is enough to find important bugs if people would actually test.

It's probably enough for testing, but surely not enough for fixing the found bugs. Here I'm talking about desktop related components (Gnome), which come with strange translations, memory leaks, or crashy behavior.

I always said that those who want the perfect product, are welcome to continue working on *:Update, but I see no action, so I would like everyone who doesn't want to put his money where his mouth is to stay away from using "+1" on this list.

In general, I like this approach (working on *:Update), and it is a little bit unfair to pretend that there is no action ;) Many developers still do not know that fixing "minor" bugs for a released openSUSE product is appreciated by me and you. They often think working those bugs is not allowed.

To summarize: no longer RC phase with me and no "alphaX" and no "betaX" with me. I'm not convinced that it changes anything, but I'm open to call the milestone before the RC phase Beta, but that's about the naming.

Ok, that's fine. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Dienstag, 12. Juli 2011 schrieb Karl Eichwalder:

Stephan Kulow writes:

...

No, it simply means we need more users that install also other milestones than the very last before final. The question how to gain them is not by making the product worse in having older, buggier software on them.

Might work. But, of course, there are also some caveats. Major components such as "the desktop" often came late. And the older Where have you been when people seriously suggested waiting with the release just for the next patchlevel version of Kernel GNOME or KDE without even knowing what they get?

...

And don't fool yourself, it's not the openSUSE project that fixes the most bugs, but it's the upstream projects that we take the software from.

This also depends. At least, we sometimes do "important" stuff (e.g., Gnome Main Menu or software translations).

Gnome Main Menu? The 10.1 was released before I became release manager. And you hopefully won't claim that openSUSE translates more software than the upstream projects. You should know better.

...

And openSUSE RC phases with continued upstream integration is pointless.

Sure, but only as long as upstream is in bug fixing mode. Upstream often does bug fixes, changes, and enhancements at the same time...

That's what I'm saying too, not sure where you see the conflict.

...

...

nice and fixed after RC3 or RC4, wait two or three additional weeks and bugs will pile up.

We have _4 weeks_ of RC phase, that is enough to find important bugs if people would actually test.

It's probably enough for testing, but surely not enough for fixing the found bugs. Here I'm talking about desktop related components (Gnome), which come with strange translations, memory leaks, or crashy behavior.

Possibly. If we take 8 months to fix the bugs in 11.4, we might please _some_, but the question remains what developers you want to attract doing that. People might still believe that, but open source development is not about pleasing users, but about finding a balance between fun for developers and fun for users.

...

I always said that those who want the perfect product, are welcome to continue working on *:Update, but I see no action, so I would like everyone who doesn't want to put his money where his mouth is to stay away from using "+1" on this list.

In general, I like this approach (working on *:Update), and it is a little bit unfair to pretend that there is no action ;) Many developers still do not know that fixing "minor" bugs for a released openSUSE product is appreciated by me and you. They often think working those bugs is not allowed.

Point them http://en.opensuse.org/Portal:Maintenance - the team waits to be asked. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Jul 12, 2011 at 11:35:55AM +0200, Guido Berhoerster wrote:

* Stephan Kulow [2011-07-12 09:08]:

...

...

In general, I like this approach (working on *:Update), and it is a little bit unfair to pretend that there is no action ;) Many developers still do not know that fixing "minor" bugs for a released openSUSE product is appreciated by me and you. They often think working those bugs is not allowed. Point them http://en.opensuse.org/Portal:Maintenance - the team waits to be asked.

The criteria listed on http://en.opensuse.org/openSUSE:Maintenance_policy are quite restrictive (data loss/corruption with common configurations, regressions to previous releases or due to previous updates), if actual practice has diverged from that an update to the policy might encourage more maintenance work on released versions.

We approve fixes for nearly every bug that is queried from us. I will check the page. Ciao, Marcus (openSUSE Maintenance) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org