The openSUSE release team is taking care of building and releasing of all openSUSE distributions. It keeps an eye on
- The release of all openSUSE distributions
- The openSUSE:Factory project in the Build Service and submissions to it
- The bugs for the next openSUSE release in Bugzilla
The team also tries to facilitate and take decisions regarding the direction and well being of the openSUSE distributions.
- #opensuse-factory is the IRC channel our members hang out in
- firstname.lastname@example.org - is the mailinglist where we coordinate over the next release and discuss global changes.
Subscribe - Unsubscribe - Help - Archives
- Bugzilla is where we fix and track issues found in the Factory
- Meeting minutes from a Wednesday 10:30am (CET) openSUSE Release Engineering meeting (10:30 CET/CEST on Wednesdays, details in the etherpad).
- Dimstar Talk - Contributions openSUSE Tumbleweed Release Manager
- RBrownSUSE Talk - Contributions openSUSE Tumbleweed Release Engineer, MicroOS|Kubic Release Manager
- Guillaume_G Talk - Contributions (Dedicated to Arm architectures)
- AdaLovelace Talk - Contributions (Dedicated to s390x architectures)
- lkocman Talk - Contributions openSUSE Leap Release Manager
- Dirkmueller Talk - Contributions Regular openSUSE Step and Arm Contributor
- Max Lin openSUSE Release Engineer
- Douglas DeMaio openSUSE Coordination
What do we do
We are trying to document our processes for various tasks we are following when maintaining openSUSE:Factory.
Building and distribution of [Portal:Leap|openSUSE Leap] is very different from the way how we build openSUSE Tumbleweed, as the distribution is based on inherited binaries from SUSE Linux Enterprise. As an example we do not use Staging for the changes to the based of the distribution, but rather only for community part of packages maintained in openSUSE Backports project.
How to help
Are you an openSUSE Member and want to help us? Contact us on the mailing list or irc, there are loads of things we need to do. Some examples of the tasks we would love but don't have cycles now:
- Extending documentation of our processes
- Fixing corner case issues in the tools we use for the Factory deployment
- Writing new automation extension from scratch to speed up the processes
And for common work we could use more hands on:
- checking the Factory health and fixing unresolvable/failed things
- fixing issues on status page, plus providing descriptions for unknown failures to make it easy for maintainer to pick-up
But please be aware that maintaining a distribution is a very time consuming and technically challenging task. We appreciate if you bring something to the table but we most likely won't find the time to teach you a lot.