<div dir="ltr"><div>Thanks for this Aleksandra!!</div><div><br></div><div>As Cloud and NFV SIGs member I'm really interested in contributing validation jobs to validate pre-release CentOS Stream content and find out issues as early as possible in the workflow.</div><div><br></div><div>Let us know if we can help somehow in this new SIG!</div><div><br></div><div>Best regards,</div><div><br></div><div>Alfredo<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 31, 2023 at 2:53 PM Aleksandra Fedorova <<a href="mailto:alpha@bookwar.info">alpha@bookwar.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, all,<br>
<br>
I'd like to propose a new Special Interest Group focused on integration <br>
efforts around CentOS Stream.<br>
<br>
----<br>
<br>
# Introduction<br>
<br>
Integration is verifying that products and services built on top of RHEL <br>
or CentOS Stream will continue to work on CentOS Stream and the next <br>
release of RHEL and will not break on package updates.<br>
<br>
As RHEL content becomes available only after the release, RHEL-based <br>
services traditionally use a catching-up integration pattern: people <br>
have to adjust their products and services to work on new RHEL *after* <br>
the update is shipped. Adjusting the services takes time, eating into <br>
the supported RHEL lifecycle period. It also reduces the options for how <br>
we can deal with breaking changes.<br>
<br>
CentOS Stream provides a way to enable forward-looking integration: you <br>
can do the integration early during the development before the change is <br>
shipped to the CentOS Stream or RHEL repositories. This allows us to <br>
prevent or at least prepare better for any breaking changes, which might <br>
be shipped via CentOS Stream or RHEL updates.<br>
<br>
# Purpose of the SIG<br>
<br>
Provide a shared space to develop and maintain tooling and knowledge <br>
base on collaborative gating and testing of CentOS Stream updates before <br>
they are published to CentOS mirrors. This includes both - package-level <br>
and compose-level integration.<br>
<br>
# Goals<br>
<br>
* Document existing integration workflows used by other SIGs.<br>
* Identify common issues.<br>
* Manage, develop and promote the Third-Party CI for CentOS Stream.<br>
   - Document events and triggers.<br>
   - Document standard pipelines.<br>
* Develop the Integration toolkit.<br>
<br>
# Deliverables<br>
<br>
* CentOS Stream Integration Guide<br>
<br>
   The main focus of the SIG at least at the beginning would be to <br>
collect and maintain the knowledge base for integration patterns and <br>
tools used by other SIGs and community members.<br>
<br>
* CentOS Third-Party CI service<br>
<br>
   Eventually SIG may take the ownership of the third-party CI service <br>
(for example based on CentOS Stream Zuul CI) - this is to be discussed <br>
further.<br>
<br>
# First work items<br>
<br>
* Develop and document solution to the following question:<br>
   “I have a test case/task I want to run on every change in CentOS and <br>
get notified about the failure. How do I do it?”<br>
<br>
* Interview other SIGs for their integration workflows to identify <br>
common patterns, solutions and issues.<br>
<br>
# Logistics (to be adjusted later by the SIG members)<br>
<br>
* Matrix channel - No IRC<br>
* Discourse tag - No mailing list<br>
* Docs in some GitLab repo - No wiki<br>
* Bi–weekly text-only office hours on Matrix channel<br>
* (?) Occasional recorded video meeting<br>
<br>
<br>
# Questions<br>
<br>
1) Is the scope limited to integrations done by CentOS SIGs?<br>
<br>
No. There are many ways one can integrate with the CentOS Stream. CentOS <br>
Project provides the option to do it via a CentOS SIG, but it is just <br>
one of the many possibilities. One can run integration workflows on <br>
their own infrastructure (both in the open or in private). We welcome <br>
everyone and would like to share the knowledge and tooling (and work <br>
items :) ) as much as possible.<br>
<br>
2) Is the scope limited to integration with other FOSS projects?<br>
<br>
No. While all the contributions (tooling, configurations, docs) of the <br>
SIG should be open and licensed under the licenses approved by the <br>
CentOS Project, you can participate in the SIG even when your primary <br>
project/product or service is not public. For example you can use <br>
integration tooling in your private labs and optionally contribute test <br>
results without sharing the access to your test systems.<br>
<br>
----<br>
<br>
-- <br>
Aleksandra Fedorova<br>
Matrix: @bookwar:<a href="http://fedora.im" rel="noreferrer" target="_blank">fedora.im</a><br>
Fediverse: @<a href="mailto:bookwar@fosstodon.org" target="_blank">bookwar@fosstodon.org</a><br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</blockquote></div>