On 4/9/21 12:08 PM, Tim Bell wrote:

Thanks for the proposal.

Could there be a scenario where changes are accepted into CentOS Stream and then not accepted into RHEL or would this be to catch these suggestions earlier before they get to the public Stream release ?

Thanks Tim

...

On 9 Apr 2021, at 18:37, Aoife Moloney <amoloney@redhat.com mailto:amoloney@redhat.com> wrote:

Hi everyone,

I would like to share with you all a proposal I have submitted on creating a SIG dedicated to reviewing and triaging feature requests that come from CentOS Stream development intended for future RHEL releases.

The full proposal can be read on the CentOS wiki [0] and an issue has been opened on the CentOS board tracker [1] for review and decision.

Here is the proposal summary and I welcome any thoughts, feedback and discussion:

Purpose The purpose of this SIG will be to serve as a gate for feature requests that are first developed in CentOS Stream from contributors who wish to request these features to be included in future RHEL releases and are then filed in bugzilla. The SIGs overall goal is to make sure that features which have been filed and have technical merit are triaged internally to the correct venue for further review and development. The SIG will take ownership of regular bugzilla reviews filed under Stream and map feature requests from these bugzillas against the formal RHEL Feature Request criteria to identify and file qualifying requests inside Red Hat to achieve this.

I hope you all have a lovely weekend!

Kindest regards, Aoife,

[0] - https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest [1] - https://git.centos.org/centos/board/issue/33

https://git.centos.org/centos/board/issue/33

Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford       _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org mailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

We want to catch things that are somewhat higher-level than individual bugs. The opportunity here is to make sure "Features" go to the right place, and that status is communicated regularly. In some cases this means asking Red Hat to consider prioritizing engineering against an initiative, other times it makes more sense to spin up a SIG, other times it might make sense to recommend something like EPEL.

An example of something that would have been considered by this group is the recently completed work to build and ship Stream 8 container images to quay.io.

--Brian

On 4/9/21 12:25 PM, Davide Cavalca via CentOS-devel wrote:

On Fri, 2021-04-09 at 17:37 +0100, Aoife Moloney wrote:

...

Hi everyone,

I would like to share with you all a proposal I have submitted on creating a SIG dedicated to reviewing and triaging feature requests that come from CentOS Stream development intended for future RHEL releases.

Would this also cover triaging bug reports and ensuring they're actioned on the RHEL side? I'm thinking about stuff like https://bugzilla.redhat.com/show_bug.cgi?id=1945780 or https://bugzilla.redhat.com/show_bug.cgi?id=1930988 which aren't really "feature requests" but definitely do impact RHEL and require engagement from its maintainers.

Cheers Davide _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

I don't think this group can be directly responsible for every bug filed against Stream. Things like this are indeed maintainer engagements. We want to constantly be looking for things in bugzilla that do rise to the level of a 'Feature' though.

--Brian

On Fri, Apr 9, 2021, 7:23 PM Amy Marrich amy@redhat.com wrote:

Aiofe,

So would presenting to the SiG be a starting point to requesting a new feature, or would the SiG monitor bugzilla and other channels for new submitted feature requests? I'm assuming either route would result in the SiG then championing them if they are a good fit for the project?

Yep that's exactly it Amy! We intend to have this SIG monitor bugzillas and IRC channels for features that are already being developed in Stream for when the person/group who have been working on those would like to see this feature end up in RHEL. We would like to make sure these features get all the way into the RHEL feature process and are not missed!

Were going to make space too in an office hours type venue to make sure people can present to the group as well if they would like because we are fundamentally dedicated to make sure community features that hold technical merit which come from Stream *can* and *do* get into the RHEL process, but ideally these features would be filed as a bugzilla with a note saying 'feature' in the extra info box on the service so we know what to look for. We will then work with requestors to get their requests filed correctly. Or indeed triaged to other areas of the project where those ideas would work great in.

I'm really happy to see such positive reactions to this idea initially, and Brian, I and others who are happy to be a part of this SIG initially if approved, are happy to answer any questions people might have.

Thanks again for your engament! Aoife

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 https://www.redhat.com/

On Fri, Apr 9, 2021 at 11:38 AM Aoife Moloney amoloney@redhat.com wrote:

...

Hi everyone,

I would like to share with you all a proposal I have submitted on creating a SIG dedicated to reviewing and triaging feature requests that come from CentOS Stream development intended for future RHEL releases.

The full proposal can be read on the CentOS wiki [0] and an issue has been opened on the CentOS board tracker [1] for review and decision.

Here is the proposal summary and I welcome any thoughts, feedback and discussion:

Purpose The purpose of this SIG will be to serve as a gate for feature requests that are first developed in CentOS Stream from contributors who wish to request these features to be included in future RHEL releases and are then filed in bugzilla. The SIGs overall goal is to make sure that features which have been filed and have technical merit are triaged internally to the correct venue for further review and development. The SIG will take ownership of regular bugzilla reviews filed under Stream and map feature requests from these bugzillas against the formal RHEL Feature Request criteria to identify and file qualifying requests inside Red Hat to achieve this.

I hope you all have a lovely weekend!

Kindest regards, Aoife,

[0] - https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest [1] - https://git.centos.org/centos/board/issue/33 --

Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On Fri, Apr 9, 2021 at 3:07 PM Matthew Miller mattdm@mattdm.org wrote:

On Fri, Apr 09, 2021 at 05:37:52PM +0100, Aoife Moloney wrote:

...

The purpose of this SIG will be to serve as a gate for feature requests that are first developed in CentOS Stream from contributors who wish to request these features to be included in future RHEL releases and are then filed in bugzilla. The SIGs overall goal is to make sure that features which have been filed and have technical merit are triaged internally to the correct venue for further review and development. The SIG will take

This seems similar to one of the responsibilities of Fedora's "FESCo" ("Fedora Engineering Steering Committee") as part of our Change process. (See https://docs.fedoraproject.org/en-US/program_management/changes_policy/)

I think it'd be nice to share structure and concepts (if not outright process) as much as possible in areas like this -- it avoids duplicating work, makes it easier for people working in both projects, and can help actual work move back and forth as appropriate.

Note, the description says "...feature *requests* that are first developed in...", not "...features that are first developed in...". Perhaps otherwise worded as "...feature requests that are drafted by the CentOS Stream contributors...".

With that in mind, I'd be careful drawing analogies to FESCo. Fedora has a lot of freedom in the changes it can make. FESCo is a community body that acts as an arbiter for Fedora direction overall, and they tend to do a good job of it. CentOS Stream is more tightly bound to the direction of RHEL, which absolutely needs community input but this group isn't necessarily setting direction there.

Brian's other reply captures it well. There will be requests that the community wishes to see, sometimes in the content of the OS itself, and sometimes outside of it. Right now, we lack a group that is paying attention at a higher level to help shepherd those to the appropriate place and carry them into Red Hat as needed. The group will have less direct control and act more in an advocacy capacity for these ideas, but without it we stand a high chance of really great ideas being missed simply because of so much going on.

I can imagine in some cases the correct venue for a feature will be : get this upstream in Fedora first. Or maybe there will be some changes proposed in Fedora where the answer will be the reverse. Either way, a shared approach on either side would be nice.

Yep, you're indeed correct. Sometimes something will need to happen in Fedora first, or EPEL, or perhaps a SIG, etc. The Fedora Change process is indeed very similar. The groups working with them are slightly different.

Thus ends the not-bikeshedding part of this message. The bikeshedding part is: I wonder if "SIG" is the right name / structure for this group? SIGs generally are focused on more specific areas, right, and this is more broad. So, where I'm going with this is... "CentOS Stream Feature Steering Committee"?

I like my bikesheds to represent exactly what they're for, but I am terrible at naming.

josh

On 4/9/21 3:07 PM, Matthew Miller wrote:

The bikeshedding part is: I wonder if "SIG" is the right name / structure for this group? SIGs generally are focused on more specific areas, right, and this is more broad. So, where I'm going with this is... "CentOS Stream Feature Steering Committee"?

We only have one name for things in CentOS, and it is SIG. It might or might not be the "right" name, but it's the one that we have. The Promo SIG (such as it is) is certainly not the same species as the Storage SIG, but I, for one, don't relish the notion of determining what is a SIG, a committee, a working group, or a knitting circle.

Yes, naming things is hard.

On Tue, Apr 13, 2021 at 01:47:22PM -0400, Neal Gompa wrote:

Well, at the risk of more bikeshedding, the "official" name for all these in Fedora now is "Team", where each team can choose to call themselves a Team, a SIG, or a Working Group at their preference.

Yeah, exactly -- we also found that having hard distinctions and trying to decide what fits into what was ... not a good use of time, but also that various groups wanted to use different naming to help signal how the group works and what they do.

Working Groups in Fedora currently have a Council reporting requirement, but that's going away because nobody did it anyway...

Yeah. Still trying to figure that out. :)

On Wed, Apr 14, 2021 at 09:18:41AM -0500, Johnny Hughes wrote:

Well .. I think the terms Group and Team are fairly synonymous.

Absolutely, but "SIG" sounds... special.

Again, this is a bikeshed thread and not all that important.