openSUSE:Factory development model
|
Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу) |
Содержание
Модель разработки
Factory is built in its own project openSUSE:Factory on the Open Build Service reference server. As you can see, it is a huge repository of packages. Development, however, does not happen directly in openSUSE:Factory but in so called devel projects. A devel project, as the name suggests, is a project where development happens for a specific group of packages. Like multimedia, GNOME, KDE or Kernel. The relation of packages in the openSUSE:Factory project to packages in the devel projects is expressed in the meta data of the packages inside openSUSE:Factory.
Devel Projects
Each devel project has its own set of processes, rules and communication channels that fits them best. The reference point for this information is the project description of their Build Service project. Devel projects are also subject to change because the world of FOSS software is constantly evolving. Certain software becomes obsolete, standards and defaults change. That means devel projects can change names, get dropped, be newly created, or change content and direction, as can packages in devel projects. The current devel projects feeding into factory can be found in the drop-down menu on top of this page. You can find a summary description of the Factory submission process here.
Staging Projects
Once in a while, a specific core package (like a new version of GCC) is deemed to have the potential to break so much that the Factory Maintainers decide to create a special staging project in which Factory is build against the new package. Its developers can then fix the resulting breakage before integration back into Factory.
Development Process Overview
The complete Development Process is detailed on this page. It consists of the following steps:
- Roadmap and Feature Planning is managed by the Release Manager who creates the initial roadmap. Meanwhile, the developers set technical goals for the distribution based on the projected release and freeze dates.
- Package Development starts in a OBS home project [8]. The Package Developer can work here without affecting anything else. Once the package is good enough a submit request to a devel project can be created.
- Devel Project Integration follows, overseen by Project Maintainers who keep an eye on the technical quality of submit requests and the overall state of a Devel Project. After successful integration, the Project Maintainers create Submit Requests for Factory.
- The Review Process makes sure that all packages on their way to Factory go through 4 (sometimes 5) reviews:
- Factory-Auto: an script that checks basic rules [10]
- Legal-Auto: a script checking if the license of the package is in the permitted license database [10]
- Repo-Checker: a more in depth (and slow) automatic check [10]
- Review Team: human check of the request.
- Optional: Manual Security Team check (if Legal-Auto deems that necessary)
- Factory Integration is overseen by the Factory Maintainer and the Release Managers who accept the submit requests that come from the different devel projects to Factory [9]. They mostly decide based on timing and policy factors like freezes that might be in effect as the review process has already taken care of quality. In some cases, they decide a Staging Project is needed.
- The Quality Assurance Process (openQA) runs all the time. Periodically, ISO image are generated by OBS and ran through a predefined set of tests. If problems are found a report is created pointing to the failures in the ISO image.
- Release Process. Based on timing and the results of the QA process, a milestone or beta can be released by the Release Manager. He/she takes care of the release tasks: calculate the ISO MD5/SHA1 hashes, set up the repositories, prepare and seed to the mirrors, deploy the products and kick marketing to communicate the release.
- Public Testing takes place after the milestone release, usually on real hardware and to a lesser degree in virtual machines.
Not too long after the release of the Beta (the final milestone before total freeze), the Release Team forks off the release from Factory and uses the Maintenance update process to stabilize the release. Find out more about the release process here.
Find out what is what in the Glossary.
Governance Model
Bug fixes and new features have to be first committed to a devel project, and from there will be forwarded to the main openSUSE Factory project. Because of this, the governance of the Factory project is also further broken down.
Responsibilities
| Package | Devel Project | Factory |
|---|---|---|
| Maintainer & Bugowner | Project Maintainer & Bugowner | Release team |
See a more detailed list of roles and responsibilities here.
Escalations
Most decisions are taken by the maintainer of the package. If the maintainer cannot take a decision, or if a conflict arises between maintainers, the devel project maintainers decide together. If the devel project maintainers also do not come to a conclusion, or a conflict between two devel projects arises, the openSUSE release team takes the decision. If the decision cannot be taken by the release team, they appeal to the openSUSE Board which tries to facilitate the decision with all the involved people. If that also is not successful, the board puts up the issue to a vote among the members.
Создатель пакета ==> Devel project maintainers ==> openSUSE:Release team ==> openSUSE:Совет ==> голосование сообщества