+1 from me 🙂

Hey all. I recently opened a similar request with the DEI Team (fedora-diversity#241), so this would be a nice opportunity to do both. I could lead on this task, although it might take me until November to get through it (I am still getting up to speed on a lot of things!). I am also interested in having project boards shared by multiple teams, which is my selfish motivation to lead on this. :grinning:

I'd be interested in having the discussion in the next team meeting, seeing what others think, and whether we could pick a deadline for this migration.

+1 from me. @jwf can do it, as he says, or we can pick it up while we migrate docs repos (e.g. release notes, install guide, ...) after F37 release.

GitLab is a very unreliable third-party service: https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/

Relying on it is a completely NO-GO for me. If Fedora want to shut Pagure down, they should provide a self-hosted alternative (GitLab CE on Fedora infra, for example).

We can discuss this more in our meeting tomorrow, but Pagure is not a great solution for ticket-based discussion either because it is no longer actively maintained, there are multiple bugs which make it difficult to use (e.g. cannot change a default email address and unable to tag other users), and there are not project management features to organize issues across multiple repositories (e.g. between Mindshare, CommOps, Marketing, DEI, etc.).

On the other hand, I believe we are on some kind of a paid support plan with GitLab, GitLab receives regular updates and maintenance, and there are more advanced project management features that reflect the growing needs of Fedora community management tasks. Additionally, as @pbokoc noted, the Fedora Docs team is moving their workflow into GitLab, and the only reason we use a git repo is for our docs site.

Whatever Mindshare decides for our issue/ticket discussion doesn't mean we are locked into a decision for the rest of eternity, but it means we are committed to giving it a try, seeing what works, and then we can adapt with what we learn through the experience.

I am -1 on the idea as well for the same reasons as @xvitaly mentioned above:

GitLab is a very unreliable third-party service: https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/

Relying on it is a completely NO-GO for me. If Fedora wants to shut Pagure down, . .

WE should at least outline how we expect to address that as it is a policy that was announced and enforced after the original decision to migrate efforts away from pagure.

Hi. Our GitLab space is an ultimate tier acct and is part of the GitLab for Open Source program. I asked in their official forum if we would be impacted by this new data retention policy but on account of our space being marked ultimate, I would suspect not. See

https://forum.gitlab.com/t/gitlab-for-open-source-data-retention-policy-changes/76699

Just confirming that the data retention policy does not impact our account, see thi confirmation from Bryan B. @ GutHub:
https://forum.gitlab.com/t/gitlab-for-open-source-data-retention-policy-changes/76699

Thanks @duffy for clarifying the conditions. I'm personally sticky with pagure, but willing to commit to what the working group determines the right way to go. I know that there are obvious reasons to move to a company-assisted model. Also, I am not of the opinion that Gitlab is in any way a poor choice of direction.

I am very much aligned with @stefw on the principles of running SAAS using open source software. This is a much longer conversation, but http://stef.thewalter.net/open-source-services.html sort of sums up nicely what I think is beneficial here. Gitlab is an example in one of Stef's devconf.cz talks of what he is talking about in the blog post.

So Gitlab is not a bad direction. I am willing to concede to the benefits of following this expected trend to migrate from self-hosted to a nearly open source SAAS. These kind of alliances are welcome and important to the success of the fedora project.

I personally would prefer to stay with Pagure, it seems to work well for us, but I won't block moving to GitLab, since that seems to be the popular thing.

+0

Discussed in 2022-10-25 meeting.

In the meeting, we noted that while there is skepticism about GitLab, it could be a better tool for our Committee. One factor that is important to us is to avoid proprietary/closed features of GitLab that are unavailable in the Community Edition. Should we migrate, we will avoid using proprietary features as a condition of migrating. @duffy also noted that there are useful features that the Design Team uses and may also be useful to Mindshare, like epics, burndown charts, and Gantt charts. They may or may not be Open Source. We agreed that after migrating, we can open a new ticket to discuss before adopting a feature into our workflow that is not in the GitLab Community Edition.

We agreed to build quorum in this ticket to make a decision at the Thursday, November 3rd meeting.

• 1 from me!

+1

+1 move to gitlab because we have a community consensus, but I will put this on the table. I would enthusiastically return to pagure.io if that option comes up for the betterment of the team.

Discussed in 2022-11-03 meeting.

We have consensus to begin migrating to GitLab. Thanks all for the participation in the meeting today. I opened fedora-infrastructure#10974 to request the GitLab sub-group namespace.

Assigning this ticket to me in the meantime. I am removing this from the meeting agenda but keeping the ticket open as we begin to move the docs repo over. I'm also going to explore what options there are for moving issue history, but I suspect this will not be possible on Day 1.

Discussed in 2022-12-07 meeting.

We have modified our last meeting of the year on 20 December to be a working session instead of meeting. There, we will make the migration from Pagure to GitLab. Together, we can take the following steps:

1. Set up the GitLab repo
2. Manually copy over any open Pagure issues with ongoing work; close Pagure issues that are resolved or no further action needed from Mindshare.
3. Configure labels, metadata, and possibly a project board for our issues.
4. Set Pagure into read-only, or have a clear set of steps until we are ready to make Pagure read-only.

In the future someday, we will revisit the option of migrating our historical issues here on Pagure into GitLab. But in the meeting, we decided not to block on this and to go ahead and get comfy now. In this way, we can also be a model of best practices to other Fedora teams as well.

Discussed in 2023-01-31 meeting.

I shared four possible ways that fellow Mindshare Committee members can help with our ongoing move to GitLab:

1. Be a GitLab wrangler and work with members of the Mindshare Committee to get onboarded to GitLab. This might mean DMs or a quick audio/video call walkthrough to get set up and confirm access to the group.
2. We need to either conclude or manually move more historical tickets from Pagure without a clear resolution. We need to achieve zero open issues on Pagure before we archive the Pagure repo and set it to read-only. For tickets that do not have a clear resolution in the short-term, we need to manually copy the ticket over to GitLab.
3. Our issue templates are not copied over yet to GitLab. We need to add issue templates to GitLab for anyone making a request to the Fedora Mindshare Committee.
4. We need to move our docs into GitLab. This may be a separate repo or it may be the "Home" repository. But we need to move the docs content to GitLab, update the Fedora Docs publishing with Antora, and update said documentation to mention our new presence on GitLab.

In the meeting, we assigned some actions to be completed by our next Tuesday, 14 February meeting (which unfortunately I will be out-of-office for):

• @bt0dotninja and I agreed to tag-team on #2 to move five more issues from Pagure to GitLab by our next meeting.
• @bt0dotninja also volunteered to help on #3 to migrate some issue templates from Pagure to GitLab.
• @pbokoc volunteered on #4 to move the Mindshare docs to a new repository created under gitlab.com/fedora/mindshare/.

This keeps our migration work going steady in the new year. Turns out, this was a lot harder than it seems! But we will get there. I also think identifying new meeting times will help us with this too.

Templates are merge request on gitlab :smiley:

@bt0dotninja Thanks for your ongoing work here. :pray:

I spent additional time on this one today:

1. Created a new GitLab repository for Mindshare documentation.
2. Refreshed the docs index page and switched to using attributes for information across the index page.
3. Opened a Merge Request with the Fedora Docs team to start building the Mindshare docs from GitLab instead of Pagure.
4. Update this Pagure repository README with information about the migration, an FAQ for people who either want to open an issue or already have opened one, and updated information about how to contact the Mindshare Committee.