Matthew Miller wrote: > I hear three different main frustrations here: first, the short F27 > schedule; second, frustration with with the packagedb retirement; and > third, modularity. These are frustrations I also share: > Schedule > ======== [snip] > If, instead, we lengthened the schedule, adding 6 months from the F26 > release, we'd be in mid/late December, which we know from experience means > January. With delays, maybe February pushing March. And then, we'd be in > the exact same position for F28, debating whether to shorten that or > instead schedule for September instead of May. That would actually be > _more_ delay for _more_ things. You could actually just have skipped the October-November release as you did during the F21 cycle, leading to a single 9-month cycle, then back to 6 months. I think a 9-month cycle would be much more realistic than a 3-month cycle to fix a 3-month offset from the desired release dates. Three 7-month cycles would also have worked (and if the first one really slipped as much as you think, it'd be a 9-month cycle and you'd switch back to 6 months right away, as in the previous paragraph). > Pkgdb retirement > =================== > > On the one hand, the new https://src.fedoraproject.org/ site is > awesome. Is it really? The Pagure git browser is still missing as basic features as browsing the history of individual files or directories, something I already complained about when it was forced on us as a replacement for the Fedora Hosted Trac. Both Trac and Cgit are nice, mature Free Software projects. Their repository browsing abilities are great. I do not see why they needed to be replaced with something incomplete just because they were Not Invented Here and the incomplete replacement was. > Modularity > ========== > > Yes, there's a lot of prototyping and reworking. Some of this may fail. > But that's how it should be — it's really not possible to have > innovation without trying some unsure paths. Going down a road that will almost certainly fail is not "how it should be". > If you want to try other paths that help us solve some of the same > problems, I'll support experimenting with them too. I am both not sure that the problems you want to solve are actually problems, and that if they are, they can be solved in any reasonable way. (And yes, this implies that I do not consider the Modularity plans reasonable.) > On your specific complaint about DNF not distinguishing between rpms > and modules, you're definitely not alone; the Boltron feedback > overwhelming tilted that way. See earlier thread on topic — and as I > said in that thread, I think it makes most sense to treat modules like > "super comps groups" (with either a superset of existing groups syntax > and reuse of @, or simply a different syntax). In any case, this > feedback _is_ important and _is_ listened to. I, too, hope that this will be addressed. What I also hope is that there will be a way (by uninstalling a plugin RPM or by setting some dnf.conf option) to avoid retrieving the module metadata entirely. (In fact, I'd hope that that'll be the default on the traditional Spins!) > I do want to _strongly_ stress, though, that the point of modularity > isn't to avoid parallel installability. That's a separate problem. It is not clear to me what problems are solved by Modularity that cannot be solved by either parallel-installable compat packages or just making everything work with the latest versions as we have always done. Modularity just adds conflicts (that need containers to work around), inconsistent EOL dates (that make life harder for our users, including us ourselves), and more complexity for us packagers. > Modularity will allowing *us* at the packaging end to separate source > and spec lifecycle from binary and artifact lifecycle. That, by itself, is not a goal. It is a way to achieve an unspecified goal. > And, it will also allow those of us working on assembling spins and more > options — for example, we can have different streams for Atomic without > needing to actually duplicate every package. (And we could do the same for > KDE or whatever other artifacts would benefit from that, if we want.) That destroys the possibility to install all Fedora packages on all Fedora spins, which the shared Everything repository guaranteed. With Modularity fully implemented, you can end up being unable to install KDE Plasma on the GNOME Workstation or the other way round (at least without resorting to containers) because the desktops depend on conflicting versions of some library module. How is that an improvement? > And that's not even with doing arbitrary branching for individual > packages. The arbitrary branching is what leads to users having to track a different end of life date for, in the worst case, every single package. If Modularity is a success, users will have installed dozens of modules. If each of them comes with a different branch EOL, how does the user know when it's time to upgrade to a supported branch? (Or else, if you do the upgrade automatically, how do you ensure it does not break things? We have releases rather than a rolling release for a reason!) > If everything works out successfully with _that_, it will eventually make > _less_ work for packagers. Right now, I have a package which I maintain > for F25, F26, Rawhide, EPEL6, and EPEL7. There's no difference in any of > the versions and no real reason to keep them separated; In that case, you can just merge master to all branches and keep them fast- forwardable, where is the issue? > in the future, I will be able to have just one branch that goes to all of > them. So it would not even be rebuilt? That's less flexible than the current approach that can deal with soname bumps. With your approach, in the case of an soname bump, you end up requiring the wrong version of the library module on at least one Fedora release and thus causing a module version conflict. > Or I could have a "stable" and "experimental" branch that people could > choose from regardless of the base. That, too, only works well when the libraries did not change, for the same reason. > This can benefit *way* more packages than simply leaf desktop > applications. If you do this arbitrary branching to a non-leaf package, you cause version conflicts for all the packages depending on the non-leaf package (which exist by definition, or it would be a leaf). Then, matching versions of all those dependent packages are needed. And the container workaround is a lot less useful for non-leaf packages. > Will we get there? I don't know! It's new and different and definitely > scary. It is scary indeed. Modularity is just throwing us back to the "RPM hell" times, and the only proposed solution is to containerize everything, or at least everything that conflicts, which is a very inefficient and wasteful solution to a problem that did not exist before Modularity. > But... it's also worth trying. Is it really? Have we not learned enough from past experiences? Allowing arbitrary versions of arbitrary packages, without ensuring that they match globally, does not scale. You unavoidably run into conflicts. It has been experienced not only by us ("RPM hell"), but also on other operating systems (e.g., "DLL hell"). Grouping the packages into self-consistent modules does not solve the problem. It only means that you have larger "packages" (the modules) consisting of multiple actual packages. But you still cannot allow combining arbitrary versions of them, as the Modularity plans are all about, without running into conflicts. The only case where being self-consistent implies being globally consistent is if you have only one Everything module. > In the meantime, if you're a packager who doesn't care about any of > this, until modularity can demonstrate real success and advantages, you > can _continue_ to not care. Modules are going to be drawn from f27 (and > I expect f28) streams which will act as always, and even if Fedora > Modular Server is a success, I expect we'll also provide a minimal > install from which a traditional Fedora-based server can be built for a > good long time. I sure hope so. But I fear that we non-module users will be marginalized more and more. I also fear that the new branching scheme will either become mandatory, or there will be pressure to port some packages to it because of new-style-branched packages depending on them. And I am very worried about the implications of arbitrary branching on update availability (disparate EOL dates that are impossible for users to track). Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
