I just want to throw my 2 cents into the ring here. I'm not against a fork, but at the same time I want to see the Django mainline progress. However, let me tell you my story, and how I've seen the Django development process over the years.
I started with Django 4 years ago. It was cool, shiny, and let us get up and running. At the time, were were one of the largest Django installations. We had needs, and some of those needs were met. However, many were not. We were the only ones furiously trying to get the core team to accept our patches, ideas, etc.. Now while I'm not going to say every idea we had was right for Django, there were in fact many that were great, and eventually have made it into trunk. There are also still many (lets take the classic #17 here), that still haven't made it into trunk, even though people have been even more aggressively pushing them lately. I honestly can only remember a single patch that I've committed that has ever been fully integrated into trunk (select_related refactor). Now, the development process has changed with Django over the years, but I will sadly say that I feel it's been for the worst. I've completely given up on trac, submitting patches, or even participating. Now while some may not like my aggressive tacts (e.g. James) that doesn't mean what I've brought to the table hasn't been needed. For the last year or two all I've seen on the trac whenever I took up the time to write a patch, or even submit a ticket, was a closure of "wontfix" for some, honestly, stupid reason. It just isnt worth my time to submit the same ticket 3 times just so its "correct", or it fits everyones needs. Tickets are not patches, and they shouldn't be treated like "if this one isnt accepted, create a new one". I think there's a split within the Django core team right now and I strongly believe that unless you can tirelessly convince a core developer (no matter how large the following), a feature is not going to make it into mainline. This to me is a serious issue when you're talking about an open source, community contributed project. Sure, the core team does a large amount of the work, but not without help from the community. I'll take this back to my old analogy, not everyone is building a blog, and if they are, they can go use WordPress. Many, many things have gone ignored for far too long. I love Malcom's ORM refactor, but that was at a standstill for I don't know how long, and that entire time any patch which was related to improvements to the ORM was ignored simply stating "we're working on a refactor of the ORM". This philosophy seems to continue still today. Just recently there was a post about "High Level Talk About Django" (or whatever it was called). Now while the thread didn't make a whole lot of sense in general, it was just an attempt to gather some ideas, and brainstorm. Immediately it was shut down by the core developers. What frustrates me even more is all of this pony talk. If there's one thing I dislike it's Django's philosophy that "if it can be done 3rd party, do it", yet even the simplest things, like the template engine, have better 3rd party implementations (Jinja2). Django still doesn't have migrations. It still doesn't have dependancies. It's seriously lacking in many areas which other (albeit lesser) alternatives such as Rails have made available for far too long. Now while there's great 3rd party apps for things like this (South), and there's a few mediocre sites to find pieces of code (Django Snippets), this doesn't solve the problem which is really going on in Django: The community cant contribute beyond what the core team deems necessary. For me, I've entirely given up on trying to give back to Django. I've written enormous amounts of questionable code simply so I didn't have to patch Django, or even bother dealing w/ the process of Django's development. Monkey patching, ugly metaclass hacks, you name it. Anything that's made it easier to avoid this "process", has made it easier for us to develop. I continue to build these "ponies", but that doesn't make them any easier to integrate in Django. All in all, I think some things have been ignored for far too long. Simple things, again, like migrations, JSON and RESTful utilities, and even the tools to make development easier (the debug toolbar hasn't been around that long). Yet so much time is spent on things like refactoring the admin (while it's useful, in the big picture, its not flexible, and never can be), the template system, and many other things which have been done and done again by other people. Again, this is just my opinion, and I do know that many share it. This has been one of the largest outcries of people I've seen in a while. I honestly can't see that I see a fork succeeding, but I would definitely like to see what can happen to make the "process" friendlier to people like myself and some of the others who have posted here. Really, for me, I just don't (nor do I want to) have the time to keep up on Django's process. If I see a bug, I want to let people know, as easily as possible. If I think of a must-have feature, I want it to be shot down for a real reason. On Apr 17, 10:35 am, Simone Federici <s.feder...@gmail.com> wrote: > The work of the core team is outstanding and I find that the process of > development > is to be taken as an example. > > Unfortunately, customers often want features, but we are programmers, > engineers, > and we know who we are and what is our role. > > Compatibility is strongly important when choosing a tool. > Otherwise who would have used? only geeks? > > Imagine if we can use frameworks that between one release and another > introduce incompatibility. no thanks. > > thanks guys > S > > On Sat, Apr 17, 2010 at 15:50, Stephen Wolff <stephen.wo...@gmail.com>wrote: > > > > > > > I feel quite sad reading this thread. Good luck completing 1.2. I only wish > > I had time and energy to contribute. I suggest the core team ignore the > > thread for now if at all possible. > > > On 17 Apr 2010 14:47, "Russell Keith-Magee" <freakboy3...@gmail.com> > > wrote: > > > On Sat, Apr 17, 2010 at 7:14 PM, George Sakkis <george.sak...@gmail.com> > > wrote: > > > On Apr 17, 5:35 am... > > For the record, there are 62 tickets marked ready for checkin, not 400 > > [1]. 29 of those are documentation and translation patches (5 of which > > are specifically marked for inclusion in 1.2). > > > [1] > >http://code.djangoproject.com/query?status=new&status=assigned&status... > > > On top of that, the Ready For Checkin status doesn't mean that a > > member of the core team has reviewed a patch. It means that someone -- > > anyone -- thinks the patch is ready for checkin. There's no guarantee > > that a Ready For Checkin patch is *actually* ready for checkin. If you > > do a survey of the Ready For Checkin patches, you'll find tickets that > > don't have test cases, or add features that aren't documented, or make > > a significant changes that haven't been discussed on django-dev. If I > > were to sit down and work through that list, I guarantee I wouldn't > > end up making 62 commits to trunk using the material that has been > > provided on those tickets. > > > I would also point out the folly of looking at raw ticket counts. > > Python (the language) has 1078 tickets in the "having patch" status, > > and 96 in the "needing review" status. Does this mean that Python is a > > project in crisis? > > > Yes, there is a ticket backlog. Yes, this means there is a lot of work > > that needs to be done. What we need is people volunteering to actually > > do that work. However, as I've already indicated in this thread, much > > of that work could be done without any change in current project > > policy - we just needs people to actually do the work. > > > My dream outcome would to be in the situation where I don't *ever* > > have to spend time on Trac trying to work out if the ticket that has > > been marked Ready For Checkin is *actually* ready for checkin. Give me > > a rich vein of trunk ready tickets that has been reviewed by someone > > whose reputation I know and trust, and believe me -- I will use it. > > > > Healthy projects don't need a separately maintained fork/branch on > > > github or bitbucket just to ... > > The flipside of this is that too many cooks spoil the broth. If we > > want to maintain a high quality product, we can't just add a dozen new > > developers to the core team. > > > I would also point out that even in projects that do have large teams > > with the commit bit, access to the "core trunk" is generally only made > > available to a restricted subset of the entire team. Alternatively, > > some sort of code review process is used to ensure that multiple team > > members (occasionally, specially blessed team members) check patches > > before they are committed. There's a lot more to commit policies in > > open source than raw team size. > > > Yours, > > Russ Magee %-) > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" g... > > > -- > > 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<django-developers%2Bunsubscr > > i...@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 > 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.
