devel March 2023

devel@lists.centos.org

31 participants
20 discussions

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

[REPORT] Quarterly Report - CentOS Automotive SIG
by Jeffrey Osier-Mixon 17 Aug '23

17 Aug '23

January 2023 Quarterly report submitted by: Jefro Osier-Mixon, Red Hat - chair _____________________________________ Membership update This SIG does not have a formal membership process. The mailing list currently has 106 subscribers representing at least 32 organizations, though not all subscribers use corporate emails and some are participating as individuals. _____________________________________ Releases in the most recent quarter (or most recent release, if none in that quarter) The Automotive SIG produces three types of artifacts: - AutoSD, a streaming distribution of CentOS designed for in-vehicle automotive use cases. - An Automotive SIG RPM repository that allows the community to expand the content of AutoSD or experiment with some of its parts. - Sample images, built using OSBuild, which provide examples of how to assemble production images based on AutoSD, customized for some hardware, including container images, based on CoreOS/ostree technologies. AutoSD, or Automotive Stream Distribution, is a streaming distribution for automotive in-vehicle software development based on CentOS Stream. It is transparently the upstream project for Red Hat's eventual in-vehicle OS product. AutoSD has been downloaded and used by many organizations who have commented or asked for help, so we know it is getting some traction though of course we don't have exact metrics on usage. In Q4 2022, we released a version of AutoSD compatible with the emerging SOAFEE specification. SOAFEE (https://soafee.io) is an initiative driven by Arm for the purpose of developing a reference specification for Arm-based software-defined vehicles (SDVs) consisting of an operating system, container orchestration strategy, and application layer. In addition, we introduced a very lightweight container runtime based on podman and systemd that does not include Kubernetes, as the latter represented a significant performance hit on all relevant hardware. We presented at the Arm Developer Summit in November on these topics. In the coming quarter, we plan to tighten up documentation, begin a process for accepting and supporting hardware enablement contributions, and continue to develop AutoSD toward the SOAFEE specification while also contributing to that specification within the SOAFEE community. _____________________________________ Health report and general activity narrative The SIG typically has 1 public meeting per month with 25-40 attendees, with visible participation from 7-10 separate organizations. We have largely given up on a separate office hours meeting due to attendance. This SIG is intended to be a community effort with contributions and shared benefits from all participants. All formal meetings are recorded and posted on this page: https://wiki.centos.org/SpecialInterestGroup/Automotive/Meetings Several Red Hat employees made the initial contributions to the project as well as the infrastructure required to build and test it. We occupy a gitlab repository in the CentOS namespace building software regularly using CI, with build instructions provided on the documentation page at https://sigs.centos.org/automotive/ . Sample images are present and downloadable along with customization and build instructions. _____________________________________ Issues for the board to address, if any None, keep up the excellent work :) Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive

1 1

Adding bootc images - part of Cloud SIG or separate?
by Colin Walters 29 Jun '23

29 Jun '23

Hello, I'm a developer on Fedora/RHEL and OpenShift. Lately we've been landing a lot of "bootable container" changes in OpenShift core, and there's a lot more to come. However, as we've been doing about this...I've been saying to people that I wish I had a time machine to go back and do bootable containers from the start. There's a lot of things we're doing today that I think we should stop doing, e.g.: - Switching to kernel-rt by fiddling with each node; we should be simply pulling a pre-built bootable container image with that kernel (more on this below) - Getting away from injecting so much persistent state by default (both via Ignition and outside of it) And crucially, I think we should be developing tools and techniques that apply *outside* of Kubernetes/OpenShift and also work well with it. To be direct, I'd like to eventually productize some of what's happening here in RHEL, not in OpenShift. As part of this (potential) re-architecture of how we think of systems management, I created the https://github.com/containers/bootc project. To be direct: If successful, I think bootc will be the successor to (rpm-)ostree. It's also intended to much more closely align with the github.com/containers organization. A simple way to think of this is: One can (build and) run *application* containers with podman; and these containers can also be run in e.g. Kubernetes/OpenShift. One can build *bootable* containers using any tooling (including podman build), but *running* them is via bootc on the end machine. bootc understands kernels etc. But there's a lot to figure out here - and I want to have a space to figure out this stuff and experiment with it outside of a direct-to-product path. I think a CentOS SIG makes sense for this. So what I'd like to do is either: - Add a new effort to the Cloud SIG, which currently (IMO a bit confusingly) hosts OpenStack/RDO and OpenShift/OKD things which would be a 3rd thing. The bootc work would then be the "base OS" split for OKD/SCOS. But of course, nothing stops one from building bootable host images that are instead designed to be RDO/OpenStack hosts. - Or, create a new SIG Personally, I lean towards the latter because honestly I find the naming "Cloud" to be misleading - bootc is also intended to be useful for standalone, non-cloud-infrastructure settings (such as desktops and IoT). Specifically, I'd like to transfer the existing code that lives in https://github.com/cgwalters/bootc-demo-base-images (specifically https://github.com/cgwalters/bootc-demo-base-images/blob/main/c9s.yaml ) into something CentOS-affiliated and explicitly maintained by a team. (Though I'm not super excited to move it to pagure like at least some other SIG content, but let's not get distracted by git hosting too much here). Another way to say it is that I'd love to ship quay.io/centos/centos-boot:stream9 (notice the -boot). Or failing that, it'd be quay.io/centos-boot/centos-boot:stream9 or so. There's a *lot* to discuss in terms of what actually goes in these base images, and also ensuring it's equally ergonomic for users to build their own base images. So really it's very likely there wouldn't be just *one* base image. In fact, I recently introduced a -rt variant with the RT kernel: https://github.com/cgwalters/bootc-demo-base-images/commit/68afb072a5a1396c… - and this was specifically motivated by issues we hit in OCP. But again, I want to have a space where we try to do more of a "clean(er) slate" approach for a while, with notes "not for production use" - for a while. Everything done here though *is* made with that as an explicit goal though (e.g. it's a toplevel design goal too that existing ostree-based systems can be seamlessly switched to be container-based without reprovisioning). At the same time, bootc already introduces some quite new things that need design iteration; for example: https://github.com/containers/bootc#using-bootc-install - we ship tooling such that a container can install itself (without going through a raw disk image as is used by both OCP and Edge deployments today). And at the same time, I'd like to aim to get the Anaconda changes to install these bootable containers in https://github.com/rhinstaller/anaconda/pull/4561 OK this is already too long, so I'm just going to click send =) Thoughts?

