Good morning everyone, We're now in the final sprint before Pagure over dist-git is a real thing. This is a great time and we're very excited to see it happen. However this change brings other changes with it which are detailed below. Point of contact in bugzilla ---------------------------- Pkgdb used to be the place where package points of contact were set and then synced to bugzilla. With Pagure over dist-git, the main admin of the Pagure project is now the point of contact. However, this is not always valid. For example, there are cases where the main admin in Pagure does not want to be the point of contact for EPEL branches, or the point of contact is a group. For these cases, we have set up a procedure using a separate Pagure project which allows you to override the default point of contact and set it to a different Bugzilla account. To change the default point of contact, simply open a pull-request (we will build some automation around merging these requests so they do not depend on human interventions). More information at: https://pagure.io/dist-git-requests/ On this note, Pagure does not support having a group as the main admin. We are of course using a script to sync data from pkgdb to pagure for packages and set admin access. When this script runs on a package with a group as main admin, it will set the new main admin to the first account it encounters with commit access that is not a group. So if you are suddenly the main admin of a project where you used to only be co-maintainer before, this is likely why. Feel free to correct the situation with your fellow co-maintainers. CC in Bugzilla -------------- Pagure over dist-git does not offer issue tracking. Issues for packages will continue to be tracked in Bugzilla. However, if you look at the watch options in a project in Pagure over dist-git, you will see there is an option to watch issues on the project. This mechanism will be used to retrieve the list of packagers to be CC'd on Bugzilla tickets. Note: there is a ticket open against Pagure to have the list of people watching the project available in the UI (it is currently only present in the API). New package and new branch request process ------------------------------------------ PkgDB used to be the place where packagers could request a new branch or a new package to be added. The new package and branch processes will now rely on a project hosted on pagure.io where people can open a ticket to request additions. There is a CLI tool for packagers to use: fedrepo-req (already present in updates-testing) that opens the ticket for you in such a way that these requests can be automatically handled by release engineering. More information about this tool at: https://pagure.io/fedrepo_req Koschei integration ------------------- Packager used to activate koschei monitoring in pkgdb. Since pagure does not offer this possibility, koschei has activated its own UI to allow that. If you want to tweak koschei monitoring, the koschei web UI is now the place to do it. Anitya integration ------------------ Packagers used to be able to activate anitya integration in pkgdb. Since pagure does not offer this, the integration with anitya and the new hotness will now be achieved using the same pagure project as the bugzilla overrides. This is targeted to be adjusted after pagure is deployed. mprahl and threebean have volunteered to port the current integration status to the new mechanism without requiring any action from you. Efforts on this can be tracked at: https://github.com/fedora-infra/the-new-hotness/issues/183 Pkgdb is still there! --------------------- That is true, pkgdb is still available at its usual location. However, it has now been made read-only. So the data can still be accessed, but as Pagure becomes more integrated into our packaging workflow, the data in pkgdb will slowly grow out of sync -- especially around the different ACLs and packages, modules, containers available. This gives us a little more time to adjust all the tooling that relies on pkgdb. However, be aware the data is no longer current and you cannot rely on it. It takes a while to fork! ------------------------- This is also true. We have optimized pagure to only update parts of gitolite's configuration file when there is a change. However, just re-compiling that configuration file takes around a minute. So when you fork a repo, you may have to wait for your task to be started and that task will take a little more than a minute. Just be patient and it should work. If you wait and the task doesn't complete as expected, please let us know, either on IRC on #fedora-admin on irc.freenode.net or via a ticket on: https://pagure.io/fedora-infrastructure/new_issue One reason we wait for the gitolite configuration to be recompiled is so that once the UI shows the task is done, you can directly commit to your fork. Otherwise, the UI would show you your fork, but if you pushed to it immediately after, you would receive a "permission denied" error. Additional information ---------------------- These are only some of the changes that are coming with pagure over dist-git and more of them are described here: https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb Some of them are still a little bit unclear, so please bear with us. Better yet, come help us figure out the best solution for them. Thank you for your attention, Pierre
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
