--===============0156242302798793680== Content-Type: multipart/alternative; boundary="0000000000001f7d180595098077" --0000000000001f7d180595098077 Content-Type: text/plain; charset="UTF-8" On Wednesday, October 16, 2019, Stephen Gallagher wrote: > On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr > wrote: > > > > On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > > given that we're talking about the need to migrate defaults > > > > To clarify, that has not been decided, and a prominent option mentioned > in > > this thread is the option to simply require that there is a non-modular > > package. > > An awful lot of people are repeating this as if it's a solution > without understanding the existing architecture. Believe it or not, > attempting to abandon default streams and go back to only non-modular > content available by default is a lot harder than it sounds (or should > be, but I noted that we're working on that in another reply elsewhere > in the thread). There is currently no path to upgrades that would get > back from the modular versions and the closest we could manage would > be to rely on the dist-upgrade distro-sync, but in that case we > *still* need to have DNF recognize that the default stream has changed > (in this case, been dropped) and handle that accordingly. > > It may be more work to go backwards than forwards at this point. > Modularity does provide some useful feature additions, so to my mind > it makes more sense to properly fix the issues we have with it rather > than expend enormous amounts of energy to remove those features and > revert to the old way of doing things. And, yes, reduce Fedora's value > to Red Hat in the process. > > I started this discussion to ask the community to help us identify the > best path *forward*. An endless barrage of "kill it off" replies is > not helpful or productive. If anyone has specific advice on how to > move forward (or, indeed, if you can figure out how to migrate back > without considerable release engineering and packager effort), that > would be productive. Just please keep in mind that we have to go to > war with the army we have, not the one we wish we had. > That's just oversimplified - if you find that the way you are on is the wrong one just moving forward is not necessary the correct thing to do. Going backwards to get a saner state is a worthwhile thing to do. I have yet to see an argument how replacing existing packages with modules or providing default streams by default helps to reach the objective of 'parallel availability' - by dropping the default modules by default you get pretty much that without the downsides. --0000000000001f7d180595098077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, October 16, 2019, Stephen Gallagher <sgallagh@redhat.com> wrote:
On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr <= johnmh@splentity.com> wrote:=
>
> On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > given that we're talking about the need to migrate defaults >
> To clarify, that has not been decided, and a prominent option mentione= d in
> this thread is the option to simply require that there is a non-modula= r
> package.

An awful lot of people are repeating this as if it's a solution
without understanding the existing architecture. Believe it or not,
attempting to abandon default streams and go back to only non-modular
content available by default is a lot harder than it sounds (or should
be, but I noted that we're working on that in another reply elsewhere in the thread). There is currently no path to upgrades that would get
back from the modular versions and the closest we could manage would
be to rely on the dist-upgrade distro-sync, but in that case we
*still* need to have DNF recognize that the default stream has changed
(in this case, been dropped) and handle that accordingly.

It may be more work to go backwards than forwards at this point.
Modularity does provide some useful feature additions, so to my mind
it makes more sense to properly fix the issues we have with it rather
than expend enormous amounts of energy to remove those features and
revert to the old way of doing things. And, yes, reduce Fedora's value<= br> to Red Hat in the process.

I started this discussion to ask the community to help us identify the
best path *forward*. An endless barrage of "kill it off" replies = is
not helpful or productive. If anyone has specific advice on how to
move forward (or, indeed, if you can figure out how to migrate back
without considerable release engineering and packager effort), that
would be productive. Just please keep in mind that we have to go to
war with the army we have, not the one we wish we had.

That's just oversimplified - if you fi= nd that the way you are on is the wrong one just moving forward is not nece= ssary the correct thing to do.

Going backwards to = get a saner state is a worthwhile thing to do. I have yet to see an argumen= t how replacing existing packages with modules or providing default streams= by default helps to reach the objective of 'parallel availability'= - by dropping the default modules by default you get pretty much that with= out the downsides.=C2=A0=C2=A0
--0000000000001f7d180595098077-- --===============0156242302798793680== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu ZmVkb3JhcHJvamVjdC5vcmcK --===============0156242302798793680==--