On Mon, Oct 07, 2019 at 04:34:21PM -0400, Matthew Miller wrote:
On Mon, Oct 07, 2019 at 08:13:17PM +0200, Fabio Valentini wrote:
> To quote you from the other ongoing thread: "The default stream for a
> package shouldn't be updated in disruptive ways in shipped releases"
> If that's the case, then what *is* the benefit of abandoning the
> non-modular version of packages, if default streams need to basically
> be maintained separately for different branches anyway? 🤔
To me, most packages would benefit from having two streams: fast and slow.
That's the essential problem I want solved anyway. (Maybe with CentOS
Streams: fast, slow, very slow.)
The "slow" version would be updated on a careful cadence with big updates
aligned with release boundaries. The fast version would be rolling latest.
And for applications, you can pick which you want.
IIUC, Modules make this particular problem worse:
Let's consider this: a new version of ook came out a month ago, got
released in F31, and it seems nice and stable and fully backwards compatible.
The maintainer decides it's time to push it out to stable releases.
- non-modular: git checkout f30 && git merge f31 && fedpkg build
&& fedpkg update
(OK, consider this pseudo-code)
- modular: the "stable" stream gets updated, and now F29 users get an update
just before the release is to be retired. This is at best a waste of
compilation cycles and download bits, and increases chances of breakage
in a release that is supposed to have a minimum of disruptions.
The obvious solution is to *not* update in F29, which means that as Fabio wrote,
default streams need to basically be maintained separately for