Re: Is the Oracle backend passing the model_forms_regress test?

[Matt Boersma]

On May 6, 2009, at 8:50 PM, Karen Tracey  wrote:

> On Wed, May 6, 2009 at 10:34 PM, Leo Soto M.   
> wrote:
>
> While testing the django-jython oracle backend I get an ugly failure
> on model_forms_regress,

Yes, I saw this too.  I'll check in a fix tomorrow a.m. if no one  
beats me to it.

>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Is the Oracle backend passing the model_forms_regress test?

[Leo Soto M.]

While testing the django-jython oracle backend I get an ugly failure
on model_forms_regress, caused by the usage of the "date" keyword as a
field name (in this case, the date field on the Publication model,
added on the test while fixing
).

I wonder if it is also failing on the cx_Oracle backend, as I don't
see any new relevant code which protect against those cases. (Ref:
)

Regards,
-- 
Leo Soto M.
http://blog.leosoto.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reduce bug triage overhead: DjangoAwesomeBot

[Henrique Romano]

On May 6, 2009, at 7:23 AM, Russell Keith-Magee wrote:
> Like many things, it sounds like a good idea, but the devil is in the
> details. A tool like this is really only useful if it provides triage
> data that is both accurate and useful. Here's a quick checklist of the
> basic questions a manual triager needs to answer:
>
> 1. Does the patch apply cleanly?
> 2. Does the patch contain a test?
> 3. Does the test fail if the rest of the patch isn't applied?
> 4. Does it pass when the test is applied?
> 5. Does the patch only solve the surface problem, or does an
> underlying problem exist that needs fixing.
> 6. Does the patch contain documentation?
>
> Now, some complications:
> (1) is something that isn't that has an absolute answer - a patch may
> apply to revision X, but may not apply cleanly to revision X+N. This
> point needs to be re-established periodically.

IMO, it will be always a problem (with our without automation)... what  
happens if a patch doesn't apply when it is approved for commit? Do  
you ask for a new patch?


> (2) requires inspection of the patch contents, but that bit isn't too
> hard. However, there are conditions where not having a patch is
> acceptable (things that aren't particularly testable, such as command
> line behaviour), so the non-existence of a test doesn't necessarily
> mean that a patch isn't ready for commit.

Agreed, but the bot should not include the "ready for commit" keyword  
(maybe a "accepted by bot"), since there are others questions to  
consider. About the test itself, I would say that we can use test  
coverage to see if the lines changed were executed by the test suite.

> You also need to consider the fact that Trac doesn't much automated
> metadata to interpret which patches are valid at any given time. A
> complex ticket may have multiple patches, only some of which will
> apply at any given time; in addition, there may be competing
> approaches being discussed, so multiple tickets may be valid.

I think that even tickets being solved by many patches, each patch  
should work alone... but I'm not sure if it is case for django  
development.

> That doesn't mean there isn't a place for a bot like you describe.
> We're all in favor of any tool that will make the triage process
> easier - however, you need to be clear about what the bot will
> contribute to the process before you embark on building a complex
> tool.

Right. I'll write the initial bot work in the project page to validate  
the idea.

--
Henrique


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.1 Release Update

[George Song]

On 5/5/2009 9:20 PM, Tarun Pasrija wrote:
> I recently checked the schedule for Django 1.1 final release and the
> website says April 13th.
> 
> http://code.djangoproject.com/wiki/Version1.1Roadmap.
> 
> Are there any updates about the change in schedule and when is the
> final going to be released?

Also if you have the know-how and the time, no better way to help 
release it by tackling:


-- 
George

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Need Django Developer urgent

[haur]

不好意思，偶又幼稚咯。。。

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.1 Release Update

[Alex Gaynor]

On Wed, May 6, 2009 at 6:20 AM, Tarun Pasrija wrote:

