[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: approval for backporting stable releases of [calligra,zabbix] (not in "testing")



    Hi,

* Dmitry Smirnov <onlyjob@debian.org> [2015-11-12 22:23:36 CET]:
> 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.

 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".

 Does this clear up the misunderstanding?  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 :))

 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. :)

> 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.

 If you would get it removed you might reconsider to upload the
intermediate packages to experimental instead of to unstable to not
destroy your maintenance ability of the package for the stretch release,
and only when the next LTS release appears that you consider suitable
for a stable release upload that then to unstable.  That way you can
offer people that want to use the intermediate versions for testing
purposes to pull them from experimental while still not getting into
troubles with maintaining the versions that you deem suitable for a
stable release.

> 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.

 Backports though should never be a disconnected branch, sorry about
that.

> 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".

 With uploading a non LTS branch to unstable you already gave up
shipping an LTS branch for stretch.  At least for the time being.

> 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".

 That's only one reason for the rule.

> > 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?

 See above.  sloppy is for packages from release+2, and given that we
don't have jessie+2 in the archive yet, jessie-backports-sloppy won't
get created.

> 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.

> 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.

 Sure.  But please not with an out-of-branch version, that won't happen
in backports.

> 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?

> 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...

 The source for packages to get backported is always testing.  The
exceptions are granted on anachronistic basis, that is, when there is
good reason to get it earlier into backports than the testing transition
happens (like, security updates, bigger library transition delays or
things like that), and with outlining that reason to us.  But we won't
grant exeptions for out-of-branch versions, we always were pretty clear
about that (and yes, Vagrant, we'll update the docs to make that more
clear ;)).

> 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...

 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.

 Hope this makes some things a bit more clear and gives options on how
this can be solved. :)

 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: