During the oneiric development cycle we had syncs of library packages from experimental, introducing new sonames, and changing APIs in a way that other packages need to be ported to the new API, or if the port isn't trivial, need to be removed at the end of the cycle. This doesn't add much benefit to the distribution, compared to the work to clean up the distribution and forward port packages which otherwise don't require this kind of work (assuming the package is synced from Debian). Options to handle such syncs could be
- Keep the don't care attitude, and just remove packages at the end of the cycle (although removal of non-leaf packages comes with a price too, and isn't seen as user friendly). - Get approval for a library sync from experimental, listing the rdepends, API changes, and estimate the effort to complete this library transition. - Don't sync packages from experimental. There were at least three libraries synced from experimental which required work up into the beta phase (I don't have numbers for the "successful" syncs and merges from experimental): - dcmtk, synced from experimental during the end of the natty cycle, requested MIR (bug 702026). Left alone until the end of the oneiric cycle, then turned out that the library wasn't even needed. Caused some grief in bug 779170. Unsure if the sync review would be a help, because in the end it was uploaded to unstable and the corresponding debian report is still open (debian 623145). - libevent, synced from experimental on 2011-07-08, the sync was requested in bug 796187. A large number of packages still had to be converted from libevent1 to libevent2, and finally we had to package libevent1 to not remove other packages. Issues were discussed in other distros too: http://comments.gmane.org/gmane.linux.redhat.fedora.devel/148007 - opal, synced on 2011-05-02, with unresolvable build dependencies, needed another version update and new versions of three packages during feature freeze (bug 836915). afaics, no discussion for the sync. All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). All three cases would benefit from a review at the time of the sync (the first case for natty only), and from my point of view the cost for this review is still less than getting the issues resolved after feature freeze. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
