Weekly Edition
Return to the Distributions page
| |||||||||||||
The openSUSE Release process (SUSE openSUSE blog)
Michal Hrusecky and Jos Poortvliet team up to describe the openSUSE release process on the SUSE openSUSE blog. They cover the nuts and bolts of the software side, as well as the marketing activity preparing for a release. "There are several bots that check packages [sent] to Factory. First is factory-auto, which does some basic checks regarding you spec file, rpmlint warnings and similar. If you pass this quick test, it’s time for more thorough testing. A bot named factory-repo-checker tries to actually install your package in a testing environment to make sure it is possible and it also looks for possible file conflicts, so you wouldn’t overwrite somebody [else's] package. Last check before a package gets in front of the review team is legal-auto. This one checks the licence (did it change? is it a new package?) and if needed calls in our legal team to take a look at the package. The final step is manual review by members of review team which will try to spot mistakes that automatic checks overlook."
(Log in to post comments)
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 2:10 UTC (Sun) by torquay (guest, #92428) [Link] From the above blog entry we get a link to Keeping Factory in shape, which states:
The GTK developers may very well be in their right to remove deprecated functions. However, why on earth is openSUSE linking new GTK with old/unmaintained software that relies on old GTK features? Surely gtk v2 and v3 can live side-by-side? This brings up another point. Instead of discovering breakage as a side-product of building software, why not have deliberate and explicit API and ABI regression tests? Reasoning: much of open source software is done on a volunteer basis, and the upstream developers may not have the time/energy/knowledge to write (or maintain) their own regression tests. Wouldn't it be more useful for a distribution to provide such regression tests, rather than simply packaging upstream software? This will also help keep certain developers honest, by exposing how much unnecessary API breakage they cause.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 8:11 UTC (Sun) by boudewijn (subscriber, #14185) [Link]
I doubt they are building GTK2 applications against GTK3 -- going from GTK2 to GTK3 seems to be a major porting effort that, for instance GIMP has already spent over 3 years on. Porting from GTK2 to GTK3 is now also discouraged by the GTK maintainers.
No, I think that this is more about existing GKT3 applications that break when a new version of GTK3 is released.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 12:45 UTC (Sun) by torquay (guest, #92428) [Link] This would imply that for GTK applications that break, the GTK2 to GTK3 conversion was half-done. Or is the GTK3 API just unstable ?
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 14:16 UTC (Sun) by boudewijn (subscriber, #14185) [Link]
For what I understood, the latter is the problem.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 2, 2013 9:50 UTC (Mon) by ovitters (subscriber, #27950) [Link]
Obviously the GTK API is not unstable. Suggest to refrain from commenting if you really have no idea. There are enough people on LWN who do know specifics, just say you do not know if you do not know.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 2, 2013 9:53 UTC (Mon) by ovitters (subscriber, #27950) [Link]
What happens is that applications can request different things:
1. Disallow any deprecated APIs 2. Disallow any deprecated APIs up to version X.Y
#1 is nice for Git. #2 is acceptable for a release tarball as that won't cause any extra APIs in a newer GTK+ version to be deprecated. Unfortunately for a while only #1 was possible, and this was put into tarballs (even though it should not have). So when you request "no deprecated APIs" and a new GTK+ version deprecates a new API, stuff will break.
This does not mean that GTK+ API is unstable, this means you're doing #1 in a release tarball, while at most #2 should be done.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 2, 2013 10:12 UTC (Mon) by torquay (guest, #92428) [Link] I'm not sure I understand the above. Why would a new GTK+ version deprecate a new API ? I'm assuming that if an application is linked against GTK 3.8, it will work with GTK 3.10, as long as it doesn't use deprecated (which by default implies old) API. Or is there another level of API, marked as experimental, which is not yet solidified ?
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 2, 2013 22:46 UTC (Mon) by nix (subscriber, #2304) [Link]
He means that if a Gtk version newly deprecates some existing API, anything using -DG_DISABLE_DEPRECATED will break.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 2, 2013 13:28 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
Is this handy information documented anywhere? I've certainly never come across this advice before. The docs are really my main issue with GTK. They give good explanations of the API, but when looking for how to actually *use* some of them, I'm off hunting a repository for code which might use it.
Also, there was an article linked from the comments here a while ago about using the GDK lock to execute GUI calls in a non-GUI thread, but that has been deprecated for g_idle_add for which I have to write umpteen thousand callback functions. My files are already 3000 lines long; writing a function and custom structure to pass as user_data is at least 13 lines (in the style ofnthe rest of the codebase). Now, it makes *sense* to use g_idle_add, but the amount of code it takes is crazy (to me).
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 4, 2013 10:17 UTC (Wed) by nye (guest, #51576) [Link]
>a new GTK+ version deprecates a new API
>This does not mean that GTK+ API is unstable
Constantly deprecating APIs sounds an awful lot like API instability to me.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 4, 2013 17:14 UTC (Wed) by nix (subscriber, #2304) [Link]
I'd only call it true instability if the APIs were removed. (This is a matter of semantics and degrees of annoyance, though.)
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 5, 2013 18:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I'd call that ABI stability. GTK is good at that, I'll grant it. However, when trying to keep up-to-date and still keep the minimum version low, you end up with lots of #if GTK_VERSION_CHECK() calls to avoid deprecation warnings.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 11:08 UTC (Sun) by dark (subscriber, #8483) [Link] lintian (Debian package checking tool) has such tests, though they work with specific lists of known-deprectated symbols. It can go through each package's binaries and emit a warning if they link against any of those symbols. Then it can put the results on a webpage :)Building something like that for rpm repositories wouldn't be that hard.
The openSUSE Release process (SUSE openSUSE blog) Posted Sep 1, 2013 14:47 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
rpmlint exists for a long time
API and ABI regression tests Posted Sep 1, 2013 16:44 UTC (Sun) by RedDwarf (subscriber, #89472) [Link]
You mean something like http://upstream-tracker.org/?
The Linux Foundation has been working on this for a few years already:
API and ABI regression tests Posted Sep 2, 2013 6:30 UTC (Mon) by niner (subscriber, #26151) [Link]
Of course now we have to wonder what that spike in 2012 was :)
|
|||||||||||||