Hello,
Just for the record, we spent a good time discussion this change (to bring
> inheritance of Admin Actions in line with Python’s expected inheritance
> rules). We reviewed the entire history of the feature. We explored an
> alternative approach, which would have maintained BC. We put the discussion
> to the mailing list, where further people reviewed it, and we came to a
> decision, as a group, without any objections being raised.
That's good and reassuring news; if so, that's precisely another occurrence
of "those reasons really need to be very good, and spelled out and
explained". Most Django users will never see farther than the release
notes, so if abrupt in-places changes occur without a rationale behind, it
*appears* reckless (whetever really happened in the background). If release
notes are considered too long already, wouldn't html tooltips/collapsibles
be useful, so that one may know more about the rational behind changes?
Tech debt is a very real thing. Keeping it under control is vital to the
> pace of improvement and updates for any project, large, middling or small.
> Any project requires maintanence at minimum, just like owning a car or
> house. If you buy a car and run it every day for five years, only filling
> up the gas tank and adding a splash of oil now and then, you don't have
> any excuse to be upset at the mechanic or manufacturer for the size of the
> repair bill when things start breaking. At least with software, its alot
> easier to get fixes out than with hardware. You make a persuasive argument
> and have great passion, but the overall goal of enabling out of date and
> unsupported releases to remain around longer than they should be makes me
> feel really uncomfortable. A spftware project is not buy once and forget,
> neither is a car. And your package seems to encourage that lax practice to
> a level that I would be highly resistant at working at a company if I
> couldn't persuade management to prioritize keeping up to date and tech debt
> at a manageable level.
>
We agree on the necessity of updating code, and indeed DCP was never meant
to encourage slacking but to solve external dependency conflicts. The
latter - and the additional costs involved in solving them - are precisely
used by management to refrain from upgrading codebases.
As we're getting to the end of useful arguments here, I'd like to ask you
> to step back for a minute and take a calm look at what you're writing.
> Imagine you were receiving such messages rather than sending them. Would
> you want to spend more time collaborating with the person addressing you
> that way and to receive more such messages? Perhaps this is another reason
> why you aren't getting as much support as you'd hope.
>
My initial article, as well as most of this ML discussion, is not small
feature/bugfix request, but a rant on the whole deprecation process. The
aim is to raise awarenesss, to shake minds, to push points as deep as
possible, and to not let any falsehood or diversion slip by. As thus, it
uses all kinds of strong words, of emphases, of rhetorical figures, of
denounciations, to deliver the argumentation. I guess a rant will always
look aggressive, even if it only states the most scientific facts.
So I'm sorry if it sounded insulting, but personally I don't mind facing
adamant insistence, blunt statements, criticisms of any current state of
affairs (whatever the amount of effort one might have put into getting
there), and heated discussions, as long as they don't turn into ad hominem
attacks; in the excepts that you pointed out, I was mainly stating my frank
opinion on the (visibly incomplete) evidence that I was shown, and I would
only have sounded hypocritical by masking the seriousness these issues have
for me. Maybe some feel that Django as already having admirable commitment
regarding API stability, alas some other languages and frameworks have set
the bar much higher (farther than semantic versioning), and *they* are to
be used as references (although too extended compatibility is considered
harmful by some here).
Surely some of my words could have been better chosen ("punishing" shall be
understood as "putting at a disadvantage", and "little version" as "minor
version"), my bad, like some of yours ("throwing your toys" sounds
condescending, though I couldn't care less); but I feel that politeness
euphemisms and tone policing destroy the productiveness of crucial
controversies like this one, instead of helping them. I'd rather be called
names, but not see already-debunked untruths reappear in the conversation
("current behavior [...] *can't be fixed* without a hard compatibility
break", "*always* take the time to create deprecation paths"...); this
intellectual scrambling is what makes *me* stomach-sick, much more than old
unmaintained packages.
For example, Luke was open to amending the deprecation policy to better
> reflect reality. You should have suggested some concrete changes, erring on
> the side of caution. Instead you chose to repeat the same argument, except
> more agressively. This doesn't get us any closer to a documentation patch.
> In fact this reduces the likelihood that someone will choose to spend time
> writing that patch.
>
Imho I was not rambling, I was reformulating and pushing the issue farther
to try to understand what was really going on; and it proved useful because
Carlton Gibson, Tim Graham and Adam Johnson eventually answered my
questions on this famous "Admin Actions" change process .
Thus my final analysis on it is that none of the promises made in "API
Stability" doc are true anymore, that's why I propose its clearing (the
other "Django’s release process" doc is here to describe what's actually
occuring). Or one could reformulate this "API Stability" doc with lots of
"often", "unless it's deemed not worthy" and so on, but only the core dev
group can express its official stance on this, not me. Is my analysis
correct?
You feel that sugar-coating my assertions might have changed something to
the adoption of my proposals, but considered that the current release
process is completely praised by other contributors to the talk, and that
dependency conflicts / fork-fests are considered a minor issue, I don't
have this impression. If my convictions on all these subjects (the
difficulty of setting up compatibility, the hazard of using old packages,
the necessity of forcing users to upgrade all at once, the interest of
highly modular architectures...) are the polar opposite of people here,
there is at the contrary nothing to regret - a change of release policy is
a big and brutal thing anyway, not something to be done by small steps and
small PRs.
So documentation changes only, it will blatantly be.
thanks,
regards,
Pascal
Le mar. 20 août 2019 à 14:56, Dave Burkholder <thinkwelldesi...@gmail.com>
a écrit :
> > I love where Django is headed. I love all of those breaking changes that
> have to happen so we're not perpetually stuck with decisions from 2005.
>
> +100 to this!!
>
> Django user since 1.6 running on python2.6. Upgraded to 1.7 and python3.4
> at the same time, and _that_ migration was hard. Everything since then has
> been a cakewalk.
>
> Mega-props to the caretakers of Django. Carry on...!
>
>
>
> On Monday, August 19, 2019 at 11:51:33 AM UTC-4, Patryk Zawadzki wrote:
>>
>> As someone who has spent over 12 years working with Django, I'd like to
>> offer an opposite point of view:
>>
>> I love where Django is headed. I love all of those breaking changes that
>> have to happen so we're not perpetually stuck with decisions from 2005.
>>
>> What I truly miss is strong static typing support that would tell that
>> when my code is not going to work before I even begin to test it. With
>> static types and tools like mypy and pyright upgrading dependencies is
>> usually a matter of a single afternoon.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/GgqjkYSqfR0/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/6b6f6b14-c3cc-4ba9-9d77-92ecaab23e11%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6b6f6b14-c3cc-4ba9-9d77-92ecaab23e11%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CA%2BXNUS128hL1WrAyUvfB72Czmqpz6TmKsmOy5exjpwwB3S1FUA%40mail.gmail.com.
