Fedora-Council/tickets ticket #420: What is the Council plan for migrating to GitLab?

@jflory7 filed Fedora-Council/tickets ticket #420. Discuss here and record votes and decisions in the ticket.

Ticket text:

1 Like

I’m ambivalent about moving to GitLab by and large, but I’m strongly in favor of merging these two repos regardless of whether we move or not.

We want to preserve history somehow. Whether it’s a docs file with a list of issues, or adding links to the Internet Archive, or a process to migrate issues from Pagure to GitLab is less important to me. I don’t think that needs to be a pre-requesite for moving, if we decide to, but we can’t let it drop, either.

I’ll also note that we should not preserve pull requests. We should declare bankruptcy on outstanding pull requests that we can’t quickly resolve. Historical pull requests are not important to preserve.

We were talking about this some in your absence yesterday. If we move everything into one repo, I’d like to make a distinction in some way between tickets which represent Council-level decisions and those which represent stuff the Council or someone on the Council should undertake. That was my idea in having separate repos in the very first place. But we could do that with some other organizational tool (tags or some other filter).

That makes sense, but it doesn’t seem to be how we’ve operated in practice. In part, maybe, because the “council-docs” repo name doesn’t lend itself to the idea of “everything that’s not a voting matter”. We do have the “ticket vote” label on the current tickets instance, which I’ve tried to set to indicate that we need to vote on something. I think in practice the annoyance of having two separate repos has outweighed the organizational benefits.

One interesting approach would be to have all votes be in a repo that is very explicitly only votes with ACLs such that only Council members could create issues. So if someone has a proposal, then can open an issue in the everything-but-votes repo and then when it’s in a state for voting, a Council member could create (or move) the issue to the only-for-voting repo.

I have two big concerns with switching to the gitlab.com platform:

  1. I appreciate Gitlab’s generous offer of free resources, but that offer could change at any time. I’d like to make sure we have an “out”.
  2. There are some advantages in being about to participate using a non-Fedora, account, but a lot of downsides: people can’t rely on @mattdm as they can here (that happens to work on Gitlab for me, but that won’t be the case for a lot of people), and we can’t easily tie in Fedora Message Bus notifications by user account, and it complicates corresponding community metrics.

and one about switching anywhere in general, which is: I don’t want to lose more history. How can we migrate existing tickets?

I’m willing to try it. :classic_smiley:

FWIW, I was expecting we might grow other work repos. But that didn’t happen.

I kind of like that. But maybe something with metadata in the same repo could reproduce that well enough that a separate one wouldn’t be needed.

I was thinking we could use a project board as our “organizational view” and meaningful program management. Sometimes I feel like we are craving for a zero-issue ticket queue, and I’m not sure that is a goal either. An up-to-date, informed view that triages the important topics and discussions seems more appealing to me.

Are there specific featured you are concerned about, or are there specific assurances you would like to have in advance?

FWIW, if a person you are trying to tag is also a member of the same GitLab organization and you are working from a repo in that organization, users who are also members are prioritized in search. You have a greater chance of discovering the person you are looking for if both people are members of the same organization.

Also, this is still a problem in Pagure because some people can never be tagged in Pagure issues now that our new Account System allows for more characters in usernames that Pagure does not expect:


I think with the SAML sign-on option with a FAS account, there are mitigations we could take so that these data mappings are preserved. But it would take extra engineering effort within our existing tools.

Fortunately, FAS does have a GitLab field where people can specify their GitLab account name.

I lodged an initiative request with CPE to request a migration tool.


Given that most of the tickets across these repos are already filed by either me, @mattdm, or @bcotton, I’m not sure it is very convincing to make it harder for people to open tickets and flag issues. This approach feels like overengineering a process to me, and could risk confusing others unfamiliar to the process.