On Tue, Aug 11, 2009 at 7:01 AM, Russell Keith-Magee<freakboy3...@gmail.com> wrote: > Firstly, there is the simple issue of ownership and copyright. > Obviously, those that have written DDT components that are to be > included need to be onboard with this idea.
On this point I've strived to be pro-active (thanks to Jacob)... before any new commits from new committers were merged I made sure they're code was ok to be licensed under BSD and they were listed in the AUTHORS file. Seeing as the "framework" part hasn't changed a whole lot in the year or so it's been out, it seems like a worthwhile consideration to me. And I'd be for it. > Secondly, plugins. As I understand it, DDT is half framework, and half > a collection of debugging plugins, and one of the sources of forking > is people writing their own plugins. I haven't dug into this in > detail, but in order for DDT to get to trunk, we would need to be able > to ship an interface that is conceptually similar to db.backends - > that is, we will advertise a stable interface, and ship a small number > of obvious plugins. The community would then be in a position to > contribute extra plugins - some of which might one day get added to > django.contrib. If there is any disagreement in the interface that a > plugin is expected to implement, this would be a serious impediment to > inclusion in django.contrib. You understand it correctly. I've always meant to advertise a little more the fact that panels are just classes (subclasses of DebugPanel) that can be imported from anywhere given the full Python path to the debug toolbar config. And you are correct that some forks are adding panels that I wasn't comfortable merging due to the fact that they might be too specific and made more sense as a custom panel. Actually, to my knowledge, all the forks are panel specific and are not changing the core "framework" part of the debug toolbar. > Thirdly - look & feel. I haven't used DDT for a while, so I don't know > what the state of the art is here. Last time I used DDT, it worked > fine, but I felt that it needed a little UI polish, especially in > providing a way to hide it or preventing the toolbar from obscuring > meaningful parts of the underlying site. I don't know how time and > forking has treated this particular aspect of DDT. Agreed. UI isn't my strong point and I've always hoped a designer would be inspired to give it a full treatment. There's also the jQuery aspect of it. I think this probably leads to a bigger discussion. I have a local branch that makes some big improvements in this area already. > Lastly - time. This needs to be done in a timely fashion. If we're > going to include DDT in Django v1.2, then we're going to need to have > a consensus position - if not a ready-to-commit patch, then at least > agreement on what would be in a ready-to-commit patch - in a little > over a month. It it takes much longer than that to reconcile the > forks, then we may need to consider this a work-in-progress for v1.3. Perhaps some discussion at DjangoCon? :) > So - if you (or anyone else) is interested in advocating the addition > of DDT to django.contrib, you're going to need to make sense of the > mess for the core team. The first step in this process is wrangling > the forked community into a single repository that is a candidate for > inclusion. Hopefully I answered some of these questions and made some sense of the mess. -Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
