On Thu, 16 Apr 2020 at 15:28, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
On Thu, Apr 16, 2020 at 03:16:29PM +0200, Clement Verna wrote:
> Should we use the same prioritization category that we have for tickets ?
> (low-gain, medium-gain, high-gain, low-trouble, medium-trouble,
> high-trouble). That might give use a nice way to focus on 1 or 2 things
> :-)
> Thoughts ?
That or plain 1, 2, 3, 4 works for me :)
So here is my gain vs trouble thingy
* Finish bringing bugzilla overrides to dist-git
Trouble : Medium
Gain: High
There seems to be quite a few steps to be done, plus the need for an FBR so medium troubles, but it would be obviously a high gain in terms of user experience.
* Rework the packager sync from FAS to bugzilla
Trouble : Medium
Gain: Medium
I would put this as Medium in both Trouble and Gain since it looks like what we currently have works but we have a better way of doing things now :-).
* Finish retiring in bugzilla packages that are retired in Fedora
Trouble : Low
Gain: Low
Does not seems like this is much work to be done but I don't know how much value we will get from it too.
* Mirror the ansible git repo on [4]pagure.io
Trouble: Low
Gain: Low
Since that would not allow PRs I think the gain is quite low, but it also seems like not much trouble to do it.
* Migrate [6]stg.pagure.io and [7]src.stg.fedoraproject.org to RHEL8.
Trouble: Low
Gain: Medium
I think that would be rather low trouble (destroying the current instances and rebuilding on RHEL8) but that would give us an opportunity to test that before the move and then maybe give us the confidence to reinstall dist-git on RHEL8 in the new data centre.
just my 2cents :-)
Some are easier to do than others, but there isn't any that is very high trouble
I think.
Pierre
> On Thu, 16 Apr 2020 at 15:08, Pierre-Yves Chibon <[1]pingou@xxxxxxxxxxxx>
> wrote:
>
> Good Morning Everyone,
>
> I have a few items in my backlog that I'd like to discuss priorities
> with you,
> so here is the unsorted list, let me know how you would sort it :)
>
> * Finish bringing bugzilla overrides to dist-git
> means:
> - Deploy pagure 5.9.x to src.fp.o
> - Migrate the data from the scm-requests repo to dist-git
> - Adjust the README of the scm-requests repo
> - Close off the scm-requests repo to pull-requests
> - Announce & profit/watch the world burn
> Blocked by the current freeze, unless a FBR is acceptable to upgrade
> pagure
> to 5.9.x (knowing that 5.9.x does not bring any DB changes).
>
> * Reworkd the packager sync from FAS to bugzilla
> Currently, there is a cron job that adds bugzilla privileges to people
> that
> are added to the packager group. That cron relies on a DB in FAS that
> tracks
> people being added or removed from this group. This isn't quite the
> 2020 way
> of doing things and this will not be portable to noggin (the next gen
> FAS).
> Python-bugzilla also recently (it's merged but not released) gained
> support
> for groups, so we can finally do something like: ask FAS for all the
> packagers
> and their email, list all the people in the corresponding group in
> bugzilla,
> do a diff and add/remove accordingly.
> fixes [2]https://pagure.io/fedora-infrastructure/issue/8628
>
> * Finish retiring in bugzilla packages that are retired in Fedora (ie:
> close
> these components to new bugs in bugzilla).
> This was blocked on a change in bugzilla which has been deployed in
> the last
> release. So we should be able to proceed and adjust our
> bugzilla<->dist-git
> sync script to do this.
> fixes [3]https://pagure.io/fedora-infrastructure/issue/7639
>
> * Mirror the ansible git repo on [4]pagure.io
> I'd like to set up a mirror on [5]pagure.io that would pull from
> batcave01. It
> would mean that PR can't really be merged in this mirror (unless we're
> fast
> enough to pull from the mirror and push to the main repo right after
> the merge,
> but there is a risk of a race-condition where the commit(s) just
> merged are
> overridden by a push to the main repo).
> It would expose a more up to date ansible repo to the public and we
> should be
> able to wget the patch of the PRs, git am to apply them and git push
> to the
> main repo.
>
> * Migrate [6]stg.pagure.io and [7]src.stg.fedoraproject.org to RHEL8.
> While we're in freeze, I figure this is a good time to do this. We
> could do
> [8]pagure.io post-freeze and wait to do src.fp.o when it gets
> reinstalled in the
> new data-center.
>
> So here you go, let me know what you think :)
>
> Thanks,
> Pierre
> _______________________________________________
> infrastructure mailing list -- [9]infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to
> [10]infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> [11]https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> [12]https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> [13]https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
>
> Links:
> 1. mailto:pingou@xxxxxxxxxxxx/
> 2. https://pagure.io/fedora-infrastructure/issue/8628
> 3. https://pagure.io/fedora-infrastructure/issue/7639
> 4. http://pagure.io/
> 5. http://pagure.io/
> 6. http://stg.pagure.io/
> 7. http://src.stg.fedoraproject.org/
> 8. http://pagure.io/
> 9. mailto:infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/
> 10. mailto:infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx/
> 11. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 12. https://fedoraproject.org/wiki/Mailing_list_guidelines
> 13. https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
