Re: #12012 Logging: request for comments

[Ian Lewis]

Not sure I ever understood what Bikeshedding means properly, but fair
enough. My point was more to break it up the logging level by 2/3/400
classes of HTTP status codes and log each status code class with the
same logging level.

On Wed, Sep 29, 2010 at 1:06 AM, Alex Gaynor  wrote:
> I don't see how a 302 because someone posted something is any less debug
> thann the 200 to serve thhhe get.
>
> Bikesheddinngly yours,
> Alex
>
> On Sep 28, 2010 11:45 AM, "Ian Lewis"  wrote:
>
> Hi,
>
> On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips
>  wrote:
>> I'm worried by ...
>
> I'm split on this myself but I think making all 400 level responses warnings
> would keep things consistent and help find potential security issues easier.
>
> Something like
>
> 5xx = error
> 4xx = warning
> 3xx = info
> 2xx (>300) = debug
>
> would be very easy to understand and the desired request logging is easy
> to set up using logging levels.
>
> --
> Ian
>
> http://www.ianlewis.org/
>
> --
> 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.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Ian

http://www.ianlewis.org/

-- 
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.

No caching if request.GET not empty

[Thomas Guettler]

Hi,

I got not response on django-users, now I ask here:

requests with a query string (http://example.com?foo=bar) are not cached in 
Django:

http://code.djangoproject.com/browser/django/trunk/django/middleware/cache.py
{{{
if not request.method in ('GET', 'HEAD') or request.GET:
request._cache_update_cache = False
return None # Don't bother checking the cache.
}}}

If the query string would be used in _generate_cache_key() (utils/cache.py),
requests with a not empty request.GET could be cached.

I see no reason, not to cache requests with a query string.

Can someone explain this?

I read the documentation[1], but couldn't find a hint way GET requests
with a query string are not cached.

Should I open a ticket?

[1] cache docs: http://docs.djangoproject.com/en/dev/topics/cache/

  Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
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.

Re: No caching if request.GET not empty

[Mikhail Korobov]

Hi Thomas,

there is a ticket for that:

http://code.djangoproject.com/ticket/4992


On 29 сен, 16:36, Thomas Guettler  wrote:
> Hi,
>
> I got not response on django-users, now I ask here:
>
> requests with a query string (http://example.com?foo=bar) are not cached in 
> Django:
>
> http://code.djangoproject.com/browser/django/trunk/django/middleware/...
> {{{
>         if not request.method in ('GET', 'HEAD') or request.GET:
>             request._cache_update_cache = False
>             return None # Don't bother checking the cache.
>
> }}}
>
> If the query string would be used in _generate_cache_key() (utils/cache.py),
> requests with a not empty request.GET could be cached.
>
> I see no reason, not to cache requests with a query string.
>
> Can someone explain this?
>
> I read the documentation[1], but couldn't find a hint way GET requests
> with a query string are not cached.
>
> Should I open a ticket?
>
> [1] cache docs:http://docs.djangoproject.com/en/dev/topics/cache/
>
>   Thomas
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de

-- 
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.

Re: [Contact form] change Ukrainian locale

[Jeremy Dunck]

Oleksandr,
  I've forwarded this to django-developers@googlegroups.com which is
the more appropriate forum.

  Please join that list to participate in the discussion.

On Wed, Sep 29, 2010 at 8:31 AM,   wrote:
> From: Oleksandr 
>
> Please change Ukrainian locale form uk to ua
> ua - is right
> uk - in not very right  - uk is the united kingdom
>
> Thanks
>

-- 
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.

Re: Application, tempaltetags and namespace

[Mathieu Leduc-Hamel]

Cool, than from what i see it seems the namespacing will be more and
more implemented in Django in the future.

But as a good practice, it would be cool if it's finally happen to
force any templatetags to be used with namespace ? Cause if people can
use the old way to do things, we'll still have the same problem
related to conflicting names no?

On Mon, Sep 27, 2010 at 10:56 AM, Iván Raskovsky  wrote:
> On Mon, Sep 27, 2010 at 3:14 AM, Russell Keith-Magee
>  wrote:
>> On Mon, Sep 27, 2010 at 1:43 PM, Mathieu Leduc-Hamel  
>> wrote:
>>> Hi all,
>>>
>>> I'm curious to know if it's planned in the future to force the use of
>>> the complete name of the applications and the templatestags. I'll
>>> explain myself.
>> There are two tickets related to this problem:
>>
>> #2539: Namespacing for template tags
>> #12772: Loading by fully qualified path name
>>
>> Template tag namespacing has been accepted as an idea; it's just
>> waiting on a trunk-ready patch.
>>
>> Loading by fully qualified path is currently marked DDN; On principle,
>> the idea seems sound to me, but it requires more thought in terms of
>> how the new loading scheme will interact with existing code.
>
> I've proposed a solution[1] some time ago, where I also gathered all
> the discussions on the topic I could find. Sadly I got no feedback.
>    Iván
>
> [1] 
> http://groups.google.com/group/django-developers/browse_thread/thread/da9ed3a3116c546a/88d0d780a5e9d09f?lnk=gst&q=namespaces#88d0d780a5e9d09f
>
> --
> 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.
>
>



-- 
Mathieu Leduc-Hamel

-- 
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.

Re: [Contact form] change Ukrainian locale

[Jannis Leidel]

On 29.09.2010, at 15:44, Jeremy Dunck wrote:

> Oleksandr,
>  I've forwarded this to django-developers@googlegroups.com which is
> the more appropriate forum.
> 
>  Please join that list to participate in the discussion.
> 
> On Wed, Sep 29, 2010 at 8:31 AM,   wrote:
>> From: Oleksandr 
>> 
>> Please change Ukrainian locale form uk to ua
>> ua - is right
>> uk - in not very right  - uk is the united kingdom

"uk" is the correct language code according to ISO 639-1 [1], while "ua" is the 
country code according to ISO 3166 [2].


Best,
Jannis

1: http://en.wikipedia.org/wiki/ISO_639-1
2: http://en.wikipedia.org/wiki/ISO_3166

-- 
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.

Re: [Contact form] change Ukrainian locale

[Tom Evans]

The language code for Ukranian is uk:

http://www.iana.org/assignments/language-subtag-registry

Type: language
Subtag: uk
Description: Ukrainian
Added: 2005-10-16
Suppress-Script: Cyrl

UA is the country code for the Ukraine.

Cheers

Tom

On Wed, Sep 29, 2010 at 2:44 PM, Jeremy Dunck  wrote:
> Oleksandr,
>  I've forwarded this to django-developers@googlegroups.com which is
> the more appropriate forum.
>
>  Please join that list to participate in the discussion.
>
> On Wed, Sep 29, 2010 at 8:31 AM,   wrote:
>> From: Oleksandr 
>>
>> Please change Ukrainian locale form uk to ua
>> ua - is right
>> uk - in not very right  - uk is the united kingdom
>>
>> Thanks
>>
>
> --
> 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.
>
>

-- 
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.

Re: #12012 Logging: request for comments

[Russell Keith-Magee]

On Wed, Sep 29, 2010 at 5:43 PM, Ian Lewis  wrote:
> Not sure I ever understood what Bikeshedding means properly, but fair
> enough.

For the history and meaning of the term, see here:

http://bikeshed.com/

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 at 
http://groups.google.com/group/django-developers?hl=en.

be localflavor Belgium

[Laurent Luce]

Hello,

I created a patch to add support for Belgium to localflavor. I
attached the patch to a ticket which is marked as accepted. The patch
contains the forms fields, unit tests and the doc changes.

What do I need to do next ? Wait for someone to review the patch and
commit it ?

Laurent

-- 
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.

ANN: Improving our decision-making and committer process

[Jacob Kaplan-Moss]

Hi folks --

Starting today, we're going to be making some minor but significant changes
to the way the Django core committer team "does business."

Put simply, we're changing the way we make decisions so that we can make
important policy and design calls more quickly and easily. In a nutshell:

* We're substantially reducing the number of decisions that Adrian and I
  need to make as BDFLs, thus removing us as a decision-making bottleneck.

* We're cutting back on our reliance on consensus for decision making,
  thus ensuring that decisions can be made in a timely manner.

* Finally -- and I think most importantly -- we're relaxing our policy on
  adding new core committers.

I've just made a couple of changes [1] to our "Contributing to Django"
guide [2] which explain these changes; read them if you want the short
explanation of the new rules.

[1] http://code.djangoproject.com/changeset/13962
[2] http://docs.djangoproject.com/en/dev/internals/contributing/

For those who've been following our development process closely -- and
calling for these kind of changes for quite some time -- I'll explain some
of the background and ramification in more detail below.

Some background
---

The discussion leading to these changes began with conversations Russ had
at DjangoCon. I wasn't there, but he reported that there was a repeated and
general dissatisfaction with the activity and responsiveness of the core
team. I don't think this came as a surprise to any of us. I, at least, have
felt like we've been lax in our responsibilities lately.

Now, I don't really care to examine the merits of individual complaints or
make excuses/explanations for the lack of time and attention the core
team's been paying. Any way you cut it, it's clear that the core team --
and Adrian and I in particular -- have some work to do to regain the
confidence and trust of the community.

It's clear this won't happen overnight, and I don't expect the changes
we're making today to magically grant us that confidence back. Instead, I
see these changes as the first step in a general process towards more
openness and inclusiveness in Django's development process.

Making decisions


One of the main reasons we've ended up in this situation is our decision
making process. When we first came up with Django's development process,
Django was a tiny project with a handful of developers and a
not-much-larger group of users. In that context, decision by consensus made
some sense, but it simply doesn't scale as the number of participants increases.

In particular, our reliance on consensus means that any developer can
accidentally execute a veto simply by not having time to participate in
discussions!

We've always had the "out" of appealing to Adrian or I for a BDFL decision.
However, that, too, did't scale as the number of decisions-to-be-made
increased (and our own spare time decreased).

So we've adopted a new, simple, streamlined voting process. This deals with
situations where we can't reach a quick consensus, and it cuts out the
requirement that Adrian and/or I rule on each and every decision.

This new process allows a proposal to be carried if:

* There are at least 3 "+1" votes from core committers.
* There are no "-1" votes from core committers.
* A BDFL hasn't issued a ruling on the issue.

Since this process allows any core committer to veto a proposal, any "-1"
votes (or BDFL vetos) should be accompanied by an explanation that explains
what it would take to convert that "-1" into at least a "+0".

More details are in the contributor doc, but in essence this means that we
can move forward without needing to wait for the entire core team to weigh
in. It does maintain our fairly skeptical attitude towards feature-creep by
allowing any one contributor to object if something rubs him/her the wrong
way, but it also forces that contributor to explain how she/he may be
overruled.

With luck, we'll see the pace of development speed up a bit as a result.

I should stress that this voting procedure DOES NOT replace community
discussion, nor does it remove entirely the desire for consensus. In other
words, this new process is a new way to "break ties" without having to ask
for a BDFL ruling. Whenever possible, we should continue to strive to reach
consensus on issues, and use the voting process only as a fallback where
consensus can't be reached for whatever reason. I, at least, plan to vote
"-1" if I see community discussion being skipped, or if I see no attempt at
consensus before a vote.

Committers
--

It's been clear for quite some time that there's a really right bottleneck
at the top of the project: we simply don't have enough committers. The
issue of adding new ones comes up fairly regularly, but has never come to
any conclusion.

We've deliberately set the bar for new contributors quite high: new
committers required unanimous approval of all existing committers. We've
resisted lowering that bar out of a fear th

Re: be localflavor Belgium

[Gert Van Gool]

IMHO I would allow a non-spaced version. My typing my phone number as
0498725202 should also work.
Second thing, wrap the long lines :)

Relevant ticket is #14349 (http://code.djangoproject.com/ticket/14349)

-- Gert

Mobile: +32 498725202
Twitter: @gvangool 
Web: http://gert.selentic.net



On Wed, Sep 29, 2010 at 18:26, Laurent Luce  wrote:

> Hello,
>
> I created a patch to add support for Belgium to localflavor. I
> attached the patch to a ticket which is marked as accepted. The patch
> contains the forms fields, unit tests and the doc changes.
>
> What do I need to do next ? Wait for someone to review the patch and
> commit it ?
>
> Laurent
>
> --
> 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.
>
>

-- 
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.

A few thoughts on Process 2 cents

[dartdog]

I attended a Wordcamp recently (yeh, the dark side) but I was very
interested that they only have 7-8 core comitters they add feature
specific people for short, release cycles for specific features,, that
sounds sort of odd,, but I think the most interesting thing was that
that sub divide the responsibility to a large degree so that it is
clearer to the outside who does which area. So DB is on person Front-
end another admin another, of course there is overlap. but I think
that might be worth exploring as an element of scaling so that not all
issues are treated as core.. Increasingly there will be more and more
subsystems that can have something of their own teams??

According to the Wordpress comitter @nacin , Drupal has only 4 or
so...

So by these metrics Django's 14 or so looks pretty good...

So maybe subdividing the areas of responsibility might help? I know it
is generally recognized that certain comitters have specific expertise
but it might make it easier to shore up some of the bus areas like the
orm as well if the teams are more clearly understood?

Clearly I'm new and have no current aspirations to committing (still
working on using!)

-- 
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.

Re: A few thoughts on Process 2 cents

[Jacob Kaplan-Moss]

On Wed, Sep 29, 2010 at 1:34 PM, dartdog  wrote:
> So maybe subdividing the areas of responsibility might help? I know it
> is generally recognized that certain comitters have specific expertise
> but it might make it easier to shore up some of the bus areas like the
> orm as well if the teams are more clearly understood?

Yes, I agree that as we start to open up more it'll make a lot more
sense to have more area-specific committers. If someone's well-versed
in the admin, a lack of interest in the ORM certainly shouldn't be an
issue.

Jacob

-- 
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.

Re: Class based models

[subs...@gmail.com]

Hmm... I do see what you're saying.

The line in question, however, should respect subclasses. So your
example wouldn't fail in the case of a proper subclass.

I checked out that thread and I saw Russel commented on it and
ironically he mentioned contrib.comments as well.

One thing you say is 'providing abstract models feels really awkward'--
Why?

It seems like you almost want an 'attributes_for' option in the model
Meta options whereby one model can stand-in for another model. Still,
a lot of your proposal seems to rely on a developer's 'best
practices'--aka something akin to contrib.comments' get_model() use in
views and form (which can't be codified with patches, really).

-Steve

PS: One nag I have about get_model() is that is singular. Sure,
contrib.comments happens to only have one extensible but what about
when there's more?

On Sep 27, 5:45 pm, Klaas van Schelven 
wrote:
> There's a quite a few things that I don't like about the get_model
> approach. I'll focus on one though: contrib.comment's own models do
> not respect it.
>
> Consider a customized model for comments (the model MyComment in
> my_comments)
> so in settings.py we put:
> COMMENTS_APP = 'my_comments'
>
> then we do the following:
> from django.contrib.comments.models import CommentFlag
> flag = CommentFlag()
> from django.contrib.comments import get_model
> mycomment = get_model().objects.get()
> flag.comment = mycomment
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "...django/db/models/fields/related.py", line 318, in __set__
>     self.field.name, self.field.rel.to._meta.object_name))
> ValueError: Cannot assign "":
> "CommentFlag.comment" must be a "Comment" instance.
>
> You see the problem? Any help thinking about the solution is much
> appreciated.
>
> Klaas
>
> On Sep 27, 7:57 pm, "subs...@gmail.com"  wrote:
>
>
>
> > I thought that's what get_model did?
>
> > You specify your own comments app and register your own (subclass or
> > other) model within that function and its used throughout the original
> > app.
>
> > On Sep 27, 3:02 am, Klaas van Schelven 
> > wrote:
>
> > > On Sep 27, 4:17 am, "subs...@gmail.com"  wrote:
>
> > > > I may be dense but is this the functional equiv of cobtrib.comments
> > > > get_model()?
>
> > > Nope.
> > > Rather, it's a way to subclass models that are provided by reusable
> > > apps, and letting the reusable app use the subclassed instance
> > > throughout.
>
> > > > On Sep 26, 8:28 am, Klaas van Schelven 
> > > > wrote:
>
> > > > > Hi all,
>
> > > > > I'm looking for a bit of input for making Django's apps a bit more
> > > > > extendable, either by modifying Django or (preferably) by coming up
> > > > > with a common language on top op Django. The main painpoint are
> > > > > extendable models. The idea of 'extendable' is that models from
> > > > > reusable apps can be extended in any concrete project. The reusable
> > > > > apps should refer to their own models in such a way that they will get
> > > > > the concrete implementation (extension).
> > > > > Class based models if you will.
>
> > > > > Context can be found 
> > > > > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > > > > Currently, apps usually refer to their own models by simply importing
> > > > > them from models.py and referring to them. This obviously will not
> > > > > work, so any solution will need some kind of registry, or instance of
> > > > > "app". If "app" is an instance of a class referring to it can be done
> > > > > in an extendible way (simply by using Python's inheritance mechanism).
>
> > > > > I've put an example of this approach 
> > > > > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > > > > Which incorporates the above idea of an app class & instance in blog/
> > > > > __init__.py.
>
> > > > > abstract_blog/abstract_models.py and blog/models.py
>
> > > > > The key sections are:
> > > > > (in abstract_models)
>
> > > > >     def get_AbstractPage(self):
> > > > >         class AbstractPage(models.Model):
> > > > >             body = models.TextField()
> > > > >             category = models.ForeignKey(self.app.models.Category)
>
> > > > >             class Meta:
> > > > >                 abstract = True
> > > > >                 #app_label = 'abstract_blog'
> > > > >         return AbstractPage
> > > > >     AbstractPage = property(get_AbstractPage)
>
> > > > > (in models)
> > > > >     def get_Category(self):
> > > > >         class Category(self.AbstractCategory):
> > > > >             some_added_field = models.IntegerField()
> > > > >         return Category
> > > > >     Category = property(get_Category)
>
> > > > > As you can see, it is possible to refer to "the apps real
> > > > > implementation of Category" (self.app.models.Category, or just
> > > > > self.Category) from the abstract model. Less neat: the cruft that's
> > > > > needed to pass self into AbstractPage for reference (3 lines per
> > > > > clas

Re: be localflavor Belgium

[Laurent Luce]

I added a new patch to the ticket with the following changes:
add support for 0, 04 phone number format. Wrap long
lines.

Laurent

On Sep 29, 11:23 am, Gert Van Gool  wrote:
> IMHO I would allow a non-spaced version. My typing my phone number as
> 0498725202 should also work.
> Second thing, wrap the long lines :)
>
> Relevant ticket is #14349 (http://code.djangoproject.com/ticket/14349)
>
> -- Gert
>
> Mobile: +32 498725202
> Twitter: @gvangool 
> Web:http://gert.selentic.net
>
> On Wed, Sep 29, 2010 at 18:26, Laurent Luce  wrote:
> > Hello,
>
> > I created a patch to add support for Belgium to localflavor. I
> > attached the patch to a ticket which is marked as accepted. The patch
> > contains the forms fields, unit tests and the doc changes.
>
> > What do I need to do next ? Wait for someone to review the patch and
> > commit it ?
>
> > Laurent
>
> > --
> > 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.

-- 
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.

Re: A few thoughts on Process 2 cents

[subs...@gmail.com]

Speaking of which... who is interested in admin these days? Been
trying to scare up some feedback @ http://code.djangoproject.com/ticket/5833
for some time now.

On Sep 29, 2:39 pm, Jacob Kaplan-Moss  wrote:
> sense to have more area-specific committers. If someone's well-versed
> in the admin, a lack of interest in the ORM certainly shouldn't be an

-- 
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.

Re: A few thoughts on Process 2 cents

[Jacob Kaplan-Moss]

On Wed, Sep 29, 2010 at 3:21 PM, subs...@gmail.com  wrote:
> Speaking of which... who is interested in admin these days? Been
> trying to scare up some feedback @ http://code.djangoproject.com/ticket/5833
> for some time now.

Please don't derail threads with unrelated topics like this. It makes
discussions really hard to follow. Thanks.

Jacob

-- 
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.

Re: A few thoughts on Process 2 cents

[subs...@gmail.com]

Sorry about that. I was actually kind of interested in whether the
'process' aspect of admin (and possibly other contrib apps?) had
undergone any changes, given that I've heard some sentiment about
people hoping contrib was 'approaching zero'.

-Steve

On Sep 29, 4:39 pm, Jacob Kaplan-Moss  wrote:
> On Wed, Sep 29, 2010 at 3:21 PM, subs...@gmail.com  wrote:
> > Speaking of which... who is interested in admin these days? Been
> > trying to scare up some feedback @http://code.djangoproject.com/ticket/5833
> > for some time now.
>
> Please don't derail threads with unrelated topics like this. It makes
> discussions really hard to follow. Thanks.
>
> Jacob

-- 
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.

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

Hello Jacob and everyone.

On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:

Starting today, we're going to be making some minor but significant changes
to the way the Django core committer team "does business."


That's about time :-). Congratulations and thank you!

I have a comment and a suggestion:


This new process allows a proposal to be carried if:

* There are at least 3 "+1" votes from core committers.
* There are no "-1" votes from core committers.
* A BDFL hasn't issued a ruling on the issue.


This doesn't explain what's one is supposed to think in situation when a 
proposal is ignored by core devs, which may happen for all sorts of 
reasons. I suspect that "less than 3 +1 votes" means the same as any -1 
vote but I think that an explicit clarification would be nice.


---

My suggestion is about this unfortunate ticket status -- 'Accepted'. 
This now works as a sort of a dusty shelf: when anyone of the core team 
looks at the patch and decides that there's nothing wrong with it he 
puts it on that shelf where the ticket has all the chances to lie for 
months or even years. And if the author of the patch tries from time to 
time pitching it to get it into trunk he can easily fall into all sorts 
of "not-a-good-times": conferences, feature freezes, hot discussions on 
other topics etc.


My proposal is simple: 'Accepted' status shouldn't exist. If the patch 
is good it should be committed right away. If it's not there have to be 
an explanation why it needs improvement or why it's going to be 
wontfixed. Simple waiting doesn't really improve quality of the patch.


