openSUSE:Build Service Concept Devel Project
Devel project definitions
The Devel Project concepts is technically just a reference in package meta data defining a project where this package usually gets developed and tested. This is most likely only useful for projects where a release master validates the contributions from other people. The project upstream definition has no effect at building time or source management itself, it is just used for giving our source management tools useful hints where to search for sources.
The Devel Project definition shall
- Define the usual responsible people (either single persons or groups) for a certain package (successor of SUSE maintainer). This happens via the user list of the project mentioned in the upstream project definition.
- Allow tools and packagers to work directly on the most current version of a package instead of the possible already outdated version in main distribution (openSUSE:Factory for example).
- Obsolete extra review state in (submit) request handling, instead of this change submissions get reviewed by the owners in upstream project.
- Reduce load on main distribution owners, because usual submissions get preprocessed by people with knowhow in that area first.
Implementation example
The package meta data could contain a optional
<devel project="home:adrianSuSE:Factory"/>
line. This means contributors should go to home:adrianSuSE:Factory project to suggest changes. Our tools, which create branches or request submits should default also to this project, in the assumption that this project owner takes care of it, reviews it and submits it also to openSUSE:Factory in this case.
The upstream project definition is just additional, hopefully helpful, data. It does not restrict any action, so it will still be possible to request merges directly to openSUSE:Factory (for example when the project owner of the upstream project does not react).
Usecase example
openSUSE:Factory package change submission
This is an example description, open for discussion, how a submission to Project/Package does work where the user has no write permission. This is written with openSUSE:Factory in mind especially, but can be also any other project.
Assumption: User wants to add a patch or do a version upgrade to libqt4 package for openSUSE Factory distribution.
- osc co openSUSE:Factory libqt4 ( osc co libqt4 should maybe implicit default to openSUSE:Factory project)
- osc checks for Devel Project definition and receives KDE:Qt44
- osc checks out KDE:Qt44 libqt4 (there should be a switch to disable Devel Project definition).
- User edits the sources
- osc ci
- the server denies the write request because KDE:Qt44 is not writable for the user
- osc offers to request the submission
- user says yes
- osc makes API to create own project home:<user>:Factory (user shall be able change select a different project)
- home:<user>:Factory builds against all KDE:Qt44 repositories.
- osc makes API to create libqt4 package inside this project contain a source link + patch
- osc creates a merge request into KDE:Qt44
- KDE:Qt44 owner wants to have a further change and refuses with the question to use some rpm macro for example.
- Request is in refused state.
- The user has meanwhile removed the sources, so he checks out again home:<user>:Factory/libqt4
- osc shall help him to edit the sources and updating his patch, maybe utilizing quilt.
- osc ci submits the new patch with requested changes.
- osc recreates the merge request
- KDE:Qt44 owner sees merge request and accepts it
- osc command to api to merge changes
- same command marks merged request as done/accepted
- KDE:Qt44 owner requests to merge changes at a later point to openSUSE:Factory maybe together with further changes.