Re: The future of pkgdb

[Toshio Kuratomi]

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

[Vít Ondruch]

Dne 28.4.2017 v 12:27 Ryan Lerch napsal(a):
>
> On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch <vondr...@redhat.com
> <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
> <pin...@pingoured.fr <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

[Ryan Lerch]

On Fri., 28 Apr. 2017 at 6:05 pm, Vít Ondruch <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 <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

--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

[Vít Ondruch]

Dne 28.4.2017 v 07:34 Chenxiong Qi napsal(a):
> On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon <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

>
> 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

[Vít Ondruch]

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

[Chenxiong Qi]

On Wed, Apr 26, 2017 at 2:54 PM, Pierre-Yves Chibon <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.

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

[Pierre-Yves Chibon]

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

[Pierre-Yves Chibon]

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

[Chenxiong Qi]

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

[Kevin Fenzi]

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

[Matt Prahl]

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

[Jason L Tibbitts III]

> "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

[Ralph Bean]

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

[Kevin Fenzi]

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

[Ralph Bean]

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

[Matthew Miller]

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

[Mikolaj Izdebski]

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

[Ralph Bean]

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

[Ralph Bean]

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

[Ralph Bean]

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

[Mikolaj Izdebski]

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

[Pierre-Yves Chibon]

(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