Pull django-registration into contrib?

[Robert Grant]

Hello all

I've just started using Django for a serious project and am really enjoying 
using it; thank you.

I'm using Django 1.6 and Python 3.4. For user signups, everyone recommends 
using django-registration. However this is not under active development 
 (still 
works with a small code change) and as a budding Djangoer that worries me 
twice:

1) as a developer, it makes my job much easier if standard functions are 
provided. This is one of the (only) advantages of expensive corporate 
tools; things such as registration and user management are well thought 
through.
2) as a Django fan (edjangalist?) I can already see that one of Django's 
big advantages is that decent user management comes built in. However it's 
not complete, and django-registration plugs a big hole, as most websites 
will need this feature.  Without it the user side of things becomes less 
useful.

Here's my proposal:

Create a django.contrib.registration package.
Pull into it the existing django-registration code and update it to work 
with the latest version of Django.
Keep it tightly in sync with changes to django.contrib.auth in the future.
Add more flexibility, e.g. corporate options such as perhaps an admin user 
can input email addresses of people to sign up, and the system generates 
basic unactivated profiles that when triggered allow the users to then fill 
in their remaining details (for example, this is how JIRA works). And/or 
autodiscovery of users from LDAP settings and autopopulation of user models 
from LDAP queries. This may be too unfocussed for the team though; it's 
just a very nice to have!

Anyway, that's my idea. I'm worried that as over time django-registration 
drifts farther from the current version of Django, the amount of work 
developers have to do every time will increase to the point where it's 
better for them to roll their own than try and work out how Django 1.5 
worked with django-registration and what they need to do to patch the 
differences. This will lead to developers - who are attracted to Django 
because of useful stuff such as this - abandoning the platform for ones 
that provide benefits in other areas.

Thanks for reading


Robert Grant

-- 
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/6b097c64-7ab6-4d95-bf19-f7bf3bccad75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Tim Graham]

If no one has volunteered to maintain it in nearly a year since James 
stepped down, I think you'll have a tough time convincing us it's important 
enough to move into contrib. Also, the recent trend has been to remove 
things from contrib (comments, localflavor, formtools soon). 
django-registration has been viable as a third party package for a long 
time and I don't see a reason it couldn't continue as one.

On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:
>
> Hello all
>
> I've just started using Django for a serious project and am really 
> enjoying using it; thank you.
>
> I'm using Django 1.6 and Python 3.4. For user signups, everyone recommends 
> using django-registration. However this is not under active development 
>  (still 
> works with a small code change) and as a budding Djangoer that worries me 
> twice:
>
> 1) as a developer, it makes my job much easier if standard functions are 
> provided. This is one of the (only) advantages of expensive corporate 
> tools; things such as registration and user management are well thought 
> through.
> 2) as a Django fan (edjangalist?) I can already see that one of Django's 
> big advantages is that decent user management comes built in. However it's 
> not complete, and django-registration plugs a big hole, as most websites 
> will need this feature.  Without it the user side of things becomes less 
> useful.
>
> Here's my proposal:
>
> Create a django.contrib.registration package.
> Pull into it the existing django-registration code and update it to work 
> with the latest version of Django.
> Keep it tightly in sync with changes to django.contrib.auth in the future.
> Add more flexibility, e.g. corporate options such as perhaps an admin user 
> can input email addresses of people to sign up, and the system generates 
> basic unactivated profiles that when triggered allow the users to then fill 
> in their remaining details (for example, this is how JIRA works). And/or 
> autodiscovery of users from LDAP settings and autopopulation of user models 
> from LDAP queries. This may be too unfocussed for the team though; it's 
> just a very nice to have!
>
> Anyway, that's my idea. I'm worried that as over time django-registration 
> drifts farther from the current version of Django, the amount of work 
> developers have to do every time will increase to the point where it's 
> better for them to roll their own than try and work out how Django 1.5 
> worked with django-registration and what they need to do to patch the 
> differences. This will lead to developers - who are attracted to Django 
> because of useful stuff such as this - abandoning the platform for ones 
> that provide benefits in other areas.
>
> Thanks for reading
>
>
> Robert Grant
>

-- 
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/d000a15d-0723-41f5-a4b6-5ac18642e7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we use a django application class?

[Robert Grant]

Just had some thoughts about why having an application object might be a 
good idea. Pick away :)


   - Individual app objects could perhaps be introspected more easily, e.g. 
   stop, start, restart functions provided for them. Also circular dependency 
   detection etc, for impact analysis.
   - Apps could have the chance to declare their inputs and outputs, and 
   what parts of other apps they override (e.g. I override template xyz from 
   the default Django installation). Then it's easy to build up a picture 
   (possibly literally) with all the apps together and what overrides what, 
   and even control which gets priority programmatically. E.g. I don't want to 
   always override the admin screen's change password function, as the admin 
   should see it with consistent look and feel to the rest of that app, but 
   for logged in users I want them to see a different change password screen.
   - Related to this - I've been bitten before by declaring my apps in the 
   wrong order in my settings file. Having programmatic access might solve the 
   problem of "I want one part of this app's code to have priority over 
   Django's default, but I want another part to not override Django."
   - Being able to declare dependencies at the app level means I can import 
   an "app type" in my code and just declare which app solves that in the site 
   settings file.
   - The previous point is a self-supporting but special case which could 
   be more broadly solved with dependency injection. This app relies on this 
   type of app, etc. Good for testing and mocking, CI etc. Possibly Python IS 
   the general case of a DI framework here, but possibly not. For example, 
   rather than having a special caching framework setting, one could have a 
   Redis caching app, that wraps all communication to Redis, and another 
   caching app for memcached. Switching between the two would just mean 
   importing a declared app dependency (e.g. import thecache) and declaring it 
   in DI code: import blah.redis \ export('thecache' redis.cachewrapper). I 
   know the special case of caching configuration has been solved in Django, 
   but that may not be necessary if this more general mechanism were available.

-- 
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/f00aeaf8-b340-4315-8c4c-b53cb2050364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

querry to pass jquery variable value to django template, please responce me need help one of yours...

[Jaiprakash Singh]

hello all,  


i am  working on  project for learning purpose,  i have got stuck  on a 
small logic , i have tried lot to find the solution  , 
gone to url like 

http://www.sprklab.com/notes/13-passing-arguments-to-functions-in-django-template
http://www.tangowithdjango.com/book/chapters/ajax.html
and  many more 

unfortunately, i am not able find the solution, so require some hints from 
all of  u guys

so i m applying a logic under following

1) i m selecting a option form a select menu
2) on select the option eant to get the selected value
3) now this selected , i want to pass through a template tag  for query 
purpose from database.


my small part of logic is under 

###


Select Class
Class I
Class II
   
 


##


$( ".target" ).change(function () {
var id = $(this).val();
var dataString = 'id='+ id;

{% get_latest bookstoreapp.Book 5 as recent_posts %}>>> i want 
to use above $id or id instead of 5  here 

})



 

for more info sending my templates/get_latest.py
#

from django.template import Library, Node
from django.db.models import get_model

register = Library()

class LatestContentNode(Node):

def __init__(self, model, num, varname):
self.num, self.varname = int(num), varname
self.model = get_model(*model.split('.'))


def render(self, context):
context[self.varname] = self.model.objects.filter(pk = self.num)
return ''


def get_latest(parser, token):
bits = token.contents.split()

if len(bits) != 5:
raise TemplateSyntaxError, "get_latest tag takes exactly four 
arguments"

if bits[3] != 'as':
raise TemplateSyntaxError, "third argument to get_latest tag must 
be 'as'"
 
   return LatestContentNode(bits[1], bits[2], bits[4])


get_latest = register.tag(get_latest)

3


please help guys...


 

-- 
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/8fd1a136-30d1-4ca8-a45d-45428e026b96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: querry to pass jquery variable value to django template, please responce me need help one of yours...

[Daniele Procida]

On Fri, Aug 1, 2014, Jaiprakash Singh  wrote:

>unfortunately, i am not able find the solution, so require some hints from 
>all of  u guys

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20140801130123.447258122%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Robert Grant]

Hi Tim

Thanks for the reply. I'd say that it's only been viable so far because 
James created and maintained it (for most of that long time), it's only 
been a year since then and Django is pretty stable around users and 
authentication.  And even then people have forked the thing to Github to 
create ad-hoc compatible versions for 1.6, because it's a very important 
package. However, this isn't a stable situation; it was once, but now is 
going to decay without proper maintenance.

The reason why I think it should be pulled into contrib is because 
registration goes hand in hand with changes to the way users and 
authentication work in Django, and keeping the two in lockstep should be 
relatively simple for those with an intimate knowledge of that part of 
Django. Additionally, I think it's a key reason why people use Django, and 
protecting features like that is important.

Lastly, regarding the trend. South has been viable as a third party tool 
for a long time, and has said "buck you" to the trend and made it all the 
way into core. Which is great, because it means Django competes at the 
highest levels in ORM, and that's another key reason to use Django.

I suppose what I'm saying is that not everyone uses Django for love or 
loyalty, or at least not to start with, and you have to pick which things 
to maintain as its strengths and which to let go of to the community. 
Coming from the outside, but having a fair amount of technology dev, design 
and decision experience, I'd say having proper users and authentication 
makes for a big, fairly rare distinguishing feature, and reliable 
registration capabilities are an important complement to that.


On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote:
>
> If no one has volunteered to maintain it in nearly a year since James 
> stepped down, I think you'll have a tough time convincing us it's important 
> enough to move into contrib. Also, the recent trend has been to remove 
> things from contrib (comments, localflavor, formtools soon). 
> django-registration has been viable as a third party package for a long 
> time and I don't see a reason it couldn't continue as one.
>
> On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:
>>
>> Hello all
>>
>> I've just started using Django for a serious project and am really 
>> enjoying using it; thank you.
>>
>> I'm using Django 1.6 and Python 3.4. For user signups, everyone 
>> recommends using django-registration. However this is not under active 
>> development 
>>  (still 
>> works with a small code change) and as a budding Djangoer that worries me 
>> twice:
>>
>> 1) as a developer, it makes my job much easier if standard functions are 
>> provided. This is one of the (only) advantages of expensive corporate 
>> tools; things such as registration and user management are well thought 
>> through.
>> 2) as a Django fan (edjangalist?) I can already see that one of Django's 
>> big advantages is that decent user management comes built in. However it's 
>> not complete, and django-registration plugs a big hole, as most websites 
>> will need this feature.  Without it the user side of things becomes less 
>> useful.
>>
>> Here's my proposal:
>>
>> Create a django.contrib.registration package.
>> Pull into it the existing django-registration code and update it to work 
>> with the latest version of Django.
>> Keep it tightly in sync with changes to django.contrib.auth in the future.
>> Add more flexibility, e.g. corporate options such as perhaps an admin 
>> user can input email addresses of people to sign up, and the system 
>> generates basic unactivated profiles that when triggered allow the users to 
>> then fill in their remaining details (for example, this is how JIRA works). 
>> And/or autodiscovery of users from LDAP settings and autopopulation of user 
>> models from LDAP queries. This may be too unfocussed for the team though; 
>> it's just a very nice to have!
>>
>> Anyway, that's my idea. I'm worried that as over time django-registration 
>> drifts farther from the current version of Django, the amount of work 
>> developers have to do every time will increase to the point where it's 
>> better for them to roll their own than try and work out how Django 1.5 
>> worked with django-registration and what they need to do to patch the 
>> differences. This will lead to developers - who are attracted to Django 
>> because of useful stuff such as this - abandoning the platform for ones 
>> that provide benefits in other areas.
>>
>> Thanks for reading
>>
>>
>> Robert Grant
>>
>

-- 
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/g

Re: Pull django-registration into contrib?

[Tim Graham]

Did you read the reasons that James decided to stop maintaining it?

http://www.b-list.org/weblog/2013/aug/26/catching/

Any Django site that uses a database will benefit from integrating database 
migrations. On the other hand, there are many ways to do user registration 
(as James described in his post) so django-registration isn't a 90% use 
case that qualifies for inclusion in contrib.

On Friday, August 1, 2014 9:02:54 AM UTC-4, Robert Grant wrote:
>
> Hi Tim
>
> Thanks for the reply. I'd say that it's only been viable so far because 
> James created and maintained it (for most of that long time), it's only 
> been a year since then and Django is pretty stable around users and 
> authentication.  And even then people have forked the thing to Github to 
> create ad-hoc compatible versions for 1.6, because it's a very important 
> package. However, this isn't a stable situation; it was once, but now is 
> going to decay without proper maintenance.
>
> The reason why I think it should be pulled into contrib is because 
> registration goes hand in hand with changes to the way users and 
> authentication work in Django, and keeping the two in lockstep should be 
> relatively simple for those with an intimate knowledge of that part of 
> Django. Additionally, I think it's a key reason why people use Django, and 
> protecting features like that is important.
>
> Lastly, regarding the trend. South has been viable as a third party tool 
> for a long time, and has said "buck you" to the trend and made it all the 
> way into core. Which is great, because it means Django competes at the 
> highest levels in ORM, and that's another key reason to use Django.
>
> I suppose what I'm saying is that not everyone uses Django for love or 
> loyalty, or at least not to start with, and you have to pick which things 
> to maintain as its strengths and which to let go of to the community. 
> Coming from the outside, but having a fair amount of technology dev, design 
> and decision experience, I'd say having proper users and authentication 
> makes for a big, fairly rare distinguishing feature, and reliable 
> registration capabilities are an important complement to that.
>
>
> On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote:
>>
>> If no one has volunteered to maintain it in nearly a year since James 
>> stepped down, I think you'll have a tough time convincing us it's important 
>> enough to move into contrib. Also, the recent trend has been to remove 
>> things from contrib (comments, localflavor, formtools soon). 
>> django-registration has been viable as a third party package for a long 
>> time and I don't see a reason it couldn't continue as one.
>>
>> On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:
>>>
>>> Hello all
>>>
>>> I've just started using Django for a serious project and am really 
>>> enjoying using it; thank you.
>>>
>>> I'm using Django 1.6 and Python 3.4. For user signups, everyone 
>>> recommends using django-registration. However this is not under active 
>>> development 
>>>  
>>> (still works with a small code change) and as a budding Djangoer that 
>>> worries me twice:
>>>
>>> 1) as a developer, it makes my job much easier if standard functions are 
>>> provided. This is one of the (only) advantages of expensive corporate 
>>> tools; things such as registration and user management are well thought 
>>> through.
>>> 2) as a Django fan (edjangalist?) I can already see that one of Django's 
>>> big advantages is that decent user management comes built in. However it's 
>>> not complete, and django-registration plugs a big hole, as most websites 
>>> will need this feature.  Without it the user side of things becomes less 
>>> useful.
>>>
>>> Here's my proposal:
>>>
>>> Create a django.contrib.registration package.
>>> Pull into it the existing django-registration code and update it to work 
>>> with the latest version of Django.
>>> Keep it tightly in sync with changes to django.contrib.auth in the 
>>> future.
>>> Add more flexibility, e.g. corporate options such as perhaps an admin 
>>> user can input email addresses of people to sign up, and the system 
>>> generates basic unactivated profiles that when triggered allow the users to 
>>> then fill in their remaining details (for example, this is how JIRA works). 
>>> And/or autodiscovery of users from LDAP settings and autopopulation of user 
>>> models from LDAP queries. This may be too unfocussed for the team though; 
>>> it's just a very nice to have!
>>>
>>> Anyway, that's my idea. I'm worried that as over time 
>>> django-registration drifts farther from the current version of Django, the 
>>> amount of work developers have to do every time will increase to the point 
>>> where it's better for them to roll their own than try and work out how 
>>> Django 1.5 worked with django-registration and what they need to do to 
>>> patch the differences. This will le

Re: Updating the organization of the Django Project

[Aymeric Augustin]

Hello,

Since the proposal was accepted with sixteen +1, I committed it: 
https://github.com/django/django/commit/8c2b405ba8343e68bc32ac2c860be0c6cfd7d631.
 The next step is to elect the first technical board, as soon as 1.7 final is 
released.

As Tim noticed, team.txt and roles.txt are unrelated to Django versions. I 
suggest to keep master up to date and leave each version whatever was there 
when its branch was forked. I'd rather not make the wiki an authoritative 
source of information. If someone wants to build a better solution, that's cool.

I would like to thank all those who took the time to comment on the proposal as 
well as the entire core team for accepting to relinquish a few of its 
individual prerogatives.

-- 
Aymeric.



On 23 juil. 2014, at 15:29, Aymeric Augustin 
 wrote:

> Hello,
> 
> I've been working on updating our organization: 
> https://github.com/django/django/pull/2947
> 
> This proposal attempts to address several issues with our current 
> organization. There's no short version and any simplistic interpretation will 
> be wrong. Here are the main factors at play.
> 
> 1) In theory, the core team is the group of committers, each of whom has been 
> judged capable of making code design decisions. (Astute readers will have 
> noticed that it isn't true in practice.) This restrictive approach to 
> staffing makes it hard to cover all of our HR needs. Specifically:
>   a) It creates a chasm between non-core and core contributors, which has 
> perverse side effects and creates tons of frustration.
>   b) It drives away would-be contributors whose help wouldn't involve 
> committing code to the main Django repository.
>   c) Even if such contributors are found, it's hard to convince the core 
> team to bring them on board.
> 
> 2) Since the BDFLs have stepped down, there's no obvious way to counteract 
> honest mistakes made by core developers. This is making the core team 
> uncomfortable at times. While BDFLs hardly ever had to intervene, their mere 
> existence played a role. We need to recreate that role in a more democratic 
> fashion.
> 
> 3) We're good at burning out our most prolific contributors. Since we lack 
> structure, it's too easy to become responsible for everything, until you 
> can't handle it anymore and throw the towel. We must classify roles, write 
> down who takes what role, fill the gaps with new volunteers, and remove 
> pressure around stepping down.
> 
> 4) As we have grown, having no explicit organization within the core team 
> makes it complicated for newcomers to figure who does what and how they fit 
> in the picture. It doesn't erase the power structure. It merely hides it.
> 
> My proposal builds upon years of discussions at DjangoCons. It has gone 
> through many rounds of feedback inside the core team already. It's an 
> evolution, not a revolution. It takes into account the growth of the project, 
> acknowledges and formalizes some things that we're already doing, and 
> introduces just enough formal organization to make everyone comfortable.
> 
> It doesn't encompass everything we could do to improve our organization. In 
> particular I expect some follow up work on how we manage roles in order to 
> avoid burnout.
> 
> I would like to ask the core team for a formal vote on this pull request, 
> according to our guidelines. [1] Please vote by the end of July in UTC 
> (2014-08-01T00:00:00Z).
> 
> Obviously, I'm voting +1.
> 
> Thank you,
> 
> -- 
> Aymeric.
> 
> 
> [1] 
> https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-features/#how-we-make-decisions

-- 
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/C57A5215-139D-4188-9D7B-2AD5A4FA4F68%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Proposal new Django Admin css style

[Thiago Avelino]

Hi guys! Django admin has a few years, it works fine (meets the need) only
need to evolve the style following the evolution of UX today!

We have a plan for change?

What do you think of this style ​
https://github.com/hersonls/djamin#screenshots ? Is django admin html +
custom css!


Cheers,
Thiago Avelino
@avelino0  - avelino.xxx

-- 
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/CAHWh-o%2BmJ8jChPJxFiAypCSpZWdgtYdnfS%3Du%2B%2Bc2VtCHSicu6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Robert Grant]

Hi Tim

I did. I just reread it though; thanks for the link. There are multiple 
ways to do registration, agreed, but then one could - for example - make 
your same argument about logging into a system. Why provide that when some 
people might not want a site with authentication, or might want to do it 
through Facebook or OpenID? (Or, as per your reference to James' reasons, 
Persona?)

What I'm (primarily) talking about is a registration system that 
complements Django's user system. Registering a user that can log in via 
Django's built in login functionality as a Django user, with some 
toggleable features that can be extended by future releases or 3rd party 
packages. This might not be a 90% use case for all of Django, though I 
don't know how to measure the number of people that use the various 
registration tools plus the number that roll their own unnecessarily, but 
I'd imagine it's useful for a very high percentage of the projects that use 
Django's user system.

On Friday, 1 August 2014 15:30:31 UTC+2, Tim Graham wrote:
>
> Did you read the reasons that James decided to stop maintaining it?
>
> http://www.b-list.org/weblog/2013/aug/26/catching/
>
> Any Django site that uses a database will benefit from integrating 
> database migrations. On the other hand, there are many ways to do user 
> registration (as James described in his post) so django-registration isn't 
> a 90% use case that qualifies for inclusion in contrib.
>
> On Friday, August 1, 2014 9:02:54 AM UTC-4, Robert Grant wrote:
>>
>> Hi Tim
>>
>> Thanks for the reply. I'd say that it's only been viable so far because 
>> James created and maintained it (for most of that long time), it's only 
>> been a year since then and Django is pretty stable around users and 
>> authentication.  And even then people have forked the thing to Github to 
>> create ad-hoc compatible versions for 1.6, because it's a very important 
>> package. However, this isn't a stable situation; it was once, but now is 
>> going to decay without proper maintenance.
>>
>> The reason why I think it should be pulled into contrib is because 
>> registration goes hand in hand with changes to the way users and 
>> authentication work in Django, and keeping the two in lockstep should be 
>> relatively simple for those with an intimate knowledge of that part of 
>> Django. Additionally, I think it's a key reason why people use Django, and 
>> protecting features like that is important.
>>
>> Lastly, regarding the trend. South has been viable as a third party tool 
>> for a long time, and has said "buck you" to the trend and made it all the 
>> way into core. Which is great, because it means Django competes at the 
>> highest levels in ORM, and that's another key reason to use Django.
>>
>> I suppose what I'm saying is that not everyone uses Django for love or 
>> loyalty, or at least not to start with, and you have to pick which things 
>> to maintain as its strengths and which to let go of to the community. 
>> Coming from the outside, but having a fair amount of technology dev, design 
>> and decision experience, I'd say having proper users and authentication 
>> makes for a big, fairly rare distinguishing feature, and reliable 
>> registration capabilities are an important complement to that.
>>
>>
>> On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote:
>>>
>>> If no one has volunteered to maintain it in nearly a year since James 
>>> stepped down, I think you'll have a tough time convincing us it's important 
>>> enough to move into contrib. Also, the recent trend has been to remove 
>>> things from contrib (comments, localflavor, formtools soon). 
>>> django-registration has been viable as a third party package for a long 
>>> time and I don't see a reason it couldn't continue as one.
>>>
>>> On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:

 Hello all

 I've just started using Django for a serious project and am really 
 enjoying using it; thank you.

 I'm using Django 1.6 and Python 3.4. For user signups, everyone 
 recommends using django-registration. However this is not under active 
 development 
  
 (still works with a small code change) and as a budding Djangoer that 
 worries me twice:

 1) as a developer, it makes my job much easier if standard functions 
 are provided. This is one of the (only) advantages of expensive corporate 
 tools; things such as registration and user management are well thought 
 through.
 2) as a Django fan (edjangalist?) I can already see that one of 
 Django's big advantages is that decent user management comes built in. 
 However it's not complete, and django-registration plugs a big hole, as 
 most websites will need this feature.  Without it the user side of things 
 becomes less useful.

 Here's my proposal:

 Create a django.contrib.registra

Re: Proposal new Django Admin css style

[Leonardo Borges Avelino]

I really like this style. Clean and modern!

Cheers

-- 
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/CAMnPXq8fmYcky4u4XyjGvXB_F%2BS0RkQa%3DOTVe16-M7FWt8FnFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Andre Terra]

Hi, Robert,

I just wanted to say that I'm +9000 in favor of your proposal. In fact, I
think Django as a whole can benefit from the kind of reasoning behind your
argument. Having key strengths is what drives adoption from new users, and
that should be any framework's concern. I strongly feel that this sort of
"commercial" concern is the only thing that is really lacking in Django as
a framework today.

The admin has been touted as one of Django's most prominent features,
because it lets you work with data easily and early in the development
process. Is it complete? No. Is it perfect? Definitely not. But it's damn
good for a significant number of use cases, and that is why it is still
part of core.

For what it's worth, I have used django-registration much more frequently
than I have used the admin, and I'm willing to bet that's the case with
other users as well. Therefore, the "percentage of use cases" is not a
valid argument.

We ought not to confuse is and ought.


Cheers,
AT




On Fri, Aug 1, 2014 at 10:28 AM, Robert Grant 
wrote:

> Hi Tim
>
> I did. I just reread it though; thanks for the link. There are multiple
> ways to do registration, agreed, but then one could - for example - make
> your same argument about logging into a system. Why provide that when some
> people might not want a site with authentication, or might want to do it
> through Facebook or OpenID? (Or, as per your reference to James' reasons,
> Persona?)
>
> What I'm (primarily) talking about is a registration system that
> complements Django's user system. Registering a user that can log in via
> Django's built in login functionality as a Django user, with some
> toggleable features that can be extended by future releases or 3rd party
> packages. This might not be a 90% use case for all of Django, though I
> don't know how to measure the number of people that use the various
> registration tools plus the number that roll their own unnecessarily, but
> I'd imagine it's useful for a very high percentage of the projects that use
> Django's user system.
>
>
> On Friday, 1 August 2014 15:30:31 UTC+2, Tim Graham wrote:
>>
>> Did you read the reasons that James decided to stop maintaining it?
>>
>> http://www.b-list.org/weblog/2013/aug/26/catching/
>>
>> Any Django site that uses a database will benefit from integrating
>> database migrations. On the other hand, there are many ways to do user
>> registration (as James described in his post) so django-registration isn't
>> a 90% use case that qualifies for inclusion in contrib.
>>
>> On Friday, August 1, 2014 9:02:54 AM UTC-4, Robert Grant wrote:
>>>
>>> Hi Tim
>>>
>>> Thanks for the reply. I'd say that it's only been viable so far because
>>> James created and maintained it (for most of that long time), it's only
>>> been a year since then and Django is pretty stable around users and
>>> authentication.  And even then people have forked the thing to Github to
>>> create ad-hoc compatible versions for 1.6, because it's a very important
>>> package. However, this isn't a stable situation; it was once, but now is
>>> going to decay without proper maintenance.
>>>
>>> The reason why I think it should be pulled into contrib is because
>>> registration goes hand in hand with changes to the way users and
>>> authentication work in Django, and keeping the two in lockstep should be
>>> relatively simple for those with an intimate knowledge of that part of
>>> Django. Additionally, I think it's a key reason why people use Django, and
>>> protecting features like that is important.
>>>
>>> Lastly, regarding the trend. South has been viable as a third party tool
>>> for a long time, and has said "buck you" to the trend and made it all the
>>> way into core. Which is great, because it means Django competes at the
>>> highest levels in ORM, and that's another key reason to use Django.
>>>
>>> I suppose what I'm saying is that not everyone uses Django for love or
>>> loyalty, or at least not to start with, and you have to pick which things
>>> to maintain as its strengths and which to let go of to the community.
>>> Coming from the outside, but having a fair amount of technology dev, design
>>> and decision experience, I'd say having proper users and authentication
>>> makes for a big, fairly rare distinguishing feature, and reliable
>>> registration capabilities are an important complement to that.
>>>
>>>
>>> On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote:

 If no one has volunteered to maintain it in nearly a year since James
 stepped down, I think you'll have a tough time convincing us it's important
 enough to move into contrib. Also, the recent trend has been to remove
 things from contrib (comments, localflavor, formtools soon).
 django-registration has been viable as a third party package for a long
 time and I don't see a reason it couldn't continue as one.

 On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote:
>
> Hello all

Re: Proposal new Django Admin css style

[Collin Anderson]

I like that it's all done without changing the html.

-- 
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/83bb0b9f-cff6-4989-bd4e-6159b7b7632d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Qing Feng]

I like this style +1


2014-08-01 21:46 GMT+08:00 Thiago Avelino :

> Hi guys! Django admin has a few years, it works fine (meets the need) only
> need to evolve the style following the evolution of UX today!
>
> We have a plan for change?
>
> What do you think of this style ​
> https://github.com/hersonls/djamin#screenshots ? Is django admin html +
> custom css!
>
>
> Cheers,
> Thiago Avelino
> @avelino0  - avelino.xxx
>
> --
> 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/CAHWh-o%2BmJ8jChPJxFiAypCSpZWdgtYdnfS%3Du%2B%2Bc2VtCHSicu6Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAE_PXQ2VUoKHm1WN_YqLKooz1JyrGhmnYUw5BceAiskS3wDyLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Daniele Faraglia]

wonderful idea,

maybe css should be compiled by less/sass files?


2014-08-01 17:37 GMT+02:00 Qing Feng :

> I like this style +1
>
>
> 2014-08-01 21:46 GMT+08:00 Thiago Avelino :
>
> Hi guys! Django admin has a few years, it works fine (meets the need) only
>> need to evolve the style following the evolution of UX today!
>>
>> We have a plan for change?
>>
>> What do you think of this style ​
>> https://github.com/hersonls/djamin#screenshots ? Is django admin html +
>> custom css!
>>
>>
>> Cheers,
>> Thiago Avelino
>> @avelino0  - avelino.xxx
>>
>> --
>> 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/CAHWh-o%2BmJ8jChPJxFiAypCSpZWdgtYdnfS%3Du%2B%2Bc2VtCHSicu6Q%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CAE_PXQ2VUoKHm1WN_YqLKooz1JyrGhmnYUw5BceAiskS3wDyLA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAAGVtvPJG5EuCdBSuwDjU-W6GoA_FL2DXf_dfRNzZA6Vwne2MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Herson]

The main idea is to maintain compatibility with the current template,
changing only css. I changed the css and replace images icons to fonts.


On Fri, Aug 1, 2014 at 1:06 PM, Daniele Faraglia  wrote:

> wonderful idea,
>
> maybe css should be compiled by less/sass files?
>
>
> 2014-08-01 17:37 GMT+02:00 Qing Feng :
>
> I like this style +1
>>
>>
>> 2014-08-01 21:46 GMT+08:00 Thiago Avelino :
>>
>> Hi guys! Django admin has a few years, it works fine (meets the need)
>>> only need to evolve the style following the evolution of UX today!
>>>
>>> We have a plan for change?
>>>
>>> What do you think of this style ​
>>> https://github.com/hersonls/djamin#screenshots ? Is django admin html +
>>> custom css!
>>>
>>>
>>> Cheers,
>>> Thiago Avelino
>>> @avelino0  - avelino.xxx
>>>
>>> --
>>> 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/CAHWh-o%2BmJ8jChPJxFiAypCSpZWdgtYdnfS%3Du%2B%2Bc2VtCHSicu6Q%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> 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/CAE_PXQ2VUoKHm1WN_YqLKooz1JyrGhmnYUw5BceAiskS3wDyLA%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CAAGVtvPJG5EuCdBSuwDjU-W6GoA_FL2DXf_dfRNzZA6Vwne2MA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Herson Leite, Software Developer
www.hersonls.com.br

-- 
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%2BdbW12Cse8uxCe2Y1G-%2B%2BkVV80KXbCt%2BS4iGauyATZax42A2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Collin Anderson]

It seems to me, in any case, the first step is to get django-registration 
actively maintained again. James Bennett is welcoming proposals of people 
to take over maintenance of the project. Get it working well with custom 
user models and with python 3. Once django-registration is a thriving app 
as popular as django-south (about 10x as many people using it), it would 
make sense to think about the possibility of adding it to contrib.

I think LDAP and oauth (facebook login) support out of the box in django 
would be great, though I think it's easier said than done, and 
django-registration doesn't even do it out of the box.

As for me personally. I use the admin in every one of the 18 django 
websites I maintain, and in the few websites where non-staff users login to 
the website, including this line in urls.py goes a long way for me:

url(r'^accounts/', include('django.contrib.auth.urls')),

If email-verification is required, I re-use the password reset code to 
handle the tokens.

-- 
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/f5a95a35-9a56-45af-bbf8-1dba75ef91f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Christian Schmitt]

Since you've introduced these changes, wouldn't it be suitable to change 
Django's commit / review system entirely?
Like introduce gerrit, where very commit / ticket needs to be reviewed by X 
people and then it would be marked as merge ready and a "core" or whoever 
member could merge that.
There are a lot of projects which uses this kind of workflow.

Also there are like 120 Pull Requests which are over an year old 
sometimes.Which scary's off a lot of people. We should do something against 
it to have a "cleaner" queue.



Am Freitag, 1. August 2014 15:34:48 UTC+2 schrieb Aymeric Augustin:
>
> Hello, 
>
> Since the proposal was accepted with sixteen +1, I committed it: 
> https://github.com/django/django/commit/8c2b405ba8343e68bc32ac2c860be0c6cfd7d631.
>  
> The next step is to elect the first technical board, as soon as 1.7 final 
> is released. 
>
> As Tim noticed, team.txt and roles.txt are unrelated to Django versions. I 
> suggest to keep master up to date and leave each version whatever was there 
> when its branch was forked. I’d rather not make the wiki an authoritative 
> source of information. If someone wants to build a better solution, that’s 
> cool. 
>
> I would like to thank all those who took the time to comment on the 
> proposal as well as the entire core team for accepting to relinquish a few 
> of its individual prerogatives. 
>
> -- 
> Aymeric. 
>
>
>
> On 23 juil. 2014, at 15:29, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>
> > Hello, 
> > 
> > I’ve been working on updating our organization: 
> https://github.com/django/django/pull/2947 
> > 
> > This proposal attempts to address several issues with our current 
> organization. There’s no short version and any simplistic interpretation 
> will be wrong. Here are the main factors at play. 
> > 
> > 1) In theory, the core team is the group of committers, each of whom has 
> been judged capable of making code design decisions. (Astute readers will 
> have noticed that it isn’t true in practice.) This restrictive approach to 
> staffing makes it hard to cover all of our HR needs. Specifically: 
> > a) It creates a chasm between non-core and core contributors, 
> which has perverse side effects and creates tons of frustration. 
> > b) It drives away would-be contributors whose help wouldn’t 
> involve committing code to the main Django repository. 
> > c) Even if such contributors are found, it’s hard to convince 
> the core team to bring them on board. 
> > 
> > 2) Since the BDFLs have stepped down, there’s no obvious way to 
> counteract honest mistakes made by core developers. This is making the core 
> team uncomfortable at times. While BDFLs hardly ever had to intervene, 
> their mere existence played a role. We need to recreate that role in a more 
> democratic fashion. 
> > 
> > 3) We’re good at burning out our most prolific contributors. Since we 
> lack structure, it’s too easy to become responsible for everything, until 
> you can’t handle it anymore and throw the towel. We must classify roles, 
> write down who takes what role, fill the gaps with new volunteers, and 
> remove pressure around stepping down. 
> > 
> > 4) As we have grown, having no explicit organization within the core 
> team makes it complicated for newcomers to figure who does what and how 
> they fit in the picture. It doesn’t erase the power structure. It merely 
> hides it. 
> > 
> > My proposal builds upon years of discussions at DjangoCons. It has gone 
> through many rounds of feedback inside the core team already. It’s an 
> evolution, not a revolution. It takes into account the growth of the 
> project, acknowledges and formalizes some things that we’re already doing, 
> and introduces just enough formal organization to make everyone 
> comfortable. 
> > 
> > It doesn’t encompass everything we could do to improve our organization. 
> In particular I expect some follow up work on how we manage roles in order 
> to avoid burnout. 
> > 
> > I would like to ask the core team for a formal vote on this pull 
> request, according to our guidelines. [1] Please vote by the end of July in 
> UTC (2014-08-01T00:00:00Z). 
> > 
> > Obviously, I’m voting +1. 
> > 
> > Thank you, 
> > 
> > -- 
> > Aymeric. 
> > 
> > 
> > [1] 
> https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-features/#how-we-make-decisions
>  
>
>

-- 
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/6b02f379-7a95-4d87-8f68-9d33d250e27e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Collin Anderson]

>
> Also there are like 120 Pull Requests which are over an year old 
> sometimes.Which scary's off a lot of people. We should do something against 
> it to have a "cleaner" queue.
>
In theory every pull request has a trac ticket and the queue is all handled 
by queries such as:
https://code.djangoproject.com/query?status=!closed&stage=Ready+for+checkin
There are links to other useful reports here:
https://code.djangoproject.com/wiki/Reports

-- 
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/462b574c-e967-4adb-a2fa-be7e06784694%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Aymeric Augustin]

On 1 août 2014, at 18:31, Christian Schmitt  wrote:

> Since you've introduced these changes, wouldn't it be suitable to change 
> Django's commit / review system entirely?

"Hey, you climbed this hill just fine, why don't you climb the Everest while 
you're at it?" ;-) Even though the final vote looks like everything went fine, 
preparing it took three months and drained a lot of energy.

> Like introduce gerrit, where very commit / ticket needs to be reviewed by X 
> people and then it would be marked as merge ready and a "core" or whoever 
> member could merge that.
> There are a lot of projects which uses this kind of workflow.

I've discussed that idea with other core devs several times. Generally 
speaking, we're interested in shifting from a commit-oriented culture to a 
review-oriented culture.  We haven't done it (yet) for four main reasons:

- Someone has to organize this process, set up the tools, and teach everyone. 
No one has volunteered.
- The drawbacks of adding bureaucracy may exceed the advantages of reviews for 
a vast majority of patches, which are small fixes or improvements.
- We have only one person reviewing patches regularly in his free time, so 
requiring as few as two reviews for a patch to be merged is already 
unrealistic. Contrast this with the number of full-time paid developers on 
OpenStack.
- Overall e're not convinced this process would be appropriate for Django and 
we don't know what would happen if it turns out to be impractical.

> Also there are like 120 Pull Requests which are over an year old 
> sometimes.Which scary's off a lot of people. We should do something against 
> it to have a "cleaner" queue.


Unfortunately, GitHub's issues and PRs management tools are somewhere between 
primitive and non-existent. The only option GitHub gives us to move a PR that 
requires discussion out of the review queue is to close it. Often that triggers 
a heated argument with its author. That has killed all attempts to clean the 
queue. Thus we've been beaten into the path of least resistance and now we're 
letting PRs that cannot be merged as-is rot.

Overall, I don't think that change is impossible, but I think we're going to 
see how the dust settles before considering further (r)evolutions.

-- 
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/428911F3-292F-4F97-AB3C-B2AC5AC76798%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

i18n json catalog

[Manolo Gabriel Ramirez Torrico]

Hi all,

I would like to contribute with this feature, you can see the proposal in 
#22404 .
If you agree with the idea I could start writing the documentation.

Regards,

Manolo Ramirez T.

-- 
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/8a78369a-aee2-411d-a967-7b927063f012%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Schmitt, Christian]

i know that such things drains a lot of energy. I'm working for a very
small company and we changed our commit / review system entirely.

currently I think you are right at your four points, but one of your four
points is somehow really bad

> We have only one person reviewing patches regularly in his free time, so
requiring as few as two reviews for a patch to be merged is already
unrealistic

I know that everybody is working here. I mean some people are working for
django quite hard or working for their company and doing a lot of work for
django, too. But still reviewing PR's is really important for a community
project.
I know lots of things already changed and this change is great as well.
Still I think there are parts where some upstream work could be done way
better by the community than by a few (with few i mean core) and thats the
review process, thats why I came up with gerrit. I actually don't think
that gerrit actually suites everybody's projects ( and I came to the same
four conclusions in my company ;))
But maybe we are finding something that is as good as gerrit but suites the
djangos project size a little bit better.

i mean i still think commits needs control, else there would be a lot of
circlejerk as the master/replica thing. but still it looks that pr's take
way too long for django. and thats the last thing that django could do
better.
especially since there are a lots of ideas how to solve such problems in
the real world..

i mean maybe we should really look at a review tool and maybe say if two
people of the community reviewed it gets pipelined to the "core" which can
do a final review. so it would be more community oriented and fewer "bad
patches" will get to the commit pipeline.
still it takes a lot of time to teach people and setup everything. but it
will put the project further ahead.
(also I'm not a core member but if we had such a review system i
would definitely do more of these reviews since thats the thing i do at my
company, too)



2014-08-01 19:02 GMT+02:00 Aymeric Augustin <
aymeric.augus...@polytechnique.org>:

> On 1 août 2014, at 18:31, Christian Schmitt 
> wrote:
>
> Since you've introduced these changes, wouldn't it be suitable to change
> Django's commit / review system entirely?
>
>
> “Hey, you climbed this hill just fine, why don’t you climb the Everest
> while you’re at it?” ;-) Even though the final vote looks like everything
> went fine, preparing it took three months and drained a lot of energy.
>
> Like introduce gerrit, where very commit / ticket needs to be reviewed by
> X people and then it would be marked as merge ready and a "core" or whoever
> member could merge that.
> There are a lot of projects which uses this kind of workflow.
>
>
> I’ve discussed that idea with other core devs several times. Generally
> speaking, we’re interested in shifting from a commit-oriented culture to a
> review-oriented culture. We haven’t done it (yet) for four main reasons:
>
> - Someone has to organize this process, set up the tools, and teach
> everyone. No one has volunteered.
> - The drawbacks of adding bureaucracy may exceed the advantages of reviews
> for a vast majority of patches, which are small fixes or improvements.
> - We have only one person reviewing patches regularly in his free time, so
> requiring as few as two reviews for a patch to be merged is already
> unrealistic. Contrast this with the number of full-time paid developers on
> OpenStack.
> - Overall e’re not convinced this process would be appropriate for Django
> and we don’t know what would happen if it turns out to be impractical.
>
> Also there are like 120 Pull Requests which are over an year old
> sometimes.Which scary's off a lot of people. We should do something against
> it to have a "cleaner" queue.
>
>
> Unfortunately, GitHub’s issues and PRs management tools are somewhere
> between primitive and non-existent. The only option GitHub gives us to move
> a PR that requires discussion out of the review queue is to close it. Often
> that triggers a heated argument with its author. That has killed all
> attempts to clean the queue. Thus we’ve been beaten into the path of least
> resistance and now we're letting PRs that cannot be merged as-is rot.
>
> Overall, I don’t think that change is impossible, but I think we’re going
> to see how the dust settles before considering further (r)evolutions.
>
> --
> 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/428911F3-292F-4F97-AB3C-B2AC5AC76798%40polytechnique.org
> 

Re: Updating the organization of the Django Project

[Carl Meyer]

Hi Christian,

On 08/01/2014 01:37 PM, Schmitt, Christian wrote:
[snip]
> i mean maybe we should really look at a review tool and maybe say if two
> people of the community reviewed it gets pipelined to the "core" which
> can do a final review. so it would be more community oriented and fewer
> "bad patches" will get to the commit pipeline.
> still it takes a lot of time to teach people and setup everything. but
> it will put the project further ahead.
> (also I'm not a core member but if we had such a review system i
> would definitely do more of these reviews since thats the thing i do at
> my company, too)

I'm curious why the system you propose (requiring two community reviews
to fast-track a patch) would motivate you to do more reviews than the
current system, in which it only takes a single review (by any community
member) to mark a ticket as "Ready for Check-in", which already gets it
fast-tracked for commit.

Although it does happen sometimes, there isn't a big problem (AFAIK)
with lots of patches getting marked RFC when they aren't ready;
currently there are only 3 tickets in RFC state. The bigger problem is
there aren't many people doing reviews and moving tickets to RFC state.
According to dashboard.djangoproject.com, there are 52 patches awaiting
review.

Maybe it's mostly a tooling issue, in that the current process requires
reviewers to read the contribution docs, understand the ticket state
flow, and then use both GitHub and Trac and manually mark the ticket RFC
themselves after doing a review, rather than having a review tool with a
big +1 button on it that automatically handles the state changes.

Carl

-- 
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/53DBEF42.809%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Schmitt, Christian]

its a matter of trust.
gerrit tracks your reviews so its way easier to build up trust that the
things you mark as RFC is really RFC ;)
And yes its a matter of tooling since some tools provide a better way to
build trust for such community processes.
Also I'm quite young. I wouldn't want to make a "community review" just by
myself since I will definitely do some mistakes over time as everybody will
do.

to come back to the tooling. gerrit is just one tool. i don't know more
than gerrit that has such a large feature set. but i think there are
definitly some out.
In our company we use a lot of atlassian tools and atlassian has a "gerrit"
tool, too but I didn't take a look at it yet. so thats another option since
atlassian tools are free for community use.

the next thing is, reading contribution docks is easy, using trac is not.
trac is a really blocker for a lot of things on my side. i think the ux is
somewhat bad, but thats just an own perspective.




2014-08-01 21:49 GMT+02:00 Carl Meyer :

> Hi Christian,
>
> On 08/01/2014 01:37 PM, Schmitt, Christian wrote:
> [snip]
> > i mean maybe we should really look at a review tool and maybe say if two
> > people of the community reviewed it gets pipelined to the "core" which
> > can do a final review. so it would be more community oriented and fewer
> > "bad patches" will get to the commit pipeline.
> > still it takes a lot of time to teach people and setup everything. but
> > it will put the project further ahead.
> > (also I'm not a core member but if we had such a review system i
> > would definitely do more of these reviews since thats the thing i do at
> > my company, too)
>
> I'm curious why the system you propose (requiring two community reviews
> to fast-track a patch) would motivate you to do more reviews than the
> current system, in which it only takes a single review (by any community
> member) to mark a ticket as "Ready for Check-in", which already gets it
> fast-tracked for commit.
>
> Although it does happen sometimes, there isn't a big problem (AFAIK)
> with lots of patches getting marked RFC when they aren't ready;
> currently there are only 3 tickets in RFC state. The bigger problem is
> there aren't many people doing reviews and moving tickets to RFC state.
> According to dashboard.djangoproject.com, there are 52 patches awaiting
> review.
>
> Maybe it's mostly a tooling issue, in that the current process requires
> reviewers to read the contribution docs, understand the ticket state
> flow, and then use both GitHub and Trac and manually mark the ticket RFC
> themselves after doing a review, rather than having a review tool with a
> big +1 button on it that automatically handles the state changes.
>
> Carl
>
> --
> 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/53DBEF42.809%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAPDLAU4cnH3nJxBV5pTA5yW%2B_N%3D2Bwju2ZWyevgJRd3Fu%2B-7-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Tim Graham]

Christian, have you seen the patch review checklist I put together? 

https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

That is basically what I do when I review a patch. If a patch meets those 
guidelines, please mark it RFC. A core dev will always do a final review, 
but it helps a lot if we don't have to explain those basics to new 
contributors. Sure, you will make mistakes, but that is the only way to 
learn and the risks are low. Over time, the core team will see that the 
patches your mark as RFC are really RFC as you said, and we're likely to 
ask you the join the team so you can just commit those patches that you 
review yourself.

Regarding Trac, would you mind explaining what Trac is blocking you from 
doing? Perhaps we can try to address some of those issues.

On Friday, August 1, 2014 4:38:54 PM UTC-4, Christian Schmitt wrote:
>
> its a matter of trust.
> gerrit tracks your reviews so its way easier to build up trust that the 
> things you mark as RFC is really RFC ;)
> And yes its a matter of tooling since some tools provide a better way to 
> build trust for such community processes.
> Also I'm quite young. I wouldn't want to make a "community review" just by 
> myself since I will definitely do some mistakes over time as everybody will 
> do.
>
> to come back to the tooling. gerrit is just one tool. i don't know more 
> than gerrit that has such a large feature set. but i think there are 
> definitly some out.
> In our company we use a lot of atlassian tools and atlassian has a 
> "gerrit" tool, too but I didn't take a look at it yet. so thats another 
> option since atlassian tools are free for community use.
>
> the next thing is, reading contribution docks is easy, using trac is not. 
> trac is a really blocker for a lot of things on my side. i think the ux is 
> somewhat bad, but thats just an own perspective.
>
>
>
>
> 2014-08-01 21:49 GMT+02:00 Carl Meyer >:
>
>> Hi Christian,
>>
>> On 08/01/2014 01:37 PM, Schmitt, Christian wrote:
>> [snip]
>> > i mean maybe we should really look at a review tool and maybe say if two
>> > people of the community reviewed it gets pipelined to the "core" which
>> > can do a final review. so it would be more community oriented and fewer
>> > "bad patches" will get to the commit pipeline.
>> > still it takes a lot of time to teach people and setup everything. but
>> > it will put the project further ahead.
>> > (also I'm not a core member but if we had such a review system i
>> > would definitely do more of these reviews since thats the thing i do at
>> > my company, too)
>>
>> I'm curious why the system you propose (requiring two community reviews
>> to fast-track a patch) would motivate you to do more reviews than the
>> current system, in which it only takes a single review (by any community
>> member) to mark a ticket as "Ready for Check-in", which already gets it
>> fast-tracked for commit.
>>
>> Although it does happen sometimes, there isn't a big problem (AFAIK)
>> with lots of patches getting marked RFC when they aren't ready;
>> currently there are only 3 tickets in RFC state. The bigger problem is
>> there aren't many people doing reviews and moving tickets to RFC state.
>> According to dashboard.djangoproject.com, there are 52 patches awaiting
>> review.
>>
>> Maybe it's mostly a tooling issue, in that the current process requires
>> reviewers to read the contribution docs, understand the ticket state
>> flow, and then use both GitHub and Trac and manually mark the ticket RFC
>> themselves after doing a review, rather than having a review tool with a
>> big +1 button on it that automatically handles the state changes.
>>
>> Carl
>>
>> --
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/53DBEF42.809%40oddbird.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/e41b99a9-e998-48b9-871c-c9f8b2183728%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SchemaEditor + DatabaseConnection

[Andrew Godwin]

At the moment you'll need to make sure both Creation and SchemaEditor do
the right thing for stuff like that. We bumped "deprecate DatabaseCreation"
back to 2.0 for a final removal as it was so complex and so much stuff
relies on it (including SchemaEditor in places where I didn't want to
duplicate code; we'll move that code over eventually)

Andrew


On Mon, Jul 28, 2014 at 2:33 AM, Tim Graham  wrote:

> FWIW, I may have closed that PR prematurely. I didn't realize SchemaEditor
> still relied on DatabaseCreation and I'm not sure what the final
> combination of the two will ultimately look like.
>
>
> On Sunday, July 27, 2014 7:38:08 AM UTC-4, Christopher D'Cunha wrote:
>>
>> Hi All,
>>
>> I'm working on https://code.djangoproject.com/ticket/56 for the
>> EuroPython sprint. There was a PR for it (https://github.com/django/
>> django/pull/1156) but it was rejected by Tim Graham because the code
>> should apparently be in the SchemaEditor instead of the DatabaseCreation
>> class.
>>
>> As I trace through though I see that the SchemaEditor uses the
>> DatabaseCreation for some stuff. For example, in order to get the column
>> type for a field:
>>
>>
>> # /django/db/backends/schema.py
>>
>> class BaseDatabaseSchemaEditor(object):
>> ...
>>
>> def create_model(self, model):
>>  ...
>>
>> for field in model._meta.local_fields:
>> ...
>>
>> # Check constraints can go on the column SQL here
>> db_params = field.db_parameters(connection=self.connection)
>>
>>
>> # /django/db/models/fields/__init__.py
>>
>> class Field(RegisterLookupMixin):
>> """Base class for all field types"""
>>
>> ...
>>
>> def db_parameters(self, connection):
>> ...
>> type_string = self.db_type(connection)
>> ...
>>
>> def db_type(self, connection):
>> data = DictWrapper(self.__dict__, connection.ops.quote_name,
>> "qn_")
>> try:
>> return connection.creation.data_
>> types[self.get_internal_type()] % data
>> except KeyError:
>> return None
>>
>> Is it possible/worth it for me to work on #56 before all the "migrate"
>> stuff is done?
>>
>> +AndrewGodwin, I'm told that you're the best person to ask :D.
>>
>> Thanks,
>> Chris
>>
>  --
> 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/abd10460-694f-4c89-88c2-a9b06b7a6eca%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFwN1uqdSO64Uc4FHJtwEWeU5x%3Ddw59ij%2By%2Bsq%2B4sux_yZ6Ogg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Daniel Greenfeld]

What no one is discussing here is is that django-registration is just one 
out of several popular authentication backends that match it for use and 
great exceed it's functionality. They include:

* django-allauth
* django-userena
* python-social-auth (nee django-social-auth)

These three projects are extremely well maintained (huge communities of 
supporters), support dozens of OAuth implementations, and are the modern 
cornerstone of current Django registration. Bugs are fixed quickly, updates 
for OAuth providers come frequently, and **just plain work without 
forking**.

django-allauth in particular not only easily mirrors django-registration 
core functiomality, it has a safer logout mechanism.

Why do I bring this up? Well, if Django is going to have a built-in 
registration system, then I think it should benefit from having more eyes 
on the problem. While James Bennett is an awesome coder whose work has been 
a foundation of my own, his solitary effort 
(https://www.djangopackages.com/packages/p/django-registration/ shows only 
one committer) simply doesn't compare to the legions of people who have 
contributed to these other packages. Therefore, I submit that if a 
registration package will be brought into django.contrib, it should be one 
of these alternatives.

That said, I don't like the idea of adding more functionality to Django, 
even within django.contrib. IMO, a better alternative would be to suggest 
registration packages in the documentation of django.contrib.auth.

--Daniel Greenfeld



On Friday, August 1, 2014 9:17:30 AM UTC-7, Collin Anderson wrote:
>
> It seems to me, in any case, the first step is to get django-registration 
> actively maintained again. James Bennett is welcoming proposals of people 
> to take over maintenance of the project. Get it working well with custom 
> user models and with python 3. Once django-registration is a thriving app 
> as popular as django-south (about 10x as many people using it), it would 
> make sense to think about the possibility of adding it to contrib.
>
> I think LDAP and oauth (facebook login) support out of the box in django 
> would be great, though I think it's easier said than done, and 
> django-registration doesn't even do it out of the box.
>
> As for me personally. I use the admin in every one of the 18 django 
> websites I maintain, and in the few websites where non-staff users login to 
> the website, including this line in urls.py goes a long way for me:
>
> url(r'^accounts/', include('django.contrib.auth.urls')),
>
> If email-verification is required, I re-use the password reset code to 
> handle the tokens.
>

-- 
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/f5813b1d-529a-45b2-b14a-b4a78cf99757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Donald Stufft]

On August 1, 2014 at 10:28:22 AM, Robert Grant (robertlagr...@gmail.com) wrote:
> Hi Tim
>  
> I did. I just reread it though; thanks for the link. There are multiple
> ways to do registration, agreed, but then one could - for example - make
> your same argument about logging into a system. Why provide that when some
> people might not want a site with authentication, or might want to do it
> through Facebook or OpenID? (Or, as per your reference to James' reasons,
> Persona?)
> 

I think the difference between django-registration and South is that
there is a benefit to blessing a singular migrations framework as
the one true way of doing it. Namely that is interoperability.

The same can be said for django.contrib.auth as well. As long as any
system which uses users ties into that, then they’ll all interopt
with each other. The same cannot be said for the registration system
since generally most pieces of a site do not interact with the
registration system, especially not at the level as they would for
the generic concept of users or database migrations.

--  
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/etPan.53dc0fe4.6b8b4567.d5d9%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Schmitt, Christian]

> Christian, have you seen the patch review checklist I put together?

Yep and I will definitely do some more work in the future.

Everything i write now is my personal opinion.
first of all trac has some of the weakest Query Filters. (thats my personal
opinion)
the next thing is that changing the ticket and adding comments share the
same button, which leads to strange things (sometimes).
also its really hard to review for specific versions.
voting for a new feature is done on the mailing list which is okai, but i
think that would be better to do in an issue tracker. (voting through
tooling seems to be way simpler than posting a +1.)
also there is no way of saving filters to my profile. I mean i could
bookmark them but my bookmarks are way too much already.
also it would be "a cool" feature if trac would automatically add pr's as
an info to the ticket..
I mean most of these things are comfort features and still trac feels less
intuitive than other tools since they are a complete platform or link
everything together.

However none of these points would stop me or another individual from
helping / commiting / reviewing. its just a matter of time.
tools should help us to use less time.
tools should link/work together since its easier to start if you have
everything together. also i talked about gerrit, if gerrit would be
introduced it woud be even harder to keep these things together since its
another platform, too.

what i want to do in short is that sometimes we also should look at the
infrastructure and improve on these things. i mean i'm just somebody but i
think other people would say something about the currents, too.
with infrastructure i mean the things like documentation, issue tracker,
code review, etc.. and i think there are plenty improvements.
like the online documentation.



2014-08-01 23:18 GMT+02:00 Tim Graham :

