Re: approval for backporting stable releases of [calligra,zabbix] (not in "testing")
Hey :)
* Dmitry Smirnov <onlyjob@debian.org> [2015-11-14 01:23:42 CET]:
> On Friday 13 November 2015 15:28:47 Rhonda D'Vine wrote:
> > 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.
When you then open a blocking RC bug stretch won't release with the
package. So you should now already think about if the 2.4 version is
one you'd want to support for a release, otherwise you might end up with
no package in stretch.
> > > 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".
staged for the next release. Thus it's to some degree expected to
upload stuff to unstable that is acceptable for stretch, even during
development cycles. That's what I meant. Maintaining packages for the
next-to-be stable release.
> 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.
Erm, well, sure it is. If there will be the next LTS release it's the
best place to maintain it. If there are releases in between that you
don't deem to be useful for a stable release then there is experimental
for testing the versions in between, and when the next LTS version
appears replace the current one that is in unstable.
> We need an intermediate backports suite to allow that or maybe relaxed
> release policy so I could upload point release to current "stable".
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.
> > 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??
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.
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?
> > 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.
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.
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.
> 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.
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?
If you on the other hand are fine with shipping non LTS releases in an
upcoming Debian release, what are we discussing then?
Have fun,
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: