Re: The future of pkgdb
On Tue, Apr 25, 2017 at 1:27 PM, Kevin Fenzi wrote: > On 04/25/2017 01:54 PM, Jason L Tibbitts III wrote: >>> "KF" == Kevin Fenzi 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 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
Dne 28.4.2017 v 12:27 Ryan Lerch napsal(a): > > On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch <mailto:vondr...@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 > mailto:pin...@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 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-le...@lists.fedoraproject.org > <mailto:infrastructure-le...@lists.fedoraproject.org> > >> > > > > > ___ > infrastructure mailing list -- > infrastructure@lists.fedoraproject.org > <mailto:infrastructure@lists.fedoraproject.org> > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > <mailto:infrastructure-le...@lists.fedoraproject.org> > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch wrote: > > > Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a): > > On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon > 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-le...@lists.fedoraproject.org > >> > > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a): > On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon > 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-le...@lists.fedoraproject.org >> > > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
Dne 25.4.2017 v 21:54 Jason L Tibbitts III napsal(a): >> "KF" == Kevin Fenzi 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 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon 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-le...@lists.fedoraproject.org > -- -- Regards, Chenxiong Qi ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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-ow...@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. > > - 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 ... > > - 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. 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 signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
On 04/25/2017 01:54 PM, Jason L Tibbitts III wrote: >> "KF" == Kevin Fenzi 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 signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
> "KF" == Kevin Fenzi 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< ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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-ow...@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. > > - 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 > > 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. 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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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-ow...@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. > - 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 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 signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. -- Matthew Miller Fedora Project Leader ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: The future of pkgdb
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? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
The future of pkgdb
(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, w