Re: geos soname bump in F-12 updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/4/12 Devrim GÜNDÜZ <fedora-list@xxxxxxxxxx>:
> It is my bad. I should have noticed it before pushing update...

No worries. I doubt it was maliciously intended.

However, this is the 3rd different issue with basemap in the same week
where another maintainer's actions updating one of the dependency
packages have caused basemap to be unusable.   That sigh was a general
frustration over the whole thing.

One issue was an API change in EPEL when the python-matplotlib package
was updated...which I can't imagine being caught with any sort of
build or updating tooling.

Second issue was the ABI break in numpy in rawhide in F13...shows up
at runtime...simple rebuild fixes it. Again I'm not sure how our build
or update system could have caught it.

Unless we are running post-build tests..and even then the unit test
that tries to test basemap would have to run when numpy or matplotlib
was updated which I think gets a bit complex.  I can surely build that
test...do we have that capability to run them and fail an update based
on their output?

Third issue was this geos bump. And its actually the easiest to catch
because repo closure tests will find it. The repoclosure report caught
it, and I got a bug report from a user.. and Orion caught it.  Triple
notification for the win!.  The only issue here is, can we do a better
job of automatically finding soname situations before they hit users?

And let me ask this question. What do we provide in terms of workflow
tools to help maintainers remember to check the package chain for
other packages that depend on a package that's being prepped for
updates? Beyond simple soname bumps and other things expressed in the
packaging metadata... other breakage like API and ABI breaks that
can't be expressed in packaging metadata will happen. How do we do a
better job trying to catch those?  As a maintainer for niche packages
I certainly can't rely on testers to cover the installed package space
to catch the specific situations I need to test.

We have repoquery on the client yes. Anything else?  What if bodhi
grew some capability to list packages which depend on a package when
you submit it for updating? If bodhi told you that basemap depended on
geos before you pushed the update to stable.. would you have done
something different? Would you have ping'd me or perhap tested basemap
yourself to some extent?  If Bodhi had notified me as a maintainer of
basemap that geos was going into F12 testing or that matplotlib was
being updated in EPEL testing. I _might_ have remembered to test it
myself :->

-jef
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux