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.
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?
So far this proposal is way too vague to actually discuss this.
far as a "stable base" is concerned it actually becomes easier as one can stick to released components. It does become a bit more difficult for those that want to live in "alpha" world, i.e. Factory as we know it today.
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. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead 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