Re: updating roundcube backports to 1.2.x?
Hi!
* Dominic Hargreaves <dom@earth.li> [2017-05-16 13:21:19 CEST]:
> But since I did upload RT 4.2 to jessie-backports I understand I have
> taken on a responsibility for keeping it in good shape. If the scale
> of an upgrade to 4.4 means that that is not practical, or it's too
> risky, then I consider I have a responsibility to maintain it to the
> best of my ability as I would any other branch, for example by backporting
> (strictly only from testing/unstable) security fixes or regression fixes.
> If I felt unable to do that I would request help, or request removal.
Thing is, it creates an out-of-bounds backport that is solely
maintained in backports. There is no other testbed for it, no
transition delay in which people using it in unstable might be able to
find serious bugs and thus the users of the backport will be your
testers, and have all the responsibility put on their shoulders. Also,
it hinders other people to step in and help out because it requires
significant more overhead to track that, in case you lost interest.
Those are amongst the main reasons why we were always quite clear that
we don't want that to happen - and yes, it happens every now and then.
Yes, of course people can't look into the future and forsee what
additional dependencies might get added by upstream and thus make
backporting things more stressful. I can totally relate to that. But
at that point we still need to decide how to move forward. We expect
somewhat useful quality from backports and maintainability, and if we
get to that at a certain point anymore removing software from backports
instead of keeping it artificially alive might be a useful decision,
even though I'm aware that that leaves former users of said backports at
a difficult stage.
> > If it is considered too much work then that might be a good sign for
> > the future to rather avoid backporting it at all in the first place ...
>
> I would be sad if I was unable to backport future updates to RT 4.4
> to stretch-backports, because in my mind backports is an incredibly
> valuable resource for Debian users for which there is no practical
> alternative, save for setting up an entirely parallel infrastructure.
> And for that reason I am hugely grateful to those who do maintain
> backports.debian.org.
Actually request-tracker4 in jessie-backports is also pretty aged.
Let's take that specific example: At the point when the decision was
made to update rt4 in unstable from 4.2 to 4.4 it was considered in a
stage that is ready for a stable release. That's the main part of what
gets into testing in the long run. 4.4 is in testing, and thus we
expect the backport to also carry that version instead of sticking with
the old, because after all, it is deemed as release ready.
If you *also* want to keep 4.2 around you should carry out that effort
for stretch too, not only for backports. That is, having 4.2 and 4.4
side-by-side installable.
It took me personally a lot of effort to make e.g. the wesnoth releases
side-by-side installable and thus be able to support multiple releases
that way. It's something that libary maintainers do at times quite
regularly. What I don't see happening is having the effort to maintain
packages side-by-side only for backports. If you want to support both,
please do so for the regular release, not only on the shoulders of
backports. This leaves the backport in a stage that only you yourself
are able to tackle, and this is what we try to avoid.
> Again, I may be lacking roundcube specifics, but if there are major
> blockers (dependency hell or a large impact to users in upgrading) then
> I don't think it's fair to characterise a commitment from the maintainers
> to apply security fixes to the backports as 'unmaintained'.
You are right to some degree, but part of the maintenance expectations
we have is keeping it up to date and *not* maintain it as a seperate
package that has nothing to do anymore with what's going on in
testing/unstable from which the backport is originally done from. We
always were extremely clear on that; and actually it it's not fair to
have that ignored and actively worked against.
> For myself, I would be interested to hear more about the practical
> problems that you might forsee from allowing either of these two
> packages to exist in this sort of maintenance mode.
Backports is no place to maintain packages. It's a place to backport
packages to, the maintenance has to happen in unstable/testing. And I'm
a fair bit annoyed that this has to be repeatedly pointed out, getting
ignored again and again with no communication and then being addressed
with ignorance again. :/
Said that, I totally welcome the offer of Christian to help out with
the roundcube situation. Thanks for that! Let's concentrate on how to
improve the situation.
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: