From Fedora Project Wiki
(Created page with "= BuildSys Analysis = == Use Cases == * User logs in using OpenId. * User creates a repo. POLICY: who can create a repo, how many repos? ** The repo has a multiple mock-conf...") |
No edit summary |
||
| Line 3: | Line 3: | ||
== Use Cases == | == Use Cases == | ||
# User logs in using OpenId. | |||
# User creates a [[PrivateRepo|private repo]]. POLICY: who can create a repo, how many repos? | |||
# User alters the repo settings ([#MockConfig], TODO) as he wishes. | |||
*** Each mock-config can be altered: adding more yum repos, altering minimal buildroot. To be prepared for some kind of dist-git, we should have both SRPM build mock configs and RPM build mock configs | |||
== Explanations == | |||
This section explains different terms and their meanings/functionality details. | |||
=== PrivateRepo === | |||
The whole thing :) | |||
* The repo has multiple [[#MockConfig|mock configs]], e.g. fedora(/centos?) release and architecture. | |||
* POLICY: Each repo has only repo-level permissions. The permissions should be divided at least into these groups: repo-admin (specifies permissions of other users for the repo), repo-rel-eng (can add/modify/delete mock configs), repo-packager (can build packages, delete old builds). No package-level permissions are considered for first version. | |||
=== MockConfig === | |||
* A single mock config in a repo (this should in fact be a mock config file as in /etc/mock). | |||
* Each mock-config can be altered: adding more yum repos, altering minimal buildroot. To be prepared for some kind of dist-git, we should have both SRPM build mock configs and RPM build mock configs. The first version should only use RPM build mock configs. When both are used in later versions, they should come in pairs (e.g. each RPM build mock config should have either associated SRPM build mock config - or none, perhaps). | |||
Revision as of 07:18, 10 September 2012
BuildSys Analysis
Use Cases
- User logs in using OpenId.
- User creates a private repo. POLICY: who can create a repo, how many repos?
- User alters the repo settings ([#MockConfig], TODO) as he wishes.
Explanations
This section explains different terms and their meanings/functionality details.
PrivateRepo
The whole thing :)
- The repo has multiple mock configs, e.g. fedora(/centos?) release and architecture.
- POLICY: Each repo has only repo-level permissions. The permissions should be divided at least into these groups: repo-admin (specifies permissions of other users for the repo), repo-rel-eng (can add/modify/delete mock configs), repo-packager (can build packages, delete old builds). No package-level permissions are considered for first version.
MockConfig
- A single mock config in a repo (this should in fact be a mock config file as in /etc/mock).
- Each mock-config can be altered: adding more yum repos, altering minimal buildroot. To be prepared for some kind of dist-git, we should have both SRPM build mock configs and RPM build mock configs. The first version should only use RPM build mock configs. When both are used in later versions, they should come in pairs (e.g. each RPM build mock config should have either associated SRPM build mock config - or none, perhaps).