On Friday 13 November 2015 15:28:47 Rhonda D'Vine wrote:
> Actually backports if for packages from the release+1. The phrase
> "from testing" is mostly from a time when we only had one stable
> supported releases. I think it should be more clear since we have the
> -sloppy branches too which are a pocket for packages "from release+2".
Makes sense.
> Does this clear up the misunderstanding?
I think so.
> Btw., speaking of zabbix in
> wheezy-backports, it's a bit behind from what's in jessie, is there a
> specific reason? (just curious, while we are at the topic :))
Usual reasons: lack of time, motivation, funding and other priorities.
Moreover I'm not sure if that minor update worth the effort...
> Your wording of "maintain Zabbix in backports" is just as misleading.
> From what I can see it's maintained through jessie and was then
> backported to wheezy-backports, not maintained in backports disconnected
> seperately? That's absolutely fine and how it should be. :)
Exactly. Thanks for correction.
> > 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.
>
> Then let me ask this: What's your approach when stretch will get
> released? Will you ask for removal for zabbix 2.4 because you don't
> consider it suitable for a stable release? Keep in mind: backports is
> for stable releases.
Let's not confuse "stable" and "suitable for release". I'll think about it
when the time comes. 2.4 is "stable" (I use it in production) but it is not
"LTS". I'll probably ask upstream and in worst case scenario block open an RC
bug to prevent migration to "testing".
2.2 is "stable" and "LTS" that's why I want(ed) it in backports.
> Backports though should never be a disconnected branch, sorry about
> that.
Thanks for making it clear.
> > 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.
>
> You have it the wrong way around. If you want to maintain LTS releases
> you should do that in unstable/testing, not in backports. Backports is
> not a place to "maintain" packages, the place to maintain them is
> unstable/testing and then get offered through backports, too. Emphasis
> on "too".
Sorry but I disagree. "testing"/"unstable" is where packages are _staged_.
It makes no sense to "maintain" packages for "stable" in "testing".
The problem is that we stop maintaining packages in "stable" (except for
absolutely necessary fixes). "Testing" moved on to become staging area for
next Debian release therefore "testing" is not suitable to maintain LTS
releases for backporting.
We need an intermediate backports suite to allow that or maybe relaxed
release policy so I could upload point release to current "stable".
> With uploading a non LTS branch to unstable you already gave up
> shipping an LTS branch for stretch. At least for the time being.
Hold on. There were never intention to ship the same LTS branch as Jessie in
Stretch. Upstream already changed support policy for 2.4 (new point release
was published just few days ago). New release of 2.4 is a good candidate for
Stretch unless upstream release new LTS version. Do we have to go into
details here??
> > 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].
> Then please get stable zabbix and calligra into testing instead having
> versions there you don't deem to be suitable for stable.
Stable Zabbix is already in "testing" and stable Calligra can not be in
testing because it is QT4 while "testing" moved on to QT5.
> > 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.
>
> calligra has the same version in unstable as in jessie anyway?
Except that at the moment it is utterly broken in "unstable" and not even
builds.
> The source for packages to get backported is always testing.
Understood, thanks.
> Yes. But you don't maintain those conservative upstream stable
> releases anymore, you chose to settle to maintain a non-stable upstream
> release in unstable. That was your own choice - and my suggestion is to
> rethink that approach and fix it.
My approach is not broken. We (Debian) need to be able to ship updated
stable/LTS Zabbix 2.2 for Jessie at the same time while "testing" is moved to
new release 2.4+. Therefore I think we need a new "disconnected" backports
suite.
What you are saying makes no sense because in order to support "LTS" releases
in "backports" I should give up on packaging new releases for upcoming
Debian?!? Arguably upcoming Debian release is equally (if not more) important
than current one.
> Hope this makes some things a bit more clear and gives options on how
> this can be solved. :)
It certainly did make things more clear. Thank you.
--
Cheers,
Dmitry Smirnov.
---
The happy do not believe in miracles.
-- Goethe
Attachment:
signature.asc
Description: This is a digitally signed message part.