7 10

Discussion: Open technical questions concerning SIG content for RHEL releases
by Peter Georg 09 Jun '23

09 Jun '23

Dear all, There has been an inquiry to the CentOS Board to clarify how long SIGs can expect to be able to build against RHEL build targets [1]. This is necessary to allow SIGs themselves to communicate expected lifecycle of their content to users. The outcome of this, in summary, is that SIGs should be able to build against RHEL until it reaches EOL (end of Maintenance Phase) + 30 days (no access to ELS content). This policy follows the one used by EPEL. Note: It is (obviously) still up to every single SIG to decide if and for how long they want to support a particular RHEL (or CentOS Stream) release. This inquiry also included respectively raised some technical questions. These technical questions are not to be decided by the CentOS Board. In [2] it has been recommended to discuss these on centos-devel. So let's do that. I want to start with two open questions which I do know of. In case there are other open question concerning this matter please raise them here. First open question is where to push content produced by SIGs for RHEL8 to. To better understand the issue, let me summarize the current situation, for which we first need to define the used format for tags in CBS: <sig><el>-<project>-<version>-{candidate,testing,release} where <el> can currently be 7,8,8s,9,9s Packages tagged for -testing are pushed to: https://buildlogs.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ Packages tagged for -released are push to: If el = 8 or 8s: debuginfo rpm packages: https://debuginfo.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ src.rpm packages: https://vault.centos.org/centos/<el>/<sig>/Source/<project>-<version>/ Everything else: http://mirror.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ If el = 9 or 9s: http://mirror.stream.centos.org/SIGs/<el>/<sig>/<arch>/<project>-<version>/ For src.rpm <arch> is source. Note: Although it is not relevant for the discussion, in fact on the mirrors the suffix "s" of <el> is replaced by "-stream". This currently is all fine. However it is planned that the infrastructure currently used for packages built for 8 or 8s will disappear once CentOS Stream 8 and CentOS Linux 7 are EOL (June 30th, 2024). So in case any SIG decides to produce content for RHEL 8 after that date packages can not be distributed properly anymore. Only using the -testing tag and thus https://buildlogs.centos.org is not really an option as it would probably produce too much load on these. My proposal: After CentOS Stream 8 went EOL (May 31st, 2024), which is the same date as the end of the Full support phase of RHEL 8, at least the -release tag of all RHEL 8 build targets is locked and SIGs have to opt-in in case they want to build content for RHEL 8 during its Maintenance Support phase (End: May 31st 2029) for a particular build target. For these, tagging for -release will then push content to http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/, i.e. the same location as used for 9 and 9s. This gives SIGs one month for all required changes before the currently infrastructure disappears. Of course this means additional work for SIGs and Infra. However at some point the location where to push content to has to be changed before the currently used infrastructure disappears. Choosing an earlier date would result in work for SIGs who do not want to continue providing any packages once RHEL 8 enters Maintenance Support phase anyway. The second open question concerns the centos-release-* packages provided by SIGs to allow users to easily consume SIGs' content. For 8s and 9s the CBS tags extras<el>-extras-common-{candidate,testing,release} are used to build these packages. This repository is added in CentOS Stream 8 and 9. For packages build for RHEL 8 and 9 there is currently no common way to provide any means of easing the process to consume SIGs' content. My proposal to fix this is by adding extras<el>-extras-common-{candidate,testing,release} for <el> = 8 and 9, i.e., using the same system as currently used for 8s and 9s. To further ease the process I propose to introduce a package named centos-release-extras which contains the repository config pointing to the content of the tags extras<el>-extras-common-{testing,release} (only -release enabled by default) and the CentOS-SIG-Extras GPG key. The centos-release-extras packages itself would be built in the extras<el>-extras-common-el<el> build target. Users of RHEL would then only need to install this single package to allow them to easily install any other centos-release-* packages. Obviously someone needs to maintain the centos-release-extras package. I volunteer to maintain this package. [1]: https://git.centos.org/centos/board/issue/82 [2]: https://pagure.io/centos-infra/issue/1002

