Re: 1.7 release status (RC2 coming soon)

[Andre Terra]

On Fri, Jul 25, 2014 at 5:12 PM, Ryan Hiebert  wrote:

> I agree that learning to deal with git is probably one of the best things
> we can encourage a new user to do. To that extent, I agree with your
> sentiment, and if we can encourage more usage of git, I’m all for it. We
> are the entry point to development for many people, and if we can use our
> position of authority to encourage newcomers to do things right, that’s a
> great idea.
>
> However, I perceived that the debate was more about the bastardization of
> the “release candidate” version name for something that’s not possible to
> release, and I’m OK with it, if it’s really going to be helpful. I, for
> instance, would prefer to be testing some of my projects off of a
> pre-release version on PyPI, at least partially because I know that pip
> freeze will have a version string that works (and isn’t -e with a huge git
> commit hash).
>
> We can’t go back and make another beta, because the versioning won’t be
> properly ordered, and that’s a Bad Thing. That leaves us with either not
> releasing, or releasing an RC with known bugs. The RC turning into a
> release possibility isn’t such a hard requirement for me, it’s just
> another, more polished, beta version, that’s closer to release. I certainly
> don’t want to stop being able to versioning things just because we’re
> getting lots of help finding bugs.
>
> Ryan
>


Touché. I guess my complaint was mostly directed to Ian's original post --
claiming that to tell a user to git clone is confusing -- than at your
concerns about the beta/RC debacle. FWIW, I also believe an RC2 is the
correct path to pursue, because practicality beats purity. It's pretty
clearly the lesser of two evils.


Best,
AT

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

Re: Overriding AppConfig.get_model(s)

[Andrew Godwin]

Actually, managed won't work, because that just affects if stuff gets put
into migration files, IIRC - even if you change it it won't affect
migrations.

The main problem is that whatever you do, Django is going to mark the
migration as applied if you have sessions set to a non-db store and then
when you switch the setting to a db store it's not going to magically mark
the migration as unapplied and make the table again. People are going to
have to run "./manage.py migrate --fake sessions zero; ./manage.py migrate
sessions" to make the table.

The only sensible approach would be to change the session app's
MIGRATION_MODULES based on the setting, to point to an empty set of
migrations if it's non-db and a set with one to make the table with it in
if it's db. This will have the intended effect but Django might get annoyed
if you switch from db to non-db and now it has a migration applied that no
longer exists on disk.

Andrew


On Fri, Jul 25, 2014 at 1:38 PM, Nick Sandford 
wrote:

