On 12/02/2013 07:38 AM, Stephan Kulow wrote:
On 02.12.2013 13:14, Adrian Schröter wrote:
I do not see the need for this actually. It is
perfectly fine to run
the staging approach, but replace more then one package in it.
We may should have a staging project for collecting such small changes.
But we should release them altogether to Factory after validating it
with one rebuild (plus possible QA checks if we have some in future).
That sounds like a very sensible thing to do. I wonder how to manage it
though. Any ideas?
Let's assume we have a limited set of staging projects, we'd need to put
a change into one of them "where it fits best".
One option may be to collect changes for a certain period of time and
then run a "final" or "master" build of that staging project. If
successful it moves to factory. For example there could be a staging
project for GNOME, KDE, other DEs. One could collect all the scripting
language stuff Perl, Python, Go, PHP..... into one staging project as
they are reasonably disconnected and people will not step on each others
feet. The problem with that is that if Perl is broken changes for Python
cannot migrate to factory either. Then it becomes a people management
problem and in the end is the root cause for the "ever growing number of
staging trees problem" I mentioned. Also the time factor needs to be
debated as a contributor can only get changes into the "distribution
proper" based on the cadence of the staging tree he/she works in.
Whatever the solution, I think the following basic premisses apply:
- People interested in contribution to the distribution, i.e. having
packages in factory want to see their changes as soon as possible in
factory after submission
- People are not very tolerant about having their changes blocked by
apparently unrelated "broken" changes. Not very tolerant means that
people loose interest quickly when they cannot get their changes into
factory because something out of their area of interest is broken.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org