Re: GitHub migration planning
Thank you Alex and Max for your responses. -Original Message- From: Alex Ogier Sent: Friday, April 20, 2012 3:15 PM To: django-developers@googlegroups.com Subject: Re: GitHub migration planning On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski wrote: Was BitBucket (mercurial system which is python based) not considered? And could someone point me to a url where I can read the discussion on this migration; I am rather curious why it’s happening – the current system works so I see no reason to fix it. Well there are two somewhat related questions in play. One is moving Django's master repository to Git from SVN. This has a lot of support, as Git is significantly more powerful and many (most?) Django developers already use the Git mirror. The other debate is about switching to Github as a hosting platform. It already hosts the Git mirror, and people regularly submit pull requests, a feature made possible by Git and that is being considered as an alternative to submitting patches. Github Issues are basically unacceptable for Django's process, so they have never been seriously considered as far as I know. There is a large social benefit to leveraging github: there is a large community of developers with established presences there, and making Django accessible to that community is valuable. BitBucket does not have the same social benefits, and all the same drawbacks, so I don't think anyone would seriously advocate moving there. Best, Alex Ogier -- 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. -- 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: GitHub migration planning
On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski wrote: > Was BitBucket (mercurial system which is python based) not considered? And > could someone point me to a url where I can read the discussion on this > migration; I am rather curious why it’s happening – the current system works > so I see no reason to fix it. Well there are two somewhat related questions in play. One is moving Django's master repository to Git from SVN. This has a lot of support, as Git is significantly more powerful and many (most?) Django developers already use the Git mirror. The other debate is about switching to Github as a hosting platform. It already hosts the Git mirror, and people regularly submit pull requests, a feature made possible by Git and that is being considered as an alternative to submitting patches. Github Issues are basically unacceptable for Django's process, so they have never been seriously considered as far as I know. There is a large social benefit to leveraging github: there is a large community of developers with established presences there, and making Django accessible to that community is valuable. BitBucket does not have the same social benefits, and all the same drawbacks, so I don't think anyone would seriously advocate moving there. Best, Alex Ogier -- 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: GitHub migration planning
Paul, I meant no offense. I should have been more clear that I meant my question to explore what makes Trac ideal for Django. My apologies for any misunderstandings. Daniel: Indeed, BitBucket was considered. There's a thread about it from pretty recently here: http://python.6.n6.nabble.com/Moving-to-Github-vs-Bitbucket-td4476484.html Best regards, Max On Fri, Apr 20, 2012 at 2:52 PM, Paul McMillan wrote: > Max, and others on this thread, > > Arguing about the specific mechanics of how github issues work isn't > productive. Put very plainly: > > Django will not move to github issues because they cannot support our > open community triage process. > > This is not negotiable. > > Regards, > -Paul > > -- > 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. > > -- 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: GitHub migration planning
Was BitBucket (mercurial system which is python based) not considered? And could someone point me to a url where I can read the discussion on this migration; I am rather curious why it’s happening – the current system works so I see no reason to fix it. From: Max Thayer Sent: Friday, April 20, 2012 1:26 PM To: django-developers@googlegroups.com Subject: Re: GitHub migration planning Luke, maybe I don't understand something about Trac, but some of the issues raised by you or those you quoted seem easily fixed. Consider: "- there isn't a notion of "component", so there's no way to ask "give me the list of all contrib.auth tickets, so I can find the duplicate quickly";" Why not tag all relevant issues "contrib.auth"? "- it's hard to navigate when there are more than 200 open tickets on a project." There are easily that many open tickets on Trac (a quick look seems to indicate there are about 2k open tickets). What about Trac makes the number of open tickets a non-issue? "- we can't put customized flags on tickets (easy, ui/ux) -- there are tags, but the result of the "Keywords" field in Trac shows the limits of unstructured tags;" Could you explain this more? "customized flag" sounds exactly like a tag. Best regards, Max On Fri, Apr 20, 2012 at 3:21 AM, Luke Plant wrote: On 18/04/12 22:44, philipn wrote: > Hey folks! > > I started a wiki page to help plan a migration to GitHub: > > https://code.djangoproject.com/wiki/GitHub%20Migration > > I don't know what I'm doing, but I do know that the current Trac setup > (attaching patches, etc) is less accessible to non-core contributors > than GitHub and I'd love to do anything I can to help make this better. In discussing the move to GitHub on django-core, we fairly quickly came to the conclusion that we wouldn't be using GitHub issues. One of my major points in this discussion was the need to be able to import our current Trac database, because otherwise we are throwing away a huge amount of important history. As a core committer I regularly trace history to work out why a certain change was made, and often find myself looking at bugs on Trac and reading the discussion there. But importing our Trac database to GitHub issues would be basically impossible as it doesn't support attachments, and various other things - we would lose a huge amount of info if we attempted to port our current Trac database. There were a fair amount of other objections too. Some copy and paste from that thread: Aymeric wrote: """ I just looked at it again and here's what I noticed: - there is no workflow, so we lose the ability for the community to triage tickets; - we can't upload patches (which forces every contributor to sign up for GitHub and learn git) or arbitrary files (like logs, screenshots, tracebacks: not everything is a pull request); - there isn't a notion of "component", so there's no way to ask "give me the list of all contrib.auth tickets, so I can find the duplicate quickly"; - we can't put customized flags on tickets (easy, ui/ux) -- there are tags, but the result of the "Keywords" field in Trac shows the limits of unstructured tags; - it's hard to navigate when there are more than 200 open tickets on a project. """ Justin Bronn wrote: """ GitHub's issue tracker is so much worse than Trac I don't know why we're even considering it. I can attest it has NOT gotten better with age, and large projects on GitHub can't use it either. For example, both Chef and Puppet are hosted on GitHub yet use their own ticket solutions (Puppet uses Redmine, Chef uses Jira). The Pinax folks wrote their own issue system rather than using GitHub's! """ Cheers, Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) 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-developers@googlegroups.com. To unsubscribe from this group, send email to mailto:django-developers%2bunsubscr...@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-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. -- Daniel Sokolowski Web Engineer Danols Web Engineering http://webdesign.danols.com/ Office: 613-817-6833 Fax: 613-817-4553 Toll Free: 1-855-5DANOLS Kingston, ON K7L 1H3, Canada -- You received this message because you are subscribed to the Google Groups "Django dev
Re: GitHub migration planning
Max, and others on this thread, Arguing about the specific mechanics of how github issues work isn't productive. Put very plainly: Django will not move to github issues because they cannot support our open community triage process. This is not negotiable. Regards, -Paul -- 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: GitHub migration planning
Luke, maybe I don't understand something about Trac, but some of the issues raised by you or those you quoted seem easily fixed. Consider: "- there isn't a notion of "component", so there's no way to ask "give me > the list of all contrib.auth tickets, so I can find the duplicate > quickly";" Why not tag all relevant issues "contrib.auth"? "- it's hard to navigate when there are more than 200 open tickets on a > project." There are easily that many open tickets on Trac (a quick look seems to indicate there are about 2k open tickets). What about Trac makes the number of open tickets a non-issue? "- we can't put customized flags on tickets (easy, ui/ux) -- there are > tags, but the result of the "Keywords" field in Trac shows the limits of > unstructured tags;" Could you explain this more? "customized flag" sounds exactly like a tag. Best regards, Max On Fri, Apr 20, 2012 at 3:21 AM, Luke Plant wrote: > On 18/04/12 22:44, philipn wrote: > > Hey folks! > > > > I started a wiki page to help plan a migration to GitHub: > > > > https://code.djangoproject.com/wiki/GitHub%20Migration > > > > I don't know what I'm doing, but I do know that the current Trac setup > > (attaching patches, etc) is less accessible to non-core contributors > > than GitHub and I'd love to do anything I can to help make this better. > > In discussing the move to GitHub on django-core, we fairly quickly came > to the conclusion that we wouldn't be using GitHub issues. > > One of my major points in this discussion was the need to be able to > import our current Trac database, because otherwise we are throwing away > a huge amount of important history. As a core committer I regularly > trace history to work out why a certain change was made, and often find > myself looking at bugs on Trac and reading the discussion there. > > But importing our Trac database to GitHub issues would be basically > impossible as it doesn't support attachments, and various other things - > we would lose a huge amount of info if we attempted to port our current > Trac database. > > There were a fair amount of other objections too. Some copy and paste > from that thread: > > Aymeric wrote: > """ > I just looked at it again and here's what I noticed: > - there is no workflow, so we lose the ability for the community to > triage tickets; > - we can't upload patches (which forces every contributor to sign up for > GitHub and learn git) or arbitrary files (like logs, screenshots, > tracebacks: not everything is a pull request); > - there isn't a notion of "component", so there's no way to ask "give me > the list of all contrib.auth tickets, so I can find the duplicate quickly"; > - we can't put customized flags on tickets (easy, ui/ux) -- there are > tags, but the result of the "Keywords" field in Trac shows the limits of > unstructured tags; > - it's hard to navigate when there are more than 200 open tickets on a > project. > """ > > Justin Bronn wrote: > """ > GitHub's issue tracker is so much worse than Trac I don't know why we're > even considering it. I can attest it has NOT gotten better with age, > and large projects on GitHub can't use it either. For example, both > Chef and Puppet are hosted on GitHub yet use their own ticket solutions > (Puppet uses Redmine, Chef uses Jira). The Pinax folks wrote their own > issue system rather than using GitHub's! > """ > > Cheers, > > Luke > > -- > "My capacity for happiness you could fit into a matchbox without > taking out the matches first." (Marvin the paranoid android) > > 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-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. > > -- 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: #18094: signals, model inheritance, and proxy models
On Apr 12, 10:27 pm, Anssi Kääriäinen wrote: > > So perhaps we do need the signal inheritance behavior to be opt-in when > > connecting the signal handler. I think I'd like to see a deprecation > > path so that eventually the inheritance behavior is the default, and you > > have to opt out of it, as I think in most cases it's the desired behavior. > > Unfortunately this seems to be the only backwards compatible way > forward. I don't know how to do the technical details... from > __future__ import pre_save? :) Could we force the caller to define the wanted signal inheritance mode when .connect() is called? The inherit mode must be one of True,False or None. Default of None means no inheritance (as now) but it will be deprecated. Another problem is that delete fires the same signal multiple times in the inheritance chain. We can't remove the parent signal for backwards compatibility reasons, nor can we fire them as then inheriting listeners will see the delete signals multiple times. Maybe the parent class signal could be sent in a way that it is only visible to those listeners having None as their inherit argument - that is those who use the deprecation mode setting. When the None as argument is removed, so is the parent delete signal, too. The above would lead into clean situation where signals are handled coherently. I know the above is ugly, but it is just for the transition period. Another option is to continue as currently: model signals aren't handled coherently, and there is no signal inheritance. Django users have managed to survive thus far with the current signals implementation, so maybe it doesn't need fixing? Any opinions on the above transition phase idea? Other ideas? Is the "define signal inheritance on connect" the wanted behavior in 1.7 or should it be something else? - Anssi -- 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: Improved assignment_tag
On Apr 19, 6:21 pm, Choongmin Lee wrote: > Is it only me who needs a simple tag with optional assignment, e.g. that > both {% mytag %} and {% mytag as varname %} are possible? > > Attached is a patch that make the assignment optional for assignment_tag. > > If this change of behavior of assignment_tag is not acceptable, then how > about adding a new decorator like 'optional_assignment_tag', or adding a > new parameter to assignment_tag? Please clarify more why and how this should be used, as I don't get the use-case. BTW patches aren't usually attached to django-developers posts, we use Trac for that (https://code.djangoproject.com/). - Anssi -- 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.
Reverse manager assignments doing an implicit save
I was going through ORM tickets marked ready for checkin and stumbled upon ticket #14368. The ticket is about caching of o2o fields. The interesting part is not the caching, but this functionality: class A: pass class B: a = O2O(A, null=True, related_name='b') a1 = A.save() b1 = B.save() # The below does not do a save currently. a1.b = b1 # But after the patch there is an implicit save of b1 The implicit save is implemented because there is a similar functionality for ForeinKeys: >>> someobj.reverse_fk_set = RelatedObj.objects.all() What happens is that the RelatedObj.objects.all() queryset is iterated, and each object of the queryset is saved with the fk changed to point to the someobj. An implicit save again. Now, I don't like the implicit saves at all. A variable assignment should not cause a database save. So, I would like to deprecate the current behavior. Assignment to reverse_fk_set (and I guess this goes for m2m, too) is no longer allowed. Instead you will need to explicitly do: >>> someobj.reverse_fk_set.set(RelatedObj.objects.all()) Now you are calling a method, and saving in this situation is OK and analogous to other related manager methods. Lets raise a deprecation warning on direct assignment to the reverse_fk_set and remove it then in 1.7. The message would be something like "Direct assignment to the reverse side of a related set is deprecated. Use .set() instead. See ... for more details." A related thread discussing this same issue: http://groups.google.com/group/django-developers/tree/browse_frm/thread/634499444687556f#doc_f1a254e8bf4ad8d9 Comments? - Anssi -- 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: GSoC 2012: Security Enhancements
On 16:03 +0100 / 18 Apr, Luke Plant wrote: > On 15/04/12 05:23, Rohan Jain wrote: > > On 22:50 +0100 / 13 Apr, Luke Plant wrote: > >> The reason for the strict referer checking under HTTPS is set out here: > >> > >> https://code.djangoproject.com/wiki/CsrfProtection > >> > >> Particularly, it is to fix the 'CSRF + MITM' attack that is possible > >> under HTTPS. The key elements are set out in the following scenario > >> (although it is not the only variation): > >> > >> - a client connects to a site via HTTP: http://example.com/ > >> - in the response, an active MITM attacker sets a cookie over > >>HTTP for example.com > >> - this cookie will be used by the client when it connects over HTTPS > >>to the same domain (this is the fundamental problem, but we can't > >>fix it - it's what browsers do). > >> - the MITM also inserts a POST form in the HTTP response. > >>The form has a CSRF token that matches the cookie that was > >>set by the attacker. > >>The forms targets https://example.com/ and is automatically > >>submitted by javascript. > >> > >> Without strict referer checking, the POST request will succeed, even > >> though it is forged. > >> > >> Signing the cookie or token value does no good at all, because the > >> attacker can retrieve a valid cookie/token pair directly from > >> https://example.com/. > > > > I am a bit confused about this. How can an attacker extract the token > > out of the signed cookie without the private key? There is a > > possibility that the attacker deletes and sets the cookie right out, > > but since that case won't be correctly signed server can handle it > > securely. > > They don't need to extract the token, they just need to replay an > existing good token/cookie pair, which they can get directly from the > server any time they want. > > (Also, signing does nothing to hide the token. Are you actually talking > about encryption here? But even if you encrypt it, it doesn't help - the > only thing that matters is that the CSRF form token 'matches' the CSRF > cookie, whatever your definition of 'match', and that can be achieved by > getting the pair from the server.) Sorry, my bad. I didn't realize swaying towards encryption. Encryption is something the SoC Ideas page suggests against for CSRF. I am no crypto expert so shouldn't waste time over this I guess. -- Rohan -- 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: GitHub migration planning
On 18/04/12 22:44, philipn wrote: > Hey folks! > > I started a wiki page to help plan a migration to GitHub: > > https://code.djangoproject.com/wiki/GitHub%20Migration > > I don't know what I'm doing, but I do know that the current Trac setup > (attaching patches, etc) is less accessible to non-core contributors > than GitHub and I'd love to do anything I can to help make this better. In discussing the move to GitHub on django-core, we fairly quickly came to the conclusion that we wouldn't be using GitHub issues. One of my major points in this discussion was the need to be able to import our current Trac database, because otherwise we are throwing away a huge amount of important history. As a core committer I regularly trace history to work out why a certain change was made, and often find myself looking at bugs on Trac and reading the discussion there. But importing our Trac database to GitHub issues would be basically impossible as it doesn't support attachments, and various other things - we would lose a huge amount of info if we attempted to port our current Trac database. There were a fair amount of other objections too. Some copy and paste from that thread: Aymeric wrote: """ I just looked at it again and here's what I noticed: - there is no workflow, so we lose the ability for the community to triage tickets; - we can't upload patches (which forces every contributor to sign up for GitHub and learn git) or arbitrary files (like logs, screenshots, tracebacks: not everything is a pull request); - there isn't a notion of "component", so there's no way to ask "give me the list of all contrib.auth tickets, so I can find the duplicate quickly"; - we can't put customized flags on tickets (easy, ui/ux) -- there are tags, but the result of the "Keywords" field in Trac shows the limits of unstructured tags; - it's hard to navigate when there are more than 200 open tickets on a project. """ Justin Bronn wrote: """ GitHub's issue tracker is so much worse than Trac I don't know why we're even considering it. I can attest it has NOT gotten better with age, and large projects on GitHub can't use it either. For example, both Chef and Puppet are hosted on GitHub yet use their own ticket solutions (Puppet uses Redmine, Chef uses Jira). The Pinax folks wrote their own issue system rather than using GitHub's! """ Cheers, Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) 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-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.