On 12/03/2013 01:21 PM, Michal Hrusecky wrote:
Robert Schweikert - 12:59 3.12.13 wrote:
...
Correct. I agree that having basically one person doing this (coolo today) is not a good approach and we need to fix this problem. What I am not so confident about is that those touching the very core packages have the interest/knowledge/energy/time to chaperone a staging branch.
If AJ pulls a new glibc from upstream and tons of stuff breaks in the staging project we are basically asking AJ to be coolo and run after all the package maintainers that now have broken stuff. From my point of view that doesn't really resolve the basic problem, it just shifts the problem onto the shoulders of someone else. That someone else most likely has less time to chase all the broken stuff than coolo. I am not advocating to stay with what we have, I just fail to see how the staging of updates improves the situation overall. Certainly coolo will do less chasing and that's a good thing, but will the distribution as a whole improve or are we more likely to get stuck with older versions because the new chaperones of the staging branches do not have the time/energy etc. to chase everything that happens to break?
You missed the second part. No new version of the broken package will get in unless it fixes the staging project.
Hmmm that would require that everyone that is a staging tree chaperone knows about all the broken packages in all staging projects. If the chaperone's do not poses this knowledge a new version of the broken package can enter factory through an unrelated staging branch.
So now both maintainers are stuck with old versions that work together. And it is in the interest of both of them to resolve the issues.
Nope, it is in the interest of the user that they resolve the issue, not necessarily in the interest of the packager.
...
I think what we are actually doing is discouraging changes for packages that have a large impact such as gcc, glibc and others. As I mentioned in another thread, we do not want to encourage "dump and run" but this appears to go toward the other extreme. Basically if one is not willing to chaperone a staging project better not send any things that are potentially disruptive.
No, we are postponing the integration of changes till we are sure that integration will result in something that would work :-)
True, but the process chosen to get there requires more stage tree chaperones, i.e. we need to clone coolo. Why do we believe that is going to work? Why do we think that everyone that maintains some low level package is ready, willing, and able to chaperone a staging project with potentially many broken things? But we do not really need to discuss this in a theoretical vacuum. @Richard are you going to chase all the package maintainers that have broken packages when your gcc update cannot get merged to factory and is stuck in a staging branch? I do not want to put words in Richard's mouth, but historically the answer to that question has been NO. coolo and others have done most of the chasing and fixing. Thus, having the staging branch addresses the "factory" is broken problem, but all the other issues, i.e. we only have a few people chasing and fixing things remain the same as they are today. Who is going to be willing, able, and resourceful enough to be a chaperone for a staging branch and has the necessary time to do the job well? 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