Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
On Thursday, May 25, 2017 08:57:13 PM Rhonda D'Vine wrote:
> * Scott Kitterman <debian@kitterman.com> [2017-05-25 14:51:28 CEST]:
> > On May 25, 2017 8:05:50 AM EDT, Rhonda D'Vine <rhonda@deb.at> wrote:
> > >* Scott Kitterman <debian@kitterman.com> [2017-05-25 13:45:35 CEST]:
> > >> If we care about this user code (and I think we should), then Django
> > >> 1.10 in backports is a non-starter. If we don't care about user code
> > >> then the python-django package isn't something I would ever
> > >
> > >recommend.
> > >
> > > If the packagers cared about user code (and I think they should), then
> > >
> > >we would have Django 1.8 in stretch?
> >
> > Possibly true, but unless you have a time machine, irrelevant.
> >
> > I'm not a python-django maintainer so whatever mistakes they may have
> > have made, it wasn't me who did it.
>
> I'm also in no way interested who did what or not. I don't hold
> grudges against people, unless they repeatedly rub me personally wrongly
> or don't think there is a need to acknowledge the mistakes done. I
> simply don't care for who did mistakes, they happen. The way how one
> reacts to a mistake that's being pointed out is though something that
> can de/escalate a situation quite quickly and easily.
>
> I rejected the package in the light of that we always want security
> fixes to go through unstable/testing to also assure that those releases
> are fixed. Backports are called Backports for a reason. It's even
> implied in the name. I wasn't aware of any reasoning behind it; and I
> consider it highly unfair to expect us to just accept it without any
> communication at all. That's not the standard way, and that's very well
> known.
>
> I (personally, not double-checked with Alexander) would be willing to
> accept the package for this very moment in the light of the security
> fixes. But that in no way doesn't mean that that can/will/should
> continue like that. That doesn't close the discussion for me in any
> sense, that exception is clearly to not delay the security fixes
Thanks. I think that will help this move forward.
> further. The discussion is not affected in any way by that, because:
> > We should be smarter for Buster, but for Jessie and Stretch, we're
> > stuck. Please let's work together to resolve this and not fall back
> > on "they screwed up, so it's not my problem".
>
> No. This can't be a "should", this is definitely a must. I request a
> clear plan how to avoid this to happen again. So far what I heard is
> "this is where we are and this is the only way we see how to fix it"
> without any hint of understanding of that that situation is highly
> inconvenient, and that leads me to the impression that if we can't find
> an agreement that this was clearly the wrong way to do it that we will
> have this very discussion again once we get into buster freeze. It was
> pointed out that the release schedules of django don't align well with
> the Debian schedules - but that doesn't mean we should throw everything
> over board and just do whatever we like. We should find a way to
> approach that in a useful way; and that very much includes users of our
> stable releases, and as convenient as it might be seen to have backports
> being there as a gap closer, that's the wrong approach and doesn't help
> users of our stable releases, at all.
>
> So as long as I don't have the impression that the users of our stable
> releases are taken into consideration I don't think we can move forward
> with this in any way. And as long as there is the impression that we
> can't communicate about such things then don't blame us for the lack of
> communication that comes from your end. I can't be more clear than
> that, it isn't our fault that it was chosen to *not* communicate that
> beforehand, and I'm not willing to suck it up like that and ignore that
> intentional lack of communication.
>
> So long for now,
> Rhonda
I believe if you are willing to allow the jessie-backports updates of python-
django 1.8.X for security fixes (unless upstream violates their own policy,
that's all there will be), we can definitely come up with a solution that
avoids the need to do this kind of exception in the future and we'll have a
good path forward.
I believe it will take a bit of time for the python-django maintainers to
figure out the best plan, but I don't think it's at all urgent until after
stretch releases, so we have a few days to sort out that part of the plan.
I'm all for communication. You may have noticed I wrote a lot of emails on
this topic since I became aware of the disconnect between the backports team
and the python-django maintainers. Obviously it will take more communication
to get this issue completely resolved, but I think your message is a great
basis for working towards getting this all figured out.
Scott K
Reply to: