11:53 p.m.
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(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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