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
On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor otaylor@redhat.com 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.
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 <sgallagh@redhat.com wrote:
On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor otaylor@redhat.com 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-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
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.
On 27. 11. 18 16:49, Stephen Gallagher wrote:
On Tue, Nov 27, 2018 at 10:40 AM Owen Taylor otaylor@redhat.com 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.
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.
Owen
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.
On Tue, Nov 27, 2018 at 10:56 PM drago01 drago01@gmail.com wrote:
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.
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-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
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 otaylor@redhat.com 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-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
On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor otaylor@redhat.com 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-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
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.
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 rishi.is@lostca.se 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-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
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 lruzicka@redhat.com 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 rishi.is@lostca.se 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-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
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. https://redhat.com/trusted
On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor otaylor@redhat.com 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.
On Tue, Nov 27, 2018 at 3:39 PM Owen Taylor otaylor@redhat.com 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
On Thu, 29 Nov 2018 12:15:52 +0000, 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?
On Thu, Nov 29, 2018 at 2:58 PM Gerald Henriksen ghenriks@gmail.com wrote:
On Thu, 29 Nov 2018 12:15:52 +0000, 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.
On Thu, Nov 29, 2018 at 12:15:52PM +0000, 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.)
On Thu, Nov 29, 2018 at 11:10 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Nov 29, 2018 at 12:15:52PM +0000, 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
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?
On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia nkadel@gmail.com 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 :).
On Sat, Dec 1, 2018 at 10:24 AM Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia nkadel@gmail.com 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.
* 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@lists.stg.fedoraproject.org
-
Brian (bex) Exelbierd -
Debarshi Ray -
drago01 -
Fabio Valentini -
Florian Weimer -
Gerald Henriksen -
Igor Gnatenko -
Kamil Paral -
Leigh Scott -
Lukas Ruzicka -
Matthew Miller -
Miro Hrončok -
Nico Kadel-Garcia -
Owen Taylor -
Peter Robinson -
Stephen Gallagher -
Stephen John Smoogen