> Managed might be the ticket then. I don't think it's too surprising to the
> user who configures a cache or file session backend that no database table
> is created. I think that's slightly less surprising than the status quo --
> they configured a file session backend and when they run migrate they
> notice that a database table for sessions has been created, which might
> lead them to question if the session backend is working as intended. I'll
> pursue the meta option for now :).
>
> If they start with the database backend, and switch at a later date to a
> non-database backend, then I'm comfortable to make it the user's
> responsibility to clean up the leftover database table, but were you
> suggesting if they start with a non-database backend and at some later
> stage decide to switch to a database backend it won't work?
>
> Thanks for the help.
>
> Nick
>
>
>
>
> On Fri, Jul 25, 2014 at 9:24 PM, Andrew Godwin 
> wrote:
>
>> Yeah, but if you change the value of the routers during a project's
>> lifetime it's up to you to fix the resulting issues (same as if you switch
>> AUTH_USER_MODEL - you _cannot_ change this after project start without
>> serious pain).
>>
>> If you're happy saying the same thing about sessions, then go and tie the
>> model's managed option to the setting - that should do what you want - but
>> people are going to get real confused when they change the setting and the
>> table isn't made for them.
>>
>> Andrew
>>
>>
>> On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford 
>> wrote:
>>
>>> Isn't that essentially what's happening by respecting
>>> router.allow_migrate? Determining at runtime via a setting
>>> (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a
>>> user, providing a custom database router makes sense for applications they
>>> don't control, but from the perspective of an reusable app developer who
>>> doesn't have access to the project's settings, using database routers seems
>>> a bit more cumbersome.
>>>
>>> I guess I'm just thinking that having an alternative method would be
>>> useful. I'm happy to help find a solution if you feel it's a worthwhile
>>> pursuit.
>>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin 
>>> wrote:
>>>
 I don't think there's a way you can do this with migrations. You're not
 supposed to be able to change them at runtime based on settings; that was
 the cause of most of our bugs with swappable models.

 Andrew


 On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford <
 nick.sandf...@gmail.com> wrote:

> Ahh ok, that makes sense -- I guess there's no difference between
> overriding get_model(s) and manually deleting the model out of the source
> to the migrations.
>
> I can't think of any decent way to use router.allow_migrate in
> sessions other than monkey patching it to do what I want. Any suggestions?
>
> Would it be possible to detect that the models are being manually
> excluded rather than removed from the source and migrate them differently?
>
> Cheers,
> Nick
>
>
> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin 
> wrote:
>
>> Migrations instantiate their own copies of AppConfig and Apps and run
>> from those, so you won't be able to affect them by overriding methods. If
>> you want to exclude models from migrations use router.allow_migrate.
>>
>> Andrew
>>
>>
>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <
>> nick.sandf...@gmail.com> wrote:
>>
>>> I was just working on #22986 and it seems that if the
>>> AppConfig.get_model(s) methods are overridden, migrations for models 
>>> that
>>> are excluded are still run.
>>>
>>> Is this a known issue? Am I abusing get_model(s) or should I file a
>>> ticket for this?
>>>

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Managed might be the ticket then. I don't think it's too surprising to the
user who configures a cache or file session backend that no database table
is created. I think that's slightly less surprising than the status quo --
they configured a file session backend and when they run migrate they
notice that a database table for sessions has been created, which might
lead them to question if the session backend is working as intended. I'll
pursue the meta option for now :).

If they start with the database backend, and switch at a later date to a
non-database backend, then I'm comfortable to make it the user's
responsibility to clean up the leftover database table, but were you
suggesting if they start with a non-database backend and at some later
stage decide to switch to a database backend it won't work?

Thanks for the help.

Nick




On Fri, Jul 25, 2014 at 9:24 PM, Andrew Godwin  wrote:

> Yeah, but if you change the value of the routers during a project's
> lifetime it's up to you to fix the resulting issues (same as if you switch
> AUTH_USER_MODEL - you _cannot_ change this after project start without
> serious pain).
>
> If you're happy saying the same thing about sessions, then go and tie the
> model's managed option to the setting - that should do what you want - but
> people are going to get real confused when they change the setting and the
> table isn't made for them.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford 
> wrote:
>
>> Isn't that essentially what's happening by respecting
>> router.allow_migrate? Determining at runtime via a setting
>> (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a
>> user, providing a custom database router makes sense for applications they
>> don't control, but from the perspective of an reusable app developer who
>> doesn't have access to the project's settings, using database routers seems
>> a bit more cumbersome.
>>
>> I guess I'm just thinking that having an alternative method would be
>> useful. I'm happy to help find a solution if you feel it's a worthwhile
>> pursuit.
>>
>> Cheers,
>> Nick
>>
>>
>> On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin 
>> wrote:
>>
>>> I don't think there's a way you can do this with migrations. You're not
>>> supposed to be able to change them at runtime based on settings; that was
>>> the cause of most of our bugs with swappable models.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford >> > wrote:
>>>
 Ahh ok, that makes sense -- I guess there's no difference between
 overriding get_model(s) and manually deleting the model out of the source
 to the migrations.

 I can't think of any decent way to use router.allow_migrate in sessions
 other than monkey patching it to do what I want. Any suggestions?

 Would it be possible to detect that the models are being manually
 excluded rather than removed from the source and migrate them differently?

 Cheers,
 Nick


 On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin 
 wrote:

> Migrations instantiate their own copies of AppConfig and Apps and run
> from those, so you won't be able to affect them by overriding methods. If
> you want to exclude models from migrations use router.allow_migrate.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <
> nick.sandf...@gmail.com> wrote:
>
>> I was just working on #22986 and it seems that if the
>> AppConfig.get_model(s) methods are overridden, migrations for models that
>> are excluded are still run.
>>
>> Is this a known issue? Am I abusing get_model(s) or should I file a
>> ticket for this?
>>
>> Cheers,
>> Nick
>>
>> https://code.djangoproject.com/ticket/22986#comment:5
>>
>> --
>> 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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 

Re: Overriding AppConfig.get_model(s)

[Andrew Godwin]

Yeah, but if you change the value of the routers during a project's
lifetime it's up to you to fix the resulting issues (same as if you switch
AUTH_USER_MODEL - you _cannot_ change this after project start without
serious pain).

If you're happy saying the same thing about sessions, then go and tie the
model's managed option to the setting - that should do what you want - but
people are going to get real confused when they change the setting and the
table isn't made for them.

Andrew


On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford 
wrote:

> Isn't that essentially what's happening by respecting
> router.allow_migrate? Determining at runtime via a setting
> (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a
> user, providing a custom database router makes sense for applications they
> don't control, but from the perspective of an reusable app developer who
> doesn't have access to the project's settings, using database routers seems
> a bit more cumbersome.
>
> I guess I'm just thinking that having an alternative method would be
> useful. I'm happy to help find a solution if you feel it's a worthwhile
> pursuit.
>
> Cheers,
> Nick
>
>
> On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin 
> wrote:
>
>> I don't think there's a way you can do this with migrations. You're not
>> supposed to be able to change them at runtime based on settings; that was
>> the cause of most of our bugs with swappable models.
>>
>> Andrew
>>
>>
>> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford 
>> wrote:
>>
>>> Ahh ok, that makes sense -- I guess there's no difference between
>>> overriding get_model(s) and manually deleting the model out of the source
>>> to the migrations.
>>>
>>> I can't think of any decent way to use router.allow_migrate in sessions
>>> other than monkey patching it to do what I want. Any suggestions?
>>>
>>> Would it be possible to detect that the models are being manually
>>> excluded rather than removed from the source and migrate them differently?
>>>
>>> Cheers,
>>> Nick
>>>
>>>
>>> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin 
>>> wrote:
>>>
 Migrations instantiate their own copies of AppConfig and Apps and run
 from those, so you won't be able to affect them by overriding methods. If
 you want to exclude models from migrations use router.allow_migrate.

 Andrew


 On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford <
 nick.sandf...@gmail.com> wrote:

> I was just working on #22986 and it seems that if the
> AppConfig.get_model(s) methods are overridden, migrations for models that
> are excluded are still run.
>
> Is this a known issue? Am I abusing get_model(s) or should I file a
> ticket for this?
>
> Cheers,
> Nick
>
> https://code.djangoproject.com/ticket/22986#comment:5
>
> --
> 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%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 

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Isn't that essentially what's happening by respecting router.allow_migrate?
Determining at runtime via a setting (DATABASE_ROUTERS) whether to apply
migrations. From the perspective of a user, providing a custom database
router makes sense for applications they don't control, but from the
perspective of an reusable app developer who doesn't have access to the
project's settings, using database routers seems a bit more cumbersome.

I guess I'm just thinking that having an alternative method would be
useful. I'm happy to help find a solution if you feel it's a worthwhile
pursuit.

Cheers,
Nick


On Fri, Jul 25, 2014 at 9:02 PM, Andrew Godwin  wrote:

> I don't think there's a way you can do this with migrations. You're not
> supposed to be able to change them at runtime based on settings; that was
> the cause of most of our bugs with swappable models.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford 
> wrote:
>
>> Ahh ok, that makes sense -- I guess there's no difference between
>> overriding get_model(s) and manually deleting the model out of the source
>> to the migrations.
>>
>> I can't think of any decent way to use router.allow_migrate in sessions
>> other than monkey patching it to do what I want. Any suggestions?
>>
>> Would it be possible to detect that the models are being manually
>> excluded rather than removed from the source and migrate them differently?
>>
>> Cheers,
>> Nick
>>
>>
>> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin 
>> wrote:
>>
>>> Migrations instantiate their own copies of AppConfig and Apps and run
>>> from those, so you won't be able to affect them by overriding methods. If
>>> you want to exclude models from migrations use router.allow_migrate.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford >> > wrote:
>>>
 I was just working on #22986 and it seems that if the
 AppConfig.get_model(s) methods are overridden, migrations for models that
 are excluded are still run.

 Is this a known issue? Am I abusing get_model(s) or should I file a
 ticket for this?

 Cheers,
 Nick

 https://code.djangoproject.com/ticket/22986#comment:5

 --
 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%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/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%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 

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> On Jul 25, 2014, at 2:22 PM, Andre Terra  wrote:
> On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert  wrote:
> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look for the most recent release and use that (on the other hand, if
> > they see a beta 4 and an RC 1, they might not necessarily realize the
> > beta 4 is most recent either, so I take your point). The second
> > benefit is that the instructions "pull the latest from github" can
> > *sound* like a lot of work if the user is not a contributor and isn't
> > experienced with git, and that might deter them from testing.
> 
> That makes sense to me. It’s basically the same reasons that a release on 
> PyPI would be helpful: it sounds easier to a newcomer. If there’s consensus 
> on that point (I still think git is pretty easy, but I’ve been using it quite 
> a while), then I’m comfortable with the compromise of the RC nomenclature.
> 
> I respectfully disagree. Honestly, newcomers benefit more from learning 'git 
> clone foo' than from downloading tarballs from PyPI. For one thing, they are 
> probably going to need to learn it sooner or later and use version control in 
> their own projects, together with pip and virtualenv, lest they want to go 
> into a rabbit hole of frustrating import errors. *This* is what will make a 
> newcomer give up on Django/Python.
> 
> The learning curve for pulling something off a git repo is inexistent. We're 
> not asking them to git bisect, after all. It should be the standard, IMHO.

I agree that learning to deal with git is probably one of the best things we 
can encourage a new user to do. To that extent, I agree with your sentiment, 
and if we can encourage more usage of git, I’m all for it. We are the entry 
point to development for many people, and if we can use our position of 
authority to encourage newcomers to do things right, that’s a great idea.

However, I perceived that the debate was more about the bastardization of the 
“release candidate” version name for something that’s not possible to release, 
and I’m OK with it, if it’s really going to be helpful. I, for instance, would 
prefer to be testing some of my projects off of a pre-release version on PyPI, 
at least partially because I know that pip freeze will have a version string 
that works (and isn’t -e with a huge git commit hash).

We can’t go back and make another beta, because the versioning won’t be 
properly ordered, and that’s a Bad Thing. That leaves us with either not 
releasing, or releasing an RC with known bugs. The RC turning into a release 
possibility isn’t such a hard requirement for me, it’s just another, more 
polished, beta version, that’s closer to release. I certainly don’t want to 
stop being able to versioning things just because we’re getting lots of help 
finding bugs.

Ryan

-- 
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/93DA56F4-1F2E-480F-8DF3-C5F7B95B18F5%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding AppConfig.get_model(s)

[Andrew Godwin]

I don't think there's a way you can do this with migrations. You're not
supposed to be able to change them at runtime based on settings; that was
the cause of most of our bugs with swappable models.

Andrew


On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford 
wrote:

> Ahh ok, that makes sense -- I guess there's no difference between
> overriding get_model(s) and manually deleting the model out of the source
> to the migrations.
>
> I can't think of any decent way to use router.allow_migrate in sessions
> other than monkey patching it to do what I want. Any suggestions?
>
> Would it be possible to detect that the models are being manually excluded
> rather than removed from the source and migrate them differently?
>
> Cheers,
> Nick
>
>
> On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin 
> wrote:
>
>> Migrations instantiate their own copies of AppConfig and Apps and run
>> from those, so you won't be able to affect them by overriding methods. If
>> you want to exclude models from migrations use router.allow_migrate.
>>
>> Andrew
>>
>>
>> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford 
>> wrote:
>>
>>> I was just working on #22986 and it seems that if the
>>> AppConfig.get_model(s) methods are overridden, migrations for models that
>>> are excluded are still run.
>>>
>>> Is this a known issue? Am I abusing get_model(s) or should I file a
>>> ticket for this?
>>>
>>> Cheers,
>>> Nick
>>>
>>> https://code.djangoproject.com/ticket/22986#comment:5
>>>
>>> --
>>> 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%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/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%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/CAFwN1uqCaeGrc9K58ErPLP-m9UoztBXCVgNC4-9Nu4RJVKWUMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overriding AppConfig.get_model(s)

[Nick Sandford]

Ahh ok, that makes sense -- I guess there's no difference between
overriding get_model(s) and manually deleting the model out of the source
to the migrations.

I can't think of any decent way to use router.allow_migrate in sessions
other than monkey patching it to do what I want. Any suggestions?

Would it be possible to detect that the models are being manually excluded
rather than removed from the source and migrate them differently?

Cheers,
Nick


On Fri, Jul 25, 2014 at 8:05 PM, Andrew Godwin  wrote:

> Migrations instantiate their own copies of AppConfig and Apps and run from
> those, so you won't be able to affect them by overriding methods. If you
> want to exclude models from migrations use router.allow_migrate.
>
> Andrew
>
>
> On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford 
> wrote:
>
>> I was just working on #22986 and it seems that if the
>> AppConfig.get_model(s) methods are overridden, migrations for models that
>> are excluded are still run.
>>
>> Is this a known issue? Am I abusing get_model(s) or should I file a
>> ticket for this?
>>
>> Cheers,
>> Nick
>>
>> https://code.djangoproject.com/ticket/22986#comment:5
>>
>> --
>> 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%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/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Andre Terra]

On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert  wrote:

> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look for the most recent release and use that (on the other hand, if
> > they see a beta 4 and an RC 1, they might not necessarily realize the
> > beta 4 is most recent either, so I take your point). The second
> > benefit is that the instructions "pull the latest from github" can
> > *sound* like a lot of work if the user is not a contributor and isn't
> > experienced with git, and that might deter them from testing.
>
> That makes sense to me. It’s basically the same reasons that a release on
> PyPI would be helpful: it sounds easier to a newcomer. If there’s consensus
> on that point (I still think git is pretty easy, but I’ve been using it
> quite a while), then I’m comfortable with the compromise of the RC
> nomenclature.


I respectfully disagree. Honestly, newcomers benefit more from learning
'git clone foo' than from downloading tarballs from PyPI. For one thing,
they are probably going to need to learn it sooner or later and use version
control in their own projects, together with pip and virtualenv, lest they
want to go into a rabbit hole of frustrating import errors. *This* is what
will make a newcomer give up on Django/Python.

The learning curve for pulling something off a git repo is inexistent.
We're not asking them to git bisect, after all. It should be the standard,
IMHO.


Cheers,
AT

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

Re: Overriding AppConfig.get_model(s)

[Andrew Godwin]

Migrations instantiate their own copies of AppConfig and Apps and run from
those, so you won't be able to affect them by overriding methods. If you
want to exclude models from migrations use router.allow_migrate.

Andrew


On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford 
wrote:

> I was just working on #22986 and it seems that if the
> AppConfig.get_model(s) methods are overridden, migrations for models that
> are excluded are still run.
>
> Is this a known issue? Am I abusing get_model(s) or should I file a ticket
> for this?
>
> Cheers,
> Nick
>
> https://code.djangoproject.com/ticket/22986#comment:5
>
> --
> 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/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%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/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Overriding AppConfig.get_model(s)

[Nick Sandford]

I was just working on #22986 and it seems that if the
AppConfig.get_model(s) methods are overridden, migrations for models that
are excluded are still run.

Is this a known issue? Am I abusing get_model(s) or should I file a ticket
for this?

Cheers,
Nick

https://code.djangoproject.com/ticket/22986#comment:5

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

Re: 1.7 release status (RC2 coming soon)

[Tim Graham]

Here is the ticket for putting pre-releases on PyPI.

https://code.djangoproject.com/ticket/21108

We tried it for 1.7 alpha but it didn't work.

On Friday, July 25, 2014 11:21:21 AM UTC-4, Carl Meyer wrote:
>
> On 07/25/2014 09:17 AM, Ryan Hiebert wrote: 
> > On a somewhat-related tangent, I seem to recall there being a good 
> > reason for not releasing pre-release versions on PyPI, but I’m having 
> > trouble finding the discussions that document that reason. Anybody 
> > care to enlighten me, or give me a link? 
>
> Until quite recently, pip (if just told to "pip install Django" without 
> version specification) would install the latest release found on PyPI, 
> regardless of whether it was a pre-release or final release. This was a 
> very good reason not to put pre-releases on PyPI. 
>
> Now that pip defaults to not installing pre-releases, there might be an 
> argument for changing that policy. There may still be a concern about 
> people still using older versions of pip in their deployment systems (or 
> easy_install, which I don't think avoids pre-releases?) suddenly 
> beginning to accidentally install pre-releases. 
>
> 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/fc80c1f6-c7f3-447e-bcec-05d9894abf58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Jacob Kaplan-Moss]

+1.

Aymeric, I can't thank you enough for taking this on and running with it.

Jacob


On Fri, Jul 25, 2014 at 7:20 AM, Chris Foresman  wrote:

> As a non-core community member, I welcome a streamlined way for new
> potential coders to contribute.
>
>
> On Thursday, July 24, 2014 7:02:16 AM UTC-5, Russell Keith-Magee wrote:
>
>> Hi Aymeric.
>>
>> A big +1 from me. Thanks for all your work drafting these modifications.
>>
>> Russ %-)
>>
>>
>> On Wed, Jul 23, 2014 at 9:29 PM, Aymeric Augustin > 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/4920b823-debe-411c-8b3f-6fad13c10604%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/CAK8PqJGXO%3DZzkPkDFd2dfGfJs2k9x9S0An5%2BCCHhhNBOk2XDOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Carl Meyer]

On 07/25/2014 09:17 AM, Ryan Hiebert wrote:
> On a somewhat-related tangent, I seem to recall there being a good
> reason for not releasing pre-release versions on PyPI, but I’m having
> trouble finding the discussions that document that reason. Anybody
> care to enlighten me, or give me a link?

Until quite recently, pip (if just told to "pip install Django" without
version specification) would install the latest release found on PyPI,
regardless of whether it was a pre-release or final release. This was a
very good reason not to put pre-releases on PyPI.

Now that pip defaults to not installing pre-releases, there might be an
argument for changing that policy. There may still be a concern about
people still using older versions of pip in their deployment systems (or
easy_install, which I don't think avoids pre-releases?) suddenly
beginning to accidentally install pre-releases.

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

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> On Jul 25, 2014, at 10:06 AM, Ian Kelly  wrote:
> 
> On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert  wrote:
>> 
>>> On Jul 25, 2014, at 12:22 AM, Ian Kelly  wrote:
>>> 
>>> It seems to me that a new release would be useful to have for the
>>> reasons given, but it should be called what it is: a beta version, not
>>> an RC.
>>> 
>> I agree, but I don’t think that releasing a beta after an RC makes good 
>> sense either. If there was a really significant benefit to the release, then 
>> calling it an RC even though it’s more of a beta seems like a reasonable 
>> compromise. I don’t really see a significant benefit to the release over 
>> just using latest git branch, though.
> 
> I see two benefits. One is that users who are interested in testing
> aren't necessarily going to think to go to github; they're likely to
> look for the most recent release and use that (on the other hand, if
> they see a beta 4 and an RC 1, they might not necessarily realize the
> beta 4 is most recent either, so I take your point). The second
> benefit is that the instructions "pull the latest from github" can
> *sound* like a lot of work if the user is not a contributor and isn't
> experienced with git, and that might deter them from testing.

That makes sense to me. It’s basically the same reasons that a release on PyPI 
would be helpful: it sounds easier to a newcomer. If there’s consensus on that 
point (I still think git is pretty easy, but I’ve been using it quite a while), 
then I’m comfortable with the compromise of the RC nomenclature.

On a somewhat-related tangent, I seem to recall there being a good reason for 
not releasing pre-release versions on PyPI, but I’m having trouble finding the 
discussions that document that reason. Anybody care to enlighten me, or give me 
a link?

-- 
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/3A65D698-6876-47C9-A666-24F527A39B1A%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ian Kelly]

On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert  wrote:
>
>> On Jul 25, 2014, at 12:22 AM, Ian Kelly  wrote:
>>
>> It seems to me that a new release would be useful to have for the
>> reasons given, but it should be called what it is: a beta version, not
>> an RC.
>>
> I agree, but I don’t think that releasing a beta after an RC makes good sense 
> either. If there was a really significant benefit to the release, then 
> calling it an RC even though it’s more of a beta seems like a reasonable 
> compromise. I don’t really see a significant benefit to the release over just 
> using latest git branch, though.

I see two benefits. One is that users who are interested in testing
aren't necessarily going to think to go to github; they're likely to
look for the most recent release and use that (on the other hand, if
they see a beta 4 and an RC 1, they might not necessarily realize the
beta 4 is most recent either, so I take your point). The second
benefit is that the instructions "pull the latest from github" can
*sound* like a lot of work if the user is not a contributor and isn't
experienced with git, and that might deter them from testing.

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Brian,

On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django (or a versioned dependency on a really old version)
> doesn't necessarily mean they will work with any 1.4.5. Anyone want to test
> every Django package in Debian sid against the Django in wheezy?

I agree with you that this is not realistic. A better alternate solution
is to document the process of how to execute the South migrations with
Django 1.6 in a virtualenv after having done the upgrade to Debian 8.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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/20140725074344.GA15591%40x230-buxy.home.ouaza.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Chris Foresman]

As a non-core community member, I welcome a streamlined way for new 
potential coders to contribute.

On Thursday, July 24, 2014 7:02:16 AM UTC-5, Russell Keith-Magee wrote:
>
> Hi Aymeric.
>
> A big +1 from me. Thanks for all your work drafting these modifications.
>
> Russ %-)
>
> On Wed, Jul 23, 2014 at 9:29 PM, 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/4920b823-debe-411c-8b3f-6fad13c10604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> On Jul 25, 2014, at 12:22 AM, Ian Kelly  wrote:
> 
> It seems to me that a new release would be useful to have for the
> reasons given, but it should be called what it is: a beta version, not
> an RC.
> 
I agree, but I don’t think that releasing a beta after an RC makes good sense 
either. If there was a really significant benefit to the release, then calling 
it an RC even though it’s more of a beta seems like a reasonable compromise. I 
don’t really see a significant benefit to the release over just using latest 
git branch, though.

-- 
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/7C2E3124-0B7B-40E2-AC06-EA54289D3E9A%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Andrew, 

thanks for your quick answer.

On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages before? (Version
> upgrades that break installed but non-packaged things)

We probably had this kind of things before and the best we can do for
non-packaged things is usally to document this in the release notes.

But for packaged things, we try usually hard to get things to just work
without any human intervention. Hence my question.

> Neither of your suggested ways to go forward will work; the two history
> models are very different, so the tagging of positions isn't going to work,
> and Django 1.7 has changed substantially enough internally that porting
> South 1.x up to it would be a very large amount of work.

OK.

> Also, what are the applications in particular that this will be a problem
> for? I'm curious to know what Django + South things Debian is shipping
> these days.

Applications that depend on South and have different upstream versions
in Debian 7 and Debian 8 are:
http://tracker.debian.org/pkg/python-django-voting
http://tracker.debian.org/pkg/python-django-threadedcomments
http://tracker.debian.org/pkg/python-django-reversion
http://tracker.debian.org/pkg/python-django-picklefield
http://tracker.debian.org/pkg/bcfg2

Given the package names, it probably means only a single end-user application.
The others are Django "extensions" for use in non-packaged applications.

And looking more closely the case of bcfg2, the package in Debian 7 does
not use South, it started using South in the version in Jessie so it
should be easy to deal with.

For the 4 others, they should provide some NEWS.Debian entry warning
users of the potential upgrade problem.

(Bccing the 5 relevant bug reports to keep a record of this)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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/20140725080457.GC15591%40x230-buxy.home.ouaza.com.
For more options, visit https://groups.google.com/d/optout.