On Wed, Jul 31, 2013 at 12:12:39PM -0400, Robert Schweikert wrote:
Hi,
On 07/31/2013 10:15 AM, Michal Vyskocil wrote:
On Wed, Jul 31, 2013 at 03:15:46PM +0200, Bernhard Voelker wrote:
On 07/31/2013 02:01 PM, Klaus Kaempf wrote:
If some change in Factory breaks the build, I want to see it in _my_ (devel) project.
+1
... and even more: when I build may package in Base:System, it would be nice to have it also (tried to) built against a bleeding edge tool chain. If that fails, I wold be able to react long before that tool's bleeding egde version goes into Base:Build and Factory.
It does not sounds cool to create staging projects for each of 100+ devel projects we do use. What would be worthwhile is to be aware that your package does not build in Factory staging project.
From my POW he biggest design flaw in OBS is that is project centric. It is nice and easy to create your own project. But it's impossible for a package maintainer to have any clue what's going around with his package. And we are mostly selfish beasts, so we do take a care about our own stuff. Atm all you can do is to go through a number of random projects, like devel project, factory, various staging** subprojects made by coolo.
Simply switch a focus from projects* to package and you'll see how easy it will be
package/ devel - OK factory - OK staging-gcc48 - FAIL staging-rpm - FAIL staging-libpng15 - OK
That should certainly eliminate the lack of information I claim at least a group of people have.
* I do consider the idea of devel projects as the most harmfull thing we have to deal with. It is build on the similar ideas like "components", but that seems to be proven it does not work. Interdependencies are real and kill-ya.
I've seen component models work very well and scale very well, yes tooling to manage dependencies is necessary, but I have yet to see a set of dependencies that cannot be pulled apart.
OK, I'll put you, to some extent, a real world example. ftp://ftp.suse.com/pub/people/mvyskocil/maven2-bootstrap.png of course this is a Java niche, which is quite isolated, but still - some of packages needs eclipse, which used to depends on mozilla for html help rendering, so you would easilly ends in a state that every 6 weeks, your tomcat build got broken, because mozilla released new Firefox, or there is problem in gtk/pango/glib, which broke swt, or ... some popular Qt based application linked with Java will be released (http://fatrat.dolezel.info/), which will be integrated to kde, ... So we don't control dependencies, upstream projects do. And you can't isolate the lower levels affecting the upper ones as well you can't control if some upper level component start to require a specific version of lower level. And you even can't control if the dependency chain get crazy like tomcat beeing dependent on glib or KDE requires Java stack. If upstream goes crazy, we must follow or die (or not to release such beast). There is only one way how to isolate you from changes and it's called static linking or bundling and that's no way for Factory. Or to control as much stack as we can. I do consider Factory as Continuous Integration projects, where bad things happen and are expected. And it's usually better to get the broken state earlier than to isolate them in some component, because before release all components will end in one haystack. BTW: in contrast I don't thing that "components" approach for already released products should be bad idea, but that's different story. Regards Michal Vyskocil
Later, Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead 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