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 this anymore.
- the dead.package file is sufficient.  we still need to propagate
  blockage to 

Re: 2017-03-21 PHX2 Outage thoughts

[Pierre-Yves Chibon]

On Tue, Apr 25, 2017 at 08:52:06AM -0400, Paul W. Frields wrote:
> On Sat, Apr 22, 2017 at 07:42:18AM -0600, Kevin Fenzi wrote:
> [...snip...]
> > So, IMHO, some action items we might consider:
> > 
> > * Create a batcave02.rdu that has all our repos, ansible keys and dns
> > keys. We can then use this to push things out if needed. It shouldn't be
> > too hard to pull from batcave01 or otherwise keep things in sync.
> 
> Hey, maybe there's a use for the git mirroring code that Clint was
> referring to earlier...

I was wondering the same yes :)
Also maybe to distribute pagure around the world :)


Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Pagure on dist-git, the state of things

[Paul W. Frields]

Just making sure the whole original message made it to rel-eng list.
Reply-to is set to infra@ so we can keep discussion in one place.

On Thu, Apr 20, 2017 at 12:08:35PM -0500, Dennis Gilmore wrote:
> Can you please report this to releng also?
> 
> Dennis
> 
> 
> El jue, 20-04-2017 a las 15:45 +0200, Pierre-Yves Chibon escribió:
> > Good Morning Everyone,
> > 
> > I figured it has been a while since I reported progress on making pagure a
> > front-end for dist-git.
> > 
> > So here is a small status update.
> > 
> > What works:
> > - Well currently pagure is working as a front-end for dist-git in stg:
> >   https://src.stg.fedoraproject.org/pagure/
> > - Hosting repos, browsing them, creating PR works all fine (w/ one , see
> >   below)
> > - Features we want to exclude have been turned off (no user management on 
> > the
> >   pagure side)
> > 
> > What does not work:
> > - Syncing the ACLs from pkgdb to gitolite takes ~3 minutes in prod, in stg, 
> > the
> >   updated script in stg (which sync the ACLs from pkgdb to gitolite and 
> > pagure)
> >   runs in ~30/35 minutes (if it doesn't crash, which my last run just did)
> >   This is a blocker since it means it takes 30 to 35 minutes for someone to 
> > get
> >   access to their git repo or (worse) their fork
> > - This pagure instance has the same issue as the main one, including a 
> > heisenbug
> >   we're trying to track but have had no luck reproducing so far :(
> > 
> > What needs to be done:
> > - Fix the sync script
> >   - Make it *way* faster than it is
> >   - Make it creates the project on pagure using the releng user rather than
> > relying on the first contributor it finds in the list of maintainers
> >   - Make fedmsg-genacls be triggered on pagure's fork fedmsg message so 
> > that we
> > re-generate the gitolite configuration file when someone forks a project
> > (and thus give them access to their fork)
> > - Once above is done: call for more testers
> > 
> > In the future:
> > - I think we will want to deprecate pkgdb entirely, so while the work above 
> > is
> >   important, ideally it won't be there for too long.
> > - With pkgdb out of the loop, we'll need to figure some things out:
> >   - Where/How to store the contact info for bugzilla
> > - Not sure relying on pagure's ACLs there is the way to go since we 
> > would
> >   loose a level of granularity in the ACLs that I know people like and 
> > ask
> >   for (having commit w/o being on the CC list in bugzilla or being on 
> > the CC
> >   list w/o being a packager)
> >   - How/when to require people be part of the packager group in FAS?
> > - Since one of the idea of pagure is to make it easier for "drive-by"
> >   contribution to spec files, requiring to be a packager should only be
> >   there for maintainers, but pagure doesn't have this level of
> >   information/requirement, so we would need to find something or some 
> > place
> >   to add this requirement or see if that requirement still stands
> > 
> > This is all I can think of for now, I'll update this thread if I come up 
> > with
> > more ideas/challenges.
> > 
> > 
> > Have a nice day,
> > Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: 2017-03-21 PHX2 Outage thoughts

[Paul W. Frields]

On Sat, Apr 22, 2017 at 07:42:18AM -0600, Kevin Fenzi wrote:
[...snip...]
> So, IMHO, some action items we might consider:
> 
> * Create a batcave02.rdu that has all our repos, ansible keys and dns
> keys. We can then use this to push things out if needed. It shouldn't be
> too hard to pull from batcave01 or otherwise keep things in sync.

Hey, maybe there's a use for the git mirroring code that Clint was
referring to earlier...

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Pagure on dist-git, the state of things

[Paul W. Frields]

Reply-to is set to infra@ so we can keep discussion in one place.

On Thu, Apr 20, 2017 at 12:08:35PM -0500, Dennis Gilmore wrote:
> Can you please report this to releng also?
> 
> Dennis
> 
> 
> El jue, 20-04-2017 a las 15:45 +0200, Pierre-Yves Chibon escribió:
> > Good Morning Everyone,
> > 
> > I figured it has been a while since I reported progress on making
> > pagure a
> > front-end for dist-git.
> > 
> > So here is a small status update.
> > 
> > What works:
> > - Well currently pagure is working as a front-end for dist-git in
> > stg:
> >   https://src.stg.fedoraproject.org/pagure/
> > - Hosting repos, browsing them, creating PR works all fine (w/ one ,
> > see
> >   below)
> > - Features we want to exclude have been turned off (no user
> > management on the
> >   pagure side)
> > 
> > What does not work:
> > - Syncing the ACLs from pkgdb to gitolite takes ~3 minutes in prod,
> > in stg, the
> >   updated script in stg (which sync the ACLs from pkgdb to gitolite
> > and pagure)
> >   runs in ~30/35 minutes (if it doesn't crash, which my last run just
> > did)
> >   This is a blocker since it means it takes 30 to 35 minutes for
> > someone to get
> >   access to their git repo or (worse) their fork
> > - This pagure instance has the same issue as the main one, including
> > a heisenbug
> >   we're trying to track but have had no luck reproducing so far :(
> > 
> > What needs to be done:
> > - Fix the sync script
> >   - Make it *way* faster than it is
> >   - Make it creates the project on pagure using the releng user
> > rather than
> > relying on the first contributor it finds in the list of
> > maintainers
> >   - Make fedmsg-genacls be triggered on pagure's fork fedmsg message
> > so that we
> > re-generate the gitolite configuration file when someone forks a
> > project
> > (and thus give them access to their fork)
> > - Once above is done: call for more testers
> > 
> > In the future:
> > - I think we will want to deprecate pkgdb entirely, so while the work
> > above is
> >   important, ideally it won't be there for too long.
> > - With pkgdb out of the loop, we'll need to figure some things out:
> >   - Where/How to store the contact info for bugzilla
> > - Not sure relying on pagure's ACLs there is the way to go since
> > we would
> >   loose a level of granularity in the ACLs that I know people
> > like and ask
> >   for (having commit w/o being on the CC list in bugzilla or
> > being on the CC
> >   list w/o being a packager)
> >   - How/when to require people be part of the packager group in FAS?
> > - Since one of the idea of pagure is to make it easier for
> > "drive-by"
> >   contribution to spec files, requiring to be a packager should
> > only be
> >   there for maintainers, but pagure doesn't have this level of
> >   information/requirement, so we would need to find something or
> > some place
> >   to add this requirement or see if that requirement still stands
> > 
> > This is all I can think of for now, I'll update this thread if I come
> > up with
> > more ideas/challenges.
> > 
> > 
> > Have a nice day,
> > Pierre
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to infrastructure-leave@lists.fedoraproj
> > ect.org



> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org


-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

[release] pkgdb2: 2.6.1 and 2.6.2

[Pierre-Yves Chibon]

Good Morning Everyone,

Yesterday I prepared and tagged a 2.6.1 release but I messed up with the git
history, so I ended up creating a new release 2.6.2 today.

Here are their corresponding changelogs:
* Tue Apr 25 2017 Pierre-Yves Chibon  - 2.6.2-1
- Update to 2.6.2
- Fix git history in 2.6.2

* Mon Apr 24 2017 Pierre-Yves Chibon  - 2.6.1-1
- Update to 2.6.1
- Make the mapping in pkgdb-sync-bugzilla script easier to adjust (by placing it
  in the config file)

So 2.6.2 is now running in stg and prod and we should be free of any hotfix :)


Happy packaging,
Pierre


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org