Wondering about few 'burried' issues

I have been researching few (web) application frameworks and
considering our projects, Django outperforms all of them
easily,
reflecting exactly what we were going to build (well, no
need to build
now).

After playing around with some test applications I noticed a
few
things, there wasn't a way to represent a model's field
(especially m2m
fields) with multiple checkboxes in the administration
interface. This
was weird because there already was a form field
(CheckboxSelectMultipleField) to render them. Though it was
easy to
extend this functionality, by creating a 'checkbox_admin'
argument, I
didn't like the idea of patching it in after every django
update. So I
searched the tickets and found out there was also someone
else
interested in the idea. But then it hit me, ticket was
closed with
resolution 'wontfix' (http://code
.djangoproject.com/ticket/2004). I am
curious, why?

Another issue was with "BooleanFields". I
noticed they always hit the
history even if not changed. Someone else had noticed this
too and
already posted a ticket (http://code
.djangoproject.com/ticket/1511).
Pretty easy to fix but has been open for 4 months?

These are very small fixes/enchantments but still kind of
frustrating
to apply them yourself after updating django. So my question
is, what
is the reason to ignore this kind of tickets?

By the way, is there going to be an automatic 'detail'
view for objects
+ "Can view <object>" permission in the
administration interface? Would
come in handy (again relatively easy to extend yourself,
but...)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On Thu, 2006-07-27 at 03:39 -0700, Sebastian F wrote:
> I have been researching few (web) application
frameworks and
> considering our projects, Django outperforms all of
them easily,
> reflecting exactly what we were going to build (well,
no need to build
> now).
> 
> After playing around with some test applications I
noticed a few
> things, there wasn't a way to represent a model's
field (especially m2m
> fields) with multiple checkboxes in the administration
interface. This
> was weird because there already was a form field
> (CheckboxSelectMultipleField) to render them.

Without thinking too much about this particular case,
realise that
infinite customisability isn't a necessarily good design
goal. It adds a
maintenance burden (there's a whole extra code path that
needs testing
for functionality, presentation and usability), extra
learning needs
(why choose one over the other, the developer will wonder)
and no extra
functionality (you can already select one item from a list
of choices). 

>  Though it was easy to
> extend this functionality, by creating a
'checkbox_admin' argument, I
> didn't like the idea of patching it in after every
django update. So I
> searched the tickets and found out there was also
someone else
> interested in the idea. But then it hit me, ticket was
closed with
> resolution 'wontfix' (http://code
.djangoproject.com/ticket/2004). I am
> curious, why?
> 
> Another issue was with "BooleanFields". I
noticed they always hit the
> history even if not changed. Someone else had noticed
this too and
> already posted a ticket (http://code
.djangoproject.com/ticket/1511).
> Pretty easy to fix but has been open for 4 months?

We have been working on other things in the past four
months.

> These are very small fixes/enchantments but still kind
of frustrating
> to apply them yourself after updating django. So my
question is, what
> is the reason to ignore this kind of tickets?

Community Service Announcement: It is important to
understand the very
difference between "a ticket is being ignored"
(actually pretty rare)
and "a ticket has not been attended to yet".
There are over 400 open
tickets in Trac, of various degrees of impact on end-user
functionality
and/or the code. Boolean field values always appearing in
history is an
extremely minor feature wart. Of all the known problems in
Django, it
just isn't even close to things like "bad SQL gets
generated" or "Django
causes a crash".

The people who are responsible for ultimately reviewing and
applying bug
fixes (and, in many cases, evaluating potential solutions
and choosing
the most appropriate) all tend to prioritise, with more or
less success.
We are only human and all do this as a volunteer gig.

Older tickets are in a strange world do get looked at with
an eye to how
to resolve them, simply because it's a good plan to close
off the older
issues. On the other hand, the newer tickets often contain
more direct
bugs and not unreasonably sometimes get prioritised ahead.

If a ticket is still open in Trac, then it is not being
ignored,
usually. It just hasn't been attended to yet. I don't know
of anybody
who approaches bug fixing with a "who can I ignore
today" approach. If a
feature request stands no chance, it will be closed. We use
all the time
we have to fix bugs, any bugs. Even the most trivial
one-line obviously
correct patch takes 10 - 15 minutes to deal with (because
it's never
"obviously correct"). Almost everything takes
longer. Minor things do
get to wait longer and if this turns out to be, for some
reason, a
really big problem for your particular scenario, then you
can patch the
code yourself, as you realise.

Really, we aren't targeting personally as somebody to
neglect and we are
aware of the frustration caused by valid trouble ticket
reports not
being closed quickly. But there are only so many hours in a
day. It's a
big community and there are a lot of bugs / feature requests
/ planned
enhancements and other commitments that all need to be
juggled.

