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. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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