What do you think?

--
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.

Re: ANN: Improving our decision-making and committer process

[Chuck Harmston]

In my world, the "accepted" status should only be used in one circumstance:
when a person is actively developing under or maintaining a patch for the
ticket. It's an indicator that someone has taken ownership of a ticket, to
prevent duplication of effort, etc. For example, I accepted ticket #25
during the DjangoCon sprints to prevent other developers at the sprints from
attempting to develop against the ticket.

Then again, my world also has purple skies and orange grass, so take it with
a grain...errr, a bushel of salt. ;)

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com


On Wed, Sep 29, 2010 at 5:32 PM, Ivan Sagalaev
wrote:

> Hello Jacob and everyone.
>
>
> On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:
>
>> Starting today, we're going to be making some minor but significant
>> changes
>> to the way the Django core committer team "does business."
>>
>
> That's about time :-). Congratulations and thank you!
>
> I have a comment and a suggestion:
>
>
>  This new process allows a proposal to be carried if:
>>
>> * There are at least 3 "+1" votes from core committers.
>> * There are no "-1" votes from core committers.
>> * A BDFL hasn't issued a ruling on the issue.
>>
>
> This doesn't explain what's one is supposed to think in situation when a
> proposal is ignored by core devs, which may happen for all sorts of reasons.
> I suspect that "less than 3 +1 votes" means the same as any -1 vote but I
> think that an explicit clarification would be nice.
>
> ---
>
> My suggestion is about this unfortunate ticket status -- 'Accepted'. This
> now works as a sort of a dusty shelf: when anyone of the core team looks at
> the patch and decides that there's nothing wrong with it he puts it on that
> shelf where the ticket has all the chances to lie for months or even years.
> And if the author of the patch tries from time to time pitching it to get it
> into trunk he can easily fall into all sorts of "not-a-good-times":
> conferences, feature freezes, hot discussions on other topics etc.
>
> My proposal is simple: 'Accepted' status shouldn't exist. If the patch is
> good it should be committed right away. If it's not there have to be an
> explanation why it needs improvement or why it's going to be wontfixed.
> Simple waiting doesn't really improve quality of the patch.
>
> What do you think?
>
>
> --
> 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.
>

