Beta 2 is out and meanwhile, the discussion on the future of openSUSE development continues. I've attempted to summarize the current status, both to help my own overview of the discussion and to try and help clarify it for others. It has become quite a mail-client-challenging monster thread and Robert S has already asked people to open separate threads for the specifics we're discussing...
Tumbleweed
A first point of consensus was that there should be more emphasis on Tumbleweed. Greg brought up a few pain points he would need to see fixed and asked for help in general. Some conclusions and plans:
- change processes to lower amount of rebuilding of packages in OBS (Greg, Coolo, OBS team)
- add hardware for faster building (OBS team)
- optimize OBS for faster building with things like better/smarter/faster bootstrapping (pre-setup VM's with GCC ?), new filesystem, smarter dependency checking and possibly integrate the rebuild_logic="coolo" thing in OBS itself (OBS team)
- Greg needs to tell us what else we can do to help him make Tumbleweed better
Release Cycle
Consensus seems to be that a longer release cycle is a good idea but nothing concrete has been proposed. Coolo will probably simply make a 12.3 proposal for say November 2013. Some numbers where brought up that show that we can indeed use a longer stabilization period for our releases. 'Release when ready' is also still on the table.If a longer release cycle is introduced, Tumbleweed becomes more important, but so do the other OBS projects. Users will depend on OBS far more to get new packages. What effect this has and how to tackle that has not been discussed yet. On a personal note, I think the new software.opensuse.org will need some improvements in case we go this route. It would have to put more emphasize on the devel projects as 'official' sources of software. Right now, there are roadblocks put in place for users who want 'stuff from OBS' and it's made clear that things from there are untested and possibly unstable.
Changing the Development Process
Consensus seems to be that the current setup with devel projects feeding into Factory and having groups of maintainers (the aggregate of the individual package maintainers) doesn't work that great. In short, we need to stabilize Factory further. Things that might change:- Build Failures could create BNC Entries... assigned to the bug owner of the package. (OBS team?)
- Be stricter about maintainership - have 2-3 maintainers who really are responsible. There is some unclarity between the roles of bugowner and maintainer. OBS currently adds the role of maintainer to everyone in a project, which is deemed a bit overzealous - a package can that way end up with 20 maintainers but only 1-2 of these might dare to touch it. Not clear where to go with this yet.
- Do more checks on packages like rebuilding dependencies to see if they fail. Heavily depends on available build capacity (currently very limited). While it requires more work to get something in Factory, as Karl Eichwalder said: "your fun must not prevent the others from having fun."
- process of getting packages in factory might need changes. For less core packages, we could possibly skip devel projects, provided there is review done on the packages. We might also expand devel projects for the remaining packages to do more testing.
- staging projects
- we could either have one or multiple staging projects.
- With one, all eyes would be on the same, but it would have the same breakage issues as Factory. Advantage is that we can have an automatic revert policy where packages can't get in Factory until all breakage in Staging is fixed. It would require OBS to automatically detect build errors due to changes in a given package. We're unsure if that is possible.
- Another way would be to try and get Staging stable, once everything is green - move to Factory. Get new packages, stabilize again, move to factory. Etcetera. Having multiple staging's in parallel might help to lower the 'latency' of getting packages in Factory but it would cost build resources. This discussion is also still ongoing.
It was brought up that it'd be possible to create a 'core' of base openSUSE packages (roughly up to X.org) which would be 'atomically updated' for the rest of the packages on top, decreasing breakage and allowing easier testing. This could even be part of a release scheme with a 'core openSUSE' and peripheral packages in Tumbleweed and OBS. It would require some work on the software.openSUSE.org search UI and software management in general, however.
Social issues and responsibilities
Several people brought up the social side of things. As Coolo already mentioned in his initial email, we'd need more people fixing problems 'all over'. These will need mentoring - something openSUSE currently doesn't do in a structured manner, except in the context of Google Summer of Code.Aside from mentoring, there should be more clarity about responsibilities. If a new version of a library breaks things, who should fix this? The person who maintains the library or the applications which are broken by it? These questions are unanswered as well and possibly a one-size-fits-all answer doesn't exist.
Last but not least, development is helped by a positive, constructive atmosphere on the list. The openSUSE Board has been spending some efforts in improving the situation on our lists and with some success. But more would be needed and how to do this is still unclear.
Conclusion?
It is most certainly not clear where exactly we will end up. Of course, we're only 6 days since the announcement by Coolo that he thinks things have to change. Much of the discussions does point to interesting solutions, but we have to come to definite conclusions before anything can be done. And then, we need people to commit to executing some of the changes!The openSUSE Conference (Prague, October)will be a good place where we can finalize these conclusions and start implementing things. If you're in the Americas, the openSUSE Summit in Orlando in September might be more convenient for you... In both cases, if you have an interest in the future of openSUSE you should make sure to be there!
Personally don't like the 1 year release date and will admit it's the new toy syndrome. Think when it's ready is the proper way to go and that rolling releases is interesting.
ReplyDeleteThe problem with 1 year is that so many distro's use 6 months and that could cause loss of user interest also 1 year is a long lime in the world of kernel releases (12.1 uses 3.1.x and 3.5rc candidates are being tested)
Yup, 1 year has downsides too. I personally like the idea of focusing on a smaller set of core packages and releasing those - it'd probably be doable to do a release with each Linux kernel, that's 3-4 months. Then the devel projects like GNOME or Cloud can do releases on top of that.
DeleteSplitting core components and applications is an interesting option, too. But personally I really like the idea of a one year release cycle.
DeleteI’d like to see an openSUSE that fits in the gap between Debian and Ubuntu. Rock solid and more stable than Ubuntu (half year release cycle), but nevertheless more up-to-date than Debian (approximately a 2 year release cycle, released when it ready).
I think that this would attract the most users because the splitting option possibly is not stable enough for professional use (where applications should not change during short time periods) and might be not well understood by casual users.
Additionally the one year release cycle has the chance to deliver the best compromise between stable software on the one hand side and quite up-to-date software on the other.
Most other distributions do not fully satisfy this scenario and the requirements of users, who want a stable, reliable but still up-to-date OS, that works out of the box so that work can be done and updates etc. do not stand in their way.
Just my two cents. :)
"On a personal note, I think the new"...
ReplyDeleteThe rest seems to have gone missing.
... and I don't even remember what I wanted to write there... Will think about it and try to fix it :D
DeleteGot it. It was about improving software.opensuse.org to signify the greater importance/official state of the devel projects on OBS (or whatever we create to get more software to users if we pick things like longer release cycle and/or a core set of packages).
DeleteBefore deciding if it's better to release every month or every year, let's ask the good question: why do we want to release?
ReplyDelete1) For marketing purposes, to get more users ?
2) To have the latest version of everything available?
3) To have a stable OS?
4) What lifetime will we be able to offer, and what lifetime is expected by users.
5) Other reasons?
I would like to say I don't care about point 1, but we need sponsors... And it's always nice to recieve openSuse stuff here in Nicaragua ;)
Points 2 and 3 are like oposites. But you can get the latest versions using repositories updates, without the need of a new version.
Also what public do we target? If I remember well openSuse target advanced users willing latest tech and able to acomodate some instability.
Personally I would prefer to have one release per year o 18 months, with longer support.
Repository update is enough for me. Don't need a new splash screen (since I personalize it anyway ;).
I think rolling release distros have their place. But mostly that place is on someone else's computer. :)
DeleteI used Gentoo for about 5 years and came to openSUSE after flirting a bit with Kubuntu. The main reason I changed was that I wasn't interested in the churn of updates causing issues. I'm not in college anymore and I don't use Linux for the sake of using Linux. I have a dual-seat computer I share with my wife and she uses it for her work.
So #3 is the reason for sure.
I do have 17 repos enabled on my computer, but the only major 'extra' one is KDE 4.8. The KDE repos are very well maintained and certainly make openSUSE major updates quite boring since not much visible changes. :) But that's OK.
How about a distributed OBS? There were a lot of CPU oversized for their work around the world, think about a computer used only for ftp. Maybe a pair of universities would help giving some CPU time and internet bandwith during the night. You could implement a distributed OBS that can offload some work to them, not an entire distro but little piece or great piece of the stack. I think KDE.org and GNOME.org should have an OBS istance running on their server, not to offload the entire work to them, but to help when the suse one is bloated.
ReplyDeleteI believe there would be some security issues with that...
DeleteKDE and Gnome don't just have servers sitting about. :)
DeleteIf anyone does have extra servers, they could just give them to OBS, then you wouldn't have the security issue at all.
Why not distributing the work all over the community in a similar way like git, mercurial or any other distributed repo software does. Then OBs can concentrate on, lets say the "core" system (whatever content it as maybe the scope of a live system).
DeleteThe maintainers could run a local OBS and ship prebuild packages to OBS.
Then openQA can use the "core" system and the prebuild packages and check if they are fit for the next Milestone, Beta, or release candidate.
This would reduce the load on openSUSE buildservice, you get faster turn around times for rebuilds of the core system. Pushing prebuild packages to OBS would lead to better quality, because no one will push something which bracks the hole distro.
But for this you have to change the OBS software a bit to give it some functions for handling distributed package builds.
@Jradzuweit: actually, before people submit packages to OBS, they usually (but not always) have build them on their own system already for testing purpose. OBS makes this local building really easy.
DeleteBut using external systems for building our packages has a number of problems. From big to smaller issues:
- security. How do you know malware was not injected in the binary that you get back from the 3rd party system?
- data transfer. The build hosts need to do quite some work, downloading and uploading packages etcetera. This effectively moves the bottleneck from our build power to our network pipe.
- latency. The issue right now is that builds take a long time. But how do you know that using external machines will speed it up? These systems might be slow and overloaded too - and add to that the time it takes to send jobs to them and receive the results. And what if a system goes down just before submitting the result? You'd get wildly unpredictable waiting times.
So, while it is a generous offer, we'd much rather have build power under our own control - it's faster, doesn't hit our network and is more secure.
If anyone has contacts at say Intel or AMD, HP, Dell or other system builders etc it'd be nice to see if they might be interested in helping us out with a few servers!
I prefer longer release cycles as I am really sick of upgrading 2-4 Systems every 18 months. It's a pain in the ass. Therefor I already switched the Netbook over to Ubuntu LTS. Maybe LTS would be something to help finding a balance between "release often" and "release when its done"? Whoever needs new software goes with the next 9 (or 12)-month-release. The people who prefer fewer updates stay with a LTS release...
ReplyDeleteTumbleweed is far too "bleeding edge" for me as I want to use AMD blob-drivers (fglx). As you know they need a while to support new xorg versions...
I think Cedric Simon is on the spot. If the distribution release cycle is under review, there should be a decicion first on what is the audience of the Distribution and what is the aim of openSuse in general.
ReplyDeleteIf tumbleweed will be official part of openSuse and will get better and will continue to provide bleding edge packages KDE/GNome/Kernel/Gcc and create rolling distro then. A realese cycle can be slowed down.
This is something currently Fedora nor Ubuntu can offer.
an LTS realese for opensuse will be good, but again depends on what bleding edge alternatives are offered. The thing with LTS is what Novell Suse vs openSuse LTS will offer and how that will affect the current relationship with Novell.
Maybe that's the problem with having a commercial version as well. How to minimise interference...
DeleteThe decision tree for mee looks like:
Does OpenSuse find a way to send me patches for more than 18 Months
Then
stay with OpenSuse
Else
Go to Ubuntu LTS
Distro-Upgrades never really worked for me with an increasing amount of Repos active (thanks to bloody OBS). Next feature request from my side would be a "share pain button".
Seriously: A free version with patches for more then 2 years would be a major wish for me.
what's unofficial about tumbleweed?
Delete*Note that there's no Novell anymore, well it exists but we're separate from it and almost all management has been replaced.
DeleteTumbleweed is already official part of openSUSE but we can give it a bit more attention - that's one of the things we're discussing.
The audience of our distro has been under discussion for quite a while and you can find some answers here:
http://en.opensuse.org/openSUSE:Strategy
Jos, the "RELEASE SECTION" section is ended with words "On a personal note, I think the new".
ReplyDeleteWhat were you going to tell? :-)
Sorry, I mean the "RELEASE CYCLE" section, of course)
DeleteFixed now :D
DeleteIf the release cycle will be longer than, say 1 year, why not release something like a Service Pack in between releases?
ReplyDeletethey already do security updates. and if it's a feature update, just call it a new release. 'Service Pack' only makes sense in the context of there being 'free' updates and 'costs money' updates. :)
DeleteIan is very much correct. Besides, you can get 'service packs' from tumbleweed (rolling) or OBS repo's...
DeleteAs an end user, I agree with the post above that longer rather than shorter release cycles keeps my interest at least. Developers can always enjoy working with various beta versions, but for a busy end user, we prefer a stable machine with rare changes, and submit bugs reports as needed.
DeleteI switched to opensuse from ubuntu and fedora because dealing with non-functioning "updates" wasted so much time. Once I got opensuse 11.4 to work on my 3 desktops and 2 laptops I was very happy. It works so well, I am not looking forward to any new release - it just means more problems with no gain. Many linux users at work (a university) have switched to mac laptops because they do not want to deal with updates.
When I worked as sysadmin, my boss had MacOS X on his laptop and he would do upgrades (e.g. to snow Leopard and Lion) and sometimes run into problems that did not occur with the old version. So Apple does not have a magic bullet there either.
DeleteAnd yes, OBS is a great tool. We should do stable releases less often and offer frequent upgrades of applications on top in separate repos for those that want them. This can work like Tumbleweed or using only some devel repos.
The suggestion of using 'tumbleweed' as a sort of 'service pack' is, as I heard multiple times, not advisable, because (and I quote): "tumbleweed is just one bloody mess" (irc channels).
DeleteI confess, this was from some time (>1year) ago. So I hope that it is better now, but until I can get that confirmed, I stay away from tumbleweed.
On a side note: I really like the stable service-packs that SLES offers. So that was the origin of my idea.
I also like the idea of a yearly LTS build and a semi-annual 'bleeding edge' build.
ReplyDeleteOpenSuSE is the best linux distro by far. At this point in life, I am just a user so that has become my perspective. Each release of opensuse bundles new versions of nearly every underlying software package, new kernel, new xorg and drivers, new kde, new yast, new bootloader, new filesystem, new boot infrastructure, new gcc... In fact, the list seems to grow with time. Having every latest feature is great, but at what cost? Developers cannot stay on top of it all, and quality of user experience declines. I suggest implementing a more limited number of changes with each release. They could be prioritized based upon value and need. For example, release opensuse 12.1 with gcc 4.7 and bug fixes with the other packages. This type of approach would favor stability. The duration of the development cycle could be adjusted and set to a scope of work that is predictable, too. Just a thouht.
ReplyDeleteMaybe in the spirit of the earlier "collaboration across borders" meeting, now might be a good time to reach out and bring in some consultants from Ubuntu, Arch, Sabayon, etc. to get perspectives on how they handle long-term and rolling maintenance respectively? OpenSUSE gives *so much* to the greater Linux community, now would be a great time for some of the other distros to give back a little by looking over existing processes and see how they might be improved.
ReplyDeleteGood thing: our rolling release repo (Tumbleweed) is maintained by a well known Kernel maintainer and Gentoo developer (Greg) and we've got a number of other Gentoo people involved in openSUSE. Even some Ubuntu folks work with us. So when it comes to getting input, I think our openness is paying off...
DeleteI'm an archer leaving Arch's camp for openSUSE - and I will miss Arch _a lot_, I love it.
ReplyDeleteIf openSUSE can (mix and) find the balance between LTS releases (may be 24/30 months) while making and awesome rolling-release system out of Tumbleweed -just as Arch's RR model works- I think you have a big game changer here.
Just imagine that guys, a perfect OS suitable for deployment on servers, enterprises and any production environment you can think of coupled with a fully working rolling-release system modeled after Arch Linux, bleeding-edge + rock solid! ^_^
Yup, I hope this is the direction we're going in. But we'll have to keep this discussion going AND get to conclusions... Thanks for the input and welcome to openSUSE :D
Delete