Hi,
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Any comments/advice are highly appreciated.
Thanks, Phil
On 14 March 2016 at 11:47, Phil Sutter psutter@redhat.com wrote:
Hi,
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Does a new release change the user facing 'API' in a way that might not be backwards compatible to any existing scripting of the iproute2 suite of commands?
If existing scripting is still expected to work I'd say carry out version updates as and when the kernel maintenance team update kernel in the distribution.
On Mon, Mar 14, 2016 at 12:21:33PM +0000, James Hogarth wrote:
On 14 March 2016 at 11:47, Phil Sutter psutter@redhat.com wrote:
Hi,
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Does a new release change the user facing 'API' in a way that might not be backwards compatible to any existing scripting of the iproute2 suite of commands?
No, upstream iproute2 is very careful to not break existing scripts. Internal communication between iproute2 and kernel is treated equally, so a newer iproute2 should never cause problems when used on an older kernel (and vice versa, if I'm not mistaken).
If existing scripting is still expected to work I'd say carry out version updates as and when the kernel maintenance team update kernel in the distribution.
While this certainly makes sense, I start to wonder what Fedora's understanding of 'stability' really is if it seems to not cover the packages (including kernel) it distributes. Does it cover only anything else, like e.g. installation routine, default settings or components used? Apologies if I'm asking trivial questions here. I'm not a native Fedora user and therefore lack experience in these aspects.
Thanks, Phil
On Mon, Mar 14, 2016 at 01:36:38PM +0100, Phil Sutter wrote:
On Mon, Mar 14, 2016 at 12:21:33PM +0000, James Hogarth wrote:
On 14 March 2016 at 11:47, Phil Sutter psutter@redhat.com wrote:
Hi,
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Does a new release change the user facing 'API' in a way that might not be backwards compatible to any existing scripting of the iproute2 suite of commands?
No, upstream iproute2 is very careful to not break existing scripts. Internal communication between iproute2 and kernel is treated equally, so a newer iproute2 should never cause problems when used on an older kernel (and vice versa, if I'm not mistaken).
If existing scripting is still expected to work I'd say carry out version updates as and when the kernel maintenance team update kernel in the distribution.
While this certainly makes sense, I start to wonder what Fedora's understanding of 'stability' really is if it seems to not cover the packages (including kernel) it distributes. Does it cover only anything else, like e.g. installation routine, default settings or components used? Apologies if I'm asking trivial questions here. I'm not a native Fedora user and therefore lack experience in these aspects.
Things that were working at release should continue to keep working. So backwards compatible updates are allowed.
(Backwards compatible means that both inter-package dependencies and user visible APIs are not changed in an incompatible way. So it's OK to add some functionality, but it's not OK to remove functionality, and it's not OK to introduce significant changes which would break users' scripts or compiled programs. Also big changes to the GUIs or default settings would be frowned upon.)
Zbyszek
On Mon, Mar 14, 2016 at 02:03:40PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 14, 2016 at 01:36:38PM +0100, Phil Sutter wrote:
On Mon, Mar 14, 2016 at 12:21:33PM +0000, James Hogarth wrote:
On 14 March 2016 at 11:47, Phil Sutter psutter@redhat.com wrote:
Hi,
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Does a new release change the user facing 'API' in a way that might not be backwards compatible to any existing scripting of the iproute2 suite of commands?
No, upstream iproute2 is very careful to not break existing scripts. Internal communication between iproute2 and kernel is treated equally, so a newer iproute2 should never cause problems when used on an older kernel (and vice versa, if I'm not mistaken).
If existing scripting is still expected to work I'd say carry out version updates as and when the kernel maintenance team update kernel in the distribution.
While this certainly makes sense, I start to wonder what Fedora's understanding of 'stability' really is if it seems to not cover the packages (including kernel) it distributes. Does it cover only anything else, like e.g. installation routine, default settings or components used? Apologies if I'm asking trivial questions here. I'm not a native Fedora user and therefore lack experience in these aspects.
Things that were working at release should continue to keep working. So backwards compatible updates are allowed.
(Backwards compatible means that both inter-package dependencies and user visible APIs are not changed in an incompatible way. So it's OK to add some functionality, but it's not OK to remove functionality, and it's not OK to introduce significant changes which would break users' scripts or compiled programs. Also big changes to the GUIs or default settings would be frowned upon.)
Thanks for the explanation, although I honestly don't see how that could come to unison with the kernel updates applied to stable versions. Any new version could break existing functionality (although not intended), so that "should" seems to be key.
Anyway, since Fedora is obviously OK with shipping new kernel versions in stable releases, it will surely be with the same in iproute, too.
Thanks, Phil
On 2016-03-14, Phil Sutter psutter@redhat.com wrote:
Thanks for the explanation, although I honestly don't see how that could come to unison with the kernel updates applied to stable versions. Any new version could break existing functionality (although not intended), so that "should" seems to be key.
Yes. And iproute is not an exception. I remember a new iproute stopped displaying IP addresses. And the bug was there for 14 days until I fixed it.
-- Petr
On Mon, Mar 14, 2016 at 03:11:50PM +0000, Petr Pisar wrote:
On 2016-03-14, Phil Sutter psutter@redhat.com wrote:
Thanks for the explanation, although I honestly don't see how that could come to unison with the kernel updates applied to stable versions. Any new version could break existing functionality (although not intended), so that "should" seems to be key.
Yes. And iproute is not an exception. I remember a new iproute stopped displaying IP addresses. And the bug was there for 14 days until I fixed it.
Thanks Petr for your input. You seem to be the first one who understands my concerns with "rebases" (as Fedora seems to call it) in stable releases.
I really wish this topic wasn't as controversial as it appears to be. Personall, I don't really care what Fedora's policy really is and I'm fine following whatever it states. But the mere fact that it seems to allow for interpretation to a point where it contradicts itself is not only a bad sign, it most importantly for me makes it hard to follow.
Thanks, Phil
On Mon, 14 Mar 2016 16:27:42 +0100 Phil Sutter psutter@redhat.com wrote:
On Mon, Mar 14, 2016 at 03:11:50PM +0000, Petr Pisar wrote:
On 2016-03-14, Phil Sutter psutter@redhat.com wrote:
Thanks for the explanation, although I honestly don't see how that could come to unison with the kernel updates applied to stable versions. Any new version could break existing functionality (although not intended), so that "should" seems to be key.
Yes. And iproute is not an exception. I remember a new iproute stopped displaying IP addresses. And the bug was there for 14 days until I fixed it.
Thanks Petr for your input. You seem to be the first one who understands my concerns with "rebases" (as Fedora seems to call it) in stable releases.
well, if you are referring to the kernel, thats kind of a special case: https://fedoraproject.org/wiki/KernelRebases and has a exception to the normal updates policy.
I really wish this topic wasn't as controversial as it appears to be. Personall, I don't really care what Fedora's policy really is and I'm fine following whatever it states. But the mere fact that it seems to allow for interpretation to a point where it contradicts itself is not only a bad sign, it most importantly for me makes it hard to follow.
I'm not sure I see the contradiction. The kernel has an exception here (for all the reasons listed on the above wiki page)
kevin
On Mon, Mar 14, 2016 at 01:07:11PM -0600, Kevin Fenzi wrote:
On Mon, 14 Mar 2016 16:27:42 +0100 Phil Sutter psutter@redhat.com wrote:
On Mon, Mar 14, 2016 at 03:11:50PM +0000, Petr Pisar wrote:
On 2016-03-14, Phil Sutter psutter@redhat.com wrote:
Thanks for the explanation, although I honestly don't see how that could come to unison with the kernel updates applied to stable versions. Any new version could break existing functionality (although not intended), so that "should" seems to be key.
Yes. And iproute is not an exception. I remember a new iproute stopped displaying IP addresses. And the bug was there for 14 days until I fixed it.
Thanks Petr for your input. You seem to be the first one who understands my concerns with "rebases" (as Fedora seems to call it) in stable releases.
well, if you are referring to the kernel, thats kind of a special case: https://fedoraproject.org/wiki/KernelRebases and has a exception to the normal updates policy.
Yes, I was always just referring to the kernel package, since that and the iproute package are so closely related. Thanks for pointing me at this wiki page, it explains a lot!
Summarizing for myself, Fedora kernels are not stable (strictly speaking). Just jumping from one stable to the next one tries to go in that direction, but there's no guarantee a feature that worked in e.g. v4.3.5 will still work in v4.4.1. So this is merely a compromise between what is desired and what is achievable with the given manpower.
I really wish this topic wasn't as controversial as it appears to be. Personall, I don't really care what Fedora's policy really is and I'm fine following whatever it states. But the mere fact that it seems to allow for interpretation to a point where it contradicts itself is not only a bad sign, it most importantly for me makes it hard to follow.
I'm not sure I see the contradiction. The kernel has an exception here (for all the reasons listed on the above wiki page)
Sure, whether it counts as contradiction is debatable. In my opinion the mere fact that there is an exception to the rule (as the wiki page stated above clearly shows) serves as proof. But that's just nitpicking anyway.
So I will stick to my former plan of not rebasing iproute in stable releases (unless there's good reason) but become open for feature requests if there is valid need for it, a backport is feasible and it doesn't interfere with core functionality. ACK?
Thanks, Phil
On 2016-03-14 21:42, Phil Sutter wrote:
...
So I will stick to my former plan of not rebasing iproute in stable releases (unless there's good reason) but become open for feature requests if there is valid need for it, a backport is feasible and it doesn't interfere with core functionality. ACK?
Or both (at the price of additional cycles) - in addition to rebase-on-release for the main collection, (might be even without the selective post-release feature back-porting part), a semi-official COPR [1] repo in sync with the current kernel, to be available (for instance) to the dedicated sysadmins, who support bigger Fedora environments, like these in some universities.
I think that recently more and more maintainers of key packages in Fedora also start to follow this (Main-conservative + COPR-latest) delivery scheme in favor of their users/testers with special interests.
Kind Regards, Alek
[1] https://copr.fedorainfracloud.org/coprs/psutter/iproute/
On Mon, 14 Mar 2016 20:42:24 +0100 Phil Sutter psutter@redhat.com wrote: ...snip...
So I will stick to my former plan of not rebasing iproute in stable releases (unless there's good reason) but become open for feature requests if there is valid need for it, a backport is feasible and it doesn't interfere with core functionality. ACK?
That sounds fine to me.
kevin
On Wed, Mar 16, 2016 at 10:34:46AM -0600, Kevin Fenzi wrote:
On Mon, 14 Mar 2016 20:42:24 +0100 Phil Sutter psutter@redhat.com wrote: ...snip...
So I will stick to my former plan of not rebasing iproute in stable releases (unless there's good reason) but become open for feature requests if there is valid need for it, a backport is feasible and it doesn't interfere with core functionality. ACK?
That sounds fine to me.
Cool, thanks!
Cheers, Phil
On Mon, 2016-03-14 at 13:36 +0100, Phil Sutter wrote:
While this certainly makes sense, I start to wonder what Fedora's understanding of 'stability' really is if it seems to not cover the packages (including kernel) it distributes. Does it cover only anything else, like e.g. installation routine, default settings or components used? Apologies if I'm asking trivial questions here. I'm not a native Fedora user and therefore lack experience in these aspects.
The policy is here:
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases
Package maintainers have a lot of leeway as to how to interpret it. If you think an update is risky, you *probably* shouldn't do it. Otherwise, just avoid doing updates "too often."
Michael
Hi,
On Mon, Mar 14, 2016 at 12:47:25PM +0100, Phil Sutter wrote:
So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system?
Any comments/advice are highly appreciated.
I have been asked by various people why I don't update iproute in stable releases to match the shipped kernel version and then had a longer brainstorming with Lubomir about how to limit the involved risks.
My plan is to indeed do the updates, but I will adjust karma thresholds to very conservative values for them. I'm thinking about having a stable threshold of 10 and and unstable one of -1 to enforce a longer review time and have the process fail early in case problems occur.
Please drop me a note if you have strong feelings against this.
Cheers, Phil