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). And of course you need a complete new set of tools too - factory reminder mails? "GNOME component only works with 19292762 permutations of the underlying components, please fix the remaining 27171". What will define a FTP snapshot? how can we create installation DVDs for milestones/testing? I see way more problems than what it would it solve. And what exactly would it solve? I'm not so sure, because the original problem description is "only 2 or 3 people fix things" and I don't see where the new model would create more people to fix things. But let's get back to my favorite example in this context, the main reason 12.2 was delayed: - developer R makes a change to move fsck.$FS to /usr - problem that systems with split /usr are no longer installable was detected, but not understood because it was detected much too late because a lot of other things broke in between - mkinitrd was unmaintained and noone fixed it to support fsck on /usr Now take into account that mkinitrd would be in the Core component, but fsck.$FS would not (perhaps for some values of $FS but not for all). So the breakage would be hidden till component FS27 is actually released. And the question is if the developers of component FS27 actually tested (in my experience it's safe to assume developers never test) and if so, if they tested setups with a split /usr So while discussing development model is never a bad idea, I don't believe in discussing changes without first defining the problem well. IMO the problem is a) Factory is too big and unstructured b) Basically everyone can change almost everything c) Branches are only possible in theory - in practice there are too many problems to be usable d) Too few people actually care and fix problems of importance And I already mentioned in a recent status mail of mine that got almost no feedback: I'm experimenting with splitting factory into groups of importance that are orthogonal to devel projects. Based on those I would then have branches/staging projects that can be verified. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org