-- 
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.

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:40 AM, Chuck Harmston wrote:

In my world, the "accepted" status should only be used in one
circumstance: when a person is actively developing under or maintaining
a patch for the ticket. It's an indicator that someone has taken
ownership of a ticket, to prevent duplication of effort, etc. For
example, I accepted ticket #25 during the DjangoCon sprints to prevent
other developers at the sprints from attempting to develop against the
ticket.


I believe the field 'Assigned to' works just fine for this purpose, no?

--
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.

Re: ANN: Improving our decision-making and committer process

[Luke Plant]

On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:

> My suggestion is about this unfortunate ticket status -- 'Accepted'. 
> This now works as a sort of a dusty shelf: when anyone of the core team 
> looks at the patch and decides that there's nothing wrong with it he 
> puts it on that shelf where the ticket has all the chances to lie for 
> months or even years. And if the author of the patch tries from time to 
> time pitching it to get it into trunk he can easily fall into all sorts 
> of "not-a-good-times": conferences, feature freezes, hot discussions on 
> other topics etc.
> 
> My proposal is simple: 'Accepted' status shouldn't exist. If the patch 
> is good it should be committed right away. If it's not there have to be 
> an explanation why it needs improvement or why it's going to be 
> wontfixed. Simple waiting doesn't really improve quality of the patch.
> 
> What do you think?

This doesn't account for these facts:

1) Accepted != Ready for checkin.
2) A lot of triage is done by people without commit access.

Sometimes a ticket stays at 'Accepted' for a long time because it
doesn't actually have anyone motivated enough to write even a patch, or
tests etc, which means that it is de-facto low priority, and we
shouldn't feel guilty about this kind.  The ones in the 'Ready for
checkin' queue are the ones that deserve to be checked in, and it
currently has only 35 in it, compared to 1226 in 'Accepted'.

However, there are many 'Accepted' tickets which actually ought to be in
'Ready for checkin', or need some feedback to say what should be done to
move them on.  This is not something that can only be done by
committers, but how to get help with this massive task is still a big
problem. It's quite possible for someone using Django to submit a
completely valid bug report, with a good patch and tests etc., and for
it not to get reviewed because no-one else in the community cares about
that particular bug, and I for one don't know what to do about that.

The core team do agree that the "it's not a good time" response has been
an unhelpful sticking point, and we probably need to make it easier for
people to discuss things at any point in time.

Luke

