On 12/16/2013 05:32 AM, Jos Poortvliet wrote:
Dear community,
The openSUSE team has presented and with you discussed some plans for a more sustainable development project➀. Proposals like working openQA in the openSUSE development workflow, implementing staging projects, making improvements to OBS - and implementing these things will cost a lot of time.
Right now, the openSUSE team is or plans to be working on a wide range of things: the openSUSE Conference, the new merchandising program and of course we have the openSUSE release process on our plate. Especially the work on the release takes much time from our team, both in terms of ongoing effort (keep factory working, openQA testing) and of course around the release itself.
To implement the proposals we made in a reasonable time frame, we think it makes most sense for us to focus on them. That means, the openSUSE team would work on OBS, openQA etc in a series of sprints over a period of 6-8 months. In that time, we spend little if any time on the release process. Of course, after these changes the team will be back on the job at full speed.
What does this mean for the project? Either the release should be done by others or in another way, or openSUSE will essentially skip a release. The project can still get updates to its users - there is tumbleweed and OBS of course, and perhaps we can do a simpler/preview release. Many things are possible.
Shoot. What do you think?
I think the "stop what we're doing and do something different" approach has a bad track record. Over the last 1-2 years this approach has been used in a number of areas and the results have not been very satisfactory. Following the same approach is therefore, probably not the direction that will inspire much confidence that things will actually "get better." On the numbers side I tend to lean towards Richard's direction. Just relying on the numbers and boldly proclaiming that "So I think it is safe to say the majority of our users won't care much about skipping a release" neglects the fact that people cannot be summed in up in simple mathematical equations. That what we are doing is not a zero sum game. Although a given user my not upgrade a given machine that does not imply that a regular release cycle is not important to that user. The reasons for not upgrading are probably as diverse as the users we have and say nothing about the importance of having a regular cadence for the releases, rather than "randomly" deciding to skipping a release. I very much like the more moderate and measured approach Stephan has proposed of running things in parallel and taking a state of affairs early next year March/April to see where we are with the next release. If we succeed with the "more stable factory" idea it should have a positive effect on shortening the end game of the release process. Maybe we can also get more people involved now that many things have been enumerated in progress that were previously opaque. We can also take another look at the testing effort that has significantly increased over the last couple of releases. We all know that in the software world one can very easily get roped into testing nirvana but that returns on that investment are diminishing and do not justify the ever increasing effort required. I think 13.1 is a very good case study in that area. I think we will have more success with a more moderate approach that lets things run in parallel. If the changes we are talking about take 3 or 4 years instead of 1 year, is that really a big deal? Obviously some things are more pressing than others, like generating some relieve in the release process and making the busfactor greater than 1. Many of our problems are still rooted in accessibility of information and visibility of stuff that needs to get done, IMHO. For most people it is still difficult to understand/figure out how a release gets out the door and all the things that go into the process, plus how they can potentially contribute one piece of the puzzle. While there's been an effort to lift the veil, more work is necessary. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org