You're posting this on devel@, I wonder if you'd get different responses on users@. Some responses to your questions inline below, but first, >From my perspective as a user: I was in the group of users that needed newer tools for development than what I could get on RHEL/CentOS. I thought SCL was crap, so I switched to Fedora, because it just had what I needed. I loved Fedora more than RHEL/CentOS, because it gave me what I needed. Modularity to solve that problem in Fedora seems like a more "in your face" version of everything wrong with SCL, but now forced upon me. >From my perspective as a developer: Because I grew to love Fedora, I wanted to contribute back... I became a packager to help maintain tools for my own daily use. However, when modularity came to Fedora, being a casual packager became impossible... I had to devote more time to understanding what was happening to all my BuildRequires, and/or how to use modules when regular Fedora worked so perfectly for me (at least, I knew where I stood with it... I understood how to file a bug report and against which package, and where the package source was to help if necessary)... OR I had to throw my hands up in the air and complain on list, and grow more and more frustrated... OR I had to just stop maintaining my packages that broke because of the mass exodus of packages I needed as BuildRequires and Requires for my own packages. Modularity has made the packager experience worse. One of the best things about Fedora, for me as a Java developer, was the dependency convergent nature of the distro... normally a huge pain for Java development, but it was made easy in Fedora, because I could just converge on what was packaged... if a newer lib was needed, well, in 6 months, everybody would be converged on the updated version. Simple. Of course, there were special cases with compat packages, but those were rare, and with some effort, they could be avoided, too. When a package was updated, all packages which depend on it moved at the same time. Things were predictable... stable. Now, I don't know what is going on... packages are being shipped with embedded static libs, there's lots of different versions of the same package everywhere... I have to know not only which repositories I'm pulling from, but also which modules, and which application streams within those modules? It's so complicated. I've actually reverted in many cases to avoiding the packages in Fedora now... I've gone back to manually downloading Maven and Eclipse from their respective upstreams... they're more reliable, more up-to-date, and more stable. I used to like that I could get those "out of the box" in Fedora... but now the Fedora ones don't work very well, and I have to jump through hoops to even install them properly. On Mon, Aug 5, 2019 at 9:52 AM Terry Bowling <tbowling@xxxxxxxxxx> wrote: > > Hello Fedora friends! > > I would like to follow up and collect your input on Application Streams and modularity after all of the discussions over the past month. We have been listening and brainstorming on how to proceed with both the tooling, user experience, and communicating better upstream for this process. > > The team working on modularity in Fedora posted some revisions to the Fedora modularity documentation. Additionally, I described the end user experience expectations in this thread, essentially describing why fully automated stream switching cannot occur for a sane distro environment- at least at our current level of understanding and tooling. While my description was certainly focused on the RHEL user perspective, as a long time Fedora user I will say this is equally true for many Fedora users. > > That said, I am hoping you could share your collective wisdom and provide us feedback on the following: > > 1. Have we better communicated the current features and goals of Application Streams and modularity, primarily focused on end users? I do not believe these have been communicated very well at all, nor do I believe that this effort is primarily focused on end users. I think the end user experience is worse than it was before. Fedora no longer moves as one single entity composed of thousands of packages, like a school of fish, that users could cast their nets into and feed themselves from its bounty. Now, it seems to move as several different smaller schools of fish moving in different directions... no one school big enough for users to even bother throwing a net at it. > > 2. Does this help developers better understand the current limiting state and challenges for both stream and other tooling limitations? I don't think the problem is that developers don't understand the limitations. Like many things in life, there are trade-offs. I think Fedora has traded dependency convergence, good user experience, a robust set of available packages, lower barrier to entry for new packagers, and more, in favor of supporting a set of special use cases that don't matter to the vast majority of Fedora users. > > 3. What can you share from commercial ISV and/or community developer perspectives, and with respect to the user experience and stable distro goals previously described for Application Streams, do you have recommendations or requests for specific behaviors or tooling needed to benefit the Fedora and RHEL ecosystems? Such as but not limited : The loss of stable dependency convergent Java packaging available for downstream application development makes it much less appealing to ship Java applications tested and tailored for Fedora. > > a. How to provide the ability to switch streams without breaking a user's choice or need for a different AppStream in the dependency chain. > > b. What feature or tooling gaps still exist for creating community or commercial products for RHEL & Fedora? A fully stocked buildroot for Java non-modular packages is essentially non-existent now, making it very difficult to bring new Java packages to Fedora repos. dnf module tooling needs to be more well-formed (computer-parsable, "grep-able"), paginated, colorized (as well as other dnf output, but the module stuff is particularly problematic to parse); there also seems to be a lack of autocomplete goals for the module-related features of dnf More packages than necessary seem to now be "buildroot only", making it impossible for mock and fedpkg local to do local test builds of things that depend on them. Packager tooling should be sufficient to build anything locally that can be built in koji. > > c. Anything I did not think to ask? > > Thank you for your feedback! > --- > Terry Bowling > Sr. Technical Product Manager - RHEL Systems Mgmt > Red Hat, Inc. > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
