Home Home > 2008 > 07 > 10
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for July 10th, 2008

Buildservice and L3

July 10th, 2008 by

These days some people from various teams spent a lot of time the last days discussing topics around L3. L3 means Level-3 support and is one of the services that we offer for our enterprise product series. It is about bugs which are not solvable through our support organisation but require developer eyes to stroll through source code.

What that has to do with openSUSE you might wonder. Well, since we’re currently working on switching our internal build process to a Buildservice based solution, L3 comes into play as well as other parts that are hardly visible for the community but important for the business.

L3 is a really tough game: Customers are paying money for the service and if they call they expect premium service quickly. Often enough enterprise operations are endangered by L3 bugs (or it is said that it is 😉 and clearification is needed quickly to relax the situation.

For the brave guys offering this service that means that they need to replay the customer situation quickly, debug, find the bug and if needed provide a fix for the customer.

The customer of course can tell more or less accurate which system he is running on which hardware. But than it’s getting rough for us: Finding the correct source for this constellation might sound easy, but if one adds up the amount of products that we maintain, it’s subflavours and service packs and also considers the lots of maintenance updates that the customer is expected to install, it becomes clearer that there are lots of possibilities and huge hard drives with content ;-).
Having found the correct source debugging (often together with the customer under time preasure), fixing and providing a fixed package begins.

L3 is an impressive bussiness for me, done by courageous guys.

Even more nice that the Buildservice helps a lot here because it makes at least building of debug info packages and fixes easy. A well thought through project structure in the Buildservice linked together with sourcelinks and aggregrations (which is a science for itself which one where 😉 eases (at least) the source organisation a lot. Other things also sound promising.

There is still some work to do until all peaces fit together but we are looking forward to helping the L3 collegues to improve their processes with the Buildservice and maybe some other tools.
I know, this is not exactly related to community questions but I thought it might be interesting to read about these things from time to time as well…

new osc package released

July 10th, 2008 by

After two or three weeks of coding (not mine mostly, but by Marcus and Dirk), a lot of good stuff has accumulated in the osc development tree. Time to release a new package. It is a particularly good moment because today the 1.0 release of the Build Service has been announced.

The list of changes is long, the NEWS file has it all. Overview:

  • version 0.105
  • easier usage of osc submitreq: It is less picky on commandline arguments, can be called in working copies or project directories, figures out which build service instance to use, and has improved output. Also, there is a osc submitreq delete action now (which only works if you have write permissions on the destination though)
  • osc search: added option -i|–involved, to show in which projects/packages a developer is involved
  • osc importsrcpkg: no signature check anymore
  • osc linkpac: –revision option added.
  • osc copypac: use the correct userid when copying to another api host
  • osc build: double check the buildinfo for local builds.
  • osc buildhist: change the output into a format which better matches actual RPM filenames.
  • osc commit: give commit message tempfiles a “.diff” suffix, so syntax highlighting automatically works in capable editors
  • don’t expand/unexpand if the working copy has local modifications – this is a workaround for #399247 but this way the working copy isn’t screwed up. Also, make sure no _linkerror files end up in working copies.
  • better error reporting in a whole number of cases, especially printing out more available detail. For instance, osc meta now prints out a concrete text why something you submitted was not accepted.

Have a lot of fun with it.

And just a note, remember that it is very easy to write osc plugins in order to extend or alter the functionality! Here’s the documentation.