[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Modularity and the system-upgrade path
From: drago01 <drago01 () gmail ! com>
Date: 2019-10-16 16:21:59
Message-ID: CAMqY-FftOz+prDPy-wT0ARZx9xqpeMeK-urmoxz-_1R5CMfKng () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 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.
[Attachment #5 (text/html)]
<br><br>On Wednesday, October 16, 2019, Stephen Gallagher <<a \
href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr <<a \
href="mailto:johnmh@splentity.com">johnmh@splentity.com</a>> wrote:<br> ><br>
> On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote:<br>
> > given that we're talking about the need to migrate defaults<br>
><br>
> To clarify, that has not been decided, and a prominent option mentioned in<br>
> this thread is the option to simply require that there is a non-modular<br>
> package.<br>
<br>
An awful lot of people are repeating this as if it's a solution<br>
without understanding the existing architecture. Believe it or not,<br>
attempting to abandon default streams and go back to only non-modular<br>
content available by default is a lot harder than it sounds (or should<br>
be, but I noted that we're working on that in another reply elsewhere<br>
in the thread). There is currently no path to upgrades that would get<br>
back from the modular versions and the closest we could manage would<br>
be to rely on the dist-upgrade distro-sync, but in that case we<br>
*still* need to have DNF recognize that the default stream has changed<br>
(in this case, been dropped) and handle that accordingly.<br>
<br>
It may be more work to go backwards than forwards at this point.<br>
Modularity does provide some useful feature additions, so to my mind<br>
it makes more sense to properly fix the issues we have with it rather<br>
than expend enormous amounts of energy to remove those features and<br>
revert to the old way of doing things. And, yes, reduce Fedora's value<br>
to Red Hat in the process.<br>
<br>
I started this discussion to ask the community to help us identify the<br>
best path *forward*. An endless barrage of "kill it off" replies is<br>
not helpful or productive. If anyone has specific advice on how to<br>
move forward (or, indeed, if you can figure out how to migrate back<br>
without considerable release engineering and packager effort), that<br>
would be productive. Just please keep in mind that we have to go to<br>
war with the army we have, not the one we wish we had.<br>
</blockquote><div><br></div><div>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.</div><div><br></div><div>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. </div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic