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...
TumbleweedA 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 CycleConsensus 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 ProcessConsensus 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 responsibilitiesSeveral 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!