#11834: colorized debug page. Assigned to buriy
Thomas Guettler
a colorized debug page helps a lot. More than 99% of errors
are in my code, and not in django's. This patch gives "own" code
a different color.
It is assigned to "buriy" since 6 months.
http://code.djangoproject.com/ticket/11834
Why not commit?
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
Dougal Matthews
Why not commit?
bur...@gmail.com
On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
> Hi,
>
> a colorized debug page helps a lot. More than 99% of errors
> are in my code, and not in django's. This patch gives "own" code
> a different color.
>
> It is assigned to "buriy" since 6 months.
>
> http://code.djangoproject.com/ticket/11834
>
> Why not commit?
I'm buriy. Patch creator.
The agreement between core devs and me (or at least how i get it) was
that we decided that this patch needs to be a part of larger "debug
page usability improvement suite".
My decision is that until that, the patch is "incomplete" to allow
only in-house use.
I can do all development changes for all suite (and finish this patch
of course), if we discuss how it should be done.
My issue needs few improvements:
- docs & tests
- ability to hide some traceback elements, keeping notice they are
hidden -- it's so easy to shot yourself in foot otherwise.
- better display for decorators -- i think they either don't deserve
separate line or should be displayed as @decorator in the short debug
output.
- grouping template tags together and pretty display for them --
please see below.
At least, after my issue, there are 2 others:
- DEBUG_SHOW_DJANGO_TRACEBACK option (
http://code.djangoproject.com/ticket/13148 )
- output for template tags should be improved, since we're displaying
4 traceback blocks instead of template tag itself. There was a code
written for this already somewhere, there was screenshot available,
and it was discussed in this group, but i can't find it right now. Can
anyone point me at it?
And yes, I don't know where to find designers to get a look at my
implemented improvements, I'd like contact them when I'm ready.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Thomas Guettler
> Hi,
>
> On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
>> Hi,
>>
>> a colorized debug page helps a lot. More than 99% of errors
>> are in my code, and not in django's. This patch gives "own" code
>> a different color.
>>
>> It is assigned to "buriy" since 6 months.
>>
>> http://code.djangoproject.com/ticket/11834
>>
>> Why not commit?
>
> I'm buriy. Patch creator.
>
> The agreement between core devs and me (or at least how i get it) was
> that we decided that this patch needs to be a part of larger "debug
> page usability improvement suite".
> My decision is that until that, the patch is "incomplete" to allow
> only in-house use.
Django: The web framework for perfectionists with deadlines....
But where/when is the deadline?
I think with "release early, release often" you get perfect code
faster.
> I can do all development changes for all suite (and finish this patch
> of course), if we discuss how it should be done.
>
> My issue needs few improvements:
> - docs & tests
AFAIK the current debug page has no docs and tests, too.
> - ability to hide some traceback elements, keeping notice they are
> hidden -- it's so easy to shot yourself in foot otherwise.
Please explain this. What do you want to hide? The page is for developers only.
> - better display for decorators -- i think they either don't deserve
> separate line or should be displayed as @decorator in the short debug
> output.
I want to see the stacktrace the way it is (nested function calls)
> - grouping template tags together and pretty display for them --
> please see below.
>
> At least, after my issue, there are 2 others:
> - DEBUG_SHOW_DJANGO_TRACEBACK option (
> http://code.djangoproject.com/ticket/13148 )
> - output for template tags should be improved, since we're displaying
> 4 traceback blocks instead of template tag itself. There was a code
> written for this already somewhere, there was screenshot available,
> and it was discussed in this group, but i can't find it right now. Can
> anyone point me at it?
> And yes, I don't know where to find designers to get a look at my
> implemented improvements, I'd like contact them when I'm ready.
I am not a designer, but here is my opinion: Your patch highlights
own code quite good. But there are too many colors. I like the
colors of http://www.djangoproject.com/
Why not use or copy parts if this style?
I would just increase the size of "own" code, no different colors.
It would be nice if you could define a list of apps that
you consider "stable" and which should be displayed small.
bur...@gmail.com
> bur...@gmail.com wrote:
>> Hi,
>>
>> On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
>>> Hi,
>>>
>>> a colorized debug page helps a lot. More than 99% of errors
>>> are in my code, and not in django's. This patch gives "own" code
>>> a different color.
>>>
>>> It is assigned to "buriy" since 6 months.
>>>
>>> http://code.djangoproject.com/ticket/11834
>>>
>>> Why not commit?
>>
>> I'm buriy. Patch creator.
>>
>> The agreement between core devs and me (or at least how i get it) was
>> that we decided that this patch needs to be a part of larger "debug
>> page usability improvement suite".
>> My decision is that until that, the patch is "incomplete" to allow
>> only in-house use.
>
> Django: The web framework for perfectionists with deadlines....
> But where/when is the deadline?
> I think with "release early, release often" you get perfect code
> faster.
1) I have a lot of hobbies,
2) typical commit time even for perfect patch is almost a year! and
almost no one applies patches from django tickets.
3) and current state of patch works excellent for my projects.
I had few useful thoughts about changing the way Django development
contributions gets accepted and committed -- but all I get from this
mailing list that all attempts to improve any process is just a waste
of time. Core devs have no time even to accept working & looking good
patches -- and rarely have time to review patches not looking good or
working wrong!
So why should I bother to write patches fast?
But, if I have fans waiting for this feature, this is one good reason!
>> I can do all development changes for all suite (and finish this patch
>> of course), if we discuss how it should be done.
>>
>> My issue needs few improvements:
>> - docs & tests
>
> AFAIK the current debug page has no docs and tests, too.
At least we need tests for color choosing based on packages paths --
this can be customized by yourself.
>> - ability to hide some traceback elements, keeping notice they are
>> hidden -- it's so easy to shot yourself in foot otherwise.
>
> Please explain this. What do you want to hide? The page is for developers only.
The most of comments I got when developing this plugin were related to
hiding some non-interesting parts of traceback. While I for myself
tried this and find it confusing, i'm not sure if other should be able
to do this -- and they might already try to do this with current
patch.
>> - better display for decorators -- i think they either don't deserve
>> separate line or should be displayed as @decorator in the short debug
>> output.
>
> I want to see the stacktrace the way it is (nested function calls)
You get it already.
>> - grouping template tags together and pretty display for them --
>> please see below.
>>
>> At least, after my issue, there are 2 others:
>> - DEBUG_SHOW_DJANGO_TRACEBACK option (
>> http://code.djangoproject.com/ticket/13148 )
>> - output for template tags should be improved, since we're displaying
>> 4 traceback blocks instead of template tag itself. There was a code
>> written for this already somewhere, there was screenshot available,
>> and it was discussed in this group, but i can't find it right now. Can
>> anyone point me at it?
And don't you want pretty output for templates lines?
>> And yes, I don't know where to find designers to get a look at my
>> implemented improvements, I'd like contact them when I'm ready.
>
> I am not a designer, but here is my opinion: Your patch highlights
> own code quite good. But there are too many colors. I like the
> colors of http://www.djangoproject.com/
> Why not use or copy parts if this style?
>
> I would just increase the size of "own" code, no different colors.
> It would be nice if you could define a list of apps that
> you consider "stable" and which should be displayed small.
I'll try this, but colors are usually much better for visual
distinction of items.
I can make a special page, and show you and others resulting
screenshots after your suggestions, and everyone who wants to add
their 2cents.
Russell Keith-Magee
> I had few useful thoughts about changing the way Django development
> contributions gets accepted and committed -- but all I get from this
> mailing list that all attempts to improve any process is just a waste
> of time.
That's not entirely fair.
We're acutely aware of the fact that there is a backlog of tickets
that need attention. We're also aware that many people upload patches,
but then don't get any feedback on them. We want to improve this in
any way we can.
If you have suggestions on how we can improve Django's development
process and address these issues, we're happy to hear them.
However, that doesn't mean we're going to immediately implement a
suggestion just because it's been made. I don't know which suggestion
in particular you're referring to, but if you've made a suggestion and
we haven't acted on it, then I would suggest to you that this is
because we (the core team) didn't agree that your idea was as useful
or practical as you think it was.
If you have a suggestion, please make it. We're listening.
> Core devs have no time even to accept working & looking good
> patches -- and rarely have time to review patches not looking good or
> working wrong!
> So why should I bother to write patches fast?
I would point out that the core team aren't the only people that can
give feedback. Trac is an open resource for exactly that reason.
>>> I can do all development changes for all suite (and finish this patch
>>> of course), if we discuss how it should be done.
>>>
>>> My issue needs few improvements:
>>> - docs & tests
>>
>> AFAIK the current debug page has no docs and tests, too.
> At least we need tests for color choosing based on packages paths --
> this can be customized by yourself.
As I commented the last time this ticket was discussed -- no tests or
docs are required for this proposal. It's a difficult feature to test,
and there's no user-facing configuration items, so I'm happy to accept
this ticket without tests or docs.
However, it does need to have it's UX issues sorted out. The most
recent substantive comment on the ticket [1] indicates that the patch
isn't ready for checkin. It also suggests that there are broader
improvements that may need consideration. To the best of my knowledge,
nobody has tried to start a django-dev discussion to address those
improvements.
[1] http://code.djangoproject.com/ticket/11834#comment:5
Yours,
Russ Magee %-)
bur...@gmail.com
> However, it does need to have it's UX issues sorted out. The most
> recent substantive comment on the ticket [1] indicates that the patch
> isn't ready for checkin. It also suggests that there are broader
> improvements that may need consideration. To the best of my knowledge,
> nobody has tried to start a django-dev discussion to address those
> improvements.
>
> [1] http://code.djangoproject.com/ticket/11834#comment:5
Regarding ticket improvements, do you remember that guy who sent a
beautiful screenshot of his templates errors rework in the django dev
about half a year or a year ago? Can't find it, but I wanted
desperately to include it!
Russell Keith-Magee
> Hi Russell,
>
>> However, it does need to have it's UX issues sorted out. The most
>> recent substantive comment on the ticket [1] indicates that the patch
>> isn't ready for checkin. It also suggests that there are broader
>> improvements that may need consideration. To the best of my knowledge,
>> nobody has tried to start a django-dev discussion to address those
>> improvements.
>>
>> [1] http://code.djangoproject.com/ticket/11834#comment:5
>
> Regarding ticket improvements, do you remember that guy who sent a
> beautiful screenshot of his templates errors rework in the django dev
> about half a year or a year ago? Can't find it, but I wanted
> desperately to include it!
Sorry - can't say I do.
Yours,
Russ Magee %-)
Mark Bucciarelli
>
> If you have suggestions on how we can improve Django's development
> process and address these issues, we're happy to hear them.
>
You may find this interesting:
http://openbsd.org/papers/asiabsdcon2009-release_engineering/
(There's also a video of the presentation on YouTube.)
Tenets:
- all development on trunk (no $ for QA team in free software)
- daily snapshots (eat your own dogfood)
- random api lock (people tend towards complacency)
- punish dev's who don't fix their bugs quickly after api lock
(The presentation lacks specifics on the last point. ;)
Also, hackathons are a great idea. A room full of core developers can
get a hell of a lot done in a week.
m
Russell Keith-Magee
> On Sat, Aug 14, 2010 at 03:03:27PM +0800, Russell Keith-Magee wrote:
>>
>> If you have suggestions on how we can improve Django's development
>> process and address these issues, we're happy to hear them.
>>
>
> You may find this interesting:
>
> http://openbsd.org/papers/asiabsdcon2009-release_engineering/
>
> (There's also a video of the presentation on YouTube.)
I've seen the video before; I didn't know the slide deck was
available. Thanks for the link.
My take on this is that we're reasonably close to OpenBSD's
development process. The only significant difference is that we have
the 'feature discussion' period where very little gets done on the
tree, and major features are committed once that discussion period has
lapsed.
If you look at the 1.2 cycle, most of the major features were
committed in December, just prior to the alpha release. If you dropped
the 'feature discussion' period from the 1.2 timeline, you would end
up with a development cycle that matches fairly closely to OpenBSD's.
We have the feature development phase for a very good reason -- we
have extremely limited resources (based on the charts in that slide
deck, *much* lower than OpenBSD), and we want to focus those
resources. If we continued to discuss new features while we were
trying to get a release out the door, it becomes even harder to meet
deadlines, because resources that would be dedicated to finding and
fixing bugs (both core team resources and general community resources)
are diverted into developing new code.
> Tenets:
>
> - all development on trunk (no $ for QA team in free software)
We already do this.
> - daily snapshots (eat your own dogfood)
In an era where you can pip install from a git/hg/svn repository, this
isn't as important as it once was (or as important as it is for system
software like OpenBSD). However, I agree that it would be good to
automate this process somewhat (if only because we have a very low bus
factor when it comes to release management).
> - random api lock (people tend towards complacency)
I'm not entirely certain I understand this point -- or, at least, how
it would apply to Django. Our APIs are always locked, since we don't
allow backwards incompatible API changes. Major new features don't get
added to trunk until we're happy with their API, so new features
aren't subject to API changes, either.
> - punish dev's who don't fix their bugs quickly after api lock
>
> (The presentation lacks specifics on the last point. ;)
Which is a big omission. When you're not paying anyone, and you
already have a problem getting contributions, you have limited options
for punishment. I'd be very interested to hear what constitutes
"punishment" in this approach.
> Also, hackathons are a great idea. A room full of core developers can
> get a hell of a lot done in a week.
You won't get any argument from me on this one. The complication is
geography, and the resultant cost. I'm based in Western Australia, so
it costs around $3000 to get me in a room with the other core
developers somewhere in the US. That number is slightly less for
Malcolm, because he's based on the east coast of Australia. Luke and
Jannis both have to cross the Atlantic. And this completely avoids the
question of how we find the time out of our work schedules to
contribute a week of development effort.
Any suggestions on how to overcome these limitations will be
gratefully received:-)
Yours,
Russ Magee %-)
Tobias McNulty
On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com> wrote:> - punish dev's who don't fix their bugs quickly after api lockWhich is a big omission. When you're not paying anyone, and you
>
> (The presentation lacks specifics on the last point. ;)
already have a problem getting contributions, you have limited options
for punishment. I'd be very interested to hear what constitutes
"punishment" in this approach.
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com
Mark Bucciarelli
> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com> wrote:
>
>
> I'm not entirely certain I understand this point -- or, at least,
> how it would apply to Django.
>
So the interface between backend and object model is one. I suppose
there is an equivalent interface on the template side.
One example that tripped me up: in 1.2, the signature of
BaseDatabaseWrapper __init__() changed.
In 1.1, I had
def __init__(self, settings_dict):
and in 1.2 I needed
def __init__(self, *args, **kwargs):
>
> Our APIs are always locked, since we don't allow backwards incompatible
> API changes.
>
My 1.1 version must have been wrong then.
>
> > ?- punish dev's who don't fix their bugs quickly after api lock
> >
> > (The presentation lacks specifics on the last point. ;)
>
> Which is a big omission.
>
I'm not a dev there, so I don't know. I'm a regular lurker on the
mailing lists though, so it either happens off-list or on-list but
very infrequently.
>
> > Also, hackathons are a great idea. ?A room full of core developers can
> > get a hell of a lot done in a week.
>
> You won't get any argument from me on this one.
>
I wonder if you ran a really targetting fund-raising campaign how much
would come in. I know when the use is specific, it's easier to raise
money. Sounds like if you raised $12k it would get you pretty close.
m
Russell Keith-Magee
> On Mon, Aug 16, 2010 at 10:31:11AM +0800, Russell Keith-Magee wrote:
>> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com> wrote:
>>
>> > ?- random api lock (people tend towards complacency)
>>
>> I'm not entirely certain I understand this point -- or, at least,
>> how it would apply to Django.
>>
>
> So the interface between backend and object model is one. I suppose
> there is an equivalent interface on the template side.
>
> One example that tripped me up: in 1.2, the signature of
> BaseDatabaseWrapper __init__() changed.
>
> In 1.1, I had
>
> def __init__(self, settings_dict):
>
> and in 1.2 I needed
>
> def __init__(self, *args, **kwargs):
>
>>
>> Our APIs are always locked, since we don't allow backwards incompatible
>> API changes.
>>
>
> My 1.1 version must have been wrong then.
A point of clarification on my part: we don't allow backwards
incompatible API changes in APIs declared as stable. The API for
database backends isn't currently on that list [1].
[1] http://docs.djangoproject.com/en/1.2/misc/api-stability/
Whether we should promote the backed interface to a stable interface
is a separate issue, but certainly one worth discussion (especially
given that there are a number of external database backends emerging
in the community).
>> > Also, hackathons are a great idea. ?A room full of core developers can
>> > get a hell of a lot done in a week.
>>
>> You won't get any argument from me on this one.
>>
>
> I wonder if you ran a really targetting fund-raising campaign how much
> would come in. I know when the use is specific, it's easier to raise
> money. Sounds like if you raised $12k it would get you pretty close.
An interesting idea, and one where the Django Foundation could play a
big role. However, this doesn't address the 'getting a week off work'
issue
Yours,
Russ Magee %-)
Russell Keith-Magee
> On Sun, Aug 15, 2010 at 10:31 PM, Russell Keith-Magee
> <rus...@keith-magee.com> wrote:
>>
>> On Mon, Aug 16, 2010 at 10:03 AM, Mark Bucciarelli <mkb...@gmail.com>
>> wrote:
>> > - punish dev's who don't fix their bugs quickly after api lock
>> >
>> > (The presentation lacks specifics on the last point. ;)
>>
>> Which is a big omission. When you're not paying anyone, and you
>> already have a problem getting contributions, you have limited options
>> for punishment. I'd be very interested to hear what constitutes
>> "punishment" in this approach.
>
> For the record, it is mentioned. The punishment they tried for a few
> releases was denying commits from the developers who did not do their fair
> share of testing for 2 weeks after the tree was unlocked for everyone else.
My apologies -- I haven't watched the video for a while, so I forgot
that detail. I'm not sure adopting that policy would help Django,
though; we have enough of a bottleneck with committers without
exacerbating the problem.
Yours,
Russ Magee %-)
Tobias McNulty
My apologies -- I haven't watched the video for a while, so I forgot
that detail. I'm not sure adopting that policy would help Django,
though; we have enough of a bottleneck with committers without
exacerbating the problem.
Thomas Guettler
http://code.djangoproject.com/ticket/11834
it would be nice, if the CSS could be customized. But how
to do that?
I think the debug html output should be self contained.
It should not reference a CSS file. Example: I send the
HTML output by mail to myself, to see if uncaught exceptions have
happened on production sites.
Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css'
After we created a patch with configurable CSS, we could make a small
contest, and the best gets commited to be the default.
Thomas
bur...@gmail.com wrote:
> Hi,
>
> On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
...
bur...@gmail.com
On Mon, Aug 16, 2010 at 8:12 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
> Hi buriy,
>
> http://code.djangoproject.com/ticket/11834
>
> it would be nice, if the CSS could be customized. But how
> to do that?
>
> I think the debug html output should be self contained.
> It should not reference a CSS file. Example: I send the
> HTML output by mail to myself, to see if uncaught exceptions have
> happened on production sites.
>
> Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css'
>
> After we created a patch with configurable CSS, we could make a small
> contest, and the best gets commited to be the default.
Yes, thanks, I though of anything similar.
But don't you think developers should spend time to work on the
project, not make the debug page better?
So here one-size-fits-all solution is much better rather than
customization playground.
The only reason I'm working on this patch is that without colors it's
taking some time to understand what module caused the error if
traceback contains database access, querysets manipulations or
templates processing.
However, you can edit django http500 template and create your own
version, make a good screenshot and impress us.
Just replace default 500 debug response with yours!