-- 
"Defeat: For every winner, there are dozens of losers.  Odds are 
you're one of them." (despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
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.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>
>> My suggestion is about this unfortunate ticket status -- 'Accepted'.
>> This now works as a sort of a dusty shelf: when anyone of the core team
>> looks at the patch and decides that there's nothing wrong with it he
>> puts it on that shelf where the ticket has all the chances to lie for
>> months or even years. And if the author of the patch tries from time to
>> time pitching it to get it into trunk he can easily fall into all sorts
>> of "not-a-good-times": conferences, feature freezes, hot discussions on
>> other topics etc.
>>
>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch
>> is good it should be committed right away. If it's not there have to be
>> an explanation why it needs improvement or why it's going to be
>> wontfixed. Simple waiting doesn't really improve quality of the patch.
>>
>> What do you think?
>
> This doesn't account for these facts:
>
> 1) Accepted != Ready for checkin.
> 2) A lot of triage is done by people without commit access.
>
> Sometimes a ticket stays at 'Accepted' for a long time because it
> doesn't actually have anyone motivated enough to write even a patch, or
> tests etc, which means that it is de-facto low priority, and we
> shouldn't feel guilty about this kind.  The ones in the 'Ready for
> checkin' queue are the ones that deserve to be checked in, and it
> currently has only 35 in it, compared to 1226 in 'Accepted'.

This is an important stat -- but it glosses over the fact that 1226
"accepted" tickets doesn't necessarily clarify how many of these have
viable patches -- or patches at all.

Accepted tickets can be:

 * Purely accepted, indicating that someone has verified that the
problem exists, but not how to solve it

 * Accepted with a patch that is wrong in some way (e.g., fixing the
symptom, not the problem)

 * Accepted with a patch that is missing documentation or tests

 * Accepted with a valid patch, just awaiting review by someone else.

A ticket in the first three conditions patently isn't ready for
checkin. A ticket in the last condition *may* be ready for checkin; we
ask for independent verification before it gets moved to RFC.

So - IMHO "Accepted" plays a very important role in our triage system.
I don't think it can be eliminated without overloading a different
area of the ticket system.

> However, there are many 'Accepted' tickets which actually ought to be in
> 'Ready for checkin', or need some feedback to say what should be done to
> move them on.  This is not something that can only be done by
> committers, but how to get help with this massive task is still a big
> problem. It's quite possible for someone using Django to submit a
> completely valid bug report, with a good patch and tests etc., and for
> it not to get reviewed because no-one else in the community cares about
> that particular bug, and I for one don't know what to do about that.

There was some work done at DjangoCon to try and provide a voting
extension to Trac. The aim here would be to provide a way for people
to register "I've been bitten by this bug", so we can get a list of
issues ordered by how many people are being affected. This will
hopefully provide some direction to triage (and committer) activity so
that the "most important" tickets get addressed first.

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 at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Waylan Limberg]

On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee
 wrote:
> On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
>> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>>
>>> My suggestion is about this unfortunate ticket status -- 'Accepted'.
>>> This now works as a sort of a dusty shelf: when anyone of the core team
>>> looks at the patch and decides that there's nothing wrong with it he
>>> puts it on that shelf where the ticket has all the chances to lie for
>>> months or even years. And if the author of the patch tries from time to
>>> time pitching it to get it into trunk he can easily fall into all sorts
>>> of "not-a-good-times": conferences, feature freezes, hot discussions on
>>> other topics etc.
>>>
>>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch
>>> is good it should be committed right away. If it's not there have to be
>>> an explanation why it needs improvement or why it's going to be
>>> wontfixed. Simple waiting doesn't really improve quality of the patch.
>>>
>>> What do you think?
>>
>> This doesn't account for these facts:
>>
>> 1) Accepted != Ready for checkin.
>> 2) A lot of triage is done by people without commit access.
>>
>> Sometimes a ticket stays at 'Accepted' for a long time because it
>> doesn't actually have anyone motivated enough to write even a patch, or
>> tests etc, which means that it is de-facto low priority, and we
>> shouldn't feel guilty about this kind.  The ones in the 'Ready for
>> checkin' queue are the ones that deserve to be checked in, and it
>> currently has only 35 in it, compared to 1226 in 'Accepted'.
>
> This is an important stat -- but it glosses over the fact that 1226
> "accepted" tickets doesn't necessarily clarify how many of these have
> viable patches -- or patches at all.
>
> Accepted tickets can be:
>
>  * Purely accepted, indicating that someone has verified that the
> problem exists, but not how to solve it
>
>  * Accepted with a patch that is wrong in some way (e.g., fixing the
> symptom, not the problem)
>
>  * Accepted with a patch that is missing documentation or tests
>
>  * Accepted with a valid patch, just awaiting review by someone else.
>
> A ticket in the first three conditions patently isn't ready for
> checkin. A ticket in the last condition *may* be ready for checkin; we
> ask for independent verification before it gets moved to RFC.

So, in other words, accepted simply means that the ticket reports a
valid bug or feature request that is considered worth fixing, but
offers to indication as to the status of any patches for committing.
Obviously, some seem to imply the later meaning into "Accepted" which
could raise the question regarding whether it is named correctly (I
say it is fine). But, more importantly, is there a place were each
status is simply defined?

