On Thu, Aug 20, 2020 at 02:17:09PM -0400, Stephen Gallagher wrote: > On Thu, Aug 6, 2020 at 10:46 AM Miro Hrončok <mhron...@redhat.com> wrote: > > > > On 05. 08. 20 21:36, Stephen Gallagher wrote: > > > FESCo has requested that I submit the module policy once more to the > > > Fedora development list for discussion. Feedback is welcome. > > > > > > == Requirements for Default Streams > > > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > > > permits defaults streams that adhere to the policy below. > > > > Since this has been discussed at lengths at FESCo and this is the first > > time it > > has been brought here (thanks for doing it, Stephen), let me summarize my > > concerns with allowing default modular streams in ELN. > > > > I would like to know if my concerns are valid or if I am just biased. Sorry > > for > > the long email. > > > > > > Fedora has experimented with default modular streams for several releases > > and we > > seemed to be at an agreement that the experiment has failed: > > > > See https://pagure.io/fesco/issue/2406 which includes links to relevant > > previous > > discussions on the topic. Admitting that default modular streams are bad > > took as > > nearly two years, despite a few loud and persistent individuals pointing it > > out > > since the beginning. > > > > While I understand the original idea behind the concept of default modular > > streams concept, shipping defaults via non-modular content has been proven > > superior to default modular streams -- it has been proven that default > > modular > > streams cannot be better than nonmodular defaults and that they can only > > try to > > be as good as them, while they are currently technologically failing to do > > that: > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/ > > > > > > The currently proposed modularity objective for Fedora admits that this > > won't be > > fixed until ta least Fedora 35 and later: > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/ > > > > The current modularity tech-lead strongly discourages default modular > > streams: > > > > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310 > > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502 > > > > Those comments were from Daniel when talking about Fedora as it exists > today. Not about ELN. Yes, he discourages their use in Fedora. > However, ELN has a mission to be a bridge to future RHEL and that > distribution has committed to default streams as a business necessity > for multiple reasons (among them support lifecycle which is much > harder to address via non-modular content).
Modularity that exists in Fedora today is also the Modularity as it exists in ELN. We use the same DNF and associated tools everywhere, and I hope nobody is proposing to diverge on that. The arguments that were made in those comments apply to ELN too equally well. I don't think that "RHEL ... has committed to default streams as a business necessity" is really true. The long reply that Terry Bowling sent in parallel makes it clear that RH wants a certain *user experience* (existing tools and commands continue to work, more software is available). Technical details like whether there is a default stream or not are not mentioned. If the default stream is replaced by non-modular rpms, users are not likely to notice or care. > > Yet despite all this, we got a proposal to allow default modular streams in > > ELN. > > The messaging about this proposal suggests that later, default modular > > streams > > might be proposed for Fedora as well. > > > It was written that way *at your request*. You specifically asked for > a proposal for "Fedora" that we could initially apply only to "Fedora > ELN". It seems disingenuous to now use that as an argument against it. First, I don't remember Miro making such a request. I looked at the meeting [1] notes where we agreed to take the Change-proposal route: 14:19:36 <sgallagh> mhroncok: Once it's fleshed out, I can submit it as a Self-Contained Change, if you like 14:19:45 <sgallagh> For ELN 14:19:53 <Son_Goku> sgallagh, I think that's acceptable 14:20:03 <nirik> +1 14:20:04 <mhroncok> sgallagh: I wasn't going to "require" this, but I would certainly appreciate that, thanks 14:20:04 <ignatenkobrain> sgallagh: yeah, that probably would be the best... so it follows our standard processes 14:20:04 <Son_Goku> we can also approve it essentially out of band since ELN rolls 14:20:09 <mhroncok> sgallagh++ 14:20:09 <zodbot> mhroncok: Karma for sgallagh changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:20:36 <ignatenkobrain> #action sgallagh to submit Self-Contained Change Proposal once ready [1] https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2020-06-24-14.04.log.html Second, for the sake of discussion, even if Miro did request this, with all the respect I have for Miro, his opinion is just that ... one opinion. Right now the text *is* misleading, and we shouldn't accept that just because somebody (maybe) in the past said something. > > """At present, these rules will apply only to Fedora ELN, but are written in > > such a way as to be reusable for Fedora and EPEL in the future through > > another > > Change Proposal.""" -- https://fedoraproject.org/wiki/Changes/ModularPolicy > > > > > > Fedora has decided that default modular streams are no-go. While I admit > > that > > such a decision can be reverted at any time based on significant changes in > > the > > technology, such changes have not happened and are not planned. Yet strong > > supporters of default modular streams try to allow them again and again, > > despite > > the enormous amount of feedback they've received including the feedback > > from the > > current modularity team and tech lead. > > > > > > I sincerely don't understand the RHEL's need for default modular streams, > > but > > when I tried to query the motivation behind this, the answers haven't made > > it > > any better: > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/ > > > > Josh listed some of the key reasons behind default streams: that > enterprise customers don't like to learn new commands. So default > streams allowed us to package content with shorter-than-RHEL-lifetime > and still `yum install foo` would install something the customer could > use. I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e. normal rpms cannot be yanked from the distribution, but a module can be. But technically there isn't much difference, and it's only policy that sets those two cases apart. So instead of using default modules, why not adjust the policy and use non-modular rpms with plain Obsoletes? (In fact, this simpler approach could be argued to be better, since the technology to put Obsoletes in rpms is well established and understood and works nicely, while stream Obsoletes are only being conceived.) [...] > In cases where Red Hat strongly believes that a particular alternative > stream in Rawhide is more in line with the needs of RHEL, a Change > Proposal will be filed with a request to have that stream become the > default in ELN. > * Anything that exists as non-modular content in ELN will have been > built from the Rawhide branch of the same non-modular RPM. > * The set of non-modular packages built in ELN will be a subset of the > non-modular packages in Rawhide > * Module streams built for Fedora Rawhide *may* also be built for Fedora ELN. > * Module streams built for Fedora ELN *may* be set as the default > stream in ELN. If so, those RPMs coming from the default stream *must > not* overlap the non-modular content. Does this last point mean that modular content in Rawhide can contain packages which are available only as modular content? > > I've heard several times that we need to have default modular streams in > > Fedora > > ELN to have a place to test them. In my opinion, we had this place, it was > > in > > Fedora, we have tested them and they failed. Hence I don't understand what's > > more there to test. > > Because software never changes or improves over time. Right, I forgot > we gave up on Python after we discovered that its unicode handling > wasn't great... > > Honestly, I don't understand your argument here. The *implementation* > had issues. Those issues have been identified and plans exist to > resolve them. We agreed not to put that in Fedora until we could prove > it was fixed. The important part is whether those issues have been resolved. As we all know, *plans* in software engineering are worth even less than in other human endeavors. You brought up Unicode in Python, i.e. the transition from 2 to 3. It is a good example: we waited 10 years to make python3 the default while *the implementation* was being improved, even though PEP3000 back in 2006 had all the great ideas and plans. > > OTOH, why don't just let the ELN SIG do this if it doesn't affect "Fedora > > proper"? Because I think it does. Since the beginning of the ELN project, > > it has > > been said that it ships Fedora rawhide content, built differently. Yet if we > > ship the default modular streams content in Fedora ELN and the nonmodular > > defaults in Fedora Rawhide, suddenly we ship different things, unless we > > have > > technical means to ensure the content is synchronized. > > > > I'm... not really sure what you're comparing here, but I'll try to > make it clearer. > > * Anything that exists as non-modular content in ELN will have been > built from the Rawhide branch of the same non-modular RPM. > * The set of non-modular packages built in ELN will be a subset of the > non-modular packages in Rawhide > * Module streams built for Fedora Rawhide *may* also be built for Fedora ELN. > * Module streams built for Fedora ELN *may* be set as the default > stream in ELN. If so, those RPMs coming from the default stream *must > not* overlap the non-modular content. > > Does that make more sense? > > > When the ELN proposal was discussed, several package maintainers (both from > > Fedora and RHEL) proposed to have an eln branch. It received a big NO > > because > > the content would diverge and keeping it in sync would be (close to) > > impossible. > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/44MCFHOFORTPNJFGK6JJ6YMAHFUT7QG3/ > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/ > > ..and many times more... > > > > Fedora ELN should not be a fork. Yet (some of the) default content of > > Fedora ELN > > would be built from modules, which packages built from different branches. > > Has the objective been changed? Is having separate branches for Fedora and > > Fedora ELN no longer a big NO? What changed? > > See the previous statement. The module streams for ELN will be built > from the exact same YAML as the equivalent Rawhide module stream. Thus > what is being delivered is still "Rawhide content", it just happens to > differ about which is the *default content*. > > > I am worried about the divergence between Fedora and Fedora ELN. I am > > worried > > about certain maintainers only maintaining their modules without upgrading > > packages in rawhide > > I feel that this is highly unlikely since ELN won't be a deliverable > in the traditional sense of the term. If they were to do this, their > package would stagnate in Fedora. If that happens, that's what the > non-responsive maintainer process is for. > > > -- and a need of a large volunteer-driven effort to backport > > improvements and fixes from modules to nonmodular packages: From Fedora ELN > > to > > Fedora. This seems wrong to me, as I've always considered Fedora to be the > > upstream of RHEL (and by extension of Fedora ELN) rather than downstream. > > I guess we haven't been clear enough about the artifacts that ELN > produces. They are intended as a compose for testing/CI purposes > *only*. We will not be mirroring them or making them publicly visible > on getfedora.org or anything of the sort. It's a bootstrapping effort > towards RHEL X+1. > > I intend to make it VERY clear that working in ELN but not maintaining > that content in the rest of Fedora is unacceptable. That's part of the > reason behind the package comaintainership requirement in this policy. I accept the fact that this will probably be approved, because there is such a strong desire to do so from a small but important group of contributors. But neither the motivation why this is needed is clear, nor is the wording of the proposal very appealing. Zbyszek > > When I expressed this concern in the "RHEL 9 and modularity" thread, the > > discussion went nowhere: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PQX75DGRIICQLG5KBOY4HTOFFYZVWP6K/ > > (and replies) > > > > > > I believe that allowing default modular streams in any Fedora project is a > > bad > > thing to do before the technology sees large design-level changes. I believe > > that RHEL completely ignoring Fedora's feedback is a very sad thing to > > happen. I > > believe that having default modular streams in ELN will negatively affect > > general Fedora packagers. But I realize that this is juts one person's > > opinion. > > At FESCo, I try to represent the opinion of Fedora package maintainers, not > > just > > my own. Hence I am sharing my concerns here to hear feedback from others. > > I understand your stance on the matter at large. I hope that my > responses above have provided you with at least some measure of > improved clarity. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
