* Robert Schweikert <rjschwei@suse.com> [2013-07-31 15:47]:
On 07/31/2013 09:21 AM, Guido Berhoerster wrote:
* Robert Schweikert <rjschwei@suse.com> [2013-07-31 14:51]:
Hi,
On 07/30/2013 04:37 PM, Stephan Kulow wrote:
Am 30.07.2013 20:01, schrieb Bernhard Voelker:
On 07/30/2013 07:08 PM, Robert Schweikert wrote:
With this as a short background I'd like to propose a change in development model for our beloved distribution. Everything needs a catchy title, thus I'll call it "Integration of independently released components with pull option", very catchy I know ;) .
I'v not been working for openSUSE for so long yet, so my view may be a bit limited.
I don't think such components are a good solution. Whatever problems may arise due to dependencies to other software will arise in this model, too ... but probably much later in the case the dependencies cannot be foreseen. E.g. some package coming with a shell script which uses a deprecated option which will be removed in the other package. If that dependency is not well-defined, then the problem will arrive when the components come together; and that can be pretty late according to how I read your suggestion.
In other words: whatever work has to be done in a package to adapt to a change in another package will have to be done anyway. To my knowlegde the best thing you can do is to start working early on it. I don't see how that workflow could reduce the "sleeping time" before starting to fix a problem.
This is what I think too. You only move problems and while you may (I don't even believe in that part to be honest) ease the work of the release team, you make it 100x harder for users to pick a stable base to work with. Because the dependencies are still there, but to test version 17 of X together with version 22 of GNOME together with version 8 of evolution you need to update to version 11 of Networkmanager and that then only works with the latest CORE, which then unfortunately is no longer available for X - and at that time you switch to gentoo and compile it all yourself (of course I forgot like 29 components).
Well, lets just say that problem can be addressed with definition of component boundaries that may not be immediately obvious today. As
You haven't laid out in any way along what lines you want to divide the packages that make up Factory into "components"
Purposefully, if I would have, we'd be discussing the contents of the components and implementation details, a discussion which at this point would IMHO not be very helpful.
Well, I would find it helpful because I don't see any feasible way to divide the packages into such components because they simply do not align into neatly separable components for reasons others have already pointed out. And it also makes a difference if we talk about components barely above individual package level or something that resembles the sizes of current development projects.
and how you want to deal with the interdependencies. Or how and by whom "components" should actually be managed, e.g. do you want to create dozens of "components" release teams?
Well the developers that work on any given component should manage their releases as it is not a whole lot of work. However, yes if someone is interested in contributing by being a release manager for a given component, why not?
What does a component consist of? Who are component developers? Today we have a variety of maintenance models, some packages are maintained by a group at the project level, some are manages by a single project maintainer with a few exceptions where packages have an in dividual maintainer, there a projects consisting of packages which have only individual maintainers etc., how are components supposed to be maintained? It is completely unclear to me what you are actually proposing here.
Making it more difficult and painfull for users to run Factory and having less integration is the exact opposite of what we need. openQA has its use but it is no substitute for having a broad mass of people exercising the development version with their daily workload, we should work on luring more people into running Factory before the laste release candidate.
More testing by more people is always good. Unfortunately to this day we have failed to come up with ideas that have any effect on the number of people that use factory.
I think increasing the quality of Factory, that is by filtering out the worst problems early and preventing loger periods of breakage, and maybe some marketing (testing days) we can make it more attractive. And I don't see a shortage of ideas to achieve that, e.g. by expanding openQA testing, or through the ability to create more staging projects as Coolo suggested. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org