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 different 
> branches

Zbyszek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to