4 11

Few questions on cloud images
by Pino Toscano 06 Jun '23

06 Jun '23

Hello, I have few questions related to the cloud images provides for c8s and c9s, i.e.: - https://cloud.centos.org/centos/8-stream/x86_64/images/ - https://cloud.centos.org/centos/9-stream/x86_64/images/ 1) I see the c9s images are regularly updated, while the c8s images not; is this wanted, or simply a mistake/miss somewhere? If so, will they be kept up-to-date just like the c9s images? 2) are the Vagrant images there officially supported? Let's say you use one, and find a bug; then check on a "classic" installation (baremetal/VM), and the bug isn't there; can users report problems in those cases? 3) would it be possible to have either unversioned or "-latest" symlinks for the latest versions of all the files (i.e. images, checksums, etc)? This way, it will be much easier for users to fetch the latest versions with no need to change URLs frequently. Of course, the assumption is that users of this are always willing to use the latest version. Thanks! -- Pino Toscano

7 14

RFC (Request for Comments) : future of bugs.centos.org
by Fabian Arrotin 10 May '23

10 May '23

Let's discuss https://bugs.centos.org ! For a long time, we used to only have one public tracker , powered by MantisBT (https://mantisbt.org/) , and it was https://bugs.centos.org Due to various changes in the CentOS ecosystem in the last years, some categories were removed/migrated elsewhere : - CentOS infra tracker : https://pagure.io/centos-infra/issues - CentOS Stream : https://bugzilla.redhat.com Some other SIGs also started to have (and document) their own tracker (see https://wiki.centos.org/ReportBugs) So the question is : while we can easily migrate bugs.centos.org to el9, should we ? All comments/remarks are welcome, and let's have a plan about what to do Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 4

python3.11-devel in CS8 (and RHEL8)
by Orion Poplawski 06 Apr '23

06 Apr '23

Pythno 3.11 and some modules have appeared in CentOS Stream 8 appstream. However I don't see python3.11-devel and the other modules that are in CentOS Stream 9 crb in CS8 powertools. I do see them in CS9 koji. Is this just an oversight or some kind of lag? Or is this intentional? It will make it impossible for EPEL to build needed modules for EPEL 8. I've also commented in the python 3.11 RFE here: https://bugzilla.redhat.com/show_bug.cgi?id=2137139 Thanks for any information. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

6 11

Are non-Red Hat folks not allowed to post comments to CS Jira?
by Miro Hrončok 03 Apr '23

03 Apr '23

Hello CentOS folks. I've been told "I wanted to leave a comment ..., but I apparently don't have sufficient permissions (it seems to be read only)" about this ticket: https://issues.redhat.com/browse/CS-1502 Is that by design? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

