Marc Brockschmidt wrote: > Please note that as of now, RC bugs and problematic transitions are our > main concern. There has been progress, but we still need to lower the > number of release critical bugs further. There will be a couple of Bug > Squashing Parties soon, so please consider to join one or more of them. [1] > > We want to ask you to not do disturbing updates of your packages in > unstable without contacting the release team before. If you need a staging > area or simply want to use Debian infrastructure to show newer packages, > you can always upload to experimental, which is nowadays mostly autobuilt. [2]
Probably everyone know one should avoid problematic transitions and disturbing updates of packages, though what looks like a simple change in your package might be a disturbing update and might cause a problematic transition... A simple example would be changing the name of a library package which has a couple of reverse dependencies. This doesn't look that disturbing at all... but has the potential to cause major trouble for testing transition... Another example would be uploading a package which links some transitions together... The first example can cause trouble if the old package is not available anymore (as virtual package or oldlibs for instance) as all packages depending on the library package become instantly uninstallable, you might want to look at [1] for some hints to avoid trouble with this kind of upload. These uninstallables might cause other uninstallables, failures to build and a harder testing migration as all these packages need to be installable again before they can all together transition to testing... The second example looks innocent from a package maintainer's point of view as it might only involve small fixes in packaging or documentation or whatever. Though it can make life of the Release Team quite hard. Without the intention to point fingers, lets look at a real life example, just to show you how things work: Looking at [2] you see the perl transition which involves 60 packages (recursively). If you click on perl you see the list of 60 packages. Looking at these packages you can find out that there are 4 of them which link other transitions with the perl transition: obexftp, subversion and rapidsvn. obexftp links the bluez-libs transition with the perl transition, subversion links the neon transition with the perl transition and rapidsvn and pdl link the wxwidgets2.6 transition with the perl transition. The perl transition is due to the way perl dependencies are handled for the moment: it makes sure the package will be installable as it depends on the most recent perl the package was built with. The bluez-libs transition is actually a transition like the pattern in the first example. This transition involves 14 source packages (13 extra). kdepim links in the gnokii transition which luckily doesn't involve extra packages. The neon transition involves 20 source packages (8 extra), though these 8 don't link other transitions with the neon one. The wxwidgets2.6 transition involves 12 packages (10 extra), though these 10 also don't link other transitions with the wxwidgets2.6 one. So all these packages should enter testing together unless they will still be installable in testing and the version in unstable is not ready to enter testing yet (not old enough, RC bug, not built on all release arches...) To conclude, please try to avoid linking transitions together and try to avoid making packages instantly uninstallable if possible. Cheers Luk [1] http://wiki.debian.org/TransitionBestPractices [2] http://bjorn.haxx.se/debian/stalls.html -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
signature.asc
Description: OpenPGP digital signature
