On Fri, 13 Nov 2015, Dmitry Smirnov wrote: > Thanks for quick reply, Alexander. > > On Thursday 12 November 2015 19:59:08 Alexander Wirt wrote: > > I am sorry, but we already made stated several times that we don't want to > > support such configurations. Backports is for packages from testing. > > I'd argue with that a little. :) > > 1) You probably remember that Wheezy did not have Zabbix which did not make > it into oldstable release before freeze. Then release team recommended to > maintain Zabbix in backports so I did and Wheezy had Zabbix only form > backports. Why am I reminding about that? Because it is the same 2.2.x LTS > branch that is in Jessie and which I want to upload to backports. Releaseteam is not in a position to decide that. And to be honest I am shocked that that was the case. If you would have asked, you would have earned the same answer and a removal. > > 2) I suppose our reasoning for maintaining Zabbix exclusively in backports > was not because it is "in testing" but to make it available for Wheezy > through backports. Therefore "in testing" is a rule of strong quality > assurance but not the goal or purpose of a backport. I tend to disagree, I think the whole process of unstable->testing migration is a relevant part of backports as I see it. > 3) Testing have 2.4 which is not LTS and IMHO therefore is not suitable for > backports. 2.4 is an intermediate release between current and next LTS > releases. I could ask release team for permission to update Zabbix in > "stable" but they are likely to use the same argument "never been in > testing". Also _I am_ not comfortable replacing version in stable -- that's > why I want to provide alternative from backports. > > Here I have dilemma -- on one hand in order to maintain LTS release in > backports I could never upload 2.4 to testing; or give up on shipping LTS > branch for Jessie. Both options are not great. > > 3) I believe "not in testing" rule is mostly to ensure smooth upgrade path. > For both packages what I want to upload to "jessie-backports" is << than > version in "testing". No. Its also that we want versions in backports that are used outside of backports too. We really don't want to backports carries stuff that isn't available elsewhere. And to be honest, given the experience of the last years we think should handle those cases even more strict as they are at the moment. > > > > You are looking for something like stable update or a private repo. > > or backports-sloppy? We don't have a backports-sloppy for Jessie, right? > > I do not believe in private repositories. Every significant effort should be > made public. Packaging Calligra took more than 6 weeks of effort and I'd like > to share results. There are users who want stable Zabbix and Calligra [1]. > Besides performance problem in Libreoffice forced me into looking for > alternative office suite so IMHO backport of Calligra addresses a real > problem in Jessie that backports of LibreOffice did not fix. > > I think it is just not fair to block Calligra backport on the ground that it > can't be in "testing" -- as I've said, upload to testing is impossible for > technical reasons -- Calligra simply FTBFS there due to completed QT4-->QT5 > transitions of its dependency libraries. > > I always thought that "testing" is a staging area for next release while > backports do not have to always derive from "testing" (only whenever > possible). At least that what my common sense tells me... > > Please let me know if I've missed a Debian facility allowing to deliver > conservative upstream stable releases to users of current "stable" without > replacing software that were frozen in stable. I thought that backports is a > perfect facility for that... such ja facility is missing at the moment, but backports is not meaned as such.
Attachment:
signature.asc
Description: PGP signature