Task List
Good morning, I joined into Fedora Project since little bit of time. Where I can found a Task List where the project identify what needs and goals? According to Fedora Project Infra info It likes does not exist. Is It right? https://fedoraproject.org/wiki/Infrastructure#Contribute_to_Fedora_Infrastructure If It does not exist, will be a nice choice to improve our productivity as team, I think so. I would like to be start contribute to this project someway. Greetings ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: Issue with Fedora GeoIP service
On Sat, Dec 07, 2019 at 09:39:46AM -0500, Kevin Sandy wrote: > I have an updated copy working with geoip2, with the exception of area code > data (which isn’t included in the new database). But if I’m understanding > it’s purpose correctly, telephone area code isn’t needed. I need to do some > testing with IPs around the world to ensure that the data is sane outside the > US; once I’ve had a chance to do that I’ll submit a PR on GitHub. Wow. Awesome work! Thanks for diving in and getting this going. In another email thread someone, Adrian said he had some code to do this, but if you already have it working, perhaps he could review your code/setup and we could then push it into ansible? Thanks again for working on this! kevin -- > > -- kevin > > > On Dec 6, 2019, at 7:13 PM, Kevin Sandy wrote: > > > > I’m interested in looking at this. Is this the script? > > > > https://github.com/fedora-infra/geoip-city-wsgi/blob/master/geoip-city.wsgi > > > > Assuming that’s the one, it looks like we need to replace GeoIP with geoip2 > > and wrap the geoip2 data in a structure to match what is currently being > > returned. Let me know if I’m missing anything. > > > > -- kevin > > > >> On Dec 6, 2019, at 6:39 PM, Kevin Fenzi wrote: > >> > >> On Fri, Dec 06, 2019 at 04:49:15PM +, Tom Hughes wrote: > >>> On 06/12/2019 16:41, Martin Kolman wrote: > On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote: > > > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate, > > and that DB has the correct info. > > IIRC the infra team mentioned some issues with the new geoip database > being incompatible with how the service is currently implemented, > resulting in being stuck with an outdated database until this is > resolved. > >>> > >>> Sounds like it maybe doesn't have support for GeoLite2 and is using the > >>> old MaxMind GeoLite Legacy databases which haven't been updated since > >>> the start of this year. > >> > >> Yes, that is exactly the case. > >> > >> We recently looked at this to see if we could retire the service, but it > >> looks like it's still needed, so we need to figure out how to get cycles > >> to update it. > >> > >> If someone wants to work on this, let us know! > >> > >> kevin > >> ___ > >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org > >> To unsubscribe send an email to > >> infrastructure-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > > ___ > > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: How do i join fi-apprentice group?
On Sun, Dec 08, 2019 at 09:31:07AM -, Mark Denial wrote: > How to get an invite for joining the Fi-apprentice group? > My login name is- markdenial. > please send me an invite. We usually ask folks to send an introduction to this list, then ask on irc in #fedora-admin. If you can't get on irc for some reason, drop me an email and I can look... Welcome to the fun! kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
On Mon, Dec 09, 2019 at 06:34:15PM +0100, Pierre-Yves Chibon wrote: > On Mon, Dec 09, 2019 at 05:35:58PM +0100, Pierre-Yves Chibon wrote: > > On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote: > > > It would be nice if we would implement "approval" system while doing > > > this. Like if you set somebody as override, that person must click > > > "accept". Same way to change it, the old person must click "accept". > > > > I'm trying to think how this would work for groups and pseudo users. > > For the later this should work fine, except that potentially several people > > would receive the confirmation link. > > For the former, it's bit more tricky but it would be one way where we could > > ensure that the group is correctly set-up in FAS (with an mailing list > > address). > > > > It's a bit more work than anticipated though, but should be doable. > > Thinking some more about this and while I think we should aim for this > process, > considering the gain we would have from just moving away from > fedora-scm-requests (nicer UX, easier sync to bugzilla of the information, no > need to clone that large git repo). Would we be ok with a phased release where > at first one the main admin (and infra/releng) would be able to the set the > overrides? I think that would be fine and a definite improvement. > > From there we could see if we need this approval system and if we do, who can > trigger changing it. Sounds good to me. kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
On Mon, Dec 09, 2019 at 05:35:58PM +0100, Pierre-Yves Chibon wrote: > On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote: > > It would be nice if we would implement "approval" system while doing > > this. Like if you set somebody as override, that person must click > > "accept". Same way to change it, the old person must click "accept". > > I'm trying to think how this would work for groups and pseudo users. > For the later this should work fine, except that potentially several people > would receive the confirmation link. > For the former, it's bit more tricky but it would be one way where we could > ensure that the group is correctly set-up in FAS (with an mailing list > address). > > It's a bit more work than anticipated though, but should be doable. Thinking some more about this and while I think we should aim for this process, considering the gain we would have from just moving away from fedora-scm-requests (nicer UX, easier sync to bugzilla of the information, no need to clone that large git repo). Would we be ok with a phased release where at first one the main admin (and infra/releng) would be able to the set the overrides? From there we could see if we need this approval system and if we do, who can trigger changing it. Does that sound reasonable or would you rather we land the entire change at one? (knowing that we're close to completion with Phase #1, we just need to tweak it based on the feedback we're collecting in this thread while phase #2 was not scoped at all). Thanks for your inputs, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
On Mon, Dec 09, 2019 at 05:18:32PM +0100, Igor Gnatenko wrote: > It would be nice if we would implement "approval" system while doing > this. Like if you set somebody as override, that person must click > "accept". Same way to change it, the old person must click "accept". I'm trying to think how this would work for groups and pseudo users. For the later this should work fine, except that potentially several people would receive the confirmation link. For the former, it's bit more tricky but it would be one way where we could ensure that the group is correctly set-up in FAS (with an mailing list address). It's a bit more work than anticipated though, but should be doable. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
It would be nice if we would implement "approval" system while doing this. Like if you set somebody as override, that person must click "accept". Same way to change it, the old person must click "accept". Of course, pagure admin should be able to override this, based on FESCo tickets and such. On Mon, Dec 9, 2019 at 3:14 PM Pierre-Yves Chibon wrote: > > On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote: > > On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp wrote: > > > > > > Hi, > > > > > > We are currently working on getting rid of the git repo at > > > fedora-scm-requests [1] which is nowadays only used to store the > > > overrides of the default assignee in bugzilla (for example to allow > > > different default assignee for Fedora and EPEL). > > > > > > I am working on porting this mechanism to dist-git itself (much like we > > > did for the anitya integration a few weeks ago). > > > > > > We are thinking on providing a simple text field to submit FAS username > > > or email to override the default assignee, the big question is then, who > > > should be allowed to update this field ? > > > > > > Should the main admin be able to set someone else as assignee ? > > > > > > If there is already an override assignee, who should be allowed to change > > > that ? > > > > > > If there's no override assignee set, can everyone become it or is that up > > > to the main admin of the component to decide and set ? > > > > > > > I think in this case, it should be the main admin who can change this. > > The main admin (and infra/releng) only, or all the admins of the project? > > > Pierre > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
> We are thinking on providing a simple text field to submit FAS username or > email to override the default assignee, the big question is then, who should > be allowed to update this field ? I like it's the same policy with editing the Setting page of https://src.fedoraproject.org/rpms/foo . > Should the main admin be able to set someone else as assignee ? Yes. > If there is already an override assignee, who should be allowed to change > that ? Main admin (maintainer) + other admin people can be allowed. > If there's no override assignee set, can everyone become it or is that up to > the main admin of the component to decide and set ? First, someone can take a main admin (maintainer) for https://src.fedoraproject.org/rpms/foo . Then the person can set. -- Jun | He - His - Him ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote: > On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp wrote: > > > > Hi, > > > > We are currently working on getting rid of the git repo at > > fedora-scm-requests [1] which is nowadays only used to store the overrides > > of the default assignee in bugzilla (for example to allow different default > > assignee for Fedora and EPEL). > > > > I am working on porting this mechanism to dist-git itself (much like we did > > for the anitya integration a few weeks ago). > > > > We are thinking on providing a simple text field to submit FAS username or > > email to override the default assignee, the big question is then, who > > should be allowed to update this field ? > > > > Should the main admin be able to set someone else as assignee ? > > > > If there is already an override assignee, who should be allowed to change > > that ? > > > > If there's no override assignee set, can everyone become it or is that up > > to the main admin of the component to decide and set ? > > > > I think in this case, it should be the main admin who can change this. The main admin (and infra/releng) only, or all the admins of the project? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: moving bugzilla overrides to dist-git
On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp wrote: > > Hi, > > We are currently working on getting rid of the git repo at > fedora-scm-requests [1] which is nowadays only used to store the overrides of > the default assignee in bugzilla (for example to allow different default > assignee for Fedora and EPEL). > > I am working on porting this mechanism to dist-git itself (much like we did > for the anitya integration a few weeks ago). > > We are thinking on providing a simple text field to submit FAS username or > email to override the default assignee, the big question is then, who should > be allowed to update this field ? > > Should the main admin be able to set someone else as assignee ? > > If there is already an override assignee, who should be allowed to change > that ? > > If there's no override assignee set, can everyone become it or is that up to > the main admin of the component to decide and set ? > I think in this case, it should be the main admin who can change this. If we had per-branch ACLs, then I would also say that the admins of the EPEL branches could change EPEL assignments too... -- 真実はいつも一つ!/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
moving bugzilla overrides to dist-git
Hi, We are currently working on getting rid of the git repo at fedora-scm-requests [1] which is nowadays only used to store the overrides of the default assignee in bugzilla (for example to allow different default assignee for Fedora and EPEL). I am working on porting this mechanism to dist-git itself (much like we did for the anitya integration a few weeks ago). We are thinking on providing a simple text field to submit FAS username or email to override the default assignee, the big question is then, who should be allowed to update this field ? Should the main admin be able to set someone else as assignee ? If there is already an override assignee, who should be allowed to change that ? If there's no override assignee set, can everyone become it or is that up to the main admin of the component to decide and set ? I'd appreciate your input Thanks, Karsten [1] https://pagure.io/releng/fedora-scm-requests/ ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org