Thank you so much Aleksandra for the detailed response. On 9/20/23 06:31, Aleksandra Fedorova wrote: > On 9/13/23 23:37, Carlos Rodriguez-Fernandez wrote: >> Hi, >> How will the SIG work with ci tests for EPEL packages? I was wondering >> if those tests must be in one side (EPEL), or will be on both >> (EPEL&Int. SIG 3rd Party services), or if there will be some point of >> integration (e.g., some unified place for published results, etc...). >> I see EPEL builds in bodhi but I'm not sure what the state of >> automated CI in EPEL is in respect to CentOS Stream. > > Good question. > > It touches so many interesting topics at once :) > > For example, what does "being on the side" mean? > > When we run a test, we have multiple things: > > 1. content, the test scenario written by someone; > 2. event, which triggers the test; > 3. worker, which runs the test; > 4. results, which are stored somewhere; > 5. feedback, which is shown to someone; > 6. decision, which is made based on test results. > > So who does what where? > > Let's consider the task: > > run a package build and a tmt test for it from a dist-git of an EPEL9 > package minetest, on every update of the glibc package in the CentOS > Stream 9. > > One possible implementation I have in mind would work as follows: > > ---- > > 1. content > > Content is stored in src.fedoraproject.org/rpms/<package name>:<epel9> > and managed by the package maintainer of the EPEL branch > > 2. event > > Event is created by the CentOS Stream infrastructure (message or GitLab > webhook) > > 3. worker > > Can be CentOS Stream Zuul CI. > > 4. results > > The long-term storage is probably not needed here, so the standard > storage assigned by the worker with retention about a week will be enough. > > 5. feedback > > One part of the feedback should be provided to the EPEL maintainer of > minetest - how? > Another to the CentOS package maintainer of glibc. > > 6. decision > > Here the change happens on the CentOS Stream side, so decision to land > or not to land a change is done by the CentOS package maintainer (Red > Hat employee) > > ---- > > In this example the EPEL Project doesn't even have to participate in > this work as a project. All of this can be implemented between the EPEL > package maintainer and CentOS SIG. > > Yet as EPEL represents thousands of packages we probably don't want to > handle each of them separately. Handling ownership changes alone would > be a burden. Also ideally for every test we run on change in CentOS > Stream we should run same test on change in EPEL. > > So we need to create some kind of relationship between EPEL and CentOS > Stream Integration efforts so that EPEL CI and CentOS Stream Third-Party > CI are working together. > > It may also be beneficial for EPEL to provide full control over CI > workers to EPEL maintainers, therefore to not use the CentOS Stream CI > for it, but rather introduce a different setup. > > I am not sure yet how exactly it will work in the end. But I see the > purpose of the CentOS Integration SIG is to be the place where we can > have this conversation. > > And I'd like to invite EPEL folks to it. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x47EBED05C3375B1F.asc Type: application/pgp-keys Size: 2484 bytes Desc: OpenPGP public key URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230920/5374fbfa/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230920/5374fbfa/attachment.sig>