[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: What does delaying F31 mean for packagers/users?
From:       drago01 <drago01 () gmail ! com>
Date:       2018-11-27 21:55:56
Message-ID: CAMqY-Fe+4uqW-nq7LSunwgPtYLknNmxK3hpVmZeaKCt15DO=Rw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tuesday, November 27, 2018, Owen Taylor <otaylor@redhat.com> wrote:

> On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher <sgallagh@redhat.com>
> wrote:
> > As came up in another part of the earlier thread, I think this is an
> > opportunity for Modularity. For those things like GNOME that want to
> > rev mid-release, if they shipped the 3.34 release as new stream, those
> > that want to move to it will have that option, and those who fear
> > change can remain on the 3.32 release, even if it's not getting
> > support. This would have to be something communicated at release-time
> > of course.
>
> If we want to offer optional GNOME-3.34, a module is probably a better
> alternative to using a copr - which is what we did last time.
> (https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/) But
> we have to recognize that if we create such a module we are
> effectively creating a Fedora 30.1 - because libraries in that module
> will replace system libraries. From the point where we release such a
> module, any RPM-packaged applications that use GNOME libraries will
> have to be tested against *both* F30 and F30+gnome-3-34.
>
> It's also a minimally scalable approach - we wouldn't want to have a
> GNOME 3.34 module and a NetworkManager-1.16 module and support
> arbitrary combinations.
>
> And we'd have to figure out some strategy for not breaking F31 updates
> when you have the desktop:3.34 module enabled.
>
>
>
I don't think modules are useful for non self contained package sets (like
a desktop environment). As you said we might end up having half the distro
in that module.

[Attachment #5 (text/html)]

<br><br>On Tuesday, November 27, 2018, Owen Taylor &lt;<a \
href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>&gt; wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher &lt;<a \
href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt; wrote:<br> &gt; As came \
up in another part of the earlier thread, I think this is an<br> &gt; opportunity for \
Modularity. For those things like GNOME that want to<br> &gt; rev mid-release, if \
they shipped the 3.34 release as new stream, those<br> &gt; that want to move to it \
will have that option, and those who fear<br> &gt; change can remain on the 3.32 \
release, even if it&#39;s not getting<br> &gt; support. This would have to be \
something communicated at release-time<br> &gt; of course.<br>
<br>
If we want to offer optional GNOME-3.34, a module is probably a better<br>
alternative to using a copr - which is what we did last time.<br>
(<a href="https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/" \
target="_blank">https://copr.<wbr>fedorainfracloud.org/coprs/<wbr>rhughes/f20-gnome-3-12/</a>) \
But<br> we have to recognize that if we create such a module we are<br>
effectively creating a Fedora 30.1 - because libraries in that module<br>
will replace system libraries. From the point where we release such a<br>
module, any RPM-packaged applications that use GNOME libraries will<br>
have to be tested against *both* F30 and F30+gnome-3-34.<br>
<br>
It&#39;s also a minimally scalable approach - we wouldn&#39;t want to have a<br>
GNOME 3.34 module and a NetworkManager-1.16 module and support<br>
arbitrary combinations.<br>
<br>
And we&#39;d have to figure out some strategy for not breaking F31 updates<br>
when you have the desktop:3.34 module enabled.<br>
<br><br>
</blockquote><div><br></div><div>I don&#39;t think modules are useful for non self \
contained package sets (like a desktop environment). As you said we might end up \
having half the distro in that \
module.</div><div><br></div><div><br></div><div><br></div><div>  </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://getfedora.org/code-of-conduct.html
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]