From Fedora Project Wiki
mNo edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
# User logs in using OpenId. | # User logs in using OpenId. | ||
# User creates a [[#PrivateRepo|private repo]]. POLICY: who can create a repo, how many repos? | # 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. | # User alters the repo settings ([[#MockConfig]], TODO) as he wishes. | ||
| Line 14: | Line 14: | ||
The whole thing :) | The whole thing :) | ||
* The repo has multiple [[#MockConfig|mock configs]], e.g. fedora(/centos?) release and architecture. | * The repo has multiple [[#MockConfig|mock configs]], e.g. fedora(/centos?) release and architecture. | ||
* POLICY: Each repo has only repo-level permissions. The permissions | * The repo has defined [[#Permissions|permissions]]. | ||
=== Permissions === | |||
POLICY: Each repo has only repo-level permissions. The permissions are be divided 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 === | === MockConfig === | ||
A mock config inside a PrivateRepo. | |||
* A single mock config in a repo (this should in fact be a mock config file as in /etc/mock). | * 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). | * 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:25, 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.
Terms, Definitions, 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.
- The repo has defined permissions.
Permissions
POLICY: Each repo has only repo-level permissions. The permissions are be divided 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 mock config inside a PrivateRepo.
- 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).