On 12/12/2013 10:59 AM, Ludwig Nussel wrote:
Stephan Kulow wrote:
Our ideas are just ideas, but I had
several discussions in various places and nobody offered a better idea.
So we really would like to start with it and I would like to hear
your concerns so they can be part of the final solution.
There has been some feedback that in all the enthusiasm of throwing
ideas out we still lack a good summary of the goals behind all of
those proposals. So here's my attempt to contribute to the mess by
writing yet another mail :-)
tl;dr skip to "Long story short".
According to the numbers the amount of packages in Factory is
increasing➀. However, at the same time the download statistics➁ show
that the number of actual Factory users does not grow.
The former can be explained by successful efforts in the past which
had the goal of getting more packages. Regarding the latter the
openSUSE team thinks that one of the reasons for the stagnation is
that many don't perceive Factory as reliable enough to run it on
their development systems.
Agreed and I doubt many will argue with this assessment.
At the same time however more users that
actually use Factory are needed to find issues early and fix them
Yes, also a point that is difficult to argue.
This does open the door for one of the questions I am not certain we
have explored in sufficient detail.
If we find a way to "stabilize" factory, or "make factory more useable
all the time", how confident are we that it will do the trick? Meaning
how confident are we
- that we will get more factory users?
- get more early bug reports?
Extremely difficult to answer of course, I know, thus maybe we can try a
different approach to get closer to a picture that helps us.
@ ALL TECHNICAL CONTRIBUTORS/DEVELOPERS (sorry for shouting)
- If we collectively manage to "calm" factory down to the point where it
will always boot and you do not have to fiddle with the very low level,
kernel, bootloader, glibc , X11, things after doing "zypper dup" would
- very likely
- very unlikely
to switch to factory on your every day working machine?
Those that run factory already should probably not answer this question ;)
What is being proposed, in a certain light certainly makes sense, to me
at least, and others have expressed similar sentiments. I'd just hate to
see anyone spend a ton of effort on a pipe dream, thus I think getting
answers to a few simple questions as the one above can help us get a
general feel for the lay of the land at least among those that already
contribute to openSUSE.
One needs to feel the itch to start scratching. So
some kind of a chicken and egg problem.
Therefore we proposed➀ to create a process that keeps Factory as
usable as possible for our contributors (ie zypper dup should be
fairly safe at any point in time). This means Factory becomes a more
viable option for using it as "rolling distribution". That
designation in our opinion includes also regularly releasing ISO
image snapshots with working installer so people can get started
Crucial part to get there is introducing openQA➂ and staging
projects➃ in the process.
I think there are many open questions about the staging, and maybe
that's just me, and I am more than happy to just shut up if it is just me.
One of my primary concerns that has not really received an answer, I
think, is of the number of people that now get the "promotion" to
staging tree manager.
- do we have people that work at the level of code that requires staging
trees willing to take on the "new", additional work/responsibility?
- are we introducing a new set of arbitrary decision points?
For this question I'll briefly revisit some earlier points in the
discussion. I asked whether Richard would be willing to take on the new
additional work and Stephan pointed out that gcc has a higher level
"priority/interest" over other changes that might require staging trees,
Stephan mentioned the "usr merge" effort as another example for a
staging tree project. So who decides what project/movement gets the
"higher level of interest" stamp, presumably more help from everyone,
over the you are stuck with it staging branch? I suppose this is where
the potential change process comes into place to avoid arbitrary
decisions. However, this feels a bit like changes in the factory model
forcing other changes, such as a change process, upon everyone. It
appears that we should be able to separate those a bit better.
- do we need to think of trying to develop/find a number of people that
are interested in being primarily staging tree chaperones?
All the work for that cannot be put on the
shoulders of just one guy.
Yes, but that's not a new concern, I remember having a discussion about
that at oSC11.
So we want to have a distributed,
balanced and robust development process ie share the workload among
teams with different roles. To make sure we get motivated people for
those teams the process needs to be set up in a way that promotes
mentoring and recognition➄.
Well, yes. But I'd say of all things we probably struggle with the
recognition part the most, from my perspective at least.
So what kind of skills do we need there? The increasing amount of
packages indicates that the entry level of packaging is covered
quite well in the current system. The bottlenecks we have are in the
integration. What we need are more people that are up to the
challenge of taking care of the "core" packages and the integration
of them. So that's the kind of contributors we need to have in mind
first with the new Factory.
Long story short, the goals in those proposals are
- more focus on hardcore package maintainers and distro integrators
- ensure Factory is usable at any point in time
- have a distributed, balanced and robust development process
- promote mentoring and recognition
I think there is one important point that has received some attention,
but possibly not the attention it should receive. That is the
consequences of these ideas/proposals.
For 12.3 and 13.1 the openSUSE Team as a combined force working in
unison has done a lot to get the release out the door. I think it is
generally accepted that the quality has gone up over previous releases.
One must assume that the openSUSE Team is willing to work on
implementing any of these ideas and in the openQA message there was
already a basic time commitment that that is going to happen. Since the
openSUSE team was not sitting around twiddling their thumbs it implies
that other work has to be redistributed to free up time for openSUSE
Team members to work on the "new and exiting stuff". I am making the
assumption that the rest of the development community cannot simply pick
up the "new and exciting" stuff either. Anyone can jump in of course at
any time and contribute, but all of this is a lot of work no matter how
the work is distributed and it is a net gain of work. That in the end is
what we probably need to pay attention to. There is a net gain of work
to implement new ideas in the way we develop the distribution. With a
pretty constant number of fingers on the keyboard and a possibly
reasonably constant number of hours. Our hours are already filled, how
are we going to handle this, something has to give?
Do we have a list of things we can drop, i.e. that were done but are
more nice to have than absolutely necessary?
Can we do with less effort in testing at the end stages of the release
Will a more everyday usable factory automatically lead to a reduced
effort of testing in the end game?
Is there a proposal coming that will question the 8 month release cycle?
How would a longer release cycle benefit the elusive "end user" that
cannot possibly be captured in one group? We have already heard from
some people that run servers and say "longer is better" but I am certain
we can find just as many "end users" that say 8 month is just about right.
Can we be happy with a potential drop in quality to levels achieved
prior to 12.3 when the release was produce with a different contribution
I can keep going with maybe another 10 or more questions I think we
should probably discuss and that are directly related to the changes in
I think we have long way to go to figure this out.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org