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 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.
And of course you need a complete new set of tools too
Yes we need additional tools, but I don't think that has ever stopped a project previously ;)
- factory reminder mails? "GNOME component only works with 19292762 permutations of the underlying components, please fix the remaining 27171".
The reminder mails would certainly take on a different form. If we think in terms of "this is the way it works now we have to stick with it", then nothing will ever change.
What will define a FTP snapshot? how can we create installation DVDs for milestones/testing?
You'd collect the released version of the components that meet the base requirements you defined for the next release, i.e. every component that is released and supports core version X in the dependency tree. If there is a component higher up the stack and something in between is missing than the developers up the stack have an incentive, self interest, to help those developers in the component they depend on to move forward. Today that incentive does not exist, because everything is in one big clump and in the end people know the Stephan will fix it.
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
Agreed, thus the proposal to break it up and provide a structure via defined dependencies on components.
b) Basically everyone can change almost everything
Not certain that this is a problem. I'd more define the problem as "A change by any given person may break everyone else's packages"
c) Branches are only possible in theory - in practice there are too many problems to be usable
Fair enough, but branches leave problem a.) unaddressed
d) Too few people actually care and fix problems of importance
I happen to believe, and I may be wrong, that this has 2 main causes as iterated in the original mail. People get their stuff broken by unrelated changes and this is rather de-motivating, and people plain and simply do not know. The not knowing part was also discussed during last year's developer model discussion. As I understand it there is some work planned for Hermes thus this part of the problem may go away.
And I already mentioned in a recent status mail of mine that got almost no feedback:
Maybe you need a catchy title ;) 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