On 9/24/19 12:25 PM, Japheth Cleaver wrote:
On 9/24/2019 11:24 AM, Jim Perrin wrote:
Okay, now that the release is out, and everything is announced properly. I'm happy to answer questions about Stream.
Short version is: We're working with RHEL leadership to help make RHEL development more transparent and collaborative with community engagement.
Lots of the engineering work is still "TBD" to make this happen, because we wanted to design/develop this in public collaboration with RH as possible.
Thanks for the openness -- this announcement is certainly very heartening news! The "C" in CentOS has long-meant Community-rebuilt and Community-supported, so having partially- Community-contributed is a great addition.
It's the right way to do it. It doesn't mean we can be open about *everything*, but we'll do the best we can.
My question is mostly on package management and how submissions, upstream patches, and maintenance might work. Will there be standards similar to EPEL which can be written against? For that matter, given the necessary coordination between EL users and EPEL, how does EPEL enter the picture here?
The EPEL steering committee and the CentOS Project will need to work together to sort out how the two work together. I would like to see EPEL functional for both Stream and the standard release.
Yes, we'll have standards for submissions but we haven't worked out what those are yet. At a minimum baseline you can reasonably expect:
1. Code must be accepted by the upstream. 2. Code should be additive in nature (no turning things off or reducing functionality) 3. Code should come with documentation or an explanation for why the change should be accepted. 4. Code should come with tests where appropriate.
Finally, curious whether and how Modularity and the rolling nature of Stream will interact.
Same.