Hi, Tuesday 15 July 2008, Peter Eisentraut rašė: > > cons: > > -you need to wait until package is in testing to backport it > > That might not be a bad thing, because it ensures that the packages that > you backport actually fit together and are synchronized and have had a > minimal amount of public testing. Such a big thing as kde4libs might be held out of testing due to various library transitions which are not important for stable release. Also, whole KDE usually does not migrate to testing at once, tracking which packages can be uploaded will cause headaches or introduce delay. It is also not a good idea to ship some KDE parts at newer version while other parts are still old. To sum up, backports.org is good for small packages but its rules, regulations and restrictions are inconvenient for full blown DEs like KDE.
The last but not least, when waiting for testing migration you miss "release hype". > In fact, even if you choose not to use backports.org, > someone else might end up doing backports.org backports anyway, because they > prefer that infrastructure. Such divergence can be avoided Actually, I would welcome people to do this. backports.org rules are stict. Maybe even when all KDE 4.1.x packages migrate to testing, they can be re- uploaded to backports.org from kde4.debian.net mirror. Reuploading is not a big deal, getting packages ready is. -- Modestas Vainius <[EMAIL PROTECTED]>
Description: This is a digitally signed message part.