>
> Hi All
>
> I recently checked the schedule for Django 1.1 final release and the
> website says April 13th.
>
> http://code.djangoproject.com/wiki/Version1.1Roadmap.
>
> Are there any updates about the change in schedule and when is the
> final going to be released?
>
> Thanks and Regards
> Tarun Pasrija
>
> >
>
1.1 final will be released once we are confident we have all the critical
bugs out.  Sprints will be taking place at EuroDjangocon tomorrow and the
day after to further this goal.  Other than, it will be ready when it's
ready (it sucks to hear that for what should be a time based release, but
you can't release with certain bugs, and they take time to fix).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Need Django Developer urgent

[Alex Gaynor]

2009/5/6 Yeh, Kenzou K.F. 

>
> Hello there,
>
> Actually i come from Taiwan, and i' m a software engineer.
>
> i am programmer, used to coding with c/c++, java, python, ruby. So
> nice to meet you.   : )
>
>
> 在 2009/5/6 下午 12:08000 時， haur 寫到：
>
> > hello , i'am in china
> >
> > i'am  a  pythoner ~~
> >
> >
> > uses python, django, nginx and so on.
> >
> > >
>
>
> >
>
As I've said, this is not the right place for any of these discussions.
Please take them to the appropriate forum.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Feeds refactoring

[daonb]

Hi all,
I'm a part of the Django user group in Israel and we want to have our
own project, taking a part of the Django project and improving it.
I've discussed it with Jacob, Adrian and Alex yesterday and they all
agreed that the feeds module needs refactoring.
So, if you're working on it now or if you have some design thoughts
please share.

Thanks,

Benny

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Need Django Developer urgent

[Yeh, Kenzou K.F.]

Hello there,

Actually i come from Taiwan, and i' m a software engineer.

i am programmer, used to coding with c/c++, java, python, ruby. So  
nice to meet you.   : )


在 2009/5/6 下午 12:08000 時， haur 寫到：

> hello , i'am in china
>
> i'am  a  pythoner ~~
>
>
> uses python, django, nginx and so on.
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Django 1.1 Release Update

[Tarun Pasrija]

Hi All

I recently checked the schedule for Django 1.1 final release and the
website says April 13th.

http://code.djangoproject.com/wiki/Version1.1Roadmap.

Are there any updates about the change in schedule and when is the
final going to be released?

Thanks and Regards
Tarun Pasrija

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reduce bug triage overhead: DjangoAwesomeBot

[Almad]

On 6 Kvě, 12:23, Russell Keith-Magee  wrote:
> On Wed, May 6, 2009 at 7:53 AM, Henrique Romano  wrote:
> Like many things, it sounds like a good idea, but the devil is in the
> details. A tool like this is really only useful if it provides triage
> data that is both accurate and useful. Here's a quick checklist of the
> basic questions a manual triager needs to answer:
>
>  1. Does the patch apply cleanly?
>  2. Does the patch contain a test?
>  3. Does the test fail if the rest of the patch isn't applied?
>  4. Does it pass when the test is applied?
>  5. Does the patch only solve the surface problem, or does an
> underlying problem exist that needs fixing.
>  6. Does the patch contain documentation?

Agreed, exactly was I was thinking about.

> Now, some complications:
> (1) is something that isn't that has an absolute answer - a patch may
> apply to revision X, but may not apply cleanly to revision X+N. This
> point needs to be re-established periodically.

Agreed. Well I can think about having it fancier, but for basic I'd
say it's enough to check periodically.

(Pony thought: Database with what files are affected by which patch,
scan timeline every night, check what files were affected by commits,
re-run check for patches that affect those files too)

> (2) requires inspection of the patch contents, but that bit isn't too
> hard. However, there are conditions where not having a patch is
> acceptable (things that aren't particularly testable, such as command
> line behaviour), so the non-existence of a test doesn't necessarily
> mean that a patch isn't ready for commit.

IMO command line is also testable, althrough in an ugly way. Anyway;
we should then create like "test required for this patch" trac
checkbox, or just have "ready for bot" triage state only for more
complicated and tests-requiring patches.

> (3) and (4) require a buildbot to do automatically.

