On 12/16/2013 05:32 AM, Jos Poortvliet wrote:
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
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
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.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org