Hi Andres, On Friday 29 January 2010 17:38:29 Andres Salomon wrote: > Jan Wagner <waja@cyconet.org> wrote: > > <cite="http://backports.org/dokuwiki/doku.php?id=contribute";>Before > > uploading please think about how useful the package is for stable > > users and if you want to support the package until support for the > > distribution you uploaded ends.</cite> > > > > This doesn't mean, you have to backport every minor change, but you > > should take care for new major releases and of course, fixing > > security bugs until the end of support for the target distribution. > > How is one meant to do this when a new major release adds twice as many > dependencies as the older version? I don't think it's reasonable to > expect people to fight an uphill battle like that. Security support, > bugfixes, sure.. but new major versions? One could argue that it > should be done on an as-needed basis. the problem is, if you provide a backport, your users using a "moving target". With a new version, there may get new (security-)bugs introduced. How do you wan't to fix this bugs? You can provide a new version with just fixing this specific bugs, but I guess this will lead you into troubles, as you have to maintain this specific package version (branch) for your own. Bugfixes (and new versions) are provided through sid/testing by package maintainers, if you want to participate from their work, you need to backport their versions ... this results into keeping up with their development. You mentioned that dependencies may lead you into a dependency-hell, cause the requirements may raise .... this is a "risk" you have to think about, when uploading your first package to bpo. In the past I had the pleasure ( :o)) to backport php5 to sarge and the php maintainers decided to enable lfs in their packages, while sarge didn't support this ... so I had to revert this changes for every backport and yes, it did suck ... but I decided to upload the package to bpo and with this I also decided to maintain it through the lifetime of sarge. I know, that is just the "white" side and there are enought example of the "dark" side of maintaining backports ... but there are also greyscales. My intention of the my "rant" was just, to avoid to leave unmainted versions on backports.org, which is not, what the users expect. If you want to have an impression, have a look on the older[1] and the outdated[2] packages. With kind regards, Jan. [1] http://backports.deb.at/lenny-backports/older.html [2] http://backports.deb.at/lenny-backports/outdated.html -- Never write mail to <waja@spamfalle.info>, you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ ------END GEEK CODE BLOCK------
Attachment:
signature.asc
Description: This is a digitally signed message part.