Hi, 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 quickly.
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 you be - inclined - very likely - unlikely - 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 this is 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 somewhere.
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 cycle? 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 mix? 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 development model. I think we have long way to go to figure this out. 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org