On Monday 01 February 2010 15:54:23 Stéphane Glondu wrote: > Jan Wagner a écrit : > > 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. > > My "rant" would be about your decision to backport a recent version of > dh-ocaml without contacting the original maintainers. > > As said elsewhere, keeping an "old" version of dh-ocaml in the backports > was done *on purpose*, because versions >= 0.9 of dh-ocaml introduce > very intrusive changes in the packaging workflow/toolchain not suitable > for the backports. For example, I backported an "old" version of camlbz2 > *on purpose* because newer versions introduce changes only in the > packages not relevant for a backport. > > With your backport of dh-ocaml 0.9.3, you've just complicated the > backports of OCaml packages from now on. Okay ... lets summarize what we have concluded in our discussion: * My dh-ocaml upload was rather suboptimal. From my POV, it would be nice if such a behavior (raising build-deps for transioning) is documented in a prominent place, for example README.source in all involved packages. This would life making easier for people outside the OCalm Group to understand the work(flow), for example when bughunting (on BSP or where ever) and even backporting. This should result into making your life easier too. :) * We want high quality packages on backports.org (backports.d.o in the future) There seems to be two problems. At one side, we have packages, which are just uploaded on bpo and nobody cares about it (on regular basis). On the other side, for some packages it is not sufficiant/optimal/whatever, to upload a backported version from latest testing package version. How to solve the problem? As we all want high quality packages, we need a tool to track down problems in the packages provided at backports, even more if we have backports.d.o in place. The security-tracker[1] and Rhondas "Diffs between lenny-backports and squeeze"[2] are starting points. To really track down pending bugs for backports, it would be neat to have a tool providing an overview, what bugs for backports are open, which are solved in testing. With such a tool, it would be more clear, which packages have problems and which not (even if they are older than in testing). Anyways ... even if we know, the backported version has problems, which needs to be solved and we can't migrate the version from testing back. Who will backport the isolated fixes back to the backport version (Did anybody things like thats yet?)? With the number of bugs, this will also become a pitty. It will result into creating an additional branch or unfixed packages. As long as we don't have such a tool, I'm personly trying to keep up with my backported packages with testing, as long as possible. Yes, I won't touch backports of other people in the future, without pinging them. With kind regards, Jan. [1] http://security-tracker.debian.org/tracker/status/release/stable-backports [2] http://backports.deb.at/lenny-backports/ -- 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.