Re: index_together should also have the same convinience as unique_together
On 2 mars 2014, at 02:40, Josh Smeaton wrote: > At the very least it might be a good middle ground to tag PRs with "Requires > Work" or "Not Ready", so they can be easily filtered out from "active" PRs. > On the other hand, there could be a strange mix of Trac and the PR queue > containing conflicting information. In short, Django uses PRs for code review, and nothing else. The status of a PR is defined by the status of the Trac ticket that contains a link to that PR. The ticket lifecycle is explained in the contributing guide. GitHub's issues / PR system is designed for small projects. It's improductive and impractical to look at the list of pull requests and work from there. So we don't do that. If you need to filter tickets, do it in Trac. In detail, we cannot make a better use of PRs because GitHub's UX is pathetic as soon as you have more than two dozen PRs. Having brought the number of issues on the Django Debug Toolbar down from 150 to 20, I have first hand experience of banging my head against GitHub Issues on a projet much smaller than Django, but already too large for GitHub. It's simply impossible to navigate issues efficiently when all you have is binary open / close (and contributors can't reopen when you close), tags (if you emulate state with tags, some tickets end up with multiple states and others with no state), pagination hardcoded at 30 per page, and that's it. Also, if I remember correctly, we cannot receive notifications on the django-updates mailing list when someone makes a pull request, which doesn't help. I wish I could say "sure, we'll give you access, show us how it would work" but that would mean giving you commit access to Django. At that point, we're hitting the other big limitation of GitHub: if you aren't a committer, you cannot do anything for a projet. But Django relies a lot on its broader community. So, once again, if you'd like to clarify the status of issues, the place to do it is Trac. (Triagers get a few extra permissions, just ask if you want them.) I hope this helps you understand our choices better. I wish we could do everything on GitHub, but our body of knowledge is in Trac and its features simply blow GitHub out of the water. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4EB58E53-8EAD-418C-B01F-7FB4EF76CAE6%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: The model API and strong typing
On 2 mars 2014, at 08:49, Shai Berger wrote: > On Saturday 01 March 2014 19:07:08 Aymeric Augustin wrote: > >> You should never, ever, for any reason, use a different database in >> development, test and production. It's a bad idea. It doesn't work. >> > ... except when you're developing for more than one database. Then you're > allowed to use just one in development Fair enough. > but you should have CI covering all your targets for testing. Separating > testing from production really has no excuse, AFAICT. I've heard about a web framework that doesn't have CI for all its targets... ;-) -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4EF0DEA9-1577-452E-9978-5E4AC1938B16%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: The model API and strong typing
On Sunday 02 March 2014 10:24:13 Aymeric Augustin wrote: > On 2 mars 2014, at 08:49, Shai Berger wrote: > > On Saturday 01 March 2014 19:07:08 Aymeric Augustin wrote: > >> You should never, ever, for any reason, use a different database in > >> development, test and production. It's a bad idea. It doesn't work. > > > > ... except when you're developing for more than one database. Then you're > > allowed to use just one in development > > Fair enough. > > > but you should have CI covering all your targets for testing. Separating > > testing from production really has no excuse, AFAICT. > > I've heard about a web framework that doesn't have CI for all its > targets... ;-) We tried, and we'll keep trying. And actually, I do run CI for the missing target, it's just not public. But yes, as you said: Fair enough. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201403021030.34091.shai%40platonix.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: index_together should also have the same convinience as unique_together
Good points all. Looking more closely at Trac, the combinations of "has patch" "patch needs improvement" and "ready for checkin" fields should cover the status of PRs. I'll try to set some time aside to go through the PRs and check that the status in Trac matches. Though thinking about it, going through 100-odd PRs and checking if they apply cleanly seems like a daunting task. Is there anyway of indicating that a patch needs a review? Or is simply setting "ready for checkin" a good enough signal? Cheers On Sunday, 2 March 2014 19:15:43 UTC+11, Aymeric Augustin wrote: > > On 2 mars 2014, at 02:40, Josh Smeaton > > wrote: > > > At the very least it might be a good middle ground to tag PRs with > "Requires Work" or "Not Ready", so they can be easily filtered out from > "active" PRs. On the other hand, there could be a strange mix of Trac and > the PR queue containing conflicting information. > > > In short, Django uses PRs for code review, and nothing else. The status of > a PR is defined by the status of the Trac ticket that contains a link to > that PR. The ticket lifecycle is explained in the contributing guide. > > GitHub's issues / PR system is designed for small projects. It's > improductive and impractical to look at the list of pull requests and work > from there. So we don’t do that. If you need to filter tickets, do it in > Trac. > > In detail, we cannot make a better use of PRs because GitHub’s UX is > pathetic as soon as you have more than two dozen PRs. Having brought the > number of issues on the Django Debug Toolbar down from 150 to 20, I have > first hand experience of banging my head against GitHub Issues on a projet > much smaller than Django, but already too large for GitHub. It’s simply > impossible to navigate issues efficiently when all you have is binary open > / close (and contributors can’t reopen when you close), tags (if you > emulate state with tags, some tickets end up with multiple states and > others with no state), pagination hardcoded at 30 per page, and that’s it. > Also, if I remember correctly, we cannot receive notifications on the > django-updates mailing list when someone makes a pull request, which > doesn’t help. > > I wish I could say “sure, we’ll give you access, show us how it would > work” but that would mean giving you commit access to Django. At that > point, we’re hitting the other big limitation of GitHub: if you aren’t a > committer, you cannot do anything for a projet. But Django relies a lot on > its broader community. So, once again, if you’d like to clarify the status > of issues, the place to do it is Trac. (Triagers get a few extra > permissions, just ask if you want them.) > > I hope this helps you understand our choices better. I wish we could do > everything on GitHub, but our body of knowledge is in Trac and its features > simply blow GitHub out of the water. > > -- > Aymeric. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2842db27-a723-4f33-a4ec-8cfe70bccc3d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: index_together should also have the same convinience as unique_together
On 2 mars 2014, at 09:59, Josh Smeaton wrote: > Is there anyway of indicating that a patch needs a review? Or is simply > setting "ready for checkin" a good enough signal? "Ready for checkin" means that you have reviewed the patch and you think it's complete and correct. If the patch applies cleanly but you haven't looked at it, the correct status is "Accepted" + "has patch". That combination implies that the patch needs a review. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01E7E11B-2EFA-4F0E-BCBE-0541B0E5E0C0%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6 reverse() escapes unreserved chars in path components
I wasn't expressing an opinion either way; just adding the relevant commit to the conversation. Looks like RFC 3986 is the relevant RFC describing the permitted characters in URIs, specifically section 2.2 and 2.3 - http://tools.ietf.org/html/rfc3986#section-2.2 It seems like the fix makes it easier for 90% of the uses, but explicitly blocks the other 10% (i.e. uses involving the use of 'reserved' characters as permitted by the RFC). The relevant django-developers discussion is here - https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ The final post addresses this issue, but doesn't seem to have been taken into account when the patch was accepted. On 2 March 2014 12:28, Erik van Zijst wrote: > On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai wrote: >> The relevant commit and issue - >> >> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7 >> https://code.djangoproject.com/ticket/13260 > > Yes I saw that, but I'm confused. I thought these characters are > allowed unescaped in path segments. > > >> On 1 March 2014 17:26, Erik van Zijst wrote: >>> Django's django.core.urlresolvers.reverse() seems to have changed its >>> behavior in 1.6. It now runs the arguments through quote(), without >>> specifying the safe characters for path components. As a result: >>> >>> on 1.4.10: >>> In [2]: reverse('test', args=['foo:bar']) >>> Out[2]: '/foo:bar' >>> >>> but on 1.6.2: >>> In [2]: reverse('test', args=['foo:bar']) >>> Out[2]: '/foo%3Abar' >>> >>> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are >>> all allowed unescaped in path segments AFAIK. >>> >>> Cheers, >>> Erik >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to django-developers+unsubscr...@googlegroups.com. >>> To post to this group, send email to django-developers@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Django developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/django-developers/ZLGk7T4mJuw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com. >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CA%2B69USsj%2BuWHJJfw7-Fr8SFq34Xq0TLThR3Bq2t3r66K9oAFrw%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABxbXqU903Ry9x04%2Bu%2B%2BVaQKnrHH2e1mLwXkjr2YenhYku%2Bsng%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Django 1.7: modelformset_factory() vs formset_factory()
Now that formset_factory() from 1.7 accept num_min and validate_min arguments, shouldn't modelformset_factory() also support those same arguments to allow them to be passed onto formset_factory()? *Anders Steinlein* *Eliksir AS* http://e5r.no E-post: and...@e5r.no Mobil: +47 926 13 069 Twitter: @asteinlein -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC35HNn1y93TRBhHyqXQAUR2tMpYoke7u--muma1edxm5mnQjg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.7: modelformset_factory() vs formset_factory()
Yes, see https://code.djangoproject.com/ticket/17642. If you can bring the patch up to date in the next day or two, I'll try to help review and commit it. > On Sunday, March 2, 2014 2:05:56 PM UTC-5, Anders Steinlein wrote: Now that formset_factory() from 1.7 accept num_min and validate_min > arguments, shouldn't modelformset_factory() also support those same > arguments to allow them to be passed onto formset_factory()? > > *Anders Steinlein* > *Eliksir AS* > http://e5r.no > > E-post: and...@e5r.no > Mobil: +47 926 13 069 > Twitter: @asteinlein > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ffb28253-c649-4c52-bb3c-171bc119e813%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.7: modelformset_factory() vs formset_factory()
On Sun, Mar 2, 2014 at 8:27 PM, Tim Graham wrote: > Yes, see https://code.djangoproject.com/ticket/17642. If you can bring > the patch up to date in the next day or two, I'll try to help review and > commit it. > Thanks. I'll try to get that done. Cheers, Anders -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC35HN%3DFFyVDCD8tG79-QTLhRm4dQWX33t75mn0c7rvCufhr3w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
interested in joining django-developers
I know python, c,c ++ and trying to learn django. Can you(mentors) tell me what more i should learn to join this project. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a04651ab-bd73-4a29-b8bc-2f8fdf03fe25%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: interested in joining django-developers
On Sunday, March 2, 2014 12:34:29 PM UTC-8, sameer kumar wrote: > > I know python, c,c ++ and trying to learn django. > Can you(mentors) tell me what more i should learn to join this project. > While it might take a while for someone to become a core Django developer, anyone can contribute to the project. There are all sorts of bugs to fix in Django, for your fix to be accepted it should be solid code with passing tests. Here is a link to the FAQ on contributing to the Django project. https://docs.djangoproject.com/en/1.6/internals/contributing/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d0fabc85-b797-495d-b322-40e8fb89e84c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.