On Thursday 14 June 2012 12:48:22 todd rme wrote:
On Thu, Jun 14, 2012 at 10:46 AM, Stephan Kulow
wrote: 2. We should work way more in pure staging projects and less in develop projects. Having apache in Apache and apache modules in Apache:Modules and ruby and rubygems in different projects may have appeared like a clever plan when set up, but it's a nightmare when it comes to factory development - an apache or ruby update are a pure game of luck. The same of course applies to all libraries - they never can have all their dependencies in one project. But this needs some kind of tooling support - but I'm willing to invest there, so we can more easily pick "green stacks". My goal (a pretty radical change to now) is a no-tolerance strategy about packages breaking other packages.
For the specific cases you mention, this could be solved by also having the packages in, for example, Apache:Modules also build against Apache. Before someone submits a change from Apache they should be required to check that all packages that build against the current Apache version in Factory also build against the version in the Apache repository.
devel:languages:python already does this, as does devel:languages:ruby:extensions, but perhaps having it mandatory to compare the results before submitting, or even automating it so OBS checks whether the results of the two build targets match, would help this somewhat.
Another solution, although much more (and maybe prohibitively) resource-intensive, would be for each submission to, in a temporary scratch project, either rebuild all packages that depend on it (and all packages that depened on those, etc), or rebuild all of Factory, and make sure the build results match the build results from the last factory build.
Another potential issue is that people may build a package in its devel project, submit it to Factory, then assume it builds there (which it may not), or that if it is still building in the devel project that it is also still building in Factory (which it also may not). Having OBS somehow display in a package's devel project version that there is a problem in the Factory version might help with this. In the web interface this would probably be displayed in each package, as well as in each repository's Monitor interface (if that repository has any packages that are devel packages for Factory).
Package linking is inconsistent and should probably be cleaned up. Some packages link to the version in Factory, while some link to the version in the devel project. Figuring out which is better and make a policy about this might help this somewhat.
Also, I would suggest that when looking at the list of packages in the web interface and the monitor, there should be some icon, font difference, coloring, highlight, bold, or some other visual indication when a package is a devel package for Factory, so people know to pay special attention to it.
-Todd
I think many of these suggestions are good. I do expect that they require heavy additional building in OBS and we might need extra hardware to be able to do this... That SSD discussion might have been more important than we thought :D