RFC (Request for Comments) : future of forums.centos.org
by Fabian Arrotin 29 Mar '23

29 Mar '23

Let's chat about forums.centos.org ! IMHO, that service can be easily moved to a newer OS/PHP stack and so continue to run. But on the other hand, I heard rumors that some forums moderators would like to stop maintaining/moderating it after 2024. I also heard that there is now a centos category on fedora discourse (https://discussion.fedoraproject.org/c/centos/71) So while we (centos infra) can easily migrate that server, should we ? Let's spend some time investigating the options and take a decision about it ! Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

5 6

[Action Required] : Decommissioning (on premises) OpenShift CI cluster
by Fabian Arrotin 29 Mar '23

29 Mar '23

Hi all, Camilla announced this in december already (https://lists.centos.org/pipermail/ci-users/2022-December/thread.html) and we sent multiple reminders about that. The plan was already knew since it was decided to move the whole CI infra to AWS (announced in June 2022) but the last bit that had to move was the openshift CI cluster (aka *.apps.ocp.ci.centos.org) to AWS (https://console-openshift-console.apps.ocp.cloud.ci.centos.org/) As the new cluster in AWS is deployed since end of November you still have to migrate your workload from old to new cluster, and that *before* end of March 2023 (see https://sigs.centos.org/guide/ci/#migration-to-new-ci-instance) We'll continue to send such reminders as long as we see tenants who haven't migrated (yet) We prefer announce it multiple times so that nobody will ask "where is my app gone ?" when the whole cluster will be powered down end of March. PS: if you have already migrated, please confirm to us so that we can already delete your project/namespace/storage PV in the previous cluster. Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

3 6

RFC (Request for Comments) : future of https://planet.centos.org
by Fabian Arrotin 29 Mar '23

29 Mar '23

https://planet.centos.org was deployed a long time ago to aggregate feeds from various centos contributors and it was migrated from centos release to centos newer release, as planet (python2 based app) was easy to just rebuild. Now that CentOS Linux 7 will go EOL next year, and that https://blog.centos.org/ (linked to SSO) seems to be the only source for blog posts, I'd like to consider just decommissioning that planet instance, and the "Around CentOS" section of www.centos.org homepage would fetch rss feed from blog.centos.org, instead of planet.centos.org (just acting as a MITM these days) Opinions, thoughts ? -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 2

RFC (Request for Comments) : future of https://feeds.centos.org
by Fabian Arrotin 29 Mar '23

29 Mar '23

The current situation wrt https://feeds.centos.org is that it was started as a quick/easy way to generate .xml files for RSS feeds, for people willing to just subscribe to some feeds to know when some packages land for Stream 8 and 9 (no mail is sent to centos-announce list for these) It's relying on the `repo-rss` script, from yum-utils, on CentOS 7. But it seems that such tool doesn't exist anymore in dnf-plugins-core (providing yum-utils) and so is absent in CentOS Stream 8 and Stream 9. So the question : should we just stop that service when CentOS Linux 7 will be EOL in June 2024 ? Or are there volunteers to port that tool/script upstream to python3 and have it included in a dnf-plugins-core (or a parallel package in Epel 9) ? -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 2

Fedora ELN architecture baseline preparation for CentOS Stream 10
by Brian Stinson 16 Mar '23

16 Mar '23

Hi Folks, The purpose of Fedora ELN is to reflect content from Fedora Rawhide, but built using Enterprise Linux build flags and buildroot configurations. As we prepare for CentOS Stream 10 (and ultimately RHEL 10) we are updating the x86_64 architecture baseline to x86_64-v3 in Fedora ELN [0]. There are no changes to the aarch64, ppc64le or s390x baselines. Your feedback as we make this change is appreciated, and we’re happy to help with any questions. – Brian Stinson and Stephen Gallagher [0]: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/247#reque…

5 9

Proposal: CentOS x86 SIG
by Florian Weimer 16 Mar '23

16 Mar '23

# Goals The purpose of this SIG is to quantify the potential benefits of applying existing compiler technology to distribution packages, targeting more recent CPUs, and evaluating different options for how these optimizations can be maintained in a scalable way, and delivered to end users. Today, there is a significant delay between the release of new x86-64 ISAs and the adoption across the entire CentOS distribution. For example, CentOS 9 Stream released with the x86-64-v2 ISA baseline, nine to thirteen years after such CPUs became commercially available. The concern is that this discrepancy leaves more recent CPU features unused, and end users do not see the best possible performance for the CPUs they use. Parts of the distribution are built with run-time selected optimizations, but this only applies to specialized functional areas, such as string manipulation, certain mathematical operations, and cryptography, but not (for example) to language interpreters that are part of CentOS. # Status Proposed: RFC and looking for a sponsoring Governing Board member # What’s in scope * Explore the immediate runtime performance impact of package-specific ISA-related work on key workloads e.g. language interpreters. * Evaluate the performance benefit at run-time of building CentOS with auto-vectorization and the very-cheap cost model and different x86-64 micro-architecture levels. * Explore ways how these performance-enhancing builds can be maintained at the distribution level and made available to end users for installation. * Assess the image/container size impact of those additional optimized builds (this may not be applicable to some delivery mechanisms). * Explore ways to alert users that they do not get optimal performance because of misconfigured hypervisors. * It is possible, but not likely, that work across the entire distribution may be needed to enable shadow stacks. (Userspace enablement happened as part of CentOS 8, but the kernel parts are not upstream and have changed significantly, so there is some uncertainty.) If large-scale work affecting many packages is needed, the SIG would be a natural place to prototype changes before integration into the distribution. # What's not in scope * Enablement for future x86 CPUs and chipsets, assemblers, linkers, and compiler support for new ISAs including regular performance work on individual packages (e.g., identified upstream backports). Hardware enablement must follow existing processes. * Any 32-bit work (such as 64-bit time_t, or a 32-bit kernel) is explicitly excluded. * The focus will be on userspace changes. * Rebuilds for potential observability improvements are out of scope (although shadow stacks are expected to help in this a * Adding additional hosts to the CentOS infrastructure in support of this SIG needs to be negotiated with the CentOS infrastructure team. The CPU microarchitecture level of the existing infrastructure is already sufficient. # Roadmap March 2023: Start the SIG and coordinate with partners April 2023: Adopt existing CentOS builder resources to deliver the required builds. May 2023: Initial performance analysis results. Rest TBD based on results of exploration. Resources They SIG could benefit from spare x86-64 Koji builder capacity.

9 18

CentOS Stream 8 is now ahead of RHEL 8
by Adam Samalik 16 Mar '23

16 Mar '23

Hi everyone, I'm glad to announce we have resumed releasing CentOS Stream 8 updates, and that Stream 8 is now following the same workflow as Stream 9. This is a follow up of https://lists.centos.org/pipermail/centos-devel/2023-February/142762.html This means Stream 8 builds will be appearing in the Stream koji (https://kojihub.stream.centos.org) built from sources in the Stream dist-git (https://gitlab.com/redhat/centos-stream/rpms) Mirrors remain the same as before. Individual composes can be found at https://composes.stream.centos.org/stream-8/ We're finishing up cloud and container images, you will find them in the same places as before when ready. Cheers! -- Adam Samalik --------------------------- Principal Software Engineer Red Hat

6 9

March Newsletter
by Shaun McCance 15 Mar '23

15 Mar '23

The monthly CentOS newsletter is available. This month: making Stream 8 more like Stream 9, retiring EPEL 8 Modules, web and docs work, and an x86 SIG proposal. Plus, updates from Alt Images and Virtualization SIGs. https://blog.centos.org/2023/03/centos-newsletter-march-2023/

1 0

March board meeting and office hours
by Shaun McCance 10 Mar '23

10 Mar '23

We've published the video of Wednesday's board meeting. Recording: https://youtu.be/VQ1Zc8D-xh4 Minutes: https://hackmd.io/JU0brnwQQcy0lfmoviA1FA Recap: https://blog.centos.org/2023/03/centos-board-meeting-recap-march-2023/ We'll have a followup board office hours next Thursday, March 16, at 14:00 UTC. (Note that this might be a different local time for you than last time. We have followed US DST.) https://us06web.zoom.us/j/85797326320?pwd=ang0SjlxRlRYTlRGRlFSUXJzZGNUZz09 Highlights of the recap: * Christian Glombek presented about CentOS Stream CoreOS & OKD Streams. This is a condensed version of the talk he gave at CentOS Connect. We unfortunately don't have a recording of that talk because of technical issues, so this is your chance to see it. * We discussed the x86 SIG proposal. This conversation is ongoing. * Issue 92: We discussed signing testing repositories * We gave a recap of the work to migrate content off the wiki. See the post on centos-promo. * Issue 93: We talked about the announcement around the EOL/EOB for CentOS Stream 8 and CentOS Linux 7 in 2024. Pat has written a post, and Shaun is working on how to display notices. * We talked about events. We would like to find a home event for a North America West CentOS Connect to join our European event at FOSDEM and our US East event at DevConf.US. We also talked about how to do virtual events, and giving them their own identity distinct from the in-person CentOS Connect. * We talked about doing a survey around CentOS awareness and sentiment.

1 0

CentOS Cloud SIG meeting minutes (2023-03-09) centos
by Joel Capitao 09 Mar '23

09 Mar '23

====================================================== #centos-meeting: CentOS Cloud SIG meeting (2023-03-09) ====================================================== Meeting started by jcapitao[m] at 15:00:54 UTC. The full logs are available athttps://www.centos.org/minutes/2023/March/centos-meeting.2023-03-09-15.00… . Meeting summary --------------- * roll call (jcapitao[m], 15:01:22) * OKD/SCOS Update (jcapitao[m], 15:11:40) * the preparation of the RPM builds for the OpenShift container stack is on-going (jcapitao[m], 15:12:31) * OKD/SCOS is working on standing up a cluster on massopen.cloud (jcapitao[m], 15:13:16) * New release of OpenStack: RDO Antelope schedule plans (jcapitao[m], 15:14:21) * RDO Antelope should be GA by end of March (jcapitao[m], 15:16:40) * TripleO packages won't be provided in CloudSIG repo for this release (jcapitao[m], 15:21:25) * LINK: https://lists.rdoproject.org/archives/list/dev@lists.rdoproject.org/thread/… (jcapitao[m], 15:21:33) * LINK: https://lists.centos.org/pipermail/centos-devel/2023-March/142809.html (amoralej, 15:32:23) * LINK: https://lists.centos.org/pipermail/centos-devel/2023-March/142814.html (jcapitao[m], 15:44:21) Meeting ended at 15:46:32 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jcapitao[m] (40) * amoralej (18) * spotz (10) * centguard (4) * davdunc[m (2) * karolinku12 (1) * lorbus (1) * karolinku (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Take 1 minute to help with Infra & Releng Team with a decision
by Michal Konecny 07 Mar '23

07 Mar '23

Hi everyone, it came to Infra & Releng Team (sub-team in CPE that is taking care of Fedora Infra, Fedora Release Engineering and CentOS Infra) attention that there is a confusion about the labels we are using for issues in our trackers. Namely fedora-infrastructure, releng and centos-infra. There was even a request to change them to something less confusing. So we want to decide if this is really need to change, so we ask you to take this quick survey [0] (this is an anonymous survey, nothing is collected by us) to see if the change is really needed or people are happy with current labels. The survey will be closed on 7th March 2023. On behalf of I&R Team, Michal [0] - https://forms.gle/J2HWDkw1UNuj8HYD8

1 2

2023-03-08 - CentOS Public Board Meeting
by Thomas Oulevey 02 Mar '23

02 Mar '23

Hi Everyone, Our next board meeting will take place at 21:00 UTC next week: `date -d "2023-03-08 21:00 UTC"` If you would like to attend please send me an email to alphacc(a)centosproject.org (please do not reply to @centos-devel or use another email address) and you will receive a link to a Zoom meeting room with a passcode, 1 hour before the meeting takes place. The agenda can be checked at (work in progress) : https://hackmd.io/@centosboard/BJ_FDo93s As a reminder we will enforce few rules : * Wait to be recognized by the Chair before speaking * Respect the Chair when told your time to speak is over - this will allow us to remain on agenda, and complete the meetings in the allotted time * In the event that there are Board-confidential topics, these will be put at the end of the meeting, in Executive Session, and guests will be asked to leave. We hope to minimize these items, but they do sometimes happen. The most common scenarios in which this may happen are personnel issues, or information that Red Hat wishes to share with the Board, but is not yet public. * Muting of participants, or, in extreme situations, ejection from the meeting, is at the sole discretion of the Chair. * Meetings will be recorded, and published to YouTube (possibly with edits/redaction, as approved by the Directors). Thus, by joining the meeting you consent to have your presence at the meeting, and anything you say during the meeting, made public. I hope some of you can join. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel March 2023