*There's a very large difference between feedback like "I think the user experience is suboptimal here, for this reason" and "I don't like the entire design, you should scrap it and start over".*
Well, I can agree with that. > > In the first case, it's possible to incorporate that into an existing > project if the benefits justify the investment. In the latter case, it > requires a *substantial* reinvestment in work while simultaneously > demoralizing and disrespecting the people who have been working on it. It's > a fundamental difference between constructive and destructive criticism. > > By all means, if there are user experience problems, highlight those. > I was already trying to point things out from my perspective while testing modularity in Fedora: 1. You cannot choose if you want to be modular, you just become modular when installing applications that depend on modules. At this status quo, this behaviour is hard to accept. 2. Broken upgrades for users with libgit2 - instead of a proper solution we have implemented a hack to reset the libgit2 module and thus enable to upgrade. If users knew about this (because they would have opted-in), they would be able to reset libgit2 for themselves and we would not need to hack it. 3. I do not understand why we want to hide modularity from users by shipping default modules to make users not notice we are modular. What is wrong about non-modular defaults and modular streams for various use cases? Nobody has ever explained why having everything modular is so much better. 4. Why absence of modular repos will break the system? Why cannot users choose what they need best? 5. Some modules are not correctly formed according to criteria, we have agreed upon. Bugs were opened. 6. Some streams are not correctly formed. Bugs were opened. 7. Some modules still do not have a yaml file in the fedora-module-defaults, you especially told me they must have it. 8. Naming conventions are not good, streams are named ad hoc. 9. Some modules cannot be installed on Fedora 31 due broken dependencies. Bugs opened. 10. Yet, many bugs I open against particular modules remain unresolved. 11. Even the testmodule, which should be there for people to look at how to do it, is broken. And this all will be shipped with Fedora 31, because we block on DNF behaviour but not on modular sanity. > Just don't draw the conclusion that the whole system is unsalvageable. Let > the team that's working on it figure out if there's a way to fix the UX or > if it truly does mean that a structural flaw exists in the design. The > Modularity Team is reading these threads and is keeping notes on all of the > legitimate issues raised. As of right now, we don't feel that the situation > is unrecoverable. > > I did not say anything like that. Please keep your suggestions constructive. Tell us where we are falling short. We are listening. We're just not ready to throw away years of work because it isn't perfect yet. If we did that every time, we'd never get anywhere. We wouldn't have taken projects like systemd, KDE 4, NetworkManager, and GNOME 3 from their rocky starts to where they are now. All of those examples were hard-fought changes that brought considerable instability to Fedora when they initially landed and now are cornerstones of the Fedora story. Do you point this to me or is it a general statement? I will go with the second here, because I have never said that anybody should throw their entire work away. I have only been consistently suggesting to have modularity opt-in *until the problems are fully solved*. Right now, they are not fully solved and we still force modularity upon our users. I do not think this is correct from the QE perspective. I cannot help you to code, since I am not as good, and I have never commented on how you decide to make things work. I am pointing to things that do not work, and I will be doing it again and again, because I believe it is part of my job to make sure the users get what they deserve. > > _______________________________________________ > 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 > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ 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
