Hey Petr, First of all, thanks for writing this up, much appreciated. On Wed, Oct 23, 2019 at 2:52 PM Petr Šabata <contyk@xxxxxxxxxx> wrote: > > Starting a new thread since the old one is hard to navigate at this point. > > Modularity is a distribution-level change and requires some mindset > shift from packagers and users alike. I understand the concerns some > people have, feeling it’s something new and half-baked that is being > forced on them. I entirely agree with you here. Though I'm not sure if "requires mindset shift" is good. > We’re an open source community and in order to drive innovation, we > need to be able to try new approaches and technologies in the open, > not develop them without any input and hands-on experience behind > closed doors, later serving them on a silver plate. The feedback we’re > getting is extremely valuable, but some of it is too narrowly focused > on one specific problem area and not taking into account the other > aspects, requirements, or goals that we’re pursuing. Our objective is > still to deliver multiple versions, or variants, of our content across > releases or even distributions (think EPEL or CentOS). And it’s a good > one. > > The concept of default streams was introduced to make modularity > invisible to anyone who has no interest in alternatives and wants the > system to operate as it historically has. Whether a specific package > is delivered via a module or not shouldn’t matter. (This does not mean > it should be hidden, just that it should have no practical difference > to the system.) This applies to both buildroots and runtime, leaving > the choice of whether to modularize or not to the maintainer. > Obviously, the implementation is falling short in this regard right > now, but we have solutions in development or under design. This > includes making the default streams available in the non-modular > buildroot via Ursa Prime or tracking the module enablement intent in > our software management stack, as Stephen suggested in the original > post. > > While these issues are being resolved, we are considering temporarily > disallowing default streams in Fedora. I don’t want to abandon the > idea completely, as doing so reduces the motivation to actually build > modules and reap the benefits they might provide. This basically makes modularity not useful for many things: 1. People will have to have different workflows between "default" version (standard workflow, as we have today) and "modular" version. Also that means, on the distribution upgrade maintainers will have to do many things to remove modular stream, add old one and upgrade non-modular version. This is also not only about maintainers, but end users too: FXX: fish 3.x is non-modular, stream 4.x exists FXX+1: fish 4.x is non-modular, stream 3.x exists * If user wants to stay on 3.x, he needs to enable stream explicitly *after* upgrade and then downgrade the package (which is actually unsupported). * If user wants to stay on 4.x, he needs to enable stream explicitly during FXX (which is totally fine), but after upgrade he has to explicitly disable it. Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that means: * Maintainer has to maintain that version *twice* (modular and non-modular version) * Nobody can guarantee that those will be compatible 2. In Rust we use modularity to build bunch of packages, filter buildroot-only packages and ship only one user-facing RPM. If we remove default stream, people won't be ever able to do `dnf install ripgrep'. This is worst UX we can provide. > Yes, modularity still has some additional development ahead. We need > to improve the software management stack experience; we need to > revisit our release engineering SOPs; we need to stabilize and boost > performance of our infrastructure; and last but not least, we need to > improve the packager experience, providing more features to make the > creation of modules easier, as well as guidance, best practices and > policies that make it easy to collaborate. These changes are similar > to those for other useful but disruptive technologies that Fedora has > successfully introduced in the past. I think problems with modularity is not about packager experience or some missing features (e.g. I'm waiting for some features for 1+ years, but that's not crucial). The problem is that we don't have well-defined *user* experience. Do you think you will be able to come up with some exhaustive documentation how installation/upgrades/downgrades/switches/whatnot should look like in modularity? I would imagine you need at least 70 "test-cases" for simple things. > I do believe we all intend the best, even if we sometimes disagree. We > currently don’t have any other proposal that would fulfill the vision > of our Objective and the needs of our users. The input here helps us > re-focus on the most acute pain points but the manpower and control we > have is also rather limited. If you want to and can help with the > implementation, I’d like to encourage you to do so. After last few years with modularity, I don't think it is improving but it definitely causes some problems. While I would like to achieve goals you stated in the beginning, I don't think we are ready to introduce modularity to our users and packagers yet. I would like to see it getting back to whiteboard, together with our community define behaviors and implement it outside of our main infrastructure. Give it feedback for 1-2 releases and if it makes sense for people here, get it in here. Yes, that means that people who enjoy modularity will have to start maintaining non-modular packages again and experiment with modularity somewhere else but I don't think it is bad iddea. > P > _______________________________________________ > 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
