Hello, Am Sonntag, 1. Dezember 2013 schrieb Robert Schweikert:
1.) Putting pressure on the submitter
Putting pressure on the submitter is a good concept to avoid "dump and run scenarios", i.e. put you code in and everyone has to fix the fall out. However, stated as such the submitter can very easily feel overwhelmed and left alone, thus the submission may never take place. What I think we need is a process/environment that holds the submitter sufficiently responsible to avoid "dump and run" while at the same time providing enough support such that the submitter does not feel left alone and overwhelmed.
While "the submitter fixes everything he breaks" would be ideal, I'd define the goal as: The submitter has to coordinate fixing everything he breaks. This can mean: - the submitter fixes it - the submitter works with the maintainers of the broken packages to get them fixed - the submitter asks for help on the factory ML We should also have a rule saying (assuming it didn't happen in a staging project): If the fixes don't happen in a reasonable time, revert the commit that caused the breakage. I know "reasonable time" is vague, but we'll probably need it that way because it depends on the number of broken packages, time until the release etc.
In a staging model I have no idea how to get there.
That's easy - the package can move from staging to factory after the fallout is fixed ;-)
2.) The staging approach
staging trees upon staging trees. But this only solves the problem superficially as the target tree will move ahead and thus the staging tree by definition is always out of date. Unless the target tree is frozen until a particular staging tree is merged.
The staging tree should link all packages from factory (except the changed package), so it can't be outdated. It just needs to be rebuild. We'll see if we have enough build power ;-) (For speedup, copying the factory binaries to the staging project and only rebuilding the updated package and its dependencies might save some time.)
The other problem with the staging model is that the "potentially risky interactions" knowledge is an implicit set of interactions that the staging tree managers happen to know. This is not expressed anywhere and thus makes it difficult for other people to learn. We have this problem today and from my point of view this will not be resolved with more staging trees.
Except for "staging tree for everything" - but I'm quite sure we'll overload OBS if we create a staging project for every typo fix in a README file ;-) So yes, knowing what needs a staging tree is something you have to learn over time. That's not nice, but I don't see another realistic option. Of course if a package enters factory without staging and breaks something, this is a clear sign that a staging tree would be useful ;-)
There is the component model that I had proposed a while back. The component model may merge well with the idea of rings, that's something that could be explored.
I'm somehow afraid that the component/ring model is difficult to implement because of cross-dependencies - which makes the split into several components difficult. Regards, Christian Boltz --
Feel free to close this bug as accidently ;-) fixed... Nothing happens here by accident ;-)... [> Christian Boltz and Stephan Binner, https://bugzilla.novell.com/show_bug.cgi?id=433239]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org