On Wed, Oct 23, 2019 at 12:56:41PM -0400, Matthew Miller wrote: > However, I also have a pretty strong bias towards people who showed up to > do the work, and the decisions they've made. That doesn't mean we're stuck > and can't adjust -- in fact, adjusting as we've gone along is a lot of why > we're where we are now. But unless someone shows up with people-power and > funding to do it, I take kind of a skeptical view of proposals to start a > whole new approach from scratch. Sure, people who show up to do the work get to choose what happens. But we can't take it to an extreme: there must always be an option to back out of an idea. Every Change page is required to fill out a Contingency Plan, and yes, we do occasionally execute those. There are decisions which need to be implemented for us to see all the benefits and drawbacks, and in those cases a lot of work is wasted when the contingency plan is enacted. See for example recent proposal by Ben Cotton to use Taiga: it was 90% implemented before some drawbacks became visible, and Ben and Manas took the high road and yanked it. In fact, the amount of work that has gone into a project is not a reason to keep trying. If anything, the opposite is true — the more person-hours have been "consumed" the more that indicates that the idea is not workable. As we learn from the implementation, we understand our goals and limitations better, and sometimes we need to take a hard look and say the expected *remaining* amount of work is too big. The fact that people showed up and put in work is not the final consideration. > > > Because this keeps coming up, we talked about this at the Fedora Council > > > meeting today. Our goals for modularity are: > > > 2. Those alternate streams should be able to have different lifecycles. > > > > Hmm, it sounds like the Council hasn't taken into account the constraints > > on lifecycle of modules that we have slowly discovered during the last > > two years, constraints that are now part of FESCo-approved policy. > > > > Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora > > release. And to preserve stability for users, a.k.a. following the Update > > Policy, modules should only change to new major version at Fedora > > releases. This is exactly the same as for "normal" rpms. > > This seems appropriate for default steams, but modules should be able to > have alternate, opt-in streams which either a) update on a rolling or other > cadence or b) choose to keep building the older version across the release > boundary. > > The tooling should make this clear to the users. Yes, default streams, but also streams that other streams or packages depend on. Having rolling updates or updates with independent cadence is OK if you are a leaf module and the users opt-in into those changes. But as soon as people try to build other packages on top, or try to use such modules in production as dependencies of other things, this breaks down. The general rule in Fedora is that you get version bumps and non-backwards-compat behaviour changes between releases, giving users and other packagers a clear point in time to expect this. Packages (and streams) can also only be retired at Fedora release EOL. This is a policy choice, not a technical matter. If modules became more popular, and the dependencies between modules grew, we'd need to settle on similar rules, where bigger changes are done with a certain cadence. This is why I think that the "independent lifecycles for modules" are illusory, made possible by current scarcity of modules. (Or to look at this from another POV: if we want to give users access to a rolling version of some package, we can do it just as well without modules. In fact, we already do, with the kernel, with firefox, and probably a bunch of other packages where this makes sense. For leaf packages this works. If we want to give users e.g. rolling postgresql, we could provide postgresql-rolling package. Maybe we should.) Zbyszek _______________________________________________ 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
