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
- the submitter asks for help on the factory ML
We should also have a rule saying (assuming it didn't happen in a
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
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
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
The other problem with the staging model is that the
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.
Feel free to close this bug as accidently ;-) fixed...
Nothing happens here by accident ;-)...
[> Christian Boltz and Stephan Binner,
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org