Re: approval for backporting stable releases of [calligra,zabbix] (not in "testing")
Hi!
Thanks for the fruitful discussion so far. Please keep in mind once
more: I don't know anything about calligra and zabbix, my responses are
more in general than package specific.
* Dmitry Smirnov <onlyjob@debian.org> [2015-11-18 06:28:25 CET]:
> 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.
Then this is actually one of our reasons for rejecting the backport:
You no longer use it but want to make it available for users of stable,
out of bounds. That's definitely not what backports is for.
> People who use "testing" presumably know what they are doing. However users
> of "stable" and "backports" may benefit from more conservative updates.
Users of backports benefit from updates that contain newer features for
them. That's the main reason for why backports exist. If you upload
maintenance updates to backports they won't contain newer features, will
they? It's a maintenance update to an LTS version, and thus it should
belong in stable proper. backports is not the place for bug fixes for
packages in stable.
If they add newer features to their LTS version then I'm unsure what
LTS means to them though. Honestly, I don't know what LTS means to them
at all because I don't know the project so I can just go with what I
would understand as being an LTS release.
> 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"?
Like said, that's something you have to discuss with the release team.
Point release updates aren't part of backports. :)
> > 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.
But backports *is* about newer features, and offering newer versions of
packages earlier than the next release. It is about offering users of
stable "that one killer feature" that makes them consider upgrading to
testing as a whole just to get it and with that would lose security
support for the rest of the system. And downgrades aren't supposed to
be supported between releases anyway, and from that perspective,
packages from backports *are* part of the next release already, so
not supporting downgrading from them back to stable shouldn't be any
consideration.
> > 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.
I'm sorry, but having an out of bounds package in backports is no
option for this situation.
> 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?
I don't know what the point release of zabbix LTS 2.2 does contain,
that's for you to tell. I have no clue how big the diff is but you
should be able to produce that. And you could discuss with other teams
that managed to get their LTS updates accepted for stable, both with
respect to how much troubles it is for real, and what their
argumentation line might have been.
> 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 2.4 is good enough I personally don't see any reason to not offer it
through backports if users might want to use it.
> > 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".
So far I am not really convinced about that argument, and the
limitation is there for a fair amount of reasons that I hope you can
understand or at least accept.
> 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.
Hmm, I see QT 5 in stable too? The QT4 vs QT5 argument got me confused
here, and I'm curious: Are there "just" some libraries missing for QT5
which aren't in jessie already, or is the QT5 version in jessie
otherwise unsuitable?
So long,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
Reply to: