We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Rethinking openSUSE release tooling and the build service

Formal Metadata

Title
Rethinking openSUSE release tooling and the build service
Subtitle
Simplify, improve, and increase transparency
Title of Series
Number of Parts
55
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Over the last year I have completed a large amount of work on the tools integral to the openSUSE release process and as such have become familiar with the scope, workflow, and general problems involved. After mulling over these general shortcomings it becomes clear that taking a step back and rethinking some core concepts such as the build service and the way the release tools interact with it is necessary. I have since explored and prototyped a new approach that should drastically reduce the maintenance burden on the openSUSE project while solving major pitfalls, improving transparency, solving a large number of open feature requests, and providing entirely new options. At this point it seems appropriate to present the concept and prototype to a wider audience before investing too much further. Hopefully, the openSUSE community will be as excited about this direction as I am. To start, some background on the type of work being done over the last year will be provided. Metrics will be provided to demonstrate the effect and importance of the work. After which details of pitfalls that force a cumbersome workflow will be provided in addition to covering some feature requests and general improvements desired for release work. The new approach will then be explained and how it resolves a large number of these problems while drastically reducing the overall code-base. With the reduction in the code-base along with adapting modern practices it should be easier to involve new contributors. Preferably key stake holders from OBS and release teams will be present and participate in a healthy discussion.