Yesterday I produced a fix for the KiCAD packages, and made builds for f33, f34, f35 and rawhide. In f34, it got enough karma to move to "stable". In f33, it is likely to have to sit for a week. The f35 and rawhide builds went straight to stable yesterday.
Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them.
Steve
On Tue, 2021-08-24 at 16:47 -0400, Steven A. Falco wrote:
Yesterday I produced a fix for the KiCAD packages, and made builds for f33, f34, f35 and rawhide. In f34, it got enough karma to move to "stable". In f33, it is likely to have to sit for a week. The f35 and rawhide builds went straight to stable yesterday.
Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them.
If everything's working right, you can't, by policy. You can't push an update with 0 karma stable until the 7 day wait period runs out.
It's not impossible for "the same" update to behave differently on two different releases, due to differences in *other* packages. The new version may work just fine on Fedora 34 but not work on Fedora 33 because some other package isn't new enough, or something.
There are cases where we can know that if it's OK on one it's almost certainly OK on the others too, but it's not really reliably possible to encode that in the policies.
Thanks for the explanation, Adam. I'll let the process play out as it will...
Steve
On 8/24/21 5:02 PM, Adam Williamson wrote:
On Tue, 2021-08-24 at 16:47 -0400, Steven A. Falco wrote:
Yesterday I produced a fix for the KiCAD packages, and made builds for f33, f34, f35 and rawhide. In f34, it got enough karma to move to "stable". In f33, it is likely to have to sit for a week. The f35 and rawhide builds went straight to stable yesterday.
Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them.
If everything's working right, you can't, by policy. You can't push an update with 0 karma stable until the 7 day wait period runs out.
It's not impossible for "the same" update to behave differently on two different releases, due to differences in *other* packages. The new version may work just fine on Fedora 34 but not work on Fedora 33 because some other package isn't new enough, or something.
There are cases where we can know that if it's OK on one it's almost certainly OK on the others too, but it's not really reliably possible to encode that in the policies.
Am 24.08.21 um 22:47 schrieb Steven A. Falco:
Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them.
Also I'd even prefer F33 getting the update a bit later: I assume F33 users are valuing stability over "latest versions and fixes" (otherwise they would have upgraded to F34 already). On the other hand the bug is probably not too bad (otherwise the bug would have been fixed earlier or users would have stopped using the package altogether).
So as a F33 user I'd prefer only getting "rock solid" fixes over newer stuff which might introduce regressions.
just a personal opinion though :-)
Felix
On Wed, Aug 25, 2021 at 11:00 AM Felix Schwarz fschwarz@fedoraproject.org wrote:
Am 24.08.21 um 22:47 schrieb Steven A. Falco:
Should I edit the criteria in f33 so I can mark it stable before the 7
days
elapse, or should I let it wait? It seems weird that one release would
have to
wait longer than the other releases when the fix is identical for all of
them.
Also I'd even prefer F33 getting the update a bit later: I assume F33 users are valuing stability over "latest versions and fixes" (otherwise they would have upgraded to F34 already). On the other hand the bug is probably not too bad (otherwise the bug would have been fixed earlier or users would have stopped using the package altogether).
So as a F33 user I'd prefer only getting "rock solid" fixes over newer stuff which might introduce regressions.
just a personal opinion though :-)
Felix
That isn't what happened in this case though. One of the libraries it depended on was updated, which changed the patch version in the soname (there used to be no soname versioning for that library until now, when they introduced the versioning system). The library loader inside KiCad was searching for the exact soname because of the way the loader works (load the library explicitly and then find the function pointers), but because the soname it was built with didn't exist anymore, it couldn't find it. This led to an error on launching one part of the program, making that part stop working when it was working before the library update. All that was needed to fix this was a rebuild of the package to pick up the new soname - no patches required.
-Ian
On 8/25/21 6:29 AM, Ian McInerney wrote:
On Wed, Aug 25, 2021 at 11:00 AM Felix Schwarz <fschwarz@fedoraproject.org mailto:fschwarz@fedoraproject.org> wrote:
Am 24.08.21 um 22:47 schrieb Steven A. Falco: > Should I edit the criteria in f33 so I can mark it stable before the 7 days > elapse, or should I let it wait? It seems weird that one release would have to > wait longer than the other releases when the fix is identical for all of them. Also I'd even prefer F33 getting the update a bit later: I assume F33 users are valuing stability over "latest versions and fixes" (otherwise they would have upgraded to F34 already). On the other hand the bug is probably not too bad (otherwise the bug would have been fixed earlier or users would have stopped using the package altogether). So as a F33 user I'd prefer only getting "rock solid" fixes over newer stuff which might introduce regressions. just a personal opinion though :-) Felix
That isn't what happened in this case though. One of the libraries it depended on was updated, which changed the patch version in the soname (there used to be no soname versioning for that library until now, when they introduced the versioning system). The library loader inside KiCad was searching for the exact soname because of the way the loader works (load the library explicitly and then find the function pointers), but because the soname it was built with didn't exist anymore, it couldn't find it. This led to an error on launching one part of the program, making that part stop working when it was working before the library update. All that was needed to fix this was a rebuild of the package to pick up the new soname - no patches required.
-Ian
Thanks, Ian. With the help of yourself and others, we've gotten enough +karma that I have now been able to schedule both the f33 and f34 builds for stable. I assume that the next time releng does a push those builds will become GA.
In the next upstream release, the mechanism will change, such that only the major soname number will have to match, and changing that is a much rarer occurrence.
Steve
On Wed, Aug 25, 2021 at 11:59:38AM +0200, Felix Schwarz wrote:
Am 24.08.21 um 22:47 schrieb Steven A. Falco:
Should I edit the criteria in f33 so I can mark it stable before the 7 days elapse, or should I let it wait? It seems weird that one release would have to wait longer than the other releases when the fix is identical for all of them.
Also I'd even prefer F33 getting the update a bit later: I assume F33 users are valuing stability over "latest versions and fixes" (otherwise they would have upgraded to F34 already). On the other hand the bug is probably not too bad (otherwise the bug would have been fixed earlier or users would have stopped using the package altogether).
Yeah, as a packager (and occasional runner of lagging-behind systems) I have the exact same thoughts and preferences.