I think about this tool as not a part of buildbot set and I don't
think it require buildbot. This can be done on any machine with
sanitized environment and do not require talking to buildbot.

My idea is a bot that sits in the working directory of django trunk,
applying patches for real, introspecting results by really running
tests and svn st, and reporting results as oomments to the ticket
directly in trac.

> (5) requires human analysis.

Oh I wish I could automate that ;)

> (6) requires inspection of the patch. Again, depending on the ticket,
> non-existence of docs may not be an problem, depending on the ticket.
>
> So - of the 6 tasks, only (1) can be done automatically, and even then
> it needs to be updated regularly. (2), (5) and (6) require human
> evaluation; (3) & (4) require a lot of infrastructure.

AFAIK 3 and 4 require no infrastructure from Django itself and (2) and
(6) could be easily determined if You will have a bot report (patch do
not contain tests & docs and You can see from ticket desc it should be
required).

> You also need to consider the fact that Trac doesn't much automated
> metadata to interpret which patches are valid at any given time. A
> complex ticket may have multiple patches, only some of which will
> apply at any given time; in addition, there may be competing
> approaches being discussed, so multiple tickets may be valid.

For start, I'd say applying latest diff should be enough. For future,
I'd say we want to have special triage state for "ready for bot" and
"bot approved" (easy with trac 0.11 custom workflow) and at this
state, discussion should be resolved.

I don't think it make so much sense for us to try patches that are not
in their final shape.

> That doesn't mean there isn't a place for a bot like you describe.
> We're all in favor of any tool that will make the triage process
> easier - however, you need to be clear about what the bot will
> contribute to the process before you embark on building a complex
> tool.

Like I said, IMHO it can be made a bit easier by some "convention
instead of configuration" decisions.

But yes, still work it is.

> Yours,
> Russ Magee %-)

Almad

P.S.: I just learned Eric has some pieces of this functionality
already and he's intrested in building some functionality during EDC
sprints.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reduce bug triage overhead: DjangoAwesomeBot

[Almad]

On May 6, 1:53 am, Henrique Romano  wrote:
> On May 5, 2009, at 7:03 PM, Jacob Kaplan-Moss wrote:
> It seems a good idea, and IMHO we should try to start implementing  
> something.  I've created a project at google code named django-triage-
> bot, if anyone is interested.

I decided I'd actually like to implement 'triage it for me' part for
trac in general, like

trac-trage 1109

that will download the ticket to my current directory and run the
stuff.

So if someone will implement the 'search for ticket candidates in
django trac' and 'report results', it would be nice.

> Is everybody happy with this triage automation?

That's what I've been originally asking, but as I learned, It's
impossible to judge without proof-of-concept.

> Henrique

Almad

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DatabaseWrapper operators

[Clément Nodet]

Hi,

I'm not sure this mailing list is the best place to discuss further
that topic, I guess you'll get more feedback on
http://forums.mysql.com/ if you want to keep going in the collation
direction, or on django-users.

Anyway, on that 'ś' problem, you should know more or less the full
list of polish characters and their english counterpart you want to
have equality for. I suggest you do some tests using different
built-in collations (utf8_general_ci, utf8_unicode_ci, utf8_polish_ci,
cp1250_general_ci, cp1250_polish_ci, etc.) to see if one of those
matches exactly your needs.

Well, there might also be none. But in that case, there's a
straightforward solution, just define your own collation. In MySQL 5
you don't need to recompile if you want to add a new collation based
on utf8_unicode_ci. Have a look at those links :
http://forge.mysql.com/w/images/b/b7/HowToAddACollation.pdf
http://dev.mysql.com/doc/refman/5.0/en/adding-collation-unicode-uca.html
http://unicode.org/reports/tr35/

Then you can keep tables text field in a 'regular' polish collation,
but use the custom one for search queries.
--
Clément

2009/5/6 pbzRPA :
>
> Hi,
>
> Thanks for the advice, it has solved some of my problem but the "ś"
> for example still does not get found when looking for "s".
>
> But it's a step in the right direction. :)
>
> 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-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---