On 7 February 2016 at 12:38, Oliver Kurz <okurz@suse.de> wrote:
"Staying a few versions behind" can work because others with a close enough environment of yours have hopefully already tried out the new version, reported bugs and fixes have been provided. The probability for this will increase the longer you wait with the downside of missing new features. Eventually also bugs are not fixed anymore for the old version you were intended to jump on.
From the openSUSE developers perspective it's easier to maintain -
This statement has triggered an interested train of thought I wish to share with everyone for their opinions First I want to start by making a few assumptions I believe everyone wants to/should want to run supported software. This means not only that 'it works', but that it is cared for and maintained. By maintenance in this context I mean 'security & functionality issues are found & fixed', and possibly also 'new features and hardware enablement are provided. I realise this isn't true of everyone in every circumstance - but if you're an exception to the above assumption, then it doesn't matter in the context of this discussion as you can pick whatever openSUSE release that suits your use cases. I also wish to make the assumption, more of an assertion really, that open source developers are primarily interested in developing 'new stuff'. The open source model's openness to innovation is what drives contributions to open source software. I believe this to be equally true regardless of the other motivations behind a particular persons contributions. Volunteer, employed, whatever, at their heart I believe the vast majority of open source developers are interested in developing 'new stuff' - whatever that 'new stuff' may be. Maintenance of 'old stuff' is time consuming, complex and often thankless work that often requires more thought and effort than developing new stuff. Some developers may embrace this task to a greater or lesser degree, but regardless I think few would argue with the statement that they would rather be doing 'new stuff'. It is also worth mentioning that 'maintenance' of old stuff often also means resolving integration issues with other parts of the stack that are still moving. This can often be even worse in terms of time, effort and complexity, and sometimes can just be fundamentally infeasible. This leads to a situation where many volunteer led open source projects often make dramatic strides forward while simultaneously reducing/removing the maintenance of previous versions. Plasma 5 is a perfect case study of this approach, with the KDE project abandoning maintenance of KDE 4 relatively quickly. That meant no security and bug fixes from the wider KDE Community. This led to a situation where our openSUSE KDE team felt they had no choice but to adopt Plasma 5 when they did as the alternative (continuing support for KDE 4) would have been way too much work for them to do on their own, especially when considering there are other parts of the operating system that are still moving forward and for good reason (eg. Kernel, udev, systemd for the enablement of new hardware and other pieces of software) I think it's also safe to say that in a good number of Projects, not just desktop orientated ones, there is a trend towards 'fixing things in new versions' and not expending too much effort ensuring that previous versions receive those same fixes. This is a story repeated throughout the open source world, but I believe it to be mostly a fact of life which people either have to accept, or pick up a text editor and get to work fixing it themselves, because the motivation of the current breed of open source software developers is unlikely to change Therefore, considering these factors, I actually think anyone who believes in the 'sticking to previous versions' approach is misguided. If it works for them, great, but the bulk of the collective open source worlds interest, attention, and new lines of code, are all being written for the 'current and next' versions of their software. That's where their interest lies, and focusing our collective efforts and attention on using and improving the quality of what is done there is the only way true progress is made. That said, there is a counter-weight to this situation Enterprise Linux distributions have enterprise customers who are prepared to pay for the stability/reliability they require, which enables companies like SUSE to pay salaries to dedicated maintainers to do that maintenance work that they otherwise would be unlikely to be self-motivated to do But Enterprise distros are a very different beast as a result of this For example, Leap/Tumbleweed have approx 8000 packages in their official repos SLES has about 2500 - All that maintenance really costs a lot of time, effort, and money, so a very broad package selection is not possible. Leap/Tumbleweed has many different desktop environments, because we have a community that is able and willing to work on integrating them all together SLES, and every other Enterprise distribution, all only use GNOME. Because of their very 'rearward facing' approach, the problems they do find, the issues they do fix, are rarely relevant to the upstream projects they are using, as those projects are often months, if not years ahead. It helps their users, and that's the point, their users are willing to pay for it. And so, considering all of this, what does this mean for openSUSE? Well we have Tumbleweed, which fully embraces the idea that you can make a reliable linux distribution even when doing 5 releases a week containing several hundred packags including new kernels. Everything done there is easy to feedback to every other upstream open source project, so not only does it help openSUSE but everyone else. Wishing for the open source world to be slower is unlikely to provide any noticeable result, so there is something to be said about just rolling up ones sleeves, hopping on the boat, and trying to help steer it as part of a crew, rather than trying to go it alone which is a heck of a lot more work. And we have Leap, which takes that very stable, professionally and extensively maintained enterprise codebase and then expands upon it with those community packages. that's 2500 packages less for them to worry about, so they can focus more on maintaining the remainder. But it is still volunteer work, and that work is still heavily impacted upon by decisions by various upstreams. It's not easy, it's not fun, and it's often not that rewarding either. And always, we could do with more help So, maybe if Leap or Tumbleweed isn't hitting your sweet spot, the answer is to start learning how to help maintain those parts of the software stack that matter to you? Join those mailinglists and IRC channels, ask the current maintainers questions. Offer to help. File bug reports. Learn how to file better bug reports. Come to the openSUSE Conference in June and talk to everyone involved. If packages are missing from our distributions, we have published guides on how to get them into our distributions, help them get in. If you can't do it yourself, then find someone to do it *with* you, so you can learn to do it in the future. Adding unsupported repos, or staying with previous versions after they are no longer supported and hoping for things to change isn't going to help things change, and I worry that the people doing that will just find themselves dissapointed in a long run. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org