(adding the releng list on CC, please keep the reply on the infra list)
Hi Everyone,
Following up on the thread about pagure on the top of dist-git started a
few days ago Ralph Bean, Matthew Prahl and I had a quick meeting just a few
minutes ago about the future of pkgdb.
Most of the content of the email is based on the notes we took during the
meeting, so I hope it is understandable for everyone. I have added some
context compared to the original notes, but feel free to ask questions if
there are any missing pieces or things that are unclear.
The idea is that with pagure becoming a front-end to dist-git, there is less
needs for pkgdb. So we tried to list all what pkgdb does and propose
solutions for each of these.
Let's start with the start: what does pkgdb do?
- Store point of contact for a package default assignee on bugzilla
- Store commit access for a package commit ACL
- Store admin access for a package approveacls ACL
- Store CC list for bug reports on the package watchbugzilla ACL
- Store CC list for changes made to the package watchcommits ACL
- Store new package requests
- Store new EPEL branch requests
- Allow creating new Fedora branch on demand
- Store which packages are orphaned
- Store which packages are retired
- Store collection/branches status
- Store anitya integration flag
- Store koshei integration flag
- Store critpath status
The main idea we have is to rely on pagure and PDC for as much as possible
and having a special project on pagure to use as a ticket/queuing system
for requests. This project could then be interacted with using a CLI tool.
Now going through each of the requirements listed above
- Store point of contact for a package (default assignee on bugzilla)
- we could use the first committer, alphabetically
- we could use the 'owner', but we need pagure to be able to "give" a
repo which it currently cannot.
- in order to "orphan" a package, we need this.
- we could list the default assignee in the yaml file in dist-git
- Not ideal since less "self-service"
- Store commit access for a package (commit ACL)
- Use the list of people with commit or admin access to the package
- Store admin access for a package (approveacls ACL)
- Handled in pagure directly by the people having admin access to the
package
- Need a way to prevent groups from having admin access (like we
prevented groups from having approveacls in pkgdb)
- Store CC list for changes made to the package (watchcommits ACL)
- use the pagure "watch" feature.
- Store CC list for bug reports on the package (watchbugzilla ACL)
- grow the ability in pagure to watch issues versus watch commits.
- in the meantime, just use watch commits for both.
- Factory 2.0 will handle this
- Store new package requests
- matt prahl is already cooking up a way to do this using a
https://pagure.io/repo-requests/issues/ queue and some scripts.
- https://pagure.io/fedrepo_req/pull-request/1
- !!! we have problems using pagure ticket queue here (api tokens, need
commit or really admin access...)
- other options:
- bugzilla
- custom made queue
- fpaste!
- patch pagure to do what we need.
-> Add the possibility to select a project in
https://pagure.io/settings/token/new and allow there the
issue_create, issue_update and issue_comment ACLs
-> Add the possibility to set the duration of the token (with
an upper limit: 365 days?) (per token with a default in the
config file?)
-> pingou will handle this
- Store new EPEL branch requests
- same as above.
- for the first seven days, don't show these in pkgdb-admin (or
equivalent) unless there are one or more comments from another package
maintainer.
- Allow creating new Fedora branch on demand
- except we want this to be for creating *any* new branch request "like
branch 2.0.x"
- make a little itty bitty approving service (IBAS) for auto-approving
these in a small way.
- it should re-use our replacement for pkgdb-admin under the hood so
we don't duplicate code.
- if some hard-coded set of checks pass then, auto-approve.
- checks like "is the EOL under 2 years?" "does the branch name
not include any non-ascii characters?" "run it through a swear
words dictionary"
- otherwise, leave in the queue for manual processing.
- Store which packages are orphaned
- these are just owned by the orphan user in pagure
- step 1, the orphan user is the only committer.
- step 2, when pagure grows the ability to "give" a project, then make
the orphan user the real owner.
- Factory 2.0 may handle this. Let pingou know
- Store which packages are retired
- in consultation with dgilmore, we don't think we need this anymore.
- the dead.package file is sufficient. we still need to propagate
blockage to koji (so listen on fedmsg for changes to that file instead
of listening for pkgdb message about status change).
- Also store this into PDC. it will be represented by the "active"
True/False flag on each branch.
- Store collection/branches status
- this is going to PDC as well (for modularity work, cf the video below)
- https://fedorapeople.org/groups/factory2/sprint-014/mprahl-pdc-sla-apis.mp4
- Store anitya integration flag
- store this in a yaml/toml file in the dist-git repo
- let the consumers
- do an http request to retrieve the file
- listen to fedmsg to catch changes to this file (and update a local
cache based on this)
- Store koshei integration flag
- store this in a yaml/toml file in the dist-git repo
- let the consumers
- do an http request to retrieve the file
- listen to fedmsg to catch changes to this file (and update a local
cache based on this)
- Store critpath status
- Store this in PDC and make it per branch
So with the proposed solution above, everything would be stored in:
- the git repo itself
- the pagure project of the package
- a pagure project for requests
- PDC
Now pkgdb interacts with a few known applications that will need to be adjusted
for this:
- the-new-hotness
- Cf the point about anitya above
- koshei
- Cf the point about koshei above
- zodbot
- will have to query the pagure API to find who has access
- bodhi
- will have to query the pagure API to find who has access (also, maybe
critpath flag?)
- FMN.rules (who is maintaining the package)
- will have to query the pagure API to find who has access
- pkgdb-admin
- mprahl is rewriting this to use a ticket queue, somewhere.
- pkgdb-cli (here we list all the different command and their description and
the possible solution)
acl Display ACLs for a given package
can be done, with no api keys
give Give package(s) according to the specified criteria
cannot be done yet. just return a "cannot be done yet" error.
list List package according to the specified criteria
can be done, with no api keys
orphan Orphan package(s) according to the specified criteria
cannot be done until "give" is done. this is just a "give" to the
orphan user.
unorphan Unorphan package(s) according to the specified criteria
cannot be done until "give" is done. this is just a "give" to another
user.
request Request ACLs on package(s) according to the specified criteria
to be bikedshed on devel about killing it. threebean says "just use
email!"
update Update ACLs on package(s) as desired
No longer needed since we don't do per branch ACLs anymore
branches List the active branches
Query PDC
pending List the pending ACLs requests
can easily be done by querying the pagure project for your tickets
with a status=Open (for package/branch requests)
for ACLs request, since we would not be tracking them down anymore,
it would have to be done by the packagers themselves and after a
while likely end up with a non-responsive maintainer procedure.
monitoring Get or Set the monitoring of a package
can easily get with no api key. (just http call to dist-git).
setting it no longer allowed.
koschei Get or Set the koschei monitoring of a package
can easily get with no api key. (just http call to dist-git).
setting it no longer allowed.
- bunch of links (long term)
I hope these notes are sufficiently clear, if not, we're happy to take any
and all questions.
I think we covered all bases and this is looking pretty straight forward.
What do you think?
Thanks for your inputs,
Pierre
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
