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(a)fedoraproject.org>
Fedora Project Leader