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 tend to agree with Kevin's assertion that it's not worth spending time developing when you don't know if your ideas will be thrown in the trash, but I won't complain about it because everything these people do for Django is free to us, and if they weren't hardcore, the framework could have turned into muck by this point (with the number of feature requests out there).
After a few rounds of doing that, I realized that people like Russell, who appear to be closed minded at first glance, are really not closed minded at all, but just overworked by tickets and don't have extra time to do every single ticket. I believe this is primarily because for every added feature, tons and tons of code has to be changed / added to keep everything backwards compatible with code from a year ago. I think I speak for a pretty broad user base when I say that folks who use Django are bleeding edge developers who want cool stuff, and don't mind paying a little extra to have it. It isn't like IBM and Microsoft are using Django for huge distributed projects, and upgrading all their clients to the latest version each week. And, again back to Kevin's point; if they are upgrading quickly, they are the types that understand the value of doing so. 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 ), it might be worth investing the time to start a fork. A little competition for the core team wouldn't hurt them a bit. It would relieve a little of the stress of being bombarded by tickets for things that are not possible for a whole year, etc. I would only suggest that if you were to go this route, to do so in a way that isn't harmful to Django as a whole (e.g. making empty promises will leave a bitter taste and ruin the name). On Apr 15, 12:57 pm, Kevin Howerton <kevin.hower...@gmail.com> wrote: > "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/#inter... > > >> 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 > > 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.