Best wishes,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Sebastian F wrote:
> Another issue was with "BooleanFields". I
noticed they always hit the
> history even if not changed. Someone else had noticed
this too and
> already posted a ticket (http://code
.djangoproject.com/ticket/1511).
> Pretty easy to fix but has been open for 4 months?
>
> These are very small fixes/enchantments but still kind
of frustrating
> to apply them yourself after updating django. So my
question is, what
> is the reason to ignore this kind of tickets?
>   
If you've patched this code in your install why don't you
submit the 
patch to Trac so the developers can review it and possibly
get the fix 
in the next release?  Be pro-active and help the community. 
The sooner 
patches get into these bugs (especially if they're easy)
the sooner 
they'll get closed.

Jay

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Malcolm, everything you said is absolutely true and
reasonable, in general
(actually very self-explanatory). But I was talking about
these particular
cases, not about common development philosophy. I was merely
worried about
how active is the development - after seeing a few character
fix (even if a
trivial one) open for 4 months. Though after signing up to
this mailing list
I can clearly see that there's no reason to worry.

I'm not sure why I didn't realize Jay's suggestion.
Thanks, I'll do that!

Best Regards,
Sebastian

-----Original Message-----
From: django-usersgooglegroups.com [mailto:django-usersgooglegroups.com]
On Behalf Of Malcolm Tredinnick
Sent: 27. heinäkuuta 2006 18:39
To: django-usersgooglegroups.com
Subject: Re: Wondering about few 'burried' issues


On Thu, 2006-07-27 at 03:39 -0700, Sebastian F wrote:
> I have been researching few (web) application
frameworks and
> considering our projects, Django outperforms all of
them easily,
> reflecting exactly what we were going to build (well,
no need to build
> now).
> 
> After playing around with some test applications I
noticed a few
> things, there wasn't a way to represent a model's
field (especially m2m
> fields) with multiple checkboxes in the administration
interface. This
> was weird because there already was a form field
> (CheckboxSelectMultipleField) to render them.

Without thinking too much about this particular case,
realise that
infinite customisability isn't a necessarily good design
goal. It adds a
maintenance burden (there's a whole extra code path that
needs testing
for functionality, presentation and usability), extra
learning needs
(why choose one over the other, the developer will wonder)
and no extra
functionality (you can already select one item from a list
of choices). 

>  Though it was easy to
> extend this functionality, by creating a
'checkbox_admin' argument, I
> didn't like the idea of patching it in after every
django update. So I
> searched the tickets and found out there was also
someone else
> interested in the idea. But then it hit me, ticket was
closed with
> resolution 'wontfix' (http://code
.djangoproject.com/ticket/2004). I am
> curious, why?
> 
> Another issue was with "BooleanFields". I
noticed they always hit the
> history even if not changed. Someone else had noticed
this too and
> already posted a ticket (http://code
.djangoproject.com/ticket/1511).
> Pretty easy to fix but has been open for 4 months?

We have been working on other things in the past four
months.

> These are very small fixes/enchantments but still kind
of frustrating
> to apply them yourself after updating django. So my
question is, what
> is the reason to ignore this kind of tickets?

Community Service Announcement: It is important to
understand the very
difference between "a ticket is being ignored"
(actually pretty rare)
and "a ticket has not been attended to yet".
There are over 400 open
tickets in Trac, of various degrees of impact on end-user
functionality
and/or the code. Boolean field values always appearing in
history is an
extremely minor feature wart. Of all the known problems in
Django, it
just isn't even close to things like "bad SQL gets
generated" or "Django
causes a crash".

The people who are responsible for ultimately reviewing and
applying bug
fixes (and, in many cases, evaluating potential solutions
and choosing
the most appropriate) all tend to prioritise, with more or
less success.
We are only human and all do this as a volunteer gig.

Older tickets are in a strange world do get looked at with
an eye to how
to resolve them, simply because it's a good plan to close
off the older
issues. On the other hand, the newer tickets often contain
more direct
bugs and not unreasonably sometimes get prioritised ahead.

If a ticket is still open in Trac, then it is not being
ignored,
usually. It just hasn't been attended to yet. I don't know
of anybody
who approaches bug fixing with a "who can I ignore
today" approach. If a
feature request stands no chance, it will be closed. We use
all the time
we have to fix bugs, any bugs. Even the most trivial
one-line obviously
correct patch takes 10 - 15 minutes to deal with (because
it's never
"obviously correct"). Almost everything takes
longer. Minor things do
get to wait longer and if this turns out to be, for some
reason, a
really big problem for your particular scenario, then you
can patch the
code yourself, as you realise.

Really, we aren't targeting personally as somebody to
neglect and we are
aware of the frustration caused by valid trouble ticket
reports not
being closed quickly. But there are only so many hours in a
day. It's a
big community and there are a lot of bugs / feature requests
/ planned
enhancements and other commitments that all need to be
juggled.

Best wishes,
Malcolm





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

If we have radio_admin for ForeignKeys (we do), then I
can't see why we
wouldn't want checkbox_admin for M2M.

The danger with ether of these is that it becomes a very
poor UI when
there starts to be more than a handful of choices. But...if
we've
decided it's okay for one, it seems that it ought to be
okay for the
other, too.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---