On ti, 24 syys 2019, David wrote: >On 2019-09-24 1:03 p.m., Greg Bailey wrote: >>On 9/24/19 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. >> >>I assume that the FAQ page at https://wiki.centos.org/FAQ will grow >>to include some of the Q&A discussed here? >> >>My question originates from the (lack of) available desktops >>available with CentOS 8. Would alternative desktops such as MATE >>(or KDE, etc.) continue to be published via the EPEL repository, or >>could new packages be introduced via "streams"? How does the >>contribution model for streams differ from EPEL packagers? > >The name is just 'stream' I think, not 'streams' implying there really >is just one path of: > >CentOS stream -> CentOS release + RedHat release I hope we'll get some 'side-streams', in a way similar to how modules' streams used in RHEL 8, to allow such alternative versions to exist for those who wants them. They don't need to be fully supported but at least would provide a way to test new versions before updating CentOS Stream primary content. Though, I think first a bit of definitions would help here. Even in a sentence above I had to invent new terms as there are none defined yet. For now, my understanding is that whatever consitutes CentOS Stream is built off CentOS 8 branches in git.centos.org. Let me take FreeIPA example. For many years our CentOS users asked for new versions of FreeIPA to be available in CentOS from FreeIPA upstream and we weren't able to achieve that as we needed to go with multiple changes through RHEL first. RHEL 8 packages FreeIPA in a module, with two streams: idm:client and idm:DL1, representing client-only and server-side parts of FreeIPA packaging and dependencies. The naming of branches in CentOS is following RHEL naming, not CentOS Stream itself (here it is a bit confusing for uninitiated but those 'stream' parts in the branch names are really after module streams, not CentOS Stream), so there are no separate branches for CentOS Stream: c8-stream-DL1 and c8-stream-client are direct counterparts of stream-idm-DL1 and stream-idm-client in RHEL 8.0. (see https://git.centos.org/modules/idm/c/86698e5c597737f26cde6ff11536d6707dfd4802?branch=c8-stream-DL1 for context) With CentOS Stream, technically we can create additional module streams that correspond to additional versions of the same content. Suppose, I want to get FreeIPA ipa-4-8 upstream git branch (or even just git master branch) provided with daily rebuilds. I'd imagine this would need to go into a separate branch. Let's say there would be c8-stream-DL1-daily and c8-stream-client-daily branches for idm module and IPA packages involved. Those two branches could be built and two new streams would be available for idm module in CentOS Stream. Users then could test / use these idm:DL1-daily and idm:client-daily streams instead of the idm:DL1 and idm:client streams. So far, so good. These new two streams go through some development, bug-fixes and accumulate some content changes. They do not affect normal idm:DL1 and idm:client module streams from RHEL even in CentOS Stream. Eventually, we would propose those changes for integration into c8-stream-DL1 / c8-stream-client. Ideally, this would be as simple as proposing a pull request in git.centos.org pagure instance. I wonder if such flow would be acceptable -- it actually would be pretty cool if such a pull request could be automatically relayed into whatever is powering dist-git for RHEL 8. Of course, the other side would need to see if those changes could get in due to whatever regulatory requirements Red Hat has. Certainly, this would make my integration work for newer upstream releases easier -- given that it would also be available to CentOS Stream users to test way before RHEL customers would get the packages delivered, in ideal world. It looks brighter for modules because each module stream can be fairly isolated here. We can, for example, go extreme and pull newer krb5 build into the idm:DL1-daily so that all shiny work that relies on new MIT Kerberos APIs (and ABIs) would be encapsulated in the module stream for testing purposes. After it is all tested/coordinated, we can look at providing a pull request that updates primary krb5 build and primary idm streams in one go and get it all delivered to CentOS Stream / RHEL. This doesn't look so bright for non-modular packages. They don't have ways to isolate themselves other than becoming a package in a separate module:stream just for that purpose. Or being delivered in a completely separate repository. So, I guess, there are many technical questions to answer but I have few related to what I'd see as stumbling blocks with my RHEL workflow experience: - how to get pull requests back and forth between CentOS Stream and RHEL proper - how to handle these backward pull requests in RHEL workflow where there are certain limits on what goes into which minor release to keep ABI/API changes under control, etc - how to make these pull requests usable on both sides for packages which passed through debranding - how to handle module stream renaming for these pull requests So far all the answers for these in Fedora-RHEL pairing were 'it is all manual work'. We don't use modules for FreeIPA in Fedora, for example. We do use them in RHEL. With CentOS Stream we already have modules on both sides but they use different naming and still would require manual work. However, it is promising -- if we could get it automated, that will really help all of us. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland