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 quickly.
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
- inclined - very likely - unlikely - 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 just me.
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 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
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 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.
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 releases.
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? progress.opensuse.org lists most not so technical tasks at least. http://en.opensuse.org/openSUSE:Public_release_action_plan_12.2 has 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 the manuals. 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 disk encryption?
Can we do with less effort in testing at the end stages of the release cycle?
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 same resources.
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.
The success of Tumbleweed and Evergreen at least suggests that openSUSE releases leave things to be desired on both ends of the spectrum. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org