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 

> 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]>

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to