On 06/14/2012 04:46 AM, Stephan Kulow wrote:
It's time we realize delaying milestones is not a solution. Instead,
let's use the delay of 12.2 as a reason to challenge our current
development model and look at new ways. Rather than continue to delay
milestones, let's re-think how we work.
openSUSE has grown. We have many interdependent packages in Factory. The
problems are usually not in the packages touched, so the package updates
work. What's often missing though is the work to fix the other packages
that rely on the updated package. We need to do a better job making sure
bugs caused by updates of "random packages" generate a working system.
Very fortunately we have an increasing number of contributors that
update versions or fix bugs in packages, but lately, the end result has
been getting worse, not better. And IMO it's because we can’t keep up in
the current model.
I don't remember a time during 12.2 development when we had less than
100 "red" packages in Factory. And we have packages that fail for almost
five months without anyone picking up a fix. Or packages that have
unsubmitted changes in their devel project for six months without anyone
caring to submit it (even ignoring newly introduced reminder mails).
So I would like to throw in some ideas to discuss (and you are welcome
to throw in yours as well - but please try to limit yourself to things
you have knowledge about - pretty please):
1. We need to have more people that do the integration work - this
partly means fixing build failures and partly debugging and fixing
bugs that have unknown origin.
Those will get maintainer power of all of factory devel projects, so
they can actually work on packages that current maintainers are unable
2. We should work way more in pure staging projects and less in develop
projects. Having apache in Apache and apache modules in
Apache:Modules and ruby and rubygems in different projects may have
appeared like a clever plan when set up, but it's a nightmare when it
comes to factory development - an apache or ruby update are a pure
game of luck. The same of course applies to all libraries - they never
can have all their dependencies in one project.
But this needs some kind of tooling support - but I'm willing to
invest there, so we can more easily pick "green stacks".
My goal (a pretty radical change to now) is a no-tolerance
strategy about packages breaking other packages.
3. As working more strictly will require more time, I would like to
either ditch release schedules all together or release only once a
year and then rebase Tumbleweed - as already discussed in the RC1
Let's discuss things very openly - I think we learned enough about where
the current model works and where it doesn't so we can develop a new one
Can we please get all tangential discussions moved to other threads.
So far in this thread there are discussions about the benefits of
mentoring, the use of certain type of hardware for OBS, OBS feature
discussions and I probably missed a few other side topics.
Can we please stick to the topic.
If you feel the urge to respond to a tangential discussion please start
a new thread and link to the "jumping" off point in the archive of the
list in your initial mail. That way contextually everything is
connected, but the dev model discussion does not get convoluted.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org