In the last Board meeting we discussed the future of git.centos.org, and whether it would make sense to encourage SIGs to move over to GitLab, as we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream). GitLab also provides features (notably, CI integration via Pipelines and an improved code review flow) that some SIGs would like to use and would benefit from.
To this end, I have filed https://git.centos.org/centos/board/issue/129 to summarize the discussion and decide the next steps. We'd welcome any comments and feedback on this. To be clear, there are no plans to sunset git.centos.org at this time.
Cheers Davide
On 13/12/2024 12:47, Davide Cavalca wrote:
In the last Board meeting we discussed the future of git.centos.org, and whether it would make sense to encourage SIGs to move over to GitLab, as we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream). GitLab also provides features (notably, CI integration via Pipelines and an improved code review flow) that some SIGs would like to use and would benefit from.
To this end, I have filed https://git.centos.org/centos/board/issue/129 to summarize the discussion and decide the next steps. We'd welcome any comments and feedback on this. To be clear, there are no plans to sunset git.centos.org at this time.
Cheers Davide
Hi Davide,
Thanks a lot for the info.
Some thoughts about this :
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/)
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open-source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
On Fri, Dec 13, 2024 at 9:53 AM Davide Cavalca dcavalca@centosproject.org wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open-source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
I would rather we didn't use Git LFS, because it's a pain (and sometimes impossible) to mirror.
Hi,
I think it makes sense to move everything to Gitlab. As long as we find a viable lookaside solution, I don't see any blockers for the Cloud SiG.
Joel
On Fri, Dec 13, 2024 at 4:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Dec 13, 2024 at 9:53 AM Davide Cavalca dcavalca@centosproject.org wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo -
https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/ )
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open-source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
I would rather we didn't use Git LFS, because it's a pain (and sometimes impossible) to mirror.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 13/12/2024 15:53, Davide Cavalca wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/ clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https:// about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo- a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open- source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
Hi,
I'd like to know the status about discussion for potential move to Gitlab. I tried to follow the recent board meetings but there was no clear statement/progress on this and I'd like to know in advance.
As announced, Fedora and CentOS public infra will have to migrate to a new DC/hosting facility this year (dates to be announced but probably - for centos - in Q3). That means that I'd like to know the status/future for git.centos.org and so if we have to migrate it to new DC, or not.
Migrating it wouldn't be a big issue though, but just something to consider.
Kind Regards,
On Tue, 2025-04-08 at 14:27 +0200, Fabian Arrotin wrote:
On 13/12/2024 15:53, Davide Cavalca wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/ clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https:// about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo- a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open- source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
Hi,
I'd like to know the status about discussion for potential move to Gitlab. I tried to follow the recent board meetings but there was no clear statement/progress on this and I'd like to know in advance.
As announced, Fedora and CentOS public infra will have to migrate to a new DC/hosting facility this year (dates to be announced but probably
for centos - in Q3). That means that I'd like to know the status/future for git.centos.org and so if we have to migrate it to new DC, or not.
Migrating it wouldn't be a big issue though, but just something to consider.
Davide and I met with Nick from GitLab yesterday to talk about this. In terms of resource usage, it looks like we're nowhere near any limits, and he was happy to work with us if we do reach that point. I know there were a few other concerns (Davide brought up nested virt in runners), but I think they're all solvable.
I think it would be good for us to put together a migration list of repositories, how big they are, and what kind of CI resources they use. What would be the best place for that? HackMD? GitLab issue? Google doc? Some of them will create work for you, but not all of them, I think.
-- Shaun
On 09/04/2025 16:33, Shaun McCance via devel wrote:
On Tue, 2025-04-08 at 14:27 +0200, Fabian Arrotin wrote:
On 13/12/2024 15:53, Davide Cavalca wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/ clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https:// about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo- a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open- source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
Hi,
I'd like to know the status about discussion for potential move to Gitlab. I tried to follow the recent board meetings but there was no clear statement/progress on this and I'd like to know in advance.
As announced, Fedora and CentOS public infra will have to migrate to a new DC/hosting facility this year (dates to be announced but probably
for centos - in Q3). That means that I'd like to know the status/future for git.centos.org and so if we have to migrate it to new DC, or not.
Migrating it wouldn't be a big issue though, but just something to consider.
Davide and I met with Nick from GitLab yesterday to talk about this. In terms of resource usage, it looks like we're nowhere near any limits, and he was happy to work with us if we do reach that point. I know there were a few other concerns (Davide brought up nested virt in runners), but I think they're all solvable.
I think it would be good for us to put together a migration list of repositories, how big they are, and what kind of CI resources they use. What would be the best place for that? HackMD? GitLab issue? Google doc? Some of them will create work for you, but not all of them, I think.
-- Shaun
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https://gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https://gitlab.com/centos/)
It may also be worth speaking to Xen Project and its down stream users, as software which uses Xen hypervisor has CentOS 7 for its dom. An example of such software is CSG XenServer and Vates XCP-no. So if you do migrate to another location before this date please inform them, of the new address so they can still update that part of the software.
Sent from my iPad
On 9 Apr 2025, at 17:26, Fabian Arrotin arrfab@centos.org wrote:
On 09/04/2025 16:33, Shaun McCance via devel wrote:
On Tue, 2025-04-08 at 14:27 +0200, Fabian Arrotin wrote: On 13/12/2024 15:53, Davide Cavalca wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote:
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/ clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https:// about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ? (I see Fedora also listed there but Fedora recently decided to switch to Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo- a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open- source/partners/ we should be in the clear. I will try to find out more.
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
Hi,
I'd like to know the status about discussion for potential move to Gitlab. I tried to follow the recent board meetings but there was no clear statement/progress on this and I'd like to know in advance.
As announced, Fedora and CentOS public infra will have to migrate to a new DC/hosting facility this year (dates to be announced but probably
for centos - in Q3). That means that I'd like to know the status/future for git.centos.org and so if we have to migrate it to new DC, or not.
Migrating it wouldn't be a big issue though, but just something to consider.
Davide and I met with Nick from GitLab yesterday to talk about this. In terms of resource usage, it looks like we're nowhere near any limits, and he was happy to work with us if we do reach that point. I know there were a few other concerns (Davide brought up nested virt in runners), but I think they're all solvable. I think it would be good for us to put together a migration list of repositories, how big they are, and what kind of CI resources they use. What would be the best place for that? HackMD? GitLab issue? Google doc? Some of them will create work for you, but not all of them, I think. -- Shaun
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https://gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https://gitlab.com/centos/)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Sorry meant Vates XCP-ng instead of Vates XCP-no, damn autocorrect.
Sent from my iPad
On 9 Apr 2025, at 18:59, John Cooper johnpcooper@icloud.com wrote:
It may also be worth speaking to Xen Project and its down stream users, as software which uses Xen hypervisor has CentOS 7 for its dom. An example of such software is CSG XenServer and Vates XCP-no. So if you do migrate to another location before this date please inform them, of the new address so they can still update that part of the software.
Sent from my iPad
On 9 Apr 2025, at 17:26, Fabian Arrotin arrfab@centos.org wrote:
On 09/04/2025 16:33, Shaun McCance via devel wrote:
On Tue, 2025-04-08 at 14:27 +0200, Fabian Arrotin wrote: On 13/12/2024 15:53, Davide Cavalca wrote:
On 2024-12-13 13:18, Fabian Arrotin wrote: > # gitlab agreement > It's a question someone asked me recently and in fact I have no > idea/ > clue what to answer : what's the current agreement between CentOS > Project and Gitlab and which features (limits / quota ?) can we > use or > not. > Maybe worth clarifying ? I was just checking for > features/seats/price > and found https://about.gitlab.com/pricing/. > OTOH, I was searching for info about gitlab.com hosted gitlab > being > free to use for OSS projects , and then found this : https:// > about.gitlab.com/solutions/open-source/ , and seeing that CentOS > (old > logo btw) is listed as open source partner so I guess we're then > covered and no need to be afraid of the future ? > (I see Fedora also listed there but Fedora recently decided to > switch > to Forgejo - > https://fedoramagazine.org/fedora-moves-towards-forgejo- > a-unified-decision/)
This is a good question, and I don't know the answer offhand, but I agree with you that based on https://about.gitlab.com/solutions/open- source/partners/ we should be in the clear. I will try to find out more.
> # lookaside cache usage > At the moment, we're still relying on specific cgi to let > authenticated SIGs member to push to on-premises lookaside cache. > Would there suddenly a need to evaluate using gitlfs, that they > support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
I don't think this is necessarily a requirement, we should be able to continue using the existing lookaside for now. Git LFS would be useful to explore as an option for future-proofing, but it shouldn't be a blocker here.
> # migration to gitlab > I know that Fedora, when doing some investigation about > eventually > moving projects to gitlab, have written a tool to easily > export/import > from pagure git repo itself (easy) but also the tickets/issues , > so > that it would not be lost, so eventually worth investigating ? > (https://github.com/fedora-infra/pagure-exporter) .. and btw, > migrating centos board project itself with issues would then be a > good > candidate ? :)
Yes, Neal mentioned this during the meeting as well. It's definitely something we'll look into and leverage, especially for repos such as the board issues one.
Cheers Davide
Hi,
I'd like to know the status about discussion for potential move to Gitlab. I tried to follow the recent board meetings but there was no clear statement/progress on this and I'd like to know in advance.
As announced, Fedora and CentOS public infra will have to migrate to a new DC/hosting facility this year (dates to be announced but probably
for centos - in Q3). That means that I'd like to know the status/future for git.centos.org and so if we have to migrate it to new DC, or not.
Migrating it wouldn't be a big issue though, but just something to consider.
Davide and I met with Nick from GitLab yesterday to talk about this. In terms of resource usage, it looks like we're nowhere near any limits, and he was happy to work with us if we do reach that point. I know there were a few other concerns (Davide brought up nested virt in runners), but I think they're all solvable. I think it would be good for us to put together a migration list of repositories, how big they are, and what kind of CI resources they use. What would be the best place for that? HackMD? GitLab issue? Google doc? Some of them will create work for you, but not all of them, I think. -- Shaun
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https://gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https://gitlab.com/centos/)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 2025-04-09 09:26, Fabian Arrotin wrote:
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https://gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https://gitlab.com/centos/)
I don't have strong feelings about the old source delivery branches, as long as they're preserved somehow. Worth noting some of these go all the way back to c4 (e.g. https://git.centos.org/rpms/coreutils/branches), so it's not just c7/c8, and there's also old SIG content there. Moving them to gitlab, either under redhat or centos, would be fine IMO, as long as they're clearly marked as archives (easiest is probably to just bulk migrate all the repos as they are and then archive them).
For SIG branches going forward, we should encourage SIGs to use a hierarchy within their namespace (e.g. we're using https://gitlab.com/CentOS/Hyperscale/rpms/ for Hyperscale).
Cheers Davide
On 09/04/2025 20:06, Davide Cavalca wrote:
On 2025-04-09 09:26, Fabian Arrotin wrote:
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https:// gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https:// gitlab.com/centos/)
I don't have strong feelings about the old source delivery branches, as long as they're preserved somehow. Worth noting some of these go all the way back to c4 (e.g. https://git.centos.org/rpms/coreutils/branches), so it's not just c7/c8, and there's also old SIG content there. Moving them to gitlab, either under redhat or centos, would be fine IMO, as long as they're clearly marked as archives (easiest is probably to just bulk migrate all the repos as they are and then archive them).
For SIG branches going forward, we should encourage SIGs to use a hierarchy within their namespace (e.g. we're using https://gitlab.com/ CentOS/Hyperscale/rpms/ for Hyperscale).
Cheers Davide
+1 for the SIG structure but can the board engage asap with Red Hat legal (probably through Steve as he's now the official board liaison) to get an answer. Without that, it's difficult to plan what we (at the infra side) have to plan or not, etc
Fabian,
I reached out to Steve to contact Legal and there are no issues with moving the archives to GitLab.
Thanks,
Amy
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc https://www.redhat.com/
amy@redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
On Thu, Apr 10, 2025 at 10:24 AM Fabian Arrotin arrfab@centos.org wrote:
On 09/04/2025 20:06, Davide Cavalca wrote:
On 2025-04-09 09:26, Fabian Arrotin wrote:
As you raised the question about repositories : has the board already discussed this with Red Hat legal about what to do for the el7/el8 sources that were pushed to git.centos.org ? Can we drop these ? (I guess answer is no) Can they be migrated to redhat namespace on gitlab (like https:// gitlab.com/redhat/rhel/rpms) ? Or can they be migrated to centos namespace instead ? (https:// gitlab.com/centos/)
I don't have strong feelings about the old source delivery branches, as long as they're preserved somehow. Worth noting some of these go all the way back to c4 (e.g. https://git.centos.org/rpms/coreutils/branches),
so
it's not just c7/c8, and there's also old SIG content there. Moving them to gitlab, either under redhat or centos, would be fine IMO, as long as they're clearly marked as archives (easiest is probably to just bulk migrate all the repos as they are and then archive them).
For SIG branches going forward, we should encourage SIGs to use a hierarchy within their namespace (e.g. we're using https://gitlab.com/ CentOS/Hyperscale/rpms/ for Hyperscale).
Cheers Davide
+1 for the SIG structure but can the board engage asap with Red Hat legal (probably through Steve as he's now the official board liaison) to get an answer. Without that, it's difficult to plan what we (at the infra side) have to plan or not, etc
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 16/04/2025 23:29, Amy Marrich via devel wrote:
Fabian,
I reached out to Steve to contact Legal and there are no issues with moving the archives to GitLab.
Thanks,
Amy
Perfect !
so I guess that it means gitlab.com/CentOS and not gitlab.com/redhat (in that case they'd need to do the work as we don't have access to that namespace).
How does the board want to proceed with the gitlab migration ? SIGs can opt-in to slowly migrate projects there ? Once we'll move/archive git.centos.org/rpms/* to gitlab, no SIG would ever have access to these in the usual sig branches (no regex rule in ACL will be migrated)
On 2025-04-16 23:52, Fabian Arrotin wrote:
On 16/04/2025 23:29, Amy Marrich via devel wrote:
Fabian,
I reached out to Steve to contact Legal and there are no issues with moving the archives to GitLab.
Thanks,
Amy
Perfect !
so I guess that it means gitlab.com/CentOS and not gitlab.com/redhat (in that case they'd need to do the work as we don't have access to that namespace).
How does the board want to proceed with the gitlab migration ? SIGs can opt-in to slowly migrate projects there ? Once we'll move/archive git.centos.org/rpms/* to gitlab, no SIG would ever have access to these in the usual sig branches (no regex rule in ACL will be migrated)
Here's my suggestion: - SIGs can and should start migrating to GitLab now - we should pick a flag day for when git.centos.org will become read-only, and announcing ahead of time so folks can plan around it - on the flag day, we stop allowing writes to git.centos.org - we migrate everything that's currently on git.centos.org to gitlab.com/CentOS/Archive (or something like that); ideally we'd use the pagure exporter tool, but it looks like it doesn't support git.centos.org yet (see https://github.com/fedora-infra/pagure-exporter/pull/172) - we flip the archive bit on all the repos migrated to gitlab to make it clear they're archives and people shouldn't push to them - we eventually shut down git.centos.org
This way there should be no loss of data (as everything will be preserved), and SIGs can move things at their leisure as-needed. Does this plan sound reasonable?
Cheers Davide
Just please make a point of notifying XCP-ng (https://xcp-ng.org) earlier than the general announcement. So they can update their processes to handle this change without breakages, as they’ll be accessing this for patches.
Sent from my iPad
On 17 Apr 2025, at 22:15, Davide Cavalca dcavalca@centosproject.org wrote:
On 2025-04-16 23:52, Fabian Arrotin wrote:
On 16/04/2025 23:29, Amy Marrich via devel wrote: Fabian, I reached out to Steve to contact Legal and there are no issues with moving the archives to GitLab. Thanks, Amy
Perfect ! so I guess that it means gitlab.com/CentOS and not gitlab.com/redhat (in that case they'd need to do the work as we don't have access to that namespace). How does the board want to proceed with the gitlab migration ? SIGs can opt-in to slowly migrate projects there ? Once we'll move/archive git.centos.org/rpms/* to gitlab, no SIG would ever have access to these in the usual sig branches (no regex rule in ACL will be migrated)
Here's my suggestion:
- SIGs can and should start migrating to GitLab now
- we should pick a flag day for when git.centos.org will become read-only, and announcing ahead of time so folks can plan around it
- on the flag day, we stop allowing writes to git.centos.org
- we migrate everything that's currently on git.centos.org to gitlab.com/CentOS/Archive (or something like that); ideally we'd use the pagure exporter tool, but it looks like it doesn't support git.centos.org yet (see https://github.com/fedora-infra/pagure-exporter/pull/172)
- we flip the archive bit on all the repos migrated to gitlab to make it clear they're archives and people shouldn't push to them
- we eventually shut down git.centos.org
This way there should be no loss of data (as everything will be preserved), and SIGs can move things at their leisure as-needed. Does this plan sound reasonable?
Cheers Davide _______________________________________________ devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 17/04/2025 23:40, John Cooper via devel wrote:
Just please make a point of notifying XCP-ng (https://xcp-ng.org) earlier than the general announcement. So they can update their processes to handle this change without breakages, as they’ll be accessing this for patches.
Sorry but don't know why we should try to contact people who were using this : we don't have a list of people using sources for outdated linux distributions ..
I still hope that people (especially the ones building projects on top) are subscribed to main devel list or even bonus point if they were then patching themselves in their own git (so nothing was ever pushed back to git.centos.org for third-party projects :-) )
As it seems you are yourself a user, I guess you already forwarded needed info to them ?
It’s part of the dom in that software. So it’s indirectly using it. Letting them know will enable them to update their processes. In fact it’s used by the dom in XCP-ng versions 8.2.0, 8.2.1 and also 8.3.
Sent from my iPad
On 18 Apr 2025, at 16:52, Fabian Arrotin arrfab@centos.org wrote:
On 17/04/2025 23:40, John Cooper via devel wrote:
Just please make a point of notifying XCP-ng (https://xcp-ng.org) earlier than the general announcement. So they can update their processes to handle this change without breakages, as they’ll be accessing this for patches.
Sorry but don't know why we should try to contact people who were using this : we don't have a list of people using sources for outdated linux distributions ..
I still hope that people (especially the ones building projects on top) are subscribed to main devel list or even bonus point if they were then patching themselves in their own git (so nothing was ever pushed back to git.centos.org for third-party projects :-) )
As it seems you are yourself a user, I guess you already forwarded needed info to them ?
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On Fri, Apr 18, 2025 at 1:26 PM John Cooper via devel devel@lists.centos.org wrote:
It’s part of the dom in that software. So it’s indirectly using it. Letting them know will enable them to update their processes. In fact it’s used by the dom in XCP-ng versions 8.2.0, 8.2.1 and also 8.3.
This change has no impact on their workflow, since all of their consumption of CentOS packages was based on importing source and binary RPMs into their Koji instance: https://koji.xcp-ng.org/packages?tagID=3
They never used git.centos.org beyond anything the Virt SIG produced, and these days their overlay packages all come from https://github.com/xcp-ng-rpms/.
I think they're going to be fine. That said, I let them know in their dev channel.
Thanks for doing that Neal. Now I don’t have any worries, at least with XCP-ng. Though there’s another that has a CentOS 7 DOM VM which is the XenServer software from Cloud Software Group (aka Citrix). After they have also been alerted the proposal can then proceed.
Sent from my iPad
On 18 Apr 2025, at 18:57, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Apr 18, 2025 at 1:26 PM John Cooper via devel devel@lists.centos.org wrote:
It’s part of the dom in that software. So it’s indirectly using it. Letting them know will enable them to update their processes. In fact it’s used by the dom in XCP-ng versions 8.2.0, 8.2.1 and also 8.3.
This change has no impact on their workflow, since all of their consumption of CentOS packages was based on importing source and binary RPMs into their Koji instance: https://koji.xcp-ng.org/packages?tagID=3
They never used git.centos.org beyond anything the Virt SIG produced, and these days their overlay packages all come from https://github.com/xcp-ng-rpms/.
I think they're going to be fine. That said, I let them know in their dev channel.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 17/04/2025 23:15, Davide Cavalca wrote:
On 2025-04-16 23:52, Fabian Arrotin wrote:
On 16/04/2025 23:29, Amy Marrich via devel wrote:
Fabian,
I reached out to Steve to contact Legal and there are no issues with moving the archives to GitLab.
Thanks,
Amy
Perfect !
so I guess that it means gitlab.com/CentOS and not gitlab.com/redhat (in that case they'd need to do the work as we don't have access to that namespace).
How does the board want to proceed with the gitlab migration ? SIGs can opt-in to slowly migrate projects there ? Once we'll move/archive git.centos.org/rpms/* to gitlab, no SIG would ever have access to these in the usual sig branches (no regex rule in ACL will be migrated)
Here's my suggestion:
- SIGs can and should start migrating to GitLab now
- we should pick a flag day for when git.centos.org will become read-
only, and announcing ahead of time so folks can plan around it
- on the flag day, we stop allowing writes to git.centos.org
- we migrate everything that's currently on git.centos.org to
gitlab.com/CentOS/Archive (or something like that); ideally we'd use the pagure exporter tool, but it looks like it doesn't support git.centos.org yet (see https://github.com/fedora-infra/pagure-exporter/ pull/172)
- we flip the archive bit on all the repos migrated to gitlab to make it
clear they're archives and people shouldn't push to them
- we eventually shut down git.centos.org
This way there should be no loss of data (as everything will be preserved), and SIGs can move things at their leisure as-needed. Does this plan sound reasonable?
Cheers Davide
Hey Davide,
if SIGs can just migrate themselves, nothing that Infra SIG should care about then , right ? The only ones that Infra SIG should probably migrate are the RHEL sources (so basically all under /rpms/* and /modules/*)
What about the ones under centos ? https://git.centos.org/projects/centos/%2A
git.centos.org can't probably be completely retired as it's also used for lookaside cache content (https://git.centos.org/sources) but what we can do is just have a new hostname like sources.centos.org (git.centos.org being CNAME and added to SAN for the tls cert) when we'll switch that to a new host)
Can the board just create a ticket on infra tracker so that we can officially start working on it ?
On 2025-04-24 04:24, Fabian Arrotin wrote:
Hey Davide,
if SIGs can just migrate themselves, nothing that Infra SIG should care about then , right ? The only ones that Infra SIG should probably migrate are the RHEL sources (so basically all under /rpms/* and /modules/*)
What about the ones under centos ? https://git.centos.org/projects/centos/%2A
I think the easiest is to just forklift everything currently on git.centos.org to GitLab. This way we don't have to figure out in advance what needs preserving and what doesn't, we'll just archive everything, and if a year from now someone realized they needed something, they can just fish it out of the archived repos on GitLab.
git.centos.org can't probably be completely retired as it's also used for lookaside cache content (https://git.centos.org/sources) but what we can do is just have a new hostname like sources.centos.org (git.centos.org being CNAME and added to SAN for the tls cert) when we'll switch that to a new host)
Sounds good to me
Can the board just create a ticket on infra tracker so that we can officially start working on it ?
Will take care of this today, thanks!
Cheers Davide
forklifting *everything* sounds like a mistake. I've already migrated my storage SIG packages (ceph, nfs-ganesha, and libntirpc) to gitlab; I'll be unhappy if those get borked. But the associated centos-release-storage-ceph and centos-release-storage-nfs-ganesha packages are still on git.centos.org. centos-release-storage-common too AFAIK. I undoubtedly have a bunch of distgit repos on git.centos.org left over from when we couldn't use EPEL for dependencies that are no longer needed; it'd be a waste of time and disk space to bring those to distgit.
On Thu, Apr 24, 2025 at 2:44 PM Davide Cavalca dcavalca@centosproject.org wrote:
On 2025-04-24 04:24, Fabian Arrotin wrote:
Hey Davide,
if SIGs can just migrate themselves, nothing that Infra SIG should care about then , right ? The only ones that Infra SIG should probably migrate are the RHEL sources (so basically all under /rpms/* and /modules/*)
What about the ones under centos ? https://git.centos.org/projects/centos/%2A
I think the easiest is to just forklift everything currently on git.centos.org to GitLab. This way we don't have to figure out in advance what needs preserving and what doesn't, we'll just archive everything, and if a year from now someone realized they needed something, they can just fish it out of the archived repos on GitLab.
git.centos.org can't probably be completely retired as it's also used for lookaside cache content (https://git.centos.org/sources) but what we can do is just have a new hostname like sources.centos.org (git.centos.org being CNAME and added to SAN for the tls cert) when we'll switch that to a new host)
Sounds good to me
Can the board just create a ticket on infra tracker so that we can officially start working on it ?
Will take care of this today, thanks!
Cheers Davide _______________________________________________ devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 2025-04-24 12:28, Kaleb Keithley via devel wrote:
forklifting *everything* sounds like a mistake. I've already migrated my storage SIG packages (ceph, nfs-ganesha, and libntirpc) to gitlab; I'll be unhappy if those get borked.
This migration has no bearing on the existing repos that are already on GitLab. We're talking about archiving git.centos.org into a dedicated location (e.g. gitlab.com/CentOS/Archive), so even if the names of some repos overlap that'd be wholly separate.
But the associated centos-release-storage-ceph and centos-release-storage-nfs-ganesha packages are still on git.centos.org [1]. centos-release-storage-common too AFAIK. I undoubtedly have a bunch of distgit repos on git.centos.org [1] left over from when we couldn't use EPEL for dependencies that are no longer needed; it'd be a waste of time and disk space to bring those to distgit.
I kinda disagree on this. I think there's value in preserving old repos, even if they're no longer relevant, because they might be useful to reference down the road to figure out why/how a specific package was built, or a decision was made. It's true there's some cost in terms of disk usage, but I don't expect that to be an issue in practice (the CentOS group on GitLab is under their OSS program, and GitLab is happy to work with us on resourcing as needed).
Cheers Davide
On Thu, Apr 24, 2025 at 2:44 PM Davide Cavalca dcavalca@centosproject.org wrote:
On 2025-04-24 04:24, Fabian Arrotin wrote:
Hey Davide,
if SIGs can just migrate themselves, nothing that Infra SIG should care about then , right ? The only ones that Infra SIG should probably migrate are the RHEL sources (so basically all under /rpms/* and /modules/*)
What about the ones under centos ? https://git.centos.org/projects/centos/%2A
I think the easiest is to just forklift everything currently on git.centos.org to GitLab. This way we don't have to figure out in advance what needs preserving and what doesn't, we'll just archive everything, and if a year from now someone realized they needed something, they can just fish it out of the archived repos on GitLab.
git.centos.org can't probably be completely retired as it's also used for lookaside cache content (https://git.centos.org/sources) but what we can do is just have a new hostname like sources.centos.org (git.centos.org being CNAME and added to SAN for the tls cert) when we'll switch that to a new host)
Sounds good to me
Can the board just create a ticket on infra tracker so that we can officially start working on it ?
Will take care of this today, thanks!
We can just put them into gitlab.com/CentOS/Archive/git.centos.org and preserve all namespaces and such as archived repositories underneath that. Then things can be figured out afterward.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 2025-04-24 12:37, Neal Gompa wrote:
We can just put them into gitlab.com/CentOS/Archive/git.centos.org and preserve all namespaces and such as archived repositories underneath that. Then things can be figured out afterward.
Yeah this would be my preference as well. It's also a lot easier that having to make a judgement call for every single repo at archival time.
Cheers Davide
Hey,
Maintainer of Pagure Exporter here. I have started working on an alternate PR for the feature here https://github.com/fedora-infra/pagure-exporter/pull/188 this morning. Fabian brought this to my attention yesterday evening so I should be done with the tests and releases by the next week. I am limiting my scope to only Git repositories and excluding both issues and pull requests for now unless, of course, it is needed. Please feel free to take the draft PR for a spin locally and let me know if there's anything else that is needed on it.
Regards, Akashdeep Dhar (he/him), Red Hat Community Linux Engineering t0xic0der@fedoraproject.org akashdeep@redhat.com TZ = Asia/Kolkata (UTC+05:30)
On 2025-04-25 03:31, Akashdeep Dhar wrote:
Hey,
Maintainer of Pagure Exporter here. I have started working on an alternate PR for the feature here https://github.com/fedora-infra/pagure-exporter/pull/188 this morning. Fabian brought this to my attention yesterday evening so I should be done with the tests and releases by the next week. I am limiting my scope to only Git repositories and excluding both issues and pull requests for now unless, of course, it is needed. Please feel free to take the draft PR for a spin locally and let me know if there's anything else that is needed on it.
Thanks Akashdeep!
Issues and PRs would be useful to preserve if possible, especially for repos under https://git.centos.org/projects/centos/%2A . For example, the Board repo (https://git.centos.org/centos/board) has a lot of historical context tracked in issues that would be good to keep available. For repos under rpms/, issues are disabled across the board, so those don't matter there. A small subset of rpms/ have PRs that would be good to keep if possible, but I wouldn't consider that a showstopper.
Cheers Davide
On 25/04/2025 17:31, Davide Cavalca wrote:
On 2025-04-25 03:31, Akashdeep Dhar wrote:
Hey,
Maintainer of Pagure Exporter here. I have started working on an alternate PR for the feature here https://github.com/fedora-infra/ pagure-exporter/pull/188 this morning. Fabian brought this to my attention yesterday evening so I should be done with the tests and releases by the next week. I am limiting my scope to only Git repositories and excluding both issues and pull requests for now unless, of course, it is needed. Please feel free to take the draft PR for a spin locally and let me know if there's anything else that is needed on it.
Thanks Akashdeep!
Issues and PRs would be useful to preserve if possible, especially for repos under https://git.centos.org/projects/centos/%2A . For example, the Board repo (https://git.centos.org/centos/board) has a lot of historical context tracked in issues that would be good to keep available. For repos under rpms/, issues are disabled across the board, so those don't matter there. A small subset of rpms/ have PRs that would be good to keep if possible, but I wouldn't consider that a showstopper.
Cheers Davide
Yes, exporting all would be even a required operation for some projects/repositories, like mentioned by Davide. One of the first project that will probably move is the https://pagure.io/centos-infra/ one, as it's the infra tracker so keeping history of open/closed issues is a kind of "must" :)
Thanks a lot for this !
Hey Davide and Fabian,
Ok, I will add issues to the scope as well. PRs could be tricky as we are facing a similar situation with exporting PRs from Pagure to Forgejo. Could you please help me understand by when do you folks need this ready by? I am juggling between the Forgejo work, the Fedora Messaging stuff and now this so some semblance of a deadline would help me prioritize these. Thanks.
Regards, Akashdeep Dhar (he/him), Red Hat Community Linux Engineering t0xic0der@fedoraproject.org akashdeep@redhat.com TZ = Asia/Kolkata (UTC+05:30)
On Fri 13 Dec 2024, 13:18 Fabian Arrotin, arrfab@centos.org wrote:
On 13/12/2024 12:47, Davide Cavalca wrote:
In the last Board meeting we discussed the future of git.centos.org,
and
whether it would make sense to encourage SIGs to move over to GitLab, as we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream).
GitLab also provides features (notably, CI integration via Pipelines and an improved code review flow) that some SIGs would like to use and would benefit from.
To this end, I have filed https://git.centos.org/centos/board/issue/129 to summarize the discussion and decide the next steps. We'd welcome any comments and feedback on this. To be clear, there are no plans to sunset git.centos.org at this time.
Cheers Davide
Hi Davide,
Thanks a lot for the info.
Some thoughts about this :
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ?
It's covered under their open source program, it effectively offers the equivalent of Ultimate tier capabilities. There are CI limits to avoid abuse but it's generally very permissive. When we engaged at the time they do an annual renewal to say we are still interested. It then changed to a 3 year renewal, I believe next year it's the end of that cycle. This is more a commitment on their side Vs CentOS or any community side. Happy to share what I know as I looked after the CentOS and Fedora onboarding at the time
(I see Fedora also listed there but Fedora recently decided to switch to
Forgejo - https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/ )
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Thanks Leigh for that historical information!
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc https://www.redhat.com/
amy@redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
On Fri, Dec 13, 2024 at 10:58 AM Leigh Griffin lgriffin@redhat.com wrote:
On Fri 13 Dec 2024, 13:18 Fabian Arrotin, arrfab@centos.org wrote:
On 13/12/2024 12:47, Davide Cavalca wrote:
In the last Board meeting we discussed the future of git.centos.org,
and
whether it would make sense to encourage SIGs to move over to GitLab,
as
we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream).
GitLab also provides features (notably, CI integration via Pipelines
and
an improved code review flow) that some SIGs would like to use and
would
benefit from.
To this end, I have filed https://git.centos.org/centos/board/issue/129 to summarize the discussion and decide the next steps. We'd welcome any comments and feedback on this. To be clear, there are no plans to
sunset
git.centos.org at this time.
Cheers Davide
Hi Davide,
Thanks a lot for the info.
Some thoughts about this :
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ?
It's covered under their open source program, it effectively offers the equivalent of Ultimate tier capabilities. There are CI limits to avoid abuse but it's generally very permissive. When we engaged at the time they do an annual renewal to say we are still interested. It then changed to a 3 year renewal, I believe next year it's the end of that cycle. This is more a commitment on their side Vs CentOS or any community side. Happy to share what I know as I looked after the CentOS and Fedora onboarding at the time
(I see Fedora also listed there but Fedora recently decided to switch to
Forgejo -
https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/ )
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Always happy to help when I have the opportunity :)
On Fri, Dec 13, 2024 at 9:28 PM Amy Marrich amy@redhat.com wrote:
Thanks Leigh for that historical information!
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc https://www.redhat.com/
amy@redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
On Fri, Dec 13, 2024 at 10:58 AM Leigh Griffin lgriffin@redhat.com wrote:
On Fri 13 Dec 2024, 13:18 Fabian Arrotin, arrfab@centos.org wrote:
On 13/12/2024 12:47, Davide Cavalca wrote:
In the last Board meeting we discussed the future of git.centos.org,
and
whether it would make sense to encourage SIGs to move over to GitLab,
as
we already have a group at gitlab.com/centos and that's where CentOS Stream development is happening (under gitlab.com/redhat/centos-stream).
GitLab also provides features (notably, CI integration via Pipelines
and
an improved code review flow) that some SIGs would like to use and
would
benefit from.
To this end, I have filed
https://git.centos.org/centos/board/issue/129
to summarize the discussion and decide the next steps. We'd welcome
any
comments and feedback on this. To be clear, there are no plans to
sunset
git.centos.org at this time.
Cheers Davide
Hi Davide,
Thanks a lot for the info.
Some thoughts about this :
# gitlab agreement It's a question someone asked me recently and in fact I have no idea/clue what to answer : what's the current agreement between CentOS Project and Gitlab and which features (limits / quota ?) can we use or not. Maybe worth clarifying ? I was just checking for features/seats/price and found https://about.gitlab.com/pricing/. OTOH, I was searching for info about gitlab.com hosted gitlab being free to use for OSS projects , and then found this : https://about.gitlab.com/solutions/open-source/ , and seeing that CentOS (old logo btw) is listed as open source partner so I guess we're then covered and no need to be afraid of the future ?
It's covered under their open source program, it effectively offers the equivalent of Ultimate tier capabilities. There are CI limits to avoid abuse but it's generally very permissive. When we engaged at the time they do an annual renewal to say we are still interested. It then changed to a 3 year renewal, I believe next year it's the end of that cycle. This is more a commitment on their side Vs CentOS or any community side. Happy to share what I know as I looked after the CentOS and Fedora onboarding at the time
(I see Fedora also listed there but Fedora recently decided to switch to
Forgejo -
https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/ )
# lookaside cache usage At the moment, we're still relying on specific cgi to let authenticated SIGs member to push to on-premises lookaside cache. Would there suddenly a need to evaluate using gitlfs, that they support ? (https://docs.gitlab.com/ee/topics/git/lfs/)
# migration to gitlab I know that Fedora, when doing some investigation about eventually moving projects to gitlab, have written a tool to easily export/import from pagure git repo itself (easy) but also the tickets/issues , so that it would not be lost, so eventually worth investigating ? (https://github.com/fedora-infra/pagure-exporter) .. and btw, migrating centos board project itself with issues would then be a good candidate ? :)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
-
Akashdeep Dhar -
Amy Marrich -
Davide Cavalca -
Fabian Arrotin -
Joel Capitao -
John Cooper -
Kaleb Keithley -
Leigh Griffin -
Neal Gompa -
Shaun McCance