Home Home > 2015 > 08 > 28 > Integration process for openSUSE Tumbleweed, Leap explained
Sign up | Login

Integration process for openSUSE Tumbleweed, Leap explained

August 28th, 2015 by

The SUSE office in Nuremberg, Germany, had a special presentation given by Dominique Leuenberger, last week about the interconnecting points of the openSUSE project.

Specifically, Leuenberger covered the integration process of Tumbleweed and Leap and explained the difference between the two.

“Leap is trying to find the balance between how much SLE (SUSE Linux Enterprise) and how much Tumbleweed,” he said.

Tumbleweed is a tested and stable rolling release with the most recent kernels, software versions and packages while SLE focuses on delivering enterprise-quality technology, efficiency and systems management.

Leuenberger, who has been in the openSUSE project since it started, further explained how items enter the Open Build Service, are tested and reviewed in the Factory process and then how items receive automated testing in openQA.

“Once openQA is ready, we give this all to our happy users, hopefully, most of the time,” he said. “As usual they always report more bugs, which is why the openSUSE Factory mailing list is really helpful.”

Users of Tumbleweed are recommended to sign up to the openSUSE Factory mailing list to share user experience and get involved with improving and advancing systems to create long-term stability for Free and Open Source Software systems.

The audio and video quality isn’t the high quality, but it is understandable and the slides are readable. The presentation last about 25 minutes and there was about 30 minutes dedicated to the questions about the software development process.

Both comments and pings are currently closed.

One Response to “Integration process for openSUSE Tumbleweed, Leap explained”

  1. Scott Couston

    We need to revert to publish the number of bugs outstanding and in progress once a month as we use to. As a development group this is the most important information we could publish each month.
    For those of us who have been around for a while, many of us become disillusioned when, by the time our bugs get actioned the version we report upon, is somewhat 3 or more versions behind. The bug gets closed unactioned.
    We can only hope releases are based upon technical excellence and stability and NOT the calendar driving release after release.
    If necessary release a service pack but retooling for calendar based releases as a waist of manpower