Nevertheless, I can’t re-install my server every < 18 months. Its' simply not long enough for a server. Whatever my choice turns out to be, it will probably remain my choice for several years to come. Had SuSE adopted a lifetime system similar to Ubuntu, the choice would be very simple for me.

I have been a very happy user since release 7.3. Thanks for your hard and very good work so far.

In general, a combination of approaches work best, followed by polishing as needed. These proposed changes are, after all, polishing of the current scheme.

Anyway, a one year cycle is too long. I’m waiting for a KDE refresh because the 12.1 one was too unstable and I’ve learned I don’t like Gnome at all. I could learn how to install an out-of-SuSE-repo KDE, but I don’t want to. The Linux desktop is difficult enough without going out of my way to use untested combinations. So I am waiting (a little bit impatiently) for 12.2.

WRT staging changes, I think the Debian scheme of requiring a package to live in the unstable branch for a while before integration is completely reasonable. WRT critical build infrastructure (e.g. the version of GCC used to build the entire platform), you might reasonably add a few hoops and more soak time. There is also no reason you could not put out a 12.2 built with GCC 4.6 but shipping with 4.6 and 4.7, except you have likely gone through most of the 4.7 pain by now.

So I anxiously await 12.2. Thank you.

I’ve been using openSUSE since 10.1 and I remember upgrading to 11.0 on release day. It was a rough transition, to say the least. I’ve used a lot of distros, though, and I still think openSUSE is the best one.

Learning how to use yast and get stable binaries is really important for new users joining the community. The newest stable release is the piece that everyone will see as our cutting edge and it should not be blunted by lack of polish or app crashing. It would be ideal if the included software on the release CD/DVD was so stable it only needed security updates after install, and all other apps/tools were left to OBS or source compilations.

Another commenter mentioned “OpenSUSE University” to teach people more about how to install/use/build packages and I think this is a great idea. Some troubleshooting and configuration pages are out-of-date or point to empty pages now, and what would really help is a mentoring system where experts pass on their knowledge and usage habits to new users.

I think that *forcing* a one year pace when a lot of new function is arriving is a receipe for repeated disasters. We need to be more flexible.

A new release with major upgrades should be allowed 15 to 18 months for proper integration and testing. This would be appropriate for 12.2, or any similar big jump so we don’t expect miracles. And miracles is what it would have taken.

Each upgrade should be evaluated as to complexity when being designed and scheduled, with possible extensions if we find serious problems along the way.

Part of the problem is wanting all the new stuff ASAP, and part of it is impatience. We need to move with more care. I recommend 9 to 12 months for typical intermediate upgrades, and 15 to 18 months for major changes.

I want to also suggest that 2 year lifetimes are awkward for some of us, who prefer not having new function too frequently. I’m not primarily a systems person any more, but more a cross between that and a high end user. I’d like 3 year life for alternate versions so as to give users like me more time to swing into the new stuff, maybe in parallel with the old one.

And one more suggestion: It would be nice to have some new systems come out with optional virtual operation so anyone could hold the old and experiment with the new simultaneously.

Best wishes from BillN

For those wanting more bleeding edge, we will have Tumbleweed, with the normal Firefox/Thunderbird versions
and new kernel/software/DEs/Drivers versions, after a good test period.
THE MAIN POINT here for me need to be this one: Tumbleweed need support only the CURRENT version, so after a new release,
Tumbleweed will only be supported for 3 months for the early one, giving time
for the users plan a dist-upgrade. If you wanna bleeding edge, for sure you will upgrade for a new distro release…
so no need to continue supporting Tumbleweed in “old” stable versions;

With this approach, we will have 2 brands, satisfing both audiences and will reduce workload for developers.

Another thing that I think is very important is have a GREAT online Wiki, with plentfull of informations about every topic of the distro,
alongside with How-Tos for new users;

One appeling point in this case will be have a new screen in the installer, where the user input what “Version” of the distro he want:
If Evergreen, install the base Distrowith the stable branch/repositories and if choose Tumbleweed, already configure the repositories accordingly.

Look at the current need for features, then determine what timing could realistically
support a reasonable percentage of those features/changes.

