On Tue, Mar 31, 2020 at 1:23 PM Ian McInerney <Ian.S.McInerney@xxxxxxxx> wrote:
Leigh,Do you know how many
existing integrations with pagure there are?No. Our analysis will tell us that in due courseI am concerned by this approach to the decision-making. In many of your replies, you mention wanting to get feature-parity with the current tooling and systems, but here you suggest no analysis was done to see what it would take from a technical perspective for each of the options to meet the existing needs (e.g. what integrations would actually need to be moved from the current Pagure dist-git to a GitLab dist-git, how the workflows would have to be changed for each dist-git candidate, etc.).
I never said there was no analysis done, I answered a question asking me did I know how many integrations there are for Pagure and the answer off hand is I don't. I do know of many important integrations that I come into contact with during my day to day job in the team, that doesn't mean I know everysingle one of them. We analysed the critical path needs via the requirements and any reference to tooling integrations (e.g. fedora messaging was reference in multiple conversations) will be brought forward with us for deeper technical conversations.
Most of these integrations will probably be Fedora-specific, so it would still end up on CPE to implement/update them (such as a fedora-messaging translator, Bugzilla default assignee overrides, the dashboard metrics displayed on the current dist-git repo, etc.).I understand wanting to free up CPE time from fire fighting issues to doing actual development of the community infrastructure, but it seems the original goal of this project to reduce the CPE team workload hasn't actually been shown to be satisfied by this choice of dist-git yet. Specifically, there seems to have been no analysis of the time/effort required to switch to a GitLab-based dist-git instead of implementing any missing features into the Pagure-based dist-git.
The focus here is on the retooling cost Vs the feature gap cost and the continued maintenance of that stack. While this will be a short term cost trade off for us in CPE, it ultimately frees up a lot more of our time and resources.
Additionally, you mention that new features required for this transition will be submitted to GitLab so that they can prioritize them and add them to their "backlog."
Feature gaps will be lodged
The problem here is their current issue database seems to have >26,000 open issues in it, and >13,000 are in the "backlog" category. Is there any guarantee that GitLab will implement the features CPE submits to their "backlog" that are required to get feature-parity in the 12-18 month timeframe this switchover was going to happen in (if I recall those timings correctly)?
There are no guarantees and while we can make representations ultimately they control their own development resources, we control ours.
Will CPE dedicate any staff time to doing that feature development for GitLab if GitLab is unwilling to prioritize those issues?
That's a possibility for sure.
_______________________________________________Thanks,-Ian
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Leigh Griffin
Engineering Manager
Communications House
Cork Road, Waterford City
lgriffin@xxxxxxxxxx
M: +353877545162 IM: lgriffin
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
