On Monday 16 November 2015 13:51:48 Rhonda D'Vine wrote:
> If the 2.2 LTS updates are maintenance releases similar to postgres it
> might be possible to convince the release team to do updates in stable.
> But I'm not part of the release team, and I don't know your package at
> hand and thus not the amount of changes they do in the 2.2 LTS branch,
> so I can't tell you if that's really possible.
I'm not comfortable asking release team for that because I no longer use 2.2
and therefore I'm unable to vouch for its suitability for "stable".
This is actually one of my reasons for backporting -- I do not want to
replace current version in stable but I want to offer a newer (but not
bleeding edge) version from backports.
People who use "testing" presumably know what they are doing. However users
of "stable" and "backports" may benefit from more conservative updates.
> No, and I didn't say that you need to ship the same LTS branch for
> stretch. But you said you don't want to backport 2.4 because you don't
> consider it an LTS version - thus I read that as you don't consider it
> suitable for stretch.
It is not up to me to decide whether 2.4 is LTS or not. I merely follow
upstream and my intention is to ship upcoming Debian release with LTS-Zabbix,
if possible. Upstream originally declared 2.4 as intermediate (non-LTS)
release before next major release but there were some changes already (like
cancellation of 2.6) and it is uncertain if 3.0 will be released as planned
or if 2.4 will be the only supported version for a time being.
It may happen that Stretch will be released with Zabbix 2.4 if 3.0 won't be
available before freeze. Anyway I'm starting to question why would I want LTS
Zabbix for Debian if I won't be able to upload point releases to "stable"?
> If you consider 2.4 be a useful version for stretch even if it's not an
> LTS version then why not consider it useful for backports?
To avoid pushing major changes on users of "stable". With 2.2 it would be
possible to downgrade back to version in "stable"; with 2.4 downgrade may not
be possible due to changes to database scheme.
I'm just trying to be very careful with upgrades.
> No. If you feel you "need to" be able to ship updated stable/LTS
> zabbix for jessie then there are two options: Keep updating it through
> unstable/testing and get it through testing, or appeal to the release
> team to get it in as regular stable update.
IMHO neither of those options is ideal.
> If the update is needed as you put it the release team might be
> convincable with outlining what those reasons are, and being presented
> the hopefully maintenance only diff between the LTS updates. If the
> release team considers the updates too intrusive then you should maybe
> consider only uploading LTS releases to unstable to not block yourself
> from getting it in to backports.
I am not convinced if I want to update version in "stable". How can I
convince release team? And why go through troubles in first place?
> Why doesn't it make sense to you to upload LTS releases for upcoming
> Debian? I thought that was your plan anyway when the next LTS release
> comes out, that you only want to ship LTS releases with Debian releases?
1) Because there should be another LTS release (its beta is already
available).
2) Because I do not want to include pretty much the same old-LTS Zabbix v2.2
to new Debian release and ignore years of development in 2.4+.
3) Because it would be nice if we can release upcoming Debian with long-
term-supported Zabbix _if possible_. 2.4 is good enough and I'll confirm with
upstream if they will be supporting 2.4 unless 3.0 LTS will be released as
planned.
> If you on the other hand are fine with shipping non LTS releases in an
> upcoming Debian release,
I'm almost convinced that Zabbix-2.4 is the only suitable candidate for
backporting.
> what are we discussing then?
Limitations of backports suite. More specifically the fact that it is not
always possible or feasible to make stable-backports from "testing".
Calligra is a brilliant example of such limitation -- its stable version is
not for Debian "stable" due to large number of changes; the only backporting
candidate is QT4-based therefore not suitable for "testing" and "unstable";
QT5 version is yet-to-be-released and most likely will not be suitable for
backports due to massive changes in dependency libraries.
I wish I could provide Calligra Suite through backports so I suppose it would
be nice to discuss how that would be possible.
--
All the best,
Dmitry Smirnov.
---
If any remedy is tested under controlled scientific conditions and
proved to be effective, it will cease to be alternative and will simply
become medicine. So-called alternative medicine either hasn't been
tested or it has failed its tests.
-- Richard Dawkins, 2007
Attachment:
signature.asc
Description: This is a digitally signed message part.