As a long time user of SUSE and then openSUSE, I have been rather surprised at some of
the issues that have arisen in openSUSE over the last couple years or so. Some have seemed rather fundamental to have slipped into a release. I would ask to what extent, if any,
so called TDD ( Test Driven Development ) is used in validating a release? If I’m
thinking correctly, there have been recent times when some dependent packages weren’t
included. That would seem something that would have been caught by automated
testing.

If I’m coding in Java, defining an interface, writing an automated test with something
like JUnit to verify that the new code still conforms to the interface in the same way,
tends to assure that things haven’t been overlooked.

Don’t get me wrong, I realize that with diverse development languages, and diverse
Human languages within the Community, it’s not the easiest thing in the World; we’re
all Human, we all make mistakes.

But when I see something like whether or not the menu choices from the grub menu.lst file are available on the reboot option when leaving a KDE session, flip-flop from point-release to point-release, as in, it’s one way on openSUSE 11.3, it’s the other way on 11.4, then it’s back the previous way on 12.1, I have to think, either there’s disagreement about how it should be, or it should be viewed as a defined interface, and that’s something that automated testing could check for compliance with the interface. Likewise for missing
dependent packages.

Whereas I realize that something like the auto-hiding of a KDE panel coming and going
on the fly during operation, even though no settings have been changed, or grouping
when minimized, changing during operation, even though no settings have been changed,
is more nuanced, harder to detect on an automated basis, and much harder to reproduce.

This all reminds me that it would be nice to be able to see a somewhat detailed overview of what has changed from one release to another, as well as what has been changed for openSUSE,
relative to the way code behaved in the original packages, prior to changes specific to openSUSE. Something notably more detailed than the Release Notes typically are, but without having to try to plow through masses of code or documentation, to determine the list of changes. Essentially a feature level list would seem appropriate. If documentation were done in a structured fashion during development, it might even be possible to pull most of that from the documentation, if the dev. docs. included references to allow being automagically tied back to openFATE. Likewise, greater visibility on policies used to construct openSUSE, would make bug reporting a good deal easier. That would give much greater ability for users to decide, “Is it just a change I don’t like, or just something that I would have coded differently, if I had done it? Or is it an actual design-flaw/bug?”. I have no desire to waste people’s time reporting something that isn’t an actual problem.

By it’s nature a consumer product is going to need to be more cutting edge as there is more demand to run new software on newer kit with ever differing components.

It’s very hard to explain for me, why community supports so few packages in OBS, and you know what I’m talking about. There is no successful open source project in the world without a strong community.

Then, I believe all power users are delighted with zypper. Have you ever seen more powerful packages manager? Me definitly not. Begginers, in turn, will like Yast.

I feel, the formula is pretty easy: strong and large community – bright future. To attract more people we need to promote the strong features of openSUSE. Making OBS the platform of choice for large projects we’ll also attract peoples. May be it’s not in open source spirit, but promotion is what we need in my opinion.

openSUSE is a large project. It’s not only a box with open source software. There are a lot of external projects, that is needed to be supported. And here we also need a help of community.

And even more openSUSE is still what some people mean, when saying ‘Linux’. It gives me optimism and allows to look confidently to the future.

I have the feeling that the greatest commonality amongst users is an install once, run till obsolete attitude. If I install a SLED i expect not to revisit the machine until it leaves the company, likewise with open SuSE installs on private machines, install support till new one is bought (or change of owner occurs). Having started with Suse 6.X in the last millenium, i finaly see some acceptance on the street develop. What i see is basically that support (repos availability) ideally lasts the machines lifetime (change of ownership/user/employee). From that next Versions release date is irrelevant, as long as support for the old version is extended likewise.. A bleeding edge user/developer will like the newest greatest but if that cost the appreciaton for his/her effords from common users its a no win situation. Emphasis should be on stability and functionality = release when ready and support till demand drops (aka when all user move to new release aka nr of downloads from update repos drops to to certain % point ( eg. 10% of peek) This will asure 2 things 1. Suse user can trust they’ll have a rock solid, stable OS as long as they use it.. when it gets old they’ll understand that support drops (outdated) 2. OEM’s will see sales fluctuate with release and respective outdating of versions.. release cycles and a release’s EOL is then user orientated witch normally results happy users and their appreciation for developers accordingly. Alternatively if enthusiasts are the greatest determinator (or we want it to be) then release cycles, eol do not matter and i could add neither does stabillity. Than installs would be limited to my personal machines and machines that are only touched by me. (forget about Steam on openSuse?)