On Wed, Apr 20, 2011 at 5:44 PM, Carl Meyer wrote:
> So you don't necessarily reproduce it yourself before marking Accepted?
Mm, it depends. Sometimes I don't need to -- it's clearly a bug, and I
see everything I need to track it down. I generally trust that if the
user could be bothered to write
On 04/20/2011 05:38 PM, Jacob Kaplan-Moss wrote:
> * It clearly *is* a bug, and there seems to be a fair bit of
> information (steps to reproduce, the traceback, etc.); these I quickly
> mark "accepted", fix the metadata, and move on.
So you don't necessarily reproduce it yourself before marking
Hi Tino,
On 04/20/2011 05:14 PM, TiNo wrote:
> It takes me, being a newbie at reviewing tickets, quite some more time.
> Would you (or any other core dev / speed reviewer) mind sharing your
> workflow? Any scripts to create environments at certain revisions or
> something alike? Or to quickly run
On Wed, Apr 20, 2011 at 5:24 PM, Luke Plant wrote:
> Hmm, Jacob didn't specifically mention regressions, though in our
> discussions on django-core we did include them.
Yup, sorry - was moving too fast. Regressions, clearly, get backported
-- if something worked in 1.2, it should work in 1.3 unle
On Wed, Apr 20, 2011 at 5:14 PM, TiNo wrote:
> It takes me, being a newbie at reviewing tickets, quite some more time.
> Would you (or any other core dev / speed reviewer) mind sharing your
> workflow? Any scripts to create environments at certain revisions or
> something alike? Or to quickly run
On Wed, Apr 20, 2011 at 5:14 PM, TiNo wrote:
> First of all, this sounds like a nice idea.
>
> On Wed, Apr 20, 2011 at 23:25, Jacob Kaplan-Moss wrote:
>>
>> It takes me about 5 minutes to review most unreviewed tickets
>
> It takes me, being a newbie at reviewing tickets, quite some more time.
>
On 20/04/11 22:37, Tobias McNulty wrote:
> Okay, I do think the regression issue makes a much stronger argument
> than the developer time issue.
>
> I'd be more comfortable if the policy stated that any new bugs
> introduced by the last release would be backported to that release.
> It's possibl
First of all, this sounds like a nice idea.
On Wed, Apr 20, 2011 at 23:25, Jacob Kaplan-Moss wrote:
> It takes me about 5 minutes to review most unreviewed tickets
It takes me, being a newbie at reviewing tickets, quite some more time.
Would you (or any other core dev / speed reviewer) mind sh
On 04/20/2011 04:27 PM, Alex Gaynor wrote:
> Consider me in on the 5-1 offer.
Same here.
Carl
--
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 t
On 04/20/2011 04:37 PM, Tobias McNulty wrote:
> I'd be more comfortable if the policy stated that any new bugs
> introduced by the last release would be backported to that release.
> It's possible that "major functionality bugs in newly-introduced
> features" will equate to virtually the same th
Hi folks --
Just as a quick FYI, I added an official "Easy pickings" field to Trac
to replace the current keyword-tagging thing. I wanted something a bit
more obvious; figured it couldn't hurt.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developer
On Wed, Apr 20, 2011 at 3:56 PM, Paul McMillan wrote:
> +1, I agree with Carl and Luke. The issue here is that for
> non-showstopper bugs, users have probably found (or may even be
> relying on!) the existing behavior. Keeping the "stable" branch more
> stable by only changing things when there's
Dang it, I forgot the most important part: how to *find* tickets to review!
You can find a link to unreviewed tickets at
http://code.djangoproject.com/wiki/Reports (along with a bunch of
other cool canned queries).
Jacob
--
You received this message because you are subscribed to the Google Grou
On Wed, Apr 20, 2011 at 5:25 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> We have a chronic problem: our new ticket review queue. We get roughly
> 50 new tickets each week, and we typically don't keep up with this
> flow very well. Eventually, someone (Hi, Russ!) takes it on himself to
> review
Hi folks --
We have a chronic problem: our new ticket review queue. We get roughly
50 new tickets each week, and we typically don't keep up with this
flow very well. Eventually, someone (Hi, Russ!) takes it on himself to
review the massive backlog, but that's damned painful.
Right now we only hav
On Wed, Apr 20, 2011 at 3:32 PM, Markus Gattol wrote:
> That's certainly a move in the right direction so +1 from me too. The
> problem of
> backporting correlates with how much time passes between any release
> i.e. long time between releases gives bigger pita with backporting.
> Even more so bec
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not goin
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not goin
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not goin
+1, I agree with Carl and Luke. The issue here is that for
non-showstopper bugs, users have probably found (or may even be
relying on!) the existing behavior. Keeping the "stable" branch more
stable by only changing things when there's a serious issue seems to
be a positive improvement.
I think th
Thanks for filing the bug.
It's probably best to discuss higher-level stuff on the mailing list,
and details of the ticket on the ticket. That said, there's a lot of
overlap.
While setting pickle to use a lower protocol would "fix" the problem,
it's really only a bandaid. Lower versions of the pi
Hi Ryan,
On 04/20/2011 10:42 AM, Ryan K wrote:
> Today I discovered behavior similar to that originally reported in
> #15819 (http://code.djangoproject.com/ticket/15819). I've updated it
> with a simple way to reproduce the issue. Could anyone confirm this
> behavior? It's nothing major but it doe
Hi all,
With no objections that weren't addressed, I've committed this change now.
Just to re-iterate - we've switch the admin and other templates to an
HTML5 doctype, but that doesn't mean we are dropping support for older
browsers. We will continue to be selective and conservative in the use
of
Jonathan Slenders writes:
>
> Some concerns, even if I don't know much about the subject.
>
> Are you sure that it's always appropriate to strip indentation?
I didn't say anything about 'always' :)
--
You received this message because you are subscribed to the Google Groups
"Django develop
Today I discovered behavior similar to that originally reported in
#15819 (http://code.djangoproject.com/ticket/15819). I've updated it
with a simple way to reproduce the issue. Could anyone confirm this
behavior? It's nothing major but it does seem that the admin search
behavior changed from 1.2.5
Paul McMillan writes:
> Ah, this does sound like a pretty nasty issue with our code then.
> Unfortunately, the test suite doesn't get run as often as it should
> with the various cache backends enabled, and I imagine that may be how
> this cropped up. There have been a number of similar bugs in t
Hi,
On Apr 20, 8:00 am, legutierr wrote:
> modelform.is_valid() fails to anticipate database integrity errors
> when those errors involve any fields that are not part of that form
> itself.
That is wanted behaviour, eg consider my workflow:
class SomeForm(ModelForm):
class Meta:
exclude =
i've workaround this overloading init, so the other way exist.
But i surprised when not found meta class in simple form (model and
modelform have)
On Apr 20, 3:00 pm, Xavier Ordoquy wrote:
> Le 20 avr. 2011 à 09:22, Constantine a écrit :
>
> > On Apr 20, 12:26 pm, Xavier Ordoquy wrote:
> >> Le 2
Le 20 avr. 2011 à 09:22, Constantine a écrit :
> On Apr 20, 12:26 pm, Xavier Ordoquy wrote:
>> Le 20 avr. 2011 à 05:57, Constantine a écrit :
> ...
>> Actually, I don't understand.
>> If you need object creation, ModelForm is the way to go.
> unfortunately ModelForm is not suitable
>> You could
On Apr 20, 12:26 pm, Xavier Ordoquy wrote:
> Le 20 avr. 2011 à 05:57, Constantine a écrit :
...
> Actually, I don't understand.
> If you need object creation, ModelForm is the way to go.
unfortunately ModelForm is not suitable
> You could also take it the other way. Base form should be the one wit
30 matches
Mail list logo
