On Thu, Jun 14, 2012 at 10:46 AM, Stephan Kulow
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
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
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
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.
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