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.
This sort of behavior is not conducive to a productive development environment. 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. 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. 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. 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. On Apr 16, 9:31 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sat, Apr 17, 2010 at 6:02 AM, orokusaki <flashdesign...@gmail.com> wrote: > > When I first started posting things on trac, I put up a request that > > took me an hour to create, explaining the justification, as well as > > putting the code in there. I didn't know how to make a patch, and I > > went about it the wrong way, but regardless of that, I put a lot of > > thought into it. Less than 3 minutes after I posted it, it was closed > > and resolution set to `wontfix`. It was an extremely minor change that > > didn't break any backwards compatibility, but I didn't follow the > > right procedures, so wham, gone. > > I'm going to stop you there. You repeatedly *asserted* that it was > backwards compatible. We (Joseph and I) *repeatedly* told you that we > didn't think it was, and we *repeatedly* told you to take the > discussion to django-dev, and you *repeatedly* didn't, and we > *repeatedly* pointed you at the contribution docs to tell you why we > were saying you should take it to django-dev, and you *repeatedly* > didn't... until you finally did, at which point, we demonstrated why > your idea wasn't backwards compatible, and -- unless I'm mistaken -- > you agreed. > > Please don't characterize what Joseph and I did as arbitrary or closed minded. > > > If the core team doesn't want to change the backwards compatibility > > policy a tiny bit to accommodate faster paced code ( keeping up with > > the Jone's and such, such as RoR 3.0 ), > > Django's backwards incompatibility policy doesn't mean *no change*. It > means *no sudden change*. There are *many* examples in Django 1.2 > alone of features that are being deprecated or altered in ways that > will ultimately be incompatible. Code written for Django 1.0 won't run > unmodified in Django 1.4 due to changes in admin registration, > messaging, CSRF, and many other features. However, these changes are > introduced as a series of progressive enhancements rather than sudden > changes. This enables use to provide ample active warnings advising > that code changes will be required. It also avoids the need to > introduce "USE_NEW_BEHAVIOR" settings switches that require us to > maintain two implementations in parallel and in perpetuity. > > We're open to any proposal to change the status quo - as long as it > can be done gradually and gracefully. If you think hard enough, *most* > problems can be fixed in this way. Those that can't are unfortunate > warts, but that's the price we pay for having a stable platform. As > Jacob said, that's not a claim that Django-style stability is > "correct" - it's just the policy we have adopted based on our > particular priorities. > > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
