Hi,
I think at this point it would help to move the discussion forward, if
we tried to step beyond the specific issue and phrase the revision in
the backporting policy. This will let us, I hope, have a more
principle-based discussion.
If I get it right -- please correct me, James -- it would be something
like this addition:
"In a new domain of functionality, which is considered major and
central, bugs which would have been release blockers if found in time
will be considered as candidates for backporting if found within the
next two LTS versions" -- or even "... if found before use of the new
domain of functionality becomes mainstream" -- or something similar.
I think looking at it from that angle will be more fruitful. I will say
that looking at this principle, thinking about the vicious cycle
mentioned by James, I tend towards accepting his arguments.
We may want to phrase it a different way: Think of such major domains
as "experimental". We did that in the Python3 transition -- we had
"experimental support" from 1.5, and IIRC that "experimental" label
wasn't dropped until 1.8. I doubt we can retroactively declare async
views as still experimental, but we can modify the backporting policy
to say "release-blocker-level bugs in experimental features will be
candidates for backporting as long as the feature is experimental";
and we can set an exception that says "async is still experimental for
backporting considerations", in view of the little use we've seen so
far.
(I can see the argument against the last proposition, that says
"experimental means potentially broken, so it should be less worthy of
backports rather than more"; I disagree, because (a) we do want to
encourage such experimentation, and (b) no, it doesn't really mean
potentially broken, it means the API is not yet covered by the
stability guarantees; we're at more liberty to change things when we
fix)
HTH,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20230101172133.29c41f34.shai%40platonix.com.
