Re: GitHub migration planning

2012-04-20 Thread Daniel Sokolowski 

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

2012-04-20 Thread Alex Ogier 
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

2012-04-20 Thread Max Thayer 
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

2012-04-20 Thread Daniel Sokolowski 
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

Re: GitHub migration planning

2012-04-20 Thread Paul McMillan 
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

2012-04-20 Thread Max Thayer 
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

2012-04-20 Thread Anssi Kääriäinen 
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

2012-04-20 Thread Anssi Kääriäinen 
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

2012-04-20 Thread Anssi Kääriäinen 
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

2012-04-20 Thread Rohan Jain 
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

2012-04-20 Thread Luke Plant 
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.