Dear all,
Sorry for the long silence about this.
Here is where we are now (in git, nothing merged/in prod atm): * user can request new packages on pkgdb * user can request a new branch for a package on pkgdb * these actions are recorded and stored in pkgdb Available at: http://209.132.184.188/admin/actions/ and http://209.132.184.188/api/admin/actions/ * there is a new pkgdb-admin part of pkgdb-cli allowing to list actions and act of them (approve (ie: process)/deny) -> the pkgdb UI only updates the status of the action, while the cli pkgdb-admin actually process the request (as well as updating the status of the action at the end) -> pkgdb-admin would be the place where we would add all the checks we want to do before processing a package/branch request
fedmsg messages will be broadcasted for new branch.
This part is all there and basically ready :)
The second part is about listening to fedmsg message about new branches and adjusting the git repos accordingly. This is where things are a little more hairy.
Currently, we have fedmsg-pkgdb-sync-git [1] that basically listens for pkgdb messages on the bus and run the ansible playbook: run_pkgdb_sync_git.yml [2] (which in turn runs pkgdb_sync_git_branches.py) when needed.
The problem which I am facing is in the case of new EPEL branch creation. These branches are created from another one. For example in the case of the epel7 branch we used (are we still?) to branch either from either el6 or f19. With that in mind, I allowed in pkgdb to specify from which branch one would like to get the new branch. The problem is that this information is not available to fedmsg-pkgdb-sync-git and even if it was, we would not be able to pass it along to the ansible playbook.
So afaics the options are: 1/ We hard-code somewhere from which branch each branch should come (ie: f* comes from master, el6 comes from ?, epel7 comes from f19...) 2/ We manage to create the branch in such a way that they point to the first commit in the repo (suggestion from Till), from there the maintainers should be able to fast-forward to the branch they think should apply 3/ We manage to just create the branch in gitolite and just let the maintainer populate it by merging the branch they think should apply
I have a preference for #3, but our tests with bochecha for it didn't quite succeed.
But in all 3 options, I basically can drop the `branch_from` field when requesting a new branch in pkgdb.
So what is our preference and how do we want to proceed from here?
Thanks, Pierre
[1] https://github.com/fedora-infra/fedmsg-pkgdb-sync-git [2] https://infrastructure.fedoraproject.org/infra/ansible/playbooks/run_pkgdb_s...
On Thu, Oct 09, 2014 at 11:55:07AM +0200, Pierre-Yves Chibon wrote:
Dear all,
Sorry for the long silence about this.
Here is where we are now (in git, nothing merged/in prod atm):
- user can request new packages on pkgdb
- user can request a new branch for a package on pkgdb
- these actions are recorded and stored in pkgdb Available at: http://209.132.184.188/admin/actions/ and http://209.132.184.188/api/admin/actions/
- there is a new pkgdb-admin part of pkgdb-cli allowing to list actions and act of them (approve (ie: process)/deny) -> the pkgdb UI only updates the status of the action, while the cli pkgdb-admin actually process the request (as well as updating the status of the action at the end) -> pkgdb-admin would be the place where we would add all the checks we want to do before processing a package/branch request
So I have started working on these checks. For the moment I have:
For new package: - Check that all the person that commented on a review are packagers -> as in, if one of them is not a packager, the person running the command might want to check it - Check that the person that set the fedora-review flag to '+' is a packager - Check that the title of the review follows the expected title: 'Review request: <pkg_name> - <pkg_summary>' where both pkg_name and pkg_summary are the info filled in pkgdb (one of the idea here being to check if we're not processing the request for a new package Foo while pointing at the review of the package Bar)
For new branch: - for new Fedora branch we said we can approve them directly if the user is already a point of contact for another branch - for epel branch - here I believe the biggest problem is: does the package exist on RHEL? and iirc, we do not have a simple solution for this
Are there other checks we would like to have?
Pierre
rel-eng@lists.fedoraproject.org