On Sun, Apr 18, 2010 at 5:23 AM, orokusaki <flashdesign...@gmail.com> wrote:
> Russell,
>
> This is what I meant by "straw hat" the other day. You took what I
> said out of context in a sly attempt at ignoratio elenchi. I made it
> clear in the first paragraph that **I started out thinking you were
> closed minded**, but then said that **I later realized that you were
> just busy**. I was bringing into question the policy of backwards
> compatibility, not your personality. It is you who has been engaged in
> ad hominem, not I.
I won't take any argument with the assertion that I'm busy. What I'm
getting frustrated at is that you are using argumentum ad nauseam to
establish that you are somehow the victim of either a capricious or
overworked (or both) core team. Every single decision that you have
been subjected to is, on considered reflection, completely correct and
would be repeated under identical circumstances.
The decisions that Joseph and I made on those tickets were *not* made
in haste, and were *not* made incorrectly. Your proposal *was*
backwards incompatible, and you *repeatedly* refused to follow advice
to take the discussion to django developers. Your indignation at the
fact that it took 3 minutes to reject the ticket ignores the fact that
the people closing the ticket have 18 months of prior experience
discussing the exact problem you apparently solved in an hour.
When you accused Karen of a "straw hat", you completely missed the
point that what she said was, again, completely accurate, and
substantively identical to the argument that I presented (which was
apparently sufficient for some reason).
I have no problem being accused of things that I have actually done. I
take *deep* offense at being accused of things I haven't done.
As for the backwards compatibility policy - as I've said several times
now, backwards compatibility doesn't mean *no change*, it means *no
sudden change*. This is based on a consensus between the core team on
how a software project should behave, and history demonstrates that
*most* problems can be solved within our existing policy framework.
If you want to make a case for a specific change that you think should
be given an exception to this policy, please make your case.
If you've got a suggestion for how we should modify the policy to
allow for a specific type of change, we're open to that too - but
specifics matter. Abstract discussions go nowhere fast. We would need
to see specific suggestions of how your new policy would get us out of
specific architectural holes without violating the core principles we
want to maintain.
> The real points you should be taking from all these conversations:
>
> 1) People don't like slow progress, but also want stability. Maybe
> it's time to revisit the policy to find a better balance, so that
> users aren't always recommended to use the trunk in production
> websites.
Firstly, the advice on the FAQ should be updated. The current advice
there hasn't been updated since pre 1.0 days, when we *did* advise
that people used trunk. These days, you should be using the stable
branch in production (1.1.X, at present) unless you're willing to take
on the burden of being an alpha tester.
As for slow progress: we need to be clear here. When you say slow
progress, are you referring to:
1) The fact that 1.2 is 2 months behind schedule, or
2) The fact that we have a strict policy on backwards incompatible changes?
If it's (1), the reason progress is slow is that the core team -- and
the rest of the development community, for that matter -- are
volunteers. Developing software takes time. The only solution to this
is more resources, and that means we need people to volunteer their
time.
If it's (2), then I simply disagree. I'm only aware of 2 problems in
Django that are serious flaws that can't be fixed in a backwards
compatible way:
* The inconsistent handling of the url name in {% url %}
* The need to manually call full_clean() when saving a model (and the
ModelForm problems that stem from this).
I don't really see either of these as a serious impediment to
progress. They're annoying, yes. If backwards compatibility wasn't an
issue, I'd fix them in a heartbeat. But they are two very small
aspects of Django overall, there are perfectly adequate workarounds
available, and "fixing" them would mean every single Django user in
existence would be forced to do a potentially expensive audit of their
code before an upgrade -- and that's simply not something we're
willing to ask the user base to do.
> 2) It seems that others are concerned with SVN and want to use a
> definative version, e.g. 1.2.2, instead of some r5481849448 number,
> and without having to wait for 6 months for the official 1.2 release.
Again - this is something we haven't handled well over the 1.2
lifecycle. In hindsight, we probably should have put out a 1.1.2
release a couple of months ago.
However, the reason we haven't put out 1.2 yet is because it isn't
ready yet. We've added a lot of features, and we're still fixing
problems. If we're going to encourage people to use a stable release,
it actually needs to be stable, so we're going to err on the side of
caution here. Again, if you want the release to happen faster, pitch
in.
> 3) People specifically aren't contributing because they know that
> every attempt they make will get them exactly nowhere, except close
> lined. Perhaps problem 1 could be solved by solving this problem with
> a slightly more open policy, instead of closing tickets 5 seconds
> after they're open.
Again, argumentum ad nauseum. See above.
> 4) The attitude projected at developers gives the idea that Django is
> for the core team only, and that users are graced with the ability to
> use Django. While the contribution is much appreciated, the attitude
> is harmful to the core team and to the user base.
I am completely floored by this. I simply don't see where this
perception has come from, and it doesn't mesh with the feedback I have
received in this thread, privately in response to this thread, or on
IRC.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
