Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
Hi,
On Thu, 25 May 2017, Rhonda D'Vine wrote:
> > The problem described here is that if we have Django reverse dependencies
> > in backports (I don't know if we have any), right now they have been
> > tested/validated with Django 1.7.x (stable) or 1.8.x (jessie-backports)
> > and switching to 1.10.x will likely break some of those packages that
> > were relying on deprecated features that got removed in 1.9.x and 1.10.x.
>
> Pardon me, but how would they likely break some of those packages if
> they are expected to work in stretch from where they got backported
> from? I can't follow. Either they are working in stretch with 1.10, or
> not - then they should get fixed in stretch to work with 1.10.
This assumes that they have been kept up-to-date with what's in
testing. If that's the case, then you are right.
> > > If django regularly changes API in such ways it should be considered
> > > before backporting, not sticking at an extra version that doesn't relate
> > > to what we have in testing.
> >
> > So, for you, the rules are more important than the service we provide to
> > our users. For me, it's the opposite.
>
> No, it isn't. Don't twist my words to fit them your interpretation.
How should I interpret “If django regularly changes API in such ways it
should be considered before backporting” then? For me you implied that
we shouldn't have backported Django in the first place.
Thus that sticking to the policy is more important than providing
this LTS version to our users.
> > I'm sorry, but I fail to see how it would have been different. I would
> > have been in front of the same wall, you would not understand why I want
> > to maintain the LTS version in jessie-backports and my use case would not
> > be important enough for you to bend your policy.
>
> So you intentionally chose to break the rules. Are you aware that you
> are digging your hole deeper with that? I appreciate your honesty,
> which must not be easy, but not communicating when you know you are
> breaking or twisting the rules is a definite no-go. Under no
> circumstances can I accept that. It *would* have been different because
> the mess that we are in now could have been avoided, *for our users*.
I still don't see what mess I created for our users. Some users started
to rely on the availability of this backport, yes, but then that's the
reason why I started to maintain it... it's there to be used.
Neil has probably gotten too far by making it an upgrade requirement for
Lava, but that's not my fault. I was not even aware of his doings.
> > I am not a 2-year old kid that will learn a lesson because you
> > kick me with a stick on the fingers. I would have hoped that you
> > could explain what is "messy" in this situation.
>
> If you can't see that then I'm very sorry, multiple different people
> tried to explain it to you.
Please don't play that game, be explicit with me. There are many persons
who commented, from both sides, and I'm not sure which arguments have
weight in your opinion and count as an explanation of what's messy.
Cheers,
PS: BTW I will be away for the week-end, so don't expect answers from me
before Monday.
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Reply to: