Re: What does delaying F31 mean for packagers/users?

[Florian Weimer]

* Owen Taylor:

> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?

Has a definite decision been made here?  Where can we track the process
for that, so that we can adjust our plans as necessary?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Nico Kadel-Garcia]

On Sat, Dec 1, 2018 at 10:24 AM Stephen John Smoogen  wrote:
>
> On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia  wrote:
> >
> > Folks, hi.
> >
> > Planning for a specific delay for a specific reason is one thing. But
> > the same design philosophy reasons that apply to Fedora 31 have
> > applied to almost every other Fedora releases, and changing to an
> > annual cycle is going to drive people *nuts* when updates for their
> > particular critical components get delayed up to 18 months because
> > they missed the *current* release and have to wait for the next major
> > release for the dependencies to be built up. This especially plays out
> > with tools that use many distinct small modules by different authors,
> > such as Python. Have you *looked* at what happens if python modules
> > are even slightly out of date, and the dependency chain that "pip
> > instlal" brings in?
> >
>
> I think the thinking is that you would make these modules and would
> just make them available during a release. You put a 12 month lifetime
> on each module set you are running and put out updated ones when you
> are ready to do so. The modules get retired over time and you are
> running your own 'release'. Of course this works better if packagers
> team up together and own the module versus trying to do it all
> themselves.. which is also assumed but may not have been realized by
> the packagers yet :).

The problem is maintaining the dependency chain. I tried to do this
for "airflow" under Fedora 28, and it became painful to try to
build chain. I used to do it for RHEL and CentOS 7 for previous
releases. But getting the dependencies resolved for very specific
python module requirements, and the older and newer versions of
critical modules, just got out of hand. I've found it much easier to
work from Fedora at or near the bleeding edge of all infrastructure
components than to backport mixed versions of individual components
for compatibility.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Stephen John Smoogen]

On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia  wrote:
>
> Folks, hi.
>
> Planning for a specific delay for a specific reason is one thing. But
> the same design philosophy reasons that apply to Fedora 31 have
> applied to almost every other Fedora releases, and changing to an
> annual cycle is going to drive people *nuts* when updates for their
> particular critical components get delayed up to 18 months because
> they missed the *current* release and have to wait for the next major
> release for the dependencies to be built up. This especially plays out
> with tools that use many distinct small modules by different authors,
> such as Python. Have you *looked* at what happens if python modules
> are even slightly out of date, and the dependency chain that "pip
> instlal" brings in?
>

I think the thinking is that you would make these modules and would
just make them available during a release. You put a 12 month lifetime
on each module set you are running and put out updated ones when you
are ready to do so. The modules get retired over time and you are
running your own 'release'. Of course this works better if packagers
team up together and own the module versus trying to do it all
themselves.. which is also assumed but may not have been realized by
the packagers yet :).



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Nico Kadel-Garcia]

Folks, hi.

Planning for a specific delay for a specific reason is one thing. But
the same design philosophy reasons that apply to Fedora 31 have
applied to almost every other Fedora releases, and changing to an
annual cycle is going to drive people *nuts* when updates for their
particular critical components get delayed up to 18 months because
they missed the *current* release and have to wait for the next major
release for the dependencies to be built up. This especially plays out
with tools that use many distinct small modules by different authors,
such as Python. Have you *looked* at what happens if python modules
are even slightly out of date, and the dependency chain that "pip
instlal" brings in?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Peter Robinson]

On Thu, Nov 29, 2018 at 11:10 PM Matthew Miller
 wrote:
>
> On Thu, Nov 29, 2018 at 12:15:52PM +, Peter Robinson wrote:
> > This is basically the problem I have with the work we're doing in IoT.
> > The basically will make me re-evaluate if IoT is now worth doing at
> > all in Fedora or whether I am now better off focusing my efforts
> > elsewhere.
>
> Is there something specific you're concerned about, or is it a general
> sense that there's likely to be something that you want updated? Since IoT
> is ostree-based, is it possible we could solve this by including packages
> from a newer module of whatever is problematic -- or even rawhide builds?
> (That is, you say that modularity isn't capable of soving this, but I'm not
> sure why not.)

As an example, and this is one thing, if I need to build the kernel
with some latest security feature in gcc to get some of the KSPP
functionality I can't do that with modularity.

Because so much of what IoT is doing is in a very small package set
and is focused on a combination of removing as much as possible while
tightening things down this not something that is achievable with
modularity.

The apps in containers are certainly able to make use of that, and I'm
in particular the various versions of nodejs I'm sure will be used in
IoT as there's a lot if IoT things that make use of nodejs.

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

Re: What does delaying F31 mean for packagers/users?

[Matthew Miller]

On Thu, Nov 29, 2018 at 12:15:52PM +, Peter Robinson wrote:
> This is basically the problem I have with the work we're doing in IoT.
> The basically will make me re-evaluate if IoT is now worth doing at
> all in Fedora or whether I am now better off focusing my efforts
> elsewhere.

Is there something specific you're concerned about, or is it a general
sense that there's likely to be something that you want updated? Since IoT
is ostree-based, is it possible we could solve this by including packages
from a newer module of whatever is problematic -- or even rawhide builds?
(That is, you say that modularity isn't capable of soving this, but I'm not
sure why not.)



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Leigh Scott]

Damn!, I thought this was a done deal and booked my six month holiday :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Peter Robinson]

On Thu, Nov 29, 2018 at 2:58 PM Gerald Henriksen  wrote:
>
> On Thu, 29 Nov 2018 12:15:52 +, you wrote:
>
> >From an IoT perspective where we're looking at some features around
> >security that could be cross component dependent
> >(toolchain/kernel/userspace) to be unable to consume for possibly an
> >18 month window, yes we rebase kernels but we need to rebase other
> >components and build against those, in a stable release is a complete
> >and utter disaster.
>
> Is it specific to the F30/31 timeframe, or is it something that could
> be alleviated by instead delaying to a F31/32 delay?
>
> In other words, if the delay is necessary is there a better choice of
> time to do it that would help to minimize the disruption to the
> various Fedora communities?

At the moment I don't see that changing at all from an IoT perspective.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Gerald Henriksen]

On Thu, 29 Nov 2018 12:15:52 +, you wrote:

>From an IoT perspective where we're looking at some features around
>security that could be cross component dependent
>(toolchain/kernel/userspace) to be unable to consume for possibly an
>18 month window, yes we rebase kernels but we need to rebase other
>components and build against those, in a stable release is a complete
>and utter disaster. 

Is it specific to the F30/31 timeframe, or is it something that could
be alleviated by instead delaying to a F31/32 delay?

In other words, if the delay is necessary is there a better choice of
time to do it that would help to minimize the disruption to the
various Fedora communities?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Peter Robinson]

On Tue, Nov 27, 2018 at 3:39 PM Owen Taylor  wrote:
>
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
>
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.

This is basically the problem I have with the work we're doing in IoT.
The basically will make me re-evaluate if IoT is now worth doing at
all in Fedora or whether I am now better off focusing my efforts
elsewhere.

Going back to the F-20/F21 cycle we had major issues with the year gap
in releases for ARM64. We were waiting on toolchain enhancements that
landed about around a week (exact time-frames allude me) after Fedora
20 branched, which meant ultimately we had to wait 18 months from
branch to a stable release for end users to actually be able to
consume these enhancements, there was another one, I don't remember
exact component details, that due to upstream timing as well basically
meant it was longer than that more than that to consume. For reference
Fedora 20 branched on 2013-08-20 [1] and Fedora 21 was released on
2014-12-09.

From an IoT perspective where we're looking at some features around
security that could be cross component dependent
(toolchain/kernel/userspace) to be unable to consume for possibly an
18 month window, yes we rebase kernels but we need to rebase other
components and build against those, in a stable release is a complete
and utter disaster. Unfortunately this is not a problem that
modularity is capable of solving and IoT doesn't have the cycles to
even begin to consider dealing with that at the lower levels. Sure, it
would be fine for IoT app stacks, such as noodejs, in a container but
not below that.

Peter

[1] https://fedoraproject.org/wiki/Releases/20/Schedule
[2] https://en.wikipedia.org/wiki/Fedora_(operating_system)#Releases
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Sorry about the two lines of the letter that do not fit much into the
concept:

So, I like the idea of one major and one minor release, if we want to stay
conservative and do not want to go the rolling updates way. And, in case we
want to stay super conservative and we do not want change anything, I think
Debarshi's approach would work just fine.

Thanks for understanding,
Lukas

On Wed, Nov 28, 2018 at 10:20 AM Lukas Ruzicka  wrote:

> Hello,
> I do not think that we should be taking the path towards Gnome being in
> one module. This is not, what "modular" means. In my understanding, modules
> should be smaller, rather independent units, that will help solve some user
> cases, but definitely not upgrading half of the system.
> Also, if we should provide updated ISOs, as one of the ideas was, why not
> do a normal release instead? It does not have to be packed with all new
> stuff, fixes and minor updates could be just fine ... and the new Gnome.
> I think there are several strategies, where we could go next, for example:
>
>
>- Release regularly to get the new Gnome, but do not push for so many
>new features in Fedora 31, if we need more time to fix things.
>- Adopt the Major / Minor approach and make the autumn release a minor
>one, so that Fedora 31 becomes a minor release.
>- Adopt the "rolling updates" strategy for Fedora and introduce a
>Fedora LTS that would be here for people who do not want rolling updates.
>- Just skip the release with all the consequences it will have ... no
>updates to new versions
>
> Let us not make Fedora messy by creating huge modules with dependencies in
> the whole system. It is too risky to go that way, because modularity is
> just at its beginning and has issues we must solve first. For example, what
> happens if you have a module stream installed and all the dependencies in a
> working system and you want to change from one stream to another? As far as
> I know, nobody guarantees at the moment, that the dependencies will not
> break. Can you image how putting Gnome into a module will affect the system
> when this is not solved?
>
> I'd rather see Fedora stay a bit older for a period of time than to see it
> breaking and leaving people angry.
>
> Take care,
> Lukas
>
>
>
>
> I quite like the idea of one major and one minor release in a year.
>
> I think that Debarshi's approach would work nicely
>
> On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:
>
>> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
>> > One of the key parts of making a decision to delay/skip F31 is
>> > figuring out, ahead of the decision, what the expected experience is
>> > for users and packagers. Does F30 have normal stability, or do we try
>> > to keep users happy by moving things forward with ad-hoc updates and
>> > cross-our-fingers and hope nothing breaks?
>> >
>> > I tend to think about this in terms of GNOME - would we rebase to
>> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
>> > pieces of software where similar considerations apply: container
>> > tools, cockpit, NetworkManager, etc.
>> >
>> > And if we did do updates like that, would we consider respinning media
>> > and making a "F30.1"?
>>
>> Umm... can't we treat it the same as the Fedora 20/21 situation?
>> Skipping a GNOME release can be a bit painful for the upstream GNOME
>> community, which is overwhelmingly tilted towards Fedora, but it's not
>> the end of the world either. After all, I don't think the longer
>> Fedora 21 cycle had any negative long-term effect on that group at
>> all. :)
>>
>> The Desktop Team could more aggressively backport bug-fixes to GNOME
>> 3.34 upstream, and if needed backport selected features to Fedora 30
>> downstream. We have done this during the usual six month Fedora
>> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
>> have done this for RHEL too, so there's some precedence in this area.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@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
>>
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Hello,
I do not think that we should be taking the path towards Gnome being in one
module. This is not, what "modular" means. In my understanding, modules
should be smaller, rather independent units, that will help solve some user
cases, but definitely not upgrading half of the system.
Also, if we should provide updated ISOs, as one of the ideas was, why not
do a normal release instead? It does not have to be packed with all new
stuff, fixes and minor updates could be just fine ... and the new Gnome.
I think there are several strategies, where we could go next, for example:


   - Release regularly to get the new Gnome, but do not push for so many
   new features in Fedora 31, if we need more time to fix things.
   - Adopt the Major / Minor approach and make the autumn release a minor
   one, so that Fedora 31 becomes a minor release.
   - Adopt the "rolling updates" strategy for Fedora and introduce a Fedora
   LTS that would be here for people who do not want rolling updates.
   - Just skip the release with all the consequences it will have ... no
   updates to new versions

Let us not make Fedora messy by creating huge modules with dependencies in
the whole system. It is too risky to go that way, because modularity is
just at its beginning and has issues we must solve first. For example, what
happens if you have a module stream installed and all the dependencies in a
working system and you want to change from one stream to another? As far as
I know, nobody guarantees at the moment, that the dependencies will not
break. Can you image how putting Gnome into a module will affect the system
when this is not solved?

I'd rather see Fedora stay a bit older for a period of time than to see it
breaking and leaving people angry.

Take care,
Lukas




I quite like the idea of one major and one minor release in a year.

I think that Debarshi's approach would work nicely

On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:

> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
> > One of the key parts of making a decision to delay/skip F31 is
> > figuring out, ahead of the decision, what the expected experience is
> > for users and packagers. Does F30 have normal stability, or do we try
> > to keep users happy by moving things forward with ad-hoc updates and
> > cross-our-fingers and hope nothing breaks?
> >
> > I tend to think about this in terms of GNOME - would we rebase to
> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> > pieces of software where similar considerations apply: container
> > tools, cockpit, NetworkManager, etc.
> >
> > And if we did do updates like that, would we consider respinning media
> > and making a "F30.1"?
>
> Umm... can't we treat it the same as the Fedora 20/21 situation?
> Skipping a GNOME release can be a bit painful for the upstream GNOME
> community, which is overwhelmingly tilted towards Fedora, but it's not
> the end of the world either. After all, I don't think the longer
> Fedora 21 cycle had any negative long-term effect on that group at
> all. :)
>
> The Desktop Team could more aggressively backport bug-fixes to GNOME
> 3.34 upstream, and if needed backport selected features to Fedora 30
> downstream. We have done this during the usual six month Fedora
> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
> have done this for RHEL too, so there's some precedence in this area.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Kamil Paral]

On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor  wrote:

> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?
>

What's the difference between re-spinning install media and doing a proper
F31 release? At least from QA point of view, I see very little difference.
We would need RCs, we would need a freeze, blocker bug meetings, the whole
process. And of course some of our tooling might not account for a special
F30.1 release-but-not-really, so it might end up more work than a standard
release. I can't speak for releng, but I'd expect a similar story.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Debarshi Ray]

On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
> 
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
> 
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?

Umm... can't we treat it the same as the Fedora 20/21 situation?
Skipping a GNOME release can be a bit painful for the upstream GNOME
community, which is overwhelmingly tilted towards Fedora, but it's not
the end of the world either. After all, I don't think the longer
Fedora 21 cycle had any negative long-term effect on that group at
all. :)

The Desktop Team could more aggressively backport bug-fixes to GNOME
3.34 upstream, and if needed backport selected features to Fedora 30
downstream. We have done this during the usual six month Fedora
releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
have done this for RHEL too, so there's some precedence in this area.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Brian (bex) Exelbierd]

On Tue, Nov 27, 2018 at 10:56 PM drago01  wrote:
>
>
>
> On Tuesday, November 27, 2018, Owen Taylor  wrote:
>>
>> On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher  
>> 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.

I'm not sure this is a bad thing.  My understanding is that modules
are designed to allow for this in a transparent way to to the "half"
of the system that isn't in the module.  I realize this can create a
huge build/test matrix, but putting down some boundaries can allow us
to reduce the matrix to a manageable size (with automation we need
anyway) and not block someone who has a reason to need somethign
different from either building their own bits to fill in parts of the
matrix or possibly federating with our build system to fill in gaps
for themselves and their community.

regards,

bex

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



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[drago01]

On Tuesday, November 27, 2018, Owen Taylor  wrote:

> On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher 
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Owen Taylor]

On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher  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.

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

Re: What does delaying F31 mean for packagers/users?

[Fabio Valentini]

On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor  wrote:
>
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
>
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
>
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?
>
> Owen

Yes, I could get behind this idea - it sounds like a tick-tock model,
with yearly major releases (tick), and one smaller maintenance upgrade
inbetween (tock).
That would basically result in fedora 2019.0 and 2019.1 releases,
possibly with an automatic upgrade from .0 to .1 (since it's a small
update).
This approach would also ~double the lifetime of a major fedora
release (if we want to keep two active major releases plus rawhide),
or reduce the number of active fedora releases by one (if we keep the
overall lifetime the same).

Fabio

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

Re: What does delaying F31 mean for packagers/users?

[Miro Hrončok]

On 27. 11. 18 16:49, Stephen Gallagher wrote:

On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor  wrote:


One of the key parts of making a decision to delay/skip F31 is
figuring out, ahead of the decision, what the expected experience is
for users and packagers. Does F30 have normal stability, or do we try
to keep users happy by moving things forward with ad-hoc updates and
cross-our-fingers and hope nothing breaks?

I tend to think about this in terms of GNOME - would we rebase to
GNOME 3.34 in the middle of F30 or not? But there's a lot of other
pieces of software where similar considerations apply: container
tools, cockpit, NetworkManager, etc.

And if we did do updates like that, would we consider respinning media
and making a "F30.1"?



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.


I'd argue that this adds unnecessary work to packagers.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Matthew Miller]

On Tue, Nov 27, 2018 at 10:49:55AM -0500, Stephen Gallagher 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.

And something like Silverblue could choose to pull in the updated module by
default, even.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Igor Gnatenko]

Unfortunately due to some reasons I can't or don't want to modularize some
packages.

What should I do in this case?

On Tue, Nov 27, 2018, 16:59 Stephen Gallagher  On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor  wrote:
> >
> > One of the key parts of making a decision to delay/skip F31 is
> > figuring out, ahead of the decision, what the expected experience is
> > for users and packagers. Does F30 have normal stability, or do we try
> > to keep users happy by moving things forward with ad-hoc updates and
> > cross-our-fingers and hope nothing breaks?
> >
> > I tend to think about this in terms of GNOME - would we rebase to
> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> > pieces of software where similar considerations apply: container
> > tools, cockpit, NetworkManager, etc.
> >
> > And if we did do updates like that, would we consider respinning media
> > and making a "F30.1"?
>
>
> 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.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Igor Gnatenko]

That's exactly question I had in mind, thanks for bringing it up!

Personally, if we won't be able to push breaking changes in F30, then
after some time people will not be happy about outdated software and
will leave distribution I think.

For maintainers it would probably mean that F29 won't get any updates
very soon and they would have to switch to rawhide.
On Tue, Nov 27, 2018 at 4:49 PM Owen Taylor  wrote:
>
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
>
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
>
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?
>
> Owen
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: What does delaying F31 mean for packagers/users?

[Stephen Gallagher]

On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor  wrote:
>
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
>
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
>
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?


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