Sure there is this:
http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

But that hardly makes clear exactly what "accepted" actually means.
The text in that section is helpful to understanding the basic
process, but if someone changes the status of my ticket, there's no
definitive place to go and see exactly what that status means.

In fact, in reading the list over the last few years, I have the
impression that this is a problem that is repeated constantly. People
don't understand what the various statuses mean and get frustrated
when things do not happen as they expected. I think perhaps clearer
documentation would help in this case.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

-- 
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.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thu, Sep 30, 2010 at 9:14 AM, Waylan Limberg  wrote:
> On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee
>  wrote:
>> On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
>>> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>>>
 My suggestion is about this unfortunate ticket status -- 'Accepted'.
 This now works as a sort of a dusty shelf: when anyone of the core team
 looks at the patch and decides that there's nothing wrong with it he
 puts it on that shelf where the ticket has all the chances to lie for
 months or even years. And if the author of the patch tries from time to
 time pitching it to get it into trunk he can easily fall into all sorts
 of "not-a-good-times": conferences, feature freezes, hot discussions on
 other topics etc.

 My proposal is simple: 'Accepted' status shouldn't exist. If the patch
 is good it should be committed right away. If it's not there have to be
 an explanation why it needs improvement or why it's going to be
 wontfixed. Simple waiting doesn't really improve quality of the patch.

 What do you think?
>>>
>>> This doesn't account for these facts:
>>>
>>> 1) Accepted != Ready for checkin.
>>> 2) A lot of triage is done by people without commit access.
>>>
>>> Sometimes a ticket stays at 'Accepted' for a long time because it
>>> doesn't actually have anyone motivated enough to write even a patch, or
>>> tests etc, which means that it is de-facto low priority, and we
>>> shouldn't feel guilty about this kind.  The ones in the 'Ready for
>>> checkin' queue are the ones that deserve to be checked in, and it
>>> currently has only 35 in it, compared to 1226 in 'Accepted'.
>>
>> This is an important stat -- but it glosses over the fact that 1226
>> "accepted" tickets doesn't necessarily clarify how many of these have
>> viable patches -- or patches at all.
>>
>> Accepted tickets can be:
>>
>>  * Purely accepted, indicating that someone has verified that the
>> problem exists, but not how to solve it
>>
>>  * Accepted with a patch that is wrong in some way (e.g., fixing the
>> symptom, not the problem)
>>
>>  * Accepted with a patch that is missing documentation or tests
>>
>>  * Accepted with a valid patch, just awaiting review by someone else.
>>
>> A ticket in the first three conditions patently isn't ready for
>> checkin. A ticket in the last condition *may* be ready for checkin; we
>> ask for independent verification before it gets moved to RFC.
>
> So, in other words, accepted simply means that the ticket reports a
> valid bug or feature request that is considered worth fixing, but
> offers to indication as to the status of any patches for committing.
> Obviously, some seem to imply the later meaning into "Accepted" which
> could raise the question regarding whether it is named correctly (I
> say it is fine). But, more importantly, is there a place were each
> status is simply defined?
>
> Sure there is this:
> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage
>
> But that hardly makes clear exactly what "accepted" actually means.
> The text in that section is helpful to understanding the basic
> process, but if someone changes the status of my ticket, there's no
> definitive place to go and see exactly what that status means.
>
> In fact, in reading the list over the last few years, I have the
> impression that this is a problem that is repeated constantly. People
> don't understand what the various statuses mean and get frustrated
> when things do not happen as they expected. I think perhaps clearer
> documentation would help in this case.

A reasonable suggestion if ever I've heard one. I've opened a ticket
to track the idea:

http://code.djangoproject.com/ticket/14360

and I've put it on the 1.3 milestone; if anyone wants to take a swing
a clarifying the language before I (or someone else on the core team)
gets a chance to look at it, feel free.

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 at 
http://groups.google.com/group/django-developers?hl=en.

rethinking raw_id_fields

[subs...@gmail.com]

Hello all,

I was browsing the tickets and saw a few of them nagging about some
restrictions to raw_id_fields. That they are limited to other objects
registered in admin, that they are limited arbitrarily (relative to a
regular FK) by the permissions of the user, etc. Personally, I find
the little changelist window that pops up a bit awkward and hackish-
looking.

Might a better approach be to have a django-admin view which uses
content-types to generate a list of the objects in question? If
someone can give me a simple yes, no, etc, I'd be willing to do the
necessary ticket-work and come up with a patch for review.

-- 
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.