> Christian, have you seen the patch review checklist I put together?
>
>
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>
> That is basically what I do when I review a patch. If a patch meets those
> guidelines, please mark it RFC. A core dev will always do a final review,
> but it helps a lot if we don't have to explain those basics to new
> contributors. Sure, you will make mistakes, but that is the only way to
> learn and the risks are low. Over time, the core team will see that the
> patches your mark as RFC are really RFC as you said, and we're likely to
> ask you the join the team so you can just commit those patches that you
> review yourself.
>
> Regarding Trac, would you mind explaining what Trac is blocking you from
> doing? Perhaps we can try to address some of those issues.
>
>
> On Friday, August 1, 2014 4:38:54 PM UTC-4, Christian Schmitt wrote:
>
>> its a matter of trust.
>> gerrit tracks your reviews so its way easier to build up trust that the
>> things you mark as RFC is really RFC ;)
>> And yes its a matter of tooling since some tools provide a better way to
>> build trust for such community processes.
>> Also I'm quite young. I wouldn't want to make a "community review" just
>> by myself since I will definitely do some mistakes over time as everybody
>> will do.
>>
>> to come back to the tooling. gerrit is just one tool. i don't know more
>> than gerrit that has such a large feature set. but i think there are
>> definitly some out.
>> In our company we use a lot of atlassian tools and atlassian has a
>> "gerrit" tool, too but I didn't take a look at it yet. so thats another
>> option since atlassian tools are free for community use.
>>
>> the next thing is, reading contribution docks is easy, using trac is not.
>> trac is a really blocker for a lot of things on my side. i think the ux is
>> somewhat bad, but thats just an own perspective.
>>
>>
>>
>>
>> 2014-08-01 21:49 GMT+02:00 Carl Meyer :
>>
>>> Hi Christian,
>>>
>>> On 08/01/2014 01:37 PM, Schmitt, Christian wrote:
>>> [snip]
>>> > i mean maybe we should really look at a review tool and maybe say if
>>> two
>>> > people of the community reviewed it gets pipelined to the "core" which
>>> > can do a final review. so it would be more community oriented and fewer
>>> > "bad patches" will get to the commit pipeline.
>>> > still it takes a lot of time to teach people and setup everything. but
>>> > it will put the project further ahead.
>>> > (also I'm not a core member but if we had such a review system i
>>> > would definitely do more of these reviews since thats the thing i do at
>>> > my company, too)
>>>
>>> I'm curious why the system you propose (requiring two community reviews
>>> to fast-track a patch) would motivate you to do more reviews than the
>>> current system, in which it only takes a single review (by any community
>>> member) to mark a ticket as "Ready for Check-in", which already gets it
>>> fast-tracked for commit.
>>>
>>> Although it does happen sometimes, there isn't a big problem (AFAIK)
>>> with lots of patches getting 

Re: Pull django-registration into contrib?

[James Bennett]

Speaking for myself, I am still willing to hand over the reins of
django-registration to someone who's genuinely motivated to try to solve
the issues surrounding things like custom User support, etc., though I
still do believe that's just a bridge too far for what was meant to be a
simple app.

I've been toying with the idea of splitting off a
"django-simple-registration" from an earlier version of the codebase,
building around 1.6/1.7+ idioms and just ignoring a lot of the things
Django allows people to do in favor of handling a few basic common
workflows, and let stuff like allauth be the all-singing, all-dancing,
everything-and-the-kitchen-sink user apps.

-- 
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/CAL13Cg_zyDf7M50KSLeNhR7UtmcTn8uTeYOpNYdbok6POUpMEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Write unit tests for JavaScript

[Nick Sandford]

So, I have been working a little on a PR for this (
https://github.com/django/django/pull/3003) and having spoken to Tim
briefly about getting this supported in jenkins I just wanted to check that
the approach was OK. The tests use node, grunt, qunit, istanbul and jshint.
Is this a reasonable approach? Some of the responses here are using a
similar stack.


On Mon, May 5, 2014 at 7:19 AM, Trey Hunner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I started a rough draft of a DEP for adding unit tests for Django's
> JavaScript: https://github.com/django/deps/pull/4
>
> I am suggesting that a native JavaScript test framework be used
> *without* attempting to use an adapter to run the tests under the Django
> test framework.  I anticipate that this suggestion may require further
> explanation and debate, so I have submitted a pull request for
> discussion while I continue to extend the DEP.
>
> - --
> Trey Hunner
> http://treyhunner.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTZy2KAAoJEOpnfp/Nreona8oIAKBE0T05wmnCP0tq/nvmQIlC
> 0KWB0bX47FHn3TeOjEK8dHrxebP9UDL+wmdZ8F23iOQnW8OiJIO3dJjSjqLOAXxg
> dNh5imq02kY2rvjVB6ypZp0h+INkQoaQMae5xMdN4RozLnbNrgXln7vbuSrjIB/8
> z7h983vqiRp/ofa+2urTnUnC63730gg6vBbXE5EQ+5WeJxqx2yahdbeSmB3oCnhD
> 7TMRdHYY+Tx1bdsHF3KOniKoHXA0qoeV16RK+J7EWRHMo3eKlH1zOpcbNX8klwed
> qF2zZSKFqMIj0H/mBOVWy5uePXUOfIOP4iLTjEuSy+6sPDNPCiPAvCE5R9jyz/k=
> =/i9B
> -END PGP SIGNATURE-
>
> --
> 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/53672D8A.2050005%40treyhunner.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAMwcc5WuxZ5yVQQH8wVbX51VHyaXN-ZLyrK_oJeS3e4vo5kqvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we use a django application class?

[Russell Keith-Magee]

Hi Robert,

I don't know if you've noticed, but your message is a reply to a 7 year old
thread. A lot of things have changed in the meantime - not the least of
which is the fact that Django 1.7 introduced an AppConfig object. See the
1.7 release notes and the documentation on the AppConfig object for details:

https://docs.djangoproject.com/en/1.7/releases/1.7/#app-loading-refactor
https://docs.djangoproject.com/en/1.7/ref/applications/

Yours,
Russ Magee %-)


On Fri, Aug 1, 2014 at 8:12 PM, Robert Grant 
wrote:

> Just had some thoughts about why having an application object might be a
> good idea. Pick away :)
>
>
>- Individual app objects could perhaps be introspected more easily,
>e.g. stop, start, restart functions provided for them. Also circular
>dependency detection etc, for impact analysis.
>- Apps could have the chance to declare their inputs and outputs, and
>what parts of other apps they override (e.g. I override template xyz from
>the default Django installation). Then it's easy to build up a picture
>(possibly literally) with all the apps together and what overrides what,
>and even control which gets priority programmatically. E.g. I don't want to
>always override the admin screen's change password function, as the admin
>should see it with consistent look and feel to the rest of that app, but
>for logged in users I want them to see a different change password screen.
>- Related to this - I've been bitten before by declaring my apps in
>the wrong order in my settings file. Having programmatic access might solve
>the problem of "I want one part of this app's code to have priority over
>Django's default, but I want another part to not override Django."
>- Being able to declare dependencies at the app level means I can
>import an "app type" in my code and just declare which app solves that in
>the site settings file.
>- The previous point is a self-supporting but special case which could
>be more broadly solved with dependency injection. This app relies on this
>type of app, etc. Good for testing and mocking, CI etc. Possibly Python IS
>the general case of a DI framework here, but possibly not. For example,
>rather than having a special caching framework setting, one could have a
>Redis caching app, that wraps all communication to Redis, and another
>caching app for memcached. Switching between the two would just mean
>importing a declared app dependency (e.g. import thecache) and declaring it
>in DI code: import blah.redis \ export('thecache' redis.cachewrapper). I
>know the special case of caching configuration has been solved in Django,
>but that may not be necessary if this more general mechanism were 
> available.
>
>  --
> 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/f00aeaf8-b340-4315-8c4c-b53cb2050364%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJxq848B0253SFrO09_T%3DYcB3OpwbEdObL1m3dHdSu9STsDRnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Write unit tests for JavaScript

[Trey Hunner]

Hi Nick,

Personally, I think this is a great start.  I would like to hear input
from others.

I appreciate the work you put into manually resolving those jshint
warnings.  The qunit test style looks good to me too.

I added some comments on the pull request with some suggestions for
improvements.

The biggest suggestions I made in the PR:
1. The Gruntfile.js and package.json should be moved to the top level
2. Use 4 spaces for all code in the PR (it's mostly 2 spaces currently)

Thanks for taking the initiative on this!

On 08/01/2014 05:29 PM, Nick Sandford wrote:
> So, I have been working a little on a PR for this
> (https://github.com/django/django/pull/3003) and having spoken to Tim
> briefly about getting this supported in jenkins I just wanted to check
> that the approach was OK. The tests use node, grunt, qunit, istanbul and
> jshint. Is this a reasonable approach? Some of the responses here are
> using a similar stack.
> 
> 
> On Mon, May 5, 2014 at 7:19 AM, Trey Hunner  > wrote:
> 
> I started a rough draft of a DEP for adding unit tests for Django's
> JavaScript: https://github.com/django/deps/pull/4
> 
> I am suggesting that a native JavaScript test framework be used
> *without* attempting to use an adapter to run the tests under the Django
> test framework.  I anticipate that this suggestion may require further
> explanation and debate, so I have submitted a pull request for
> discussion while I continue to extend the DEP.
> 
> 
> --
> 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/53672D8A.2050005%40treyhunner.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> 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/CAMwcc5WuxZ5yVQQH8wVbX51VHyaXN-ZLyrK_oJeS3e4vo5kqvA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Trey Hunner
http://treyhunner.com

-- 
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/53DC7575.2040808%40treyhunner.com.
For more options, visit https://groups.google.com/d/optout.