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 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
-
Amy Marrich -
Davide Cavalca -
Fabian Arrotin -
Joel Capitao -
John Cooper -
Leigh Griffin -
Neal Gompa -
Shaun McCance