(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
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches. - Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
On 2017-04-25 19:48, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches.
- Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
Koschei flag in pkgdb was implemented because people thought it's more natural to have all the package settings in one place (pkgdb). But koschei can keep track of it's packages by itself (it has a view for adding packages, it's just not visible when pkgdb integration is on). So if pkgdb goes away, it can return to old behavior of keeping the koschei flag in koschei itself.
Michael
On Tue, Apr 25, 2017 at 07:56:06PM +0200, Michael Šimáček wrote:
On 2017-04-25 19:48, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches.
- Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
Koschei flag in pkgdb was implemented because people thought it's more natural to have all the package settings in one place (pkgdb). But koschei can keep track of it's packages by itself (it has a view for adding packages, it's just not visible when pkgdb integration is on). So if pkgdb goes away, it can return to old behavior of keeping the koschei flag in koschei itself.
This works! No objection from me.
Note, we still have to solve the same problem for the-new-hotness settings, which doesn't have a UI such as koschei's.
On 04/25/2017 07:48 PM, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches.
- Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
One problem I can see with this approach is that only commiters of Pagure repo could change the file, while currently any member of packager FAS group can change Koschei flag for any package. But that could work if provenpackager policy explicitly allowed changing this file directly, without filing bugs and waiting for maintainer response.
Alternative solutions:
1. Revert to using Koschei's own package tracking mechanism. Koschei can be deployed in environments without PkgDB and therefore it has its own way for enabling package rebuilds.
2. Drop the flag and enable Koschei for all packages in all collections. In the past I would vote for this solution, but with current modularity efforts I'm not sure if we have enough builder capacity to do this.
On Tue, Apr 25, 2017 at 07:59:46PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 07:48 PM, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches.
- Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
One problem I can see with this approach is that only commiters of Pagure repo could change the file, while currently any member of packager FAS group can change Koschei flag for any package. But that could work if provenpackager policy explicitly allowed changing this file directly, without filing bugs and waiting for maintainer response.
True. Also, allowing pull-requests over dist-git with pagure would help smooth the process. Even if a drive-by packager couldn't set the flag on their own, they can *almost* set the flag on their own.
On 04/25/2017 08:16 PM, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 07:59:46PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 07:48 PM, Ralph Bean wrote:
On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote:
On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote:
- 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)
Do you mean separate yaml/toml file per package/collection, stored in dist-git branch, right next to spec file?
Yeah. We would introduce some yaml/toml file alongside the spec file in git, in branch.
We figured it could be done one of a few different ways:
- Consumers could only consider the 'master' branch. Whatever is in rawhide is true for the package across the other branches.
- Consumers could consider each branch independently. This could let koschei have new fine-grained on/off values for different releases. Not sure if that's something we actually want, though.
One problem I can see with this approach is that only commiters of Pagure repo could change the file, while currently any member of packager FAS group can change Koschei flag for any package. But that could work if provenpackager policy explicitly allowed changing this file directly, without filing bugs and waiting for maintainer response.
True. Also, allowing pull-requests over dist-git with pagure would help smooth the process. Even if a drive-by packager couldn't set the flag on their own, they can *almost* set the flag on their own.
You are very optimistic about maintainer responsivnes :)
My experience shows that there are lots of packages without active maintainers, which are kept alive only by provenpackagers. Koschei is especially useful for this kind of packages as it allows others (usually SIGs or maintainers of dependant packages) to monitor and keep such de-facto-orphaned packages buildable, which prevents their removal from distro.
On Tue, Apr 25, 2017 at 08:25:03PM +0200, Mikolaj Izdebski wrote:
My experience shows that there are lots of packages without active maintainers, which are kept alive only by provenpackagers. Koschei is especially useful for this kind of packages as it allows others (usually SIGs or maintainers of dependant packages) to monitor and keep such de-facto-orphaned packages buildable, which prevents their removal from distro.
We should get those SIGs or other packagers added as committers.
On Tue, 2017-04-25 at 16:23 +0200, Pierre-Yves Chibon wrote:
- 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"
I'd probably advocate for modifying pagure to allow "giving" repos. That sounds like a good feature anyway. Using the first committer would prevent the ability to change PoC's of a package.
On Tue, Apr 25, 2017 at 02:31:19PM -0400, Randy Barlow wrote:
On Tue, 2017-04-25 at 16:23 +0200, Pierre-Yves Chibon wrote:
- 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"
I'd probably advocate for modifying pagure to allow "giving" repos. That sounds like a good feature anyway. Using the first committer would prevent the ability to change PoC's of a package.
Agreed. mprahl will be scoping out "giving ownership" in pagure shortly.
On 04/25/2017 08:23 AM, Pierre-Yves Chibon wrote: ...snip...
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"
One possibility I'll toss out... change POC to packagename-owner@fedoraproject.org and have it go to the alias. This has the advantages of:
* Never need to update bugzilla after the package is made. * People perhaps stop thinking of packages as "theirs" a bit more.
But also disadvantages of people liking to see a name they can point to about the package or know who is cc'ed on the bug. ...snip...
- 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.
- !!! we have problems using pagure ticket queue here (api tokens, need commit or really admin access...)
- other options:
- bugzilla
no no, please not again. ;)
- custom made queue - fpaste!
Ha.
- 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
Note that I think we still want an admin to ack new package requests. ...snip...
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?
It could work.
it's likely going to need some kind of big flag day.
kevin
On Tue, Apr 25, 2017 at 01:36:50PM -0600, Kevin Fenzi wrote:
On 04/25/2017 08:23 AM, Pierre-Yves Chibon wrote: ...snip...
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"
One possibility I'll toss out... change POC to packagename-owner@fedoraproject.org and have it go to the alias. This has the advantages of:
- Never need to update bugzilla after the package is made.
- People perhaps stop thinking of packages as "theirs" a bit more.
But also disadvantages of people liking to see a name they can point to about the package or know who is cc'ed on the bug.
I like this idea a lot.
- 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.
- !!! we have problems using pagure ticket queue here (api tokens, need commit or really admin access...)
- other options:
- bugzilla
no no, please not again. ;)
- custom made queue - fpaste!Ha.
- 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 thisNote that I think we still want an admin to ack new package requests.
Agreed! Last time I talked with dgilmore about it, he pointed out that all kinds of oddball trademark issues only get caught at the cvsadmin level.
My vote is that the default assignee be the owner of the Pagure repo. Since the package email aliases will contain all users that have commit access on the Pagure repo, it'll be too noisy.
"KF" == Kevin Fenzi kevin@scrye.com writes:
[Using foo-owner@fp.o as the default owner for bugs] KF> But also disadvantages of people liking to see a name they can point KF> to about the package or know who is cc'ed on the bug.
For years I've wondered why we don't do that, honestly. But I think it might be weird that bugzilla separates the owner of a package from the owner of a bug, and some of the interactions might be non-obvious.
When I take a bug, will the other maintainers still be notified? Will bugzilla send mail to foo-owner as well as CC'ing the maintainers, so that everyone gets each message twice?
Will someone be able to log into bugzilla as foo-owner?
What happens to bugs marked as private? If they're private to foo-owner then how will the actual maintainers see them?
- J<
On 04/25/2017 01:54 PM, Jason L Tibbitts III wrote:
"KF" == Kevin Fenzi kevin@scrye.com writes:
[Using foo-owner@fp.o as the default owner for bugs] KF> But also disadvantages of people liking to see a name they can point KF> to about the package or know who is cc'ed on the bug.
For years I've wondered why we don't do that, honestly. But I think it might be weird that bugzilla separates the owner of a package from the owner of a bug, and some of the interactions might be non-obvious.
Yeah.
When I take a bug, will the other maintainers still be notified? Will bugzilla send mail to foo-owner as well as CC'ing the maintainers, so that everyone gets each message twice?
Yeah, if we made the default foo-owner and cc foo-owner, then when you took a bug, everyone would get a email because foo-owner is on there as cc, but you might get two (one for you and one via foo owner)
Will someone be able to log into bugzilla as foo-owner?
no.
What happens to bugs marked as private? If they're private to foo-owner then how will the actual maintainers see them?
Package maintainers would still need to be added to the right groups so they could see private bugs. (fedora_contrib_private I think it is).
kevin
On Tue, Apr 25, 2017 at 1:27 PM, Kevin Fenzi kevin@scrye.com wrote:
On 04/25/2017 01:54 PM, Jason L Tibbitts III wrote:
> "KF" == Kevin Fenzi kevin@scrye.com writes:
[Using foo-owner@fp.o as the default owner for bugs] KF> But also disadvantages of people liking to see a name they can point KF> to about the package or know who is cc'ed on the bug.
For years I've wondered why we don't do that, honestly. But I think it might be weird that bugzilla separates the owner of a package from the owner of a bug, and some of the interactions might be non-obvious.
Yeah.
When I take a bug, will the other maintainers still be notified? Will bugzilla send mail to foo-owner as well as CC'ing the maintainers, so that everyone gets each message twice?
Yeah, if we made the default foo-owner and cc foo-owner, then when you took a bug, everyone would get a email because foo-owner is on there as cc, but you might get two (one for you and one via foo owner)
What happens to bugs marked as private? If they're private to foo-owner then how will the actual maintainers see them?
Package maintainers would still need to be added to the right groups so they could see private bugs. (fedora_contrib_private I think it is).
IIRC, pkgdb CC'ing all listed people onto the bugs was to allow other package owners to see the private bugs but it's been quite a while and I don't know what has changed in bugzilla since then.
One way to address both the "what happens if I take ownership of a bug, which removes the packagename-owner@fp.o alias?" and the "I don't want to get bugzilla email to both the packagename-owner@fp.o and CC list email" concerns would be to use a /dev/null'd address for the initial owner field. ie: bug report is initially assigned to packagename-null@fp.o and all the maintainers are placed into the CC list.
-Toshio "Popping back into obscurity now" Kuratomi
Dne 25.4.2017 v 21:54 Jason L Tibbitts III napsal(a):
"KF" == Kevin Fenzi kevin@scrye.com writes:
[Using foo-owner@fp.o as the default owner for bugs] KF> But also disadvantages of people liking to see a name they can point KF> to about the package or know who is cc'ed on the bug.
For years I've wondered why we don't do that, honestly. But I think it might be weird that bugzilla separates the owner of a package from the owner of a bug, and some of the interactions might be non-obvious.
When I take a bug, will the other maintainers still be notified? Will bugzilla send mail to foo-owner as well as CC'ing the maintainers, so that everyone gets each message twice?
Will someone be able to log into bugzilla as foo-owner?
What happens to bugs marked as private? If they're private to foo-owner then how will the actual maintainers see them?
I had similar question about FAS groups ... here is my PR which may answer some of your questions:
https://github.com/fedora-infra/pkgdb2/pull/414
While you are adding several interesting questions on top of that :)
Vít
On Tue, Apr 25, 2017 at 01:36:50PM -0600, Kevin Fenzi wrote:
On 04/25/2017 08:23 AM, Pierre-Yves Chibon wrote: ...snip...
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"
One possibility I'll toss out... change POC to packagename-owner@fedoraproject.org and have it go to the alias. This has the advantages of:
- Never need to update bugzilla after the package is made.
- People perhaps stop thinking of packages as "theirs" a bit more.
But also disadvantages of people liking to see a name they can point to about the package or know who is cc'ed on the bug.
It also means we'll be creating one account per artifact (RPMs, container, module) in Fedora, so that's quickly going to go over the 20K+ accounts to create on bugzilla. No idea if this would be something the bugzilla folks would be grumpy about or not.
- 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.
- !!! we have problems using pagure ticket queue here (api tokens, need commit or really admin access...)
- other options:
- bugzilla
...
- 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 thisNote that I think we still want an admin to ack new package requests.
Yes, the idea here is to build this mechanism in pagure so we can use a project in pagure.io to host all the requests and have them reviewed by releng (and limb).
Pierre
On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
(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.
Will pkgdb go away? It looks Pagure would be a data store combining package repositories and pkgdb data together. From my point of view, pkgdb could still sit between packagers and Pagure rather than exposing lower level data directly as an interface of package data (whatever it comes from Pagure or PDC) to packagers and existing tools like pkgdb-cli. If anything of my understand about current pkgdb is not accurate, just scratch my thought :)
Regards, Chenxiong Qi
On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
(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.
Will pkgdb go away? It looks Pagure would be a data store combining package repositories and pkgdb data together. From my point of view, pkgdb could still sit between packagers and Pagure rather than exposing lower level data directly as an interface of package data (whatever it comes from Pagure or PDC) to packagers and existing tools like pkgdb-cli. If anything of my understand about current pkgdb is not accurate, just scratch my thought :)
The idea is indeed to retire pkgdb. However, I'm not sure I follow why you would prefer to keep it and what you don't like about dropping it. Could you expand your thoughts a little more?
Thanks, Pierre
On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
(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.
Will pkgdb go away? It looks Pagure would be a data store combining package repositories and pkgdb data together. From my point of view, pkgdb could still sit between packagers and Pagure rather than exposing lower level data directly as an interface of package data (whatever it comes from Pagure or PDC) to packagers and existing tools like pkgdb-cli. If anything of my understand about current pkgdb is not accurate, just scratch my thought :)
The idea is indeed to retire pkgdb. However, I'm not sure I follow why you would prefer to keep it and what you don't like about dropping it. Could you expand your thoughts a little more?
I thought "pkgdb" would become a main interface for anyone who wants to lookup package information without need to interact with Pagure or PDC directly, meanwhile we can keep using current terms about packages e.g. main contacts, that would be easier for anyone to get involved and start to contribute.
Will current pkgdb API[1] be still available, or need to query from Pagure or PDC individually?
Actually, I don't insist on not drop pkgdb. Whatever it'll be dropped or not and whatever the form it will be, as long as it could make things easier for packagers and potential contributors. :)
[1] https://admin.fedoraproject.org/pkgdb/api/
Thanks, Pierre
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a):
On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
(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.
Will pkgdb go away? It looks Pagure would be a data store combining package repositories and pkgdb data together. From my point of view, pkgdb could still sit between packagers and Pagure rather than exposing lower level data directly as an interface of package data (whatever it comes from Pagure or PDC) to packagers and existing tools like pkgdb-cli. If anything of my understand about current pkgdb is not accurate, just scratch my thought :)
The idea is indeed to retire pkgdb. However, I'm not sure I follow why you would prefer to keep it and what you don't like about dropping it. Could you expand your thoughts a little more?
I thought "pkgdb" would become a main interface for anyone who wants to lookup package information without need to interact with Pagure or PDC directly, meanwhile we can keep using current terms about packages e.g. main contacts, that would be easier for anyone to get involved and start to contribute.
I support this. For me is the pkgdb entry point. If I want to know something about package, I'm going to take a look into pkgdb. I'll be missing its simple UI.
Vít
Will current pkgdb API[1] be still available, or need to query from Pagure or PDC individually?
Actually, I don't insist on not drop pkgdb. Whatever it'll be dropped or not and whatever the form it will be, as long as it could make things easier for packagers and potential contributors. :)
[1] https://admin.fedoraproject.org/pkgdb/api/
Thanks, Pierre
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch vondruch@redhat.com wrote:
Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a):
On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon pingou@pingoured.fr
wrote:
On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote:
On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote:
(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.
Will pkgdb go away? It looks Pagure would be a data store combining
package
repositories and pkgdb data together. From my point of view, pkgdb
could
still sit between packagers and Pagure rather than exposing lower
level data
directly as an interface of package data (whatever it comes from
Pagure or
PDC) to packagers and existing tools like pkgdb-cli. If anything of my understand about current pkgdb is not accurate, just scratch my
thought :)
The idea is indeed to retire pkgdb. However, I'm not sure I follow why
you would
prefer to keep it and what you don't like about dropping it. Could you
expand
your thoughts a little more?
I thought "pkgdb" would become a main interface for anyone who wants to lookup package information without need to interact with Pagure or PDC directly, meanwhile we can keep using current terms about packages e.g. main contacts, that would be easier for anyone to get involved and start to contribute.
I support this. For me is the pkgdb entry point. If I want to know something about package, I'm going to take a look into pkgdb. I'll be missing its simple UI.
Vít
There is also the packages app that provides information on packages
https://apps.fedoraproject.org/packages/kernel
--ryanlerch
Will current pkgdb API[1] be still available, or need to query from Pagure or PDC individually?
Actually, I don't insist on not drop pkgdb. Whatever it'll be dropped or not and whatever the form it will be, as long as it could make things easier for packagers and potential contributors. :)
[1] https://admin.fedoraproject.org/pkgdb/api/
Thanks, Pierre
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to
infrastructure-leave@lists.fedoraproject.org
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
Dne 28.4.2017 v 12:27 Ryan Lerch napsal(a):
On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch <vondruch@redhat.com mailto:vondruch@redhat.com> wrote:
Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a): > On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon <pingou@pingoured.fr <mailto:pingou@pingoured.fr>> wrote: >> On Wed, Apr 26, 2017 at 11:29:28AM +0800, Chenxiong Qi wrote: >>> >>> On 04/25/2017 10:23 PM, Pierre-Yves Chibon wrote: >>>> (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. >>>> >>> Will pkgdb go away? It looks Pagure would be a data store combining package >>> repositories and pkgdb data together. From my point of view, pkgdb could >>> still sit between packagers and Pagure rather than exposing lower level data >>> directly as an interface of package data (whatever it comes from Pagure or >>> PDC) to packagers and existing tools like pkgdb-cli. If anything of my >>> understand about current pkgdb is not accurate, just scratch my thought :) >> The idea is indeed to retire pkgdb. However, I'm not sure I follow why you would >> prefer to keep it and what you don't like about dropping it. Could you expand >> your thoughts a little more? > I thought "pkgdb" would become a main interface for anyone who wants > to lookup package information without need to interact with Pagure or > PDC directly, meanwhile we can keep using current terms about packages > e.g. main contacts, that would be easier for anyone to get involved > and start to contribute. I support this. For me is the pkgdb entry point. If I want to know something about package, I'm going to take a look into pkgdb. I'll be missing its simple UI. VítThere is also the packages app that provides information on packages
I know ... but honestly, this one is unusable ... starting by the ton of slow javascript which often fails, ending with wrong information such as https://apps.fedoraproject.org/packages/rubygems/
Vít
--ryanlerch
> > Will current pkgdb API[1] be still available, or need to query from > Pagure or PDC individually? > > Actually, I don't insist on not drop pkgdb. Whatever it'll be dropped > or not and whatever the form it will be, as long as it could make > things easier for packagers and potential contributors. :) > > [1] https://admin.fedoraproject.org/pkgdb/api/ > >> Thanks, >> Pierre >> >> _______________________________________________ >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org <mailto:infrastructure@lists.fedoraproject.org> >> To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org <mailto:infrastructure-leave@lists.fedoraproject.org> >> > > _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org <mailto:infrastructure@lists.fedoraproject.org> To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org <mailto:infrastructure-leave@lists.fedoraproject.org>
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org
infrastructure@lists.fedoraproject.org
-
Chenxiong Qi -
Jason L Tibbitts III -
Kevin Fenzi -
Matt Prahl -
Matthew Miller -
Michael Šimáček -
Mikolaj Izdebski -
Pierre-Yves Chibon -
Ralph Bean -
Randy Barlow -
Ryan Lerch -
Toshio Kuratomi -
Vít Ondruch