On Sat, Aug 26, 2017 at 04:04:27AM +0200, Kevin Kofler wrote: > 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. Yes, possibly; let's see how this goes in practice. I think in the future we may want to officially say that if a release is delayed into July or January, we skip the next one. > > 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 That'd be a nice feature and is important _in general_, but since for Fedora RPMs and containers the repo changes are _mostly_ to one control file (spec or dockerfile), with other files generally replaced in their entirety if not just added or removed, I don't think it's a huge shortcoming for this use case. [some stuff snipped here where I think we just disagree and that's okay] > > 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!) At least in the short term, yeah, modularity-using release artifacts (spins, editions, containers, whatever) will use that and traditional ones will not. > > 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. Sure, that's fair. Here's the goal: users will have more options without exponentially increasing work for packagers and distro-creators. > 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? That scenario clearly isn't an improvement, but it's also an edge case. Anecdotally, I see "I want KDE without all this GNOME stuff" more than I see "I want all these desktops installed at once". It's _nice_ to be able to do that, but I don't think _vital_, as long a there's an easy way to switch if you want to. Or, it may be that "resorting to containers" solves the problem nicely anyway. But, in any case, yes, that's a tradeoff. The upside is that we'll be able to scale up in ways we can't otherwise. And it means that desktops _do_ have the flexibility to have conflicting libraries where that is beneficial. > 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!) This is a case of "just because we can do anything doesn't mean we should do everything". See my earlier proposal on guidelines for EOL dates (in short: let's make sure they always line up with traditional release EOLs to simplify the problem). -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
