Robert Schweikert wrote:
On 12/12/2013 10:59 AM, Ludwig Nussel wrote:
Stephan Kulow wrote:
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.
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 you be
- very likely
- very unlikely
to switch to factory on your every day working machine?
Hard to answer at this point too. Depends on whether we get the
right balance between having the latest and greatest hot new
features quickly and not breaking too badly.
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
It's not just you. I also have my doubts but at the same time think
it's worth a try. Esp since we have the chance now to not introduce
this as stand alone feature but rather back it up with other
other technical as well as social actions.
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.
As Michal already wrote the current idea is to make the packager
whose submission originally triggered the staging project
responsible. If it turns out that some people are interesting in
helping out in staging projects no matter what topic they are about
that would be even better of course :-)
- are we introducing a new set of arbitrary decision
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
I guess it's kind of natural. If one gets stuck with your staging
branch because noone wants to help then maybe the change was not
that great after all.
the potential change process comes into place to
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.
I'm not sure I can follow you here.
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.
Which actions were taken back then to address the concern?
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
I take that as compliment :-)
Do we have a list of things we can drop, i.e. that
were done but
are more nice to have than absolutely necessary?
What is the absolutely necessary?
lists most not so technical tasks at least.
lists of things we started with before we had progress if you want
to look at something simpler.
Some tasks were already dropped for 13.1. For example taking care of
On the technical side there's for sure also room for simplification.
Do we need 14 iso images for example? How about dropping the Live
and Promo images? i586? Rescue? Do we need 6 "Desktops"? Full hard
Can we do with less effort in testing at the end
stages of the
Will a more everyday usable factory automatically lead to a
reduced effort of testing in the end game?
Depends. Not having to deal with really basic problems like crashing
installer can mean less effort or more focus on the polishing with the
Is there a proposal coming that will question the 8
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.
The success of Tumbleweed and Evergreen at least suggests that
openSUSE releases leave things to be desired on both ends of the
(o_ Ludwig Nussel
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org