Pagure over dist-git: what changes?
by Pierre-Yves Chibon
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
6 years, 1 month
Fedora 27 Change Checkpoint: Completion deadline (testable)
by Jan Kurik
Greetings!
Today, on 2017-Aug-01, we have reached Fedora 27 Change
Checkpoint:Completion deadline (testable) [1].
At this point, all accepted changes [2] should be substantially
complete, and testable. Additionally, if a change is to be enabled by
default, it must be enabled at Change Completion deadline as well.
Change tracking bug should be set to the MODIFIED state to indicate it
achieved completeness.
Incomplete and non testable Changes [3] will be reported to FESCo on
2017-Aug-04 meeting. Contingency plan for System Wide Changes in case
of serious doubts regarding Change completion, will be activated.
Side note: Currently we still have several Changes waiting for FESco
approval [4]. I am going to ask FESCo to consider postponing of this
Checkpoint for these Changes, in case these are approved.
[1] https://fedoraproject.org/wiki/Releases/27/Schedule
[2] https://fedoraproject.org/wiki/Releases/27/ChangeSet
[3] http://red.ht/2vijerN
[4] https://pagure.io/fesco/issues
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
Elections July/August 2017 to FESCo, Council, FAmSCo - Campaign
period has started
by Jan Kurik
The Nomination period of Elections to Council [1], FESCo [2] and
FAmSCo [3] is now over.
The list of nominees follows:
== Council (1 open seat) ==
* Justin W. Flory (jwf / jflory7)
* Langdon White (langdon)
* Nick Bebout (nb)
* Dennis Gilmore (dgilmore / ausil)
* Till Maas (tyll / till)
== FESCo (4 open seats) ==
* Dominik Mierzejewski (Rathann/rathann)
* Stephen Gallagher (sgallagh/sgallagh)
* Randy Barlow (bowlofeggs/bowlofeggs)
* Dennis Gilmore (dgilmore / ausil)
* Till Maas (tyll / till)
== FAmSCo (3 open seats) ==
* Itamar Reis Peixoto (itamarjp/itamarjp)
* Alex Oviedo Solis (alexove/alexove)
* Eduardo Echeverria (echevemaster/echevemaster)
* Eduard Lucena (x3mboy)
* Sumantro Mukherjee (sumantro / sumantrom)
* Andrew Ward (award3535)
* Daniel Lara (danniel/Danniel)
* Sirko Kemter (gnokii/gnokii)
* Ben Williams (Southern_Gentlem/jbwillia)
* Nick Bebout (nb/nb)
Nominees can now start with their own campaign, to attract people in
the Fedora community. I am also going to work with nominees and with
people from CommOps team to prepare Community Blog for publishing
answers from nominees on collected questions in the Election's
Questionnaire [4].
I wish all the nominees good luck and a lot of fun during the campaign period.
[1] https://fedoraproject.org/wiki/Council/Nominations
[2] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[3] https://fedoraproject.org/wiki/FAmSCo_nominations
[4] https://fedoraproject.org/wiki/Elections/Questionnaire
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
