Re: updating roundcube backports to 1.2.x?
On Wed, May 03, 2017 at 10:39:35AM +0200, Rhonda D'Vine wrote:
> * Guilhem Moulin <guilhem@guilhem.org> [2017-04-11 18:07:09 CEST]:
> > When I last checked this last autumn, backporting all dependencies was
> > too much work for us.
>
> I'm a bit disappointed to read that. We really expect people to take
> this into account and not stick to a version at some point and never
> update it anymore. It becomes an out-of-bounds maintenance of a package
> which we are very unhappy about and always were very clear about when it
> was brought up.
I am not sure if there is roundcube-specific context that I'm missing here,
but I do want to respond to this general point, since I can well see it
applying to packages I maintain, such as RT.
RT has a major release every 2-3 years, and at the same time introduces
minor new functionality into its bugfix releases. This means that on the
one hand, during the lifetime of a bpo series (such as jessie) a major
new version might enter testing. But the reason people might want a
backport is equally likely because of a minor feature enhancement that
was applied during a series. For example right now jessie has something
based on 4.2.8, jessie-backports has something based on 4.2.13 and
stretch has something based on 4.4.1.
>From my work packaging 4.4.x I know that trying to update the jessie
backport will be a lot of work and risk that it's not clear anyone
would want (were I running a production server using RT 4.2.x from
jessie-backports, I would really not want it to suddenly be upgraded
to RT 4.4, for example).
Perhaps that's simply a sign that backports is not suitable for this
type of package; but it seems to me that this sort of situation could
arise with any package which is backported. Package maintainers are not
fortune-tellers and complex new dependencies to backport arise for a
number of reasons not under the control of the maintainer.
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.
> 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.
> I'm a bit uncertain on what to suggest to move forward here to get
> things straightened out again.
On Tue, May 16, 2017 at 07:01:45AM +0200, Rhonda D'Vine wrote:
> May I get a response to how the people who feel roundcube should stay
> in backports see the issue? Actually a silence doesn't move us forward
> here, and I consider removing roundcube from backports because it feels
> unmaintained if there is unwillingness to update it to the version from
> testing.
>
> I will have to remove it in two week's time if I can't get any further
> response to avoid having unmaintained packages in backports. And yes,
> just putting the security patches onto the backport feels a fair bit
> unmaintained to me/us.
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'.
Of course you are quite right to expect some sort of response to your
previous mails and I encourage the roundcube maintainers to do so.
I do realise that I am pushing the boundaries of the 'contribution'
rules here, and I will ultimately defer to the backports maintainers
on these matters. But I hope that discussing these nuances can result
in a better understanding of what different users need from backports,
and how/if they can be accommodated.
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.
Best wishes,
Dominic.
Reply to: