Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
* Brian May <bam@debian.org> [2017-05-25 09:20:52 CEST]:
> Rhonda D'Vine <rhonda@deb.at> writes:
> > Actually, they would need to do it regardless because of stretch. That
> > is a rather weak argument IMHO. If the depending package comes from
> > stretch it actually has to work with 1.10 now already.
>
> Yes, the work has already been done in unstable.
>
> However if 1.10.x enters backports, then that would mean all these
> updated packages would then have to get rebuilt for backports. This
> additional work is not required if backports stays with Django 1.8.x
binNMUs are no real work.
> I suspect this would mean more packages entering backports.
How so? If there are backports of django packages it sounds almost
they wouldn't really follow the minimum changes, wouldn't those
backports require actually more work to make them work with 1.8 instead
of 1.10?
> Rebuilding packages is for backports is generally trivial, except
> packages in unstable often have dependancies that must be backported
> first. These packages then depend on other packages that must be
> backported first (been there done that). Or work arounds implemented if
> this is not feasible.
That's all reasoning to think about before uploading a package to
backport. I don't see that at all related to the issue at hand.
> > If it's an outside package I'm not so sure if having a backport for a
> > package that changes interface so intensly that it requires a painful
> > lot of work between versions is a wise decision in the first place.
>
> Django 1.8.x versions are bug fixes only. However changing the 1.8 to
> 1.9 or beyond will introduce backward incompatable changes.
I see that, but they aren't maintained within the infrastructure, and
we were always clear on that.
> Hence the desire to keep backports on Django 1.8.x, to avoid these API
> changes.
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.
> Doing so also means increased stability of the software in backports
> that depends on Django - which is important for some people.
Software that depends on django in backports will be instable if its
upgraded to 1.10? If so, that would also mean they are instable in
stretch. Please fix that in a soon stable release.
Given that Scott wrote in 863267 that django upgrades just fine I
suggest the package to be upgraded then. Any upgrade issue should be
carried out in stretch, *not* through backports. I am out of ideas why
we are even discussing on that grounds.
And Raphael - if you would have contacted us beforehand instead of
intentionally do not this could all have been avoided and a useful
discussion could have been had. Don't turn this around that the mess
that we are in now is our fault because you did choose not to
communicate.
I strongly encourage people to engage when they plan to do things out
of the norm. *Before* they do it. Any mess could be avoided through
active communication. The mess only starts when communication is
avoided where it is desperately needed to get everyone involved on
board. I'm extremely disappointed by that choice and would hope that a
lesson was learned. We are open to constructive discussions, but not on
the grounds after harm was done but very much beforehand.
Thanks,
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: