"You seem to be suggesting that a fork will somehow magically fix the speed of Django development. I ask you: who is going to work on this fork?"
I think a hostile fork is almost a certain outcome if development continues as it has. Not only is the resistance to make backwards incompatible changes in future releases a bad policy for the quality of the framework, but the behavior in trac has a negative effect on community contributions. The level of resistance I see to change or outsider code contribution is an enormous de-motivator for people (like me) to want to make any contributions in the first place. Why should I contribute a patch to your flawed architecture if I'm going to be talked down to, ridiculed, then eventually have the patch rejected because it breaks code in some edge-use-case? Personally I believe my time might be better spent developing a fork, than arguing over clear flaws in architecture decisions that "can't be changed". It's a good idea to avoid breaking backwards compatibility in point releases, but as far as major releases go ... I whole heartedly encourage it. If keeping backwards compatibility was a good idea, my macbook pro would have a 5.12" floppy drive, a 3.25" drive, a jazz drive, it would accept serial and adb plugs.... and maybe have a display mode to emulate those green crt monitors of yore. Good software is about removing flaws, improving the architecture, and learning from past mistakes. If this comes at a price, then pay. -k On Wed, Apr 14, 2010 at 9:25 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Wed, Apr 14, 2010 at 8:34 PM, veena <vsto...@gmail.com> wrote: > >> I know there's django deprecation policy nicely documented >> http://docs.djangoproject.com/en/1.1/internals/release-process/#internal-release-deprecation-policy >> >> But what I don't know is how you discover it. Is it described >> somewhere in the text or the video from conference? What were the >> reasons to have this deprecation policy? Was there any user research? >> Research of when the django users upgrade, what are the main problems >> of upgrades and how they imagine upgrading should work? > > The policy was arrived at after a debate between the core team, based > on how the core team believe a well-behaved project should behave. For > the record, it wasn't much of a debate, either - we were all pretty > much in agreement on the core points from the beginning. > > In the opinion of the core, well-behaved projects don't require > massive rewrites (or worse - subtle bug chasing efforts) every time a > new release is made. Developers using a library should have the > confidence to know that when they write code, it will continue to work > for a long time, not just until the core developers have a change of > heart. > > I would suggest to you that one of the reasons for Django's success > has been it's policy on backwards compatibility. > >> What I try to say is that I'm little bit afraid that it seems like >> improvements of django will take years instead of months. > ... >> I think this could lead to fork the django by some devs >> and rapid development of this fork > > You seem to be suggesting that a fork will somehow magically fix the > speed of Django development. I ask you: who is going to work on this > fork? > > Progress on Django may be slower than many would like, but it's not > slow because we're hampered by backwards compatibility. It's because > the core team all have full time jobs, families and friends, and we > contribute to Django in our spare time. If you want to fix the speed > of development, pitch in. > > 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. > > -- 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.
