3:47 p.m.
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
4:02 p.m.
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
6:30 p.m.
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.
4:59 a.m.
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
5:29 a.m.
On Wed, Aug 25, 2021 at 11:00 AM Felix Schwarz <fschwarz(a)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
10:10 a.m.
On 8/25/21 6:29 AM, Ian McInerney wrote:
On Wed, Aug 25, 2021 at 11:00 AM Felix Schwarz
<fschwarz(a)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
11:18 a.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1027
days inactive
1028
days old
6 comments
5 participants
participants (5)
-
Adam Williamson -
Felix Schwarz -
Ian McInerney -
Matthew Miller -
Steven A. Falco