Michal Hrušecký has been helping out on maintaining Factory in shape and shares his experiences.
Factory is development version of openSUSE and it is where the next openSUSE is taking form. Hundreds of packagers send packages into Factory to be integrated as a part of the new release and many more use Factory for testing or for their daily work. Thus it is really important to keep Factory rolling and usable. Everybody knows that Coolo is the Factory master and he does everything to make next openSUSE be the best ever. But keeping factory in shape is really complicated and stressing task. There are dozens of request everyday and each one of them can potentially break something. So Factory can always use a pair of extra hands and for some time I have been one of them. I’d like to give you some insight in what we do, working on keeping Factory building and working.
Keep it building
With a constant influx of newer and cooler versions of libraries and tools it is easy to break existing applications with shiny new software. So we always have some build failures in Factory. Part of our job is to resolve them because if it doesn’t build, you can’t test nor ship it. As developer, you may have seen submit request in various projects in OBS fixing builds for Factory. Everyday I take a look at a number of build failures, investigate why they are not building in Factory and try to do something about it.
For example new version of the GNU C Compiler (GCC) is quite often more strict on includes, requiring developers to be more verbose about the exact internal and external libraries there applications require to be build. What used to build now doesn’t, because you are missing include files. The older GCC let you slip by, but now you have to fix it, build failure by build failure. Another example is GTK which keeps deprecating old API functions and you have to keep up and replace them with correct counterparts from the new API. Sometimes even the kernel changes API and third party modules stops building. All these errors will get eventually resolved upstream (if upstream is alive), but as we follow upstream quite closely before feature freeze, it may happen that we are first facing these issues because sometime we are the first ones who tried to compile this software using new GTK or the new GCC. Of course, we attempt to get these fixes back upstream and share them with other distributions where appropriate!
Image depicting the Factory Workflow
Test it
Another important part of working on a better Factory is testing. If everything builds, we’re happy. You might have heard the saying:
if it builds, ship it!
(un)fortunately, this isn’t Coolo’s idea of how the world works. In Factory, things not only have to build, but also work. Oh, AND conform to some stringent requirements. Here …
Así que toca utilizar alternativas menos libres como la propia interfaz web u otras opciones.
El sitio de trabajo no es muy útil sin unos cuantos sistemas de test y desarrollo y otras tareas de desarrollo. Utilizo varios sistemas para el desarrollo del kernel y para el testeo de los lanzamientos estables.
I consider it a really good step. Defaults are bult-in after all, so why to put them in config file? So I took theirs, added few things. For example 