Re: Must a Django Database Support Migrations?

[Marten Kenbeek]

Hi Marcin,

I don't believe it's some sort of ethos that got Andrew to collaborate with 
Django and create the current migration framework: It's the fact that 
pretty much everyone who used Django also used South that convinced Andrew 
to recreate its behaviour as a core Django app.

I'm not saying that Liquibase isn't useful -- I haven't really investigated 
the project you're pitching. I'm simply saying that migrations are 
considered a necessary feature for any decently-sized project, and 
currently Django's way of supplying this is its core migration framework. 
If you are able to patch Django's behaviour to not depend on its core 
migration framework, but to depend on a pluggable migration backend, I'm 
sure everyone will be very happy to see that as a Django core feature. But 
as is currently stand, it's a lot of work to recreate the Django migration 
framework as a pluggable backend, and it's not worth it if there isn't a 
tightly integrated migration framework that picks up the changes to Django 
models. 

It should still be quite easy to use Liquibase for your database 
management: simply set your models as `managed=False`, and you'll have full 
control over your database. You'll simply have to keep your Django models 
up-to-date to use them. 

With king regards,
Marten

Op maandag 27 april 2015 02:33:44 UTC+2 schreef Marcin Nowak:
>
> Hi. 
>
> Before v1.7 there were no migrations and Django was quite useful (for 
> example with South as an 3rd party app). What happened then?
>
> I think that migrations can be decoupled from core and you just don't want 
> to do this for some unknown reason. 
> I'll prepare a pull request if it will not be dropped because of some kind 
> of ethos.
>
> BR
> Marcin
>
> On Saturday, April 18, 2015 at 5:03:39 AM UTC+2, Markus Holtermann wrote:
>>
>> Hey Marvin, 
>>
>> Unfortunately this won't work as a few migration components are tightly 
>> integrated into remaining parts of Django, e.g. the field deconstruction. 
>>
>> /Markus 
>>
>> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak <
>> marcin@gmail.com> wrote: 
>> >Hi. 
>> >Just give people possibility to disable migrations functionality 
>> >(remove it 
>> >from core and put as a contrib app, if needed). 
>> > 
>> >/BR 
>> >Marcin 
>> > 
>> > 
>> >On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote: 
>> >> 
>> >> Aha! Then, I would suggest redesigning MigrationRecorder to only make 
>> >the 
>> >> table when an actual recording operation is done, and have it swallow 
>> >the 
>> >> table not existing as "no migrations applied" the rest of the time, 
>> >if 
>> >> people think that seems sensible. 
>> >> 
>> >> Andrew 
>> >> 
>> >> On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann < 
>> >> in...@markusholtermann.eu > wrote: 
>> >> 
>> >>> Hey, 
>> >>> 
>> >>> as soon as the MigrationRecorder is used there is a call to 
>> >>> "ensure_schema" that forces the creation of the migration table. The 
>> > 
>> >>> runserver command (among others?) checks for unapplied migrations 
>> >and thus 
>> >>> creates the migration table. 
>> >>> 
>> >>> /Markus 
>> >>> 
>> >>> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin 
>> >wrote: 
>>  
>>  Hi Ivan, 
>>  
>>  I'm not sure what you're asking here - are you asking to have a way 
>> >to 
>>  not have Django create the migrations recording table? I was under 
>> >the 
>>  impression that it was only created when migrate was run (at least, 
>> >that 
>>  was my original intention) so if you're managing your own schema 
>> >just don't 
>>  run migrate. Is there something else that's not working right, or 
>> >is that 
>>  being made too optimistically? 
>>  
>>  Andrew 
>>  
>>  On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel  
>> >wrote: 
>>  
>> > From Andrew: "The only extra thing it would achieve is not having 
>> > Django record migrations in the django_migrations table" 
>> > 
>> > The Django Users thread on how to keep this table from being 
>> >created 
>> > seemed to result in the 'solution' being either to stay with 1.6 
>> >or comment 
>> > the relevant lines in the Django code base. Is there really no 
>> >other way? 
>> > 
>> > I love the new migrations facilities in Django 1.7 and was a 
>> > contributor to the kickstarter but please keep in mind that many 
>> >legacy DB 
>> > projects are not avoiding migrations because they want to. IMO 
>> >it's usually 
>> > because they are forced to for some (usually political) reason 
>> >where they 
>> > don't have control over the schema. Forcing a perpetually empty 
>> > django_migrations table pretty much locks out those users. 
>> > 
>> > I see that people are worried about encouraging the non-use of 
>> > migrations but might I suggest following the Zen of Python and 
>> >making 
>> > migrations the "one obvious way to do it" and turning them off the 
>

Re: Potentially inconsistent behavior between test client and normal WSGI requests

[Matt Hooks]

I've checked against the wsgiref module and you are most certainly correct: 
unquoting PATH_INFO is the job of the wsgi server.

I'll being up the issue with with the aiohttp folks.  Thanks for your time.


On Saturday, April 25, 2015 at 3:02:50 AM UTC-4, Florian Apolloner wrote:
>
>
>
> On Saturday, April 25, 2015 at 8:46:58 AM UTC+2, Matt Hooks wrote:
>>
>> I'm not really familiar with the design ideals of the Django devs or the 
>> WSGI spec.  From what I can tell, the spec doesn't specify whether the url 
>> should be unquoted before passing it to the application.
>>
>
> I think the WSGI spec somewhat follows the CGI spec which says:
> Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain 
> path-segment parameters.
>
> So to my understanding this seems to be a bug in whatever you use, no?
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/0fa133ed-4006-4295-bded-ba29c18055c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Must a Django Database Support Migrations?

[Michael Manfre]

On Sun, Apr 26, 2015 at 8:33 PM, Marcin Nowak 
wrote:

> Hi.
>
> Before v1.7 there were no migrations and Django was quite useful (for
> example with South as an 3rd party app). What happened then?
>
> I think that migrations can be decoupled from core and you just don't want
> to do this for some unknown reason.
> I'll prepare a pull request if it will not be dropped because of some kind
> of ethos.
>

As the person who started this thread over a year ago with the motivation
of making migrations support optional, I can definitively say that
migrations will not be removed from Django. Any pull request attempting to
do so will be declined. There are certain portions of Django that can (and
likely should) be decoupled, the database API (including migrations) is not
one of those pieces. One of the many reasons for it to remain in core is
that it's useful being able to modify the models that ship with Django.
E.g. increasing the size of user name field.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAGdCwBvKVPhERYzSpP9AZ6%2Bd83ehiZhC%2BUqMXf9SRQzw_W%2B5%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

The idea of the release schedule question is to form consensus on the 
options that have already been proposed in the "1.9 release planning 
" 
thread. If you have a different idea, please propose it there.

On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote:
>
>  I like the idea of an survey, but find the release question with only 3 
> options quite limited, how about to allow there to put own numbers instead 
> of giving fixed answers or at least an other field?
>
> Am 25.04.2015 14:29, schrieb Tim Graham:
>  
> Aymeric and I put together a draft:
>
>
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>
> All questions are optional so you can just click through it to view the 
> questions. We'll probably clear any responses before its finalized anyway.
>
> Let us know if you think we should make any additions or changes.
>
> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote: 
>>
>> Great idea. 
>> The questions look good enough to me.
>>
>>  I love django-apps or libraries shipped in python packages. One of the 
>> reason I love Django is the fact that it didn't frenetically add stuff to 
>> the framework just because it's cool.
>> The good thing of python packages is that you can get some data from pypi 
>> (downloads) and github (clones). But we can't do that with contrib apps 
>> unfortunately.
>>
>>  Federico
>>
>>
>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>>>
>>> I had an idea to conduct a survey to get a sense of how developers are 
>>> using Django. I first had the idea when the question of maintenance of the 
>>> Oracle GIS backend came up. We really have no idea whether or not anyone is 
>>> actually using that backend, and it would be helpful to know so we are not 
>>> wasting resources on unused features. Also there's the question of how 
>>> often to release Django. I think it would be nice to make that decision 
>>> based on some data from the community.
>>>
>>> Is anyone is interested in coordinating such a survey (collating 
>>> questions, preparing the online survey, etc.).
>>>
>>> Some question ideas to get started:
>>>
>>> Which database backend(s) do you use?
>>> [ ] Checkbox for each one
>>>
>>> Which contrib apps do you use?
>>> [ ] Checkbox for each one
>>>
>>> How often would you like to see new major version of Django released?
>>> [ ] List some options, probably between 6 and 9 months.
>>>
>>> Describe which version of Django you use (check all the apply):
>>> [ ] I only use long-term support releases.
>>> [ ] I upgrade to the latest stable version as quickly as possible.
>>> [ ] I run off of master.
>>> [ ] I upgrade Django when the version I am using is nearing the end of 
>>> its support (or after).
>>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>>  
>>   -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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/f14071d1-c570-483a-abd2-833e1b47ab4d%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  (Contributions to Django itself)" 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/b2c3d0ac-1a8e-4a70-9fb7-24bf6e0e1581%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Must a Django Database Support Migrations?

[Marcin Nowak]

Hi. 

Before v1.7 there were no migrations and Django was quite useful (for 
example with South as an 3rd party app). What happened then?

I think that migrations can be decoupled from core and you just don't want 
to do this for some unknown reason. 
I'll prepare a pull request if it will not be dropped because of some kind 
of ethos.

BR
Marcin

On Saturday, April 18, 2015 at 5:03:39 AM UTC+2, Markus Holtermann wrote:
>
> Hey Marvin, 
>
> Unfortunately this won't work as a few migration components are tightly 
> integrated into remaining parts of Django, e.g. the field deconstruction. 
>
> /Markus 
>
> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak  > wrote: 
> >Hi. 
> >Just give people possibility to disable migrations functionality 
> >(remove it 
> >from core and put as a contrib app, if needed). 
> > 
> >/BR 
> >Marcin 
> > 
> > 
> >On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote: 
> >> 
> >> Aha! Then, I would suggest redesigning MigrationRecorder to only make 
> >the 
> >> table when an actual recording operation is done, and have it swallow 
> >the 
> >> table not existing as "no migrations applied" the rest of the time, 
> >if 
> >> people think that seems sensible. 
> >> 
> >> Andrew 
> >> 
> >> On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann < 
> >> in...@markusholtermann.eu > wrote: 
> >> 
> >>> Hey, 
> >>> 
> >>> as soon as the MigrationRecorder is used there is a call to 
> >>> "ensure_schema" that forces the creation of the migration table. The 
> > 
> >>> runserver command (among others?) checks for unapplied migrations 
> >and thus 
> >>> creates the migration table. 
> >>> 
> >>> /Markus 
> >>> 
> >>> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin 
> >wrote: 
>  
>  Hi Ivan, 
>  
>  I'm not sure what you're asking here - are you asking to have a way 
> >to 
>  not have Django create the migrations recording table? I was under 
> >the 
>  impression that it was only created when migrate was run (at least, 
> >that 
>  was my original intention) so if you're managing your own schema 
> >just don't 
>  run migrate. Is there something else that's not working right, or 
> >is that 
>  being made too optimistically? 
>  
>  Andrew 
>  
>  On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel  
> >wrote: 
>  
> > From Andrew: "The only extra thing it would achieve is not having 
> > Django record migrations in the django_migrations table" 
> > 
> > The Django Users thread on how to keep this table from being 
> >created 
> > seemed to result in the 'solution' being either to stay with 1.6 
> >or comment 
> > the relevant lines in the Django code base. Is there really no 
> >other way? 
> > 
> > I love the new migrations facilities in Django 1.7 and was a 
> > contributor to the kickstarter but please keep in mind that many 
> >legacy DB 
> > projects are not avoiding migrations because they want to. IMO 
> >it's usually 
> > because they are forced to for some (usually political) reason 
> >where they 
> > don't have control over the schema. Forcing a perpetually empty 
> > django_migrations table pretty much locks out those users. 
> > 
> > I see that people are worried about encouraging the non-use of 
> > migrations but might I suggest following the Zen of Python and 
> >making 
> > migrations the "one obvious way to do it" and turning them off the 
> >not 
> > obvious way. 
> > 
> > Ivan 
> > 
> > On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin 
> >wrote: 
> >> 
> >> My thoughts in brief on this: 
> >> 
> >>  - Database backends don't support migrations - they support 
> >schema 
> >> alteration via SchemaEditor. This could be used separately from 
> >migrations 
> >> if something wants it, and is meant to be an API on its own, so 
> >the backend 
> >> is not the place to say if you want migrations or not. 
> >> 
> >>  - There is some merit to the ability to turn off migrations on a 
> > 
> >> per-backend basis, via a DATABASES setting, but bear in mind that 
> >routers 
> >> already let you do this (with the allow_migrate method). The only 
> >extra 
> >> thing it would achieve is not having Django record migrations in 
> >the 
> >> django_migrations table, but it also looks like it would be 
> >useful for 
> >> tests if you hadn't written that part yet. 
> >> 
> >>  - I feel like a DB backend should at least implement 
> >SchemaEditor 
> >> even if it returns NotImplementedError for most of the endpoints; 
> >even in 
> >> the weirdest relational system, you can still manage 
> >create/delete model 
> >> without too much difficulty. 
> >> 
> >>  - Bear in mind that the plan is to remove DatabaseCreation 
> >entirely 
> >> in favour of SchemaEditor in a few releases' time (and backends 
> >are more 

Re: Setting database default values in migrations (postgres)

[Marcin Nowak]

Simply do not use Django builtin migrations. Consider using Liquibase 
(maybe with Liquimigrate wrapper for Django) and feel freedom.

BR
Marcin

On Thursday, October 30, 2014 at 4:47:18 PM UTC+1, Peter Coles wrote:
>
> Hey all,
>
> I'm interested in getting database migrations to support setting 
> database-level default values. I've heard talk of this being a hotly 
> contested issue in the past, but I haven't been able to find the actual 
> conversations, so far this 
> 
>  
> is the best thread I've found and I've already asked about it in 
> django-users 
> .
>
> Instead of just asking for this feature, I've gone ahead and created a new 
> db backend that is almost exactly 
> the `django.db.backends.postgresql_psycopg2` module, but with two key code 
> blocks removed (that appear to be the logic to remove default values from 
> the database).
>
> Here's the repo: https://github.com/ringly/django-postgres-dbdefaults
>
> and here it is in pypi: 
> https://pypi.python.org/pypi/django-postgres-dbdefaults/0.0.1
>
> I'd love to hear feedback/thoughts/concerns.
>
> -Peter
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/7601d0bc-bb97-48e6-95fb-a0228a81679c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Sam Baron]

Greetings, I know this is an old thread, but it's an issue I am coming up 
against and hopefully I can restart the conversation.  I do think it's 
important that we use as many native database features as possible for 
application portability, extensibility, and performance.

I have a different solution to the database default problem.  Why not 
handle it like SQLAlchemy?  There are two field properties for default - 
one applied at model instance (current Django default behavior) and one 
sent to the database.  In SQLAlchemy, it's called 'server_default', but for 
Django, I think 'db_default' would be a more appropriate name.  

So for example:
integer_column = models.IntegerField(default=0)
OR
integer_column = models.IntegerField(db_default="0")

And I agree that callables would not be included in 'db_default'.  This new 
property would only be for pushing SQL.  With this solution, I think you 
avoid user errors by keeping the two defaults behavior separate.  Only the 
advanced database folks will end up using it.

I have made the relatively minor code changes on my end.  I am in the 
process and starting a new project and will keep testing it out.  I am 
curious if this would be an acceptable solution.

Thanks,
Sam


On Saturday, November 1, 2014 at 10:17:50 AM UTC-7, Shai Berger wrote:
>
> On Friday 31 October 2014 19:16:15 Jon Dufresne wrote: 
> > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin  > wrote: 
> > > So, bear in mind that you can easily set these defaults yourself in a 
> > > migration with RunSQL if you need them for legacy purposes; that way 
> > > they'll get applied 
> > 
> > Absolutely. I effectively have such a system in place at the moment. 
> > 
> > But, my point is I am also making an effort to match Django's expected 
> > schema while moving away from the legacy schema. I would prefer not to 
> > drift too far from Django's expectations as the goal is move entirely 
> > to Django. This is just one more thing to keep track of and handle 
> > semi-manually. 
> > 
> > All I'm saying is that if the described feature existed, it would 
> > benefit me and others that share my use case. 
>
> So, we should be weighing the support-transition-from-legacy use-case 
> against 
> creating a situation where field defaults get a special treatment if they 
> are 
> primitive enough (callables are out, but I am really not sure about other 
> complex objects -- GIS would probably gain a new dimension of fun if it 
> were 
> to deal  with defaults, even when not callable). 
>
> I think the correct way forward for migrations is to keep as it does today 
> -- 
> requiring users to explicitly ask for db defaults (we could, as I said 
> earlier, give it a nicer API than RunSQL). 
>
> As for "Django's expectations" -- while I don't think we should generate 
> db 
> defaults unless specifically asked to, I don't see where such defaults 
> could 
> get in our way. If you ever run into a situation where Django mishandles 
> some 
> table because it has defaults, that is almost for sure a bug. 
>
> My 2 cents, 
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/e7d99cf6-c6a5-4d32-994c-7dd4e07ad478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Thorsten Sanders]

I like the idea of an survey, but find the release question with only 3 
options quite limited, how about to allow there to put own numbers 
instead of giving fixed answers or at least an other field?


Am 25.04.2015 14:29, schrieb Tim Graham:

Aymeric and I put together a draft:

https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform

All questions are optional so you can just click through it to view 
the questions. We'll probably clear any responses before its finalized 
anyway.


Let us know if you think we should make any additions or changes.

On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote:

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages. One of
the reason I love Django is the fact that it didn't frenetically
add stuff to the framework just because it's cool.
The good thing of python packages is that you can get some data
from pypi (downloads) and github (clones). But we can't do that
with contrib apps unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:

I had an idea to conduct a survey to get a sense of how
developers are using Django. I first had the idea when the
question of maintenance of the Oracle GIS backend came up. We
really have no idea whether or not anyone is actually using
that backend, and it would be helpful to know so we are not
wasting resources on unused features. Also there's the
question of how often to release Django. I think it would be
nice to make that decision based on some data from the community.

Is anyone is interested in coordinating such a survey
(collating questions, preparing the online survey, etc.).

Some question ideas to get started:

Which database backend(s) do you use?
[ ] Checkbox for each one

Which contrib apps do you use?
[ ] Checkbox for each one

How often would you like to see new major version of Django
released?
[ ] List some options, probably between 6 and 9 months.

Describe which version of Django you use (check all the apply):
[ ] I only use long-term support releases.
[ ] I upgrade to the latest stable version as quickly as possible.
[ ] I run off of master.
[ ] I upgrade Django when the version I am using is nearing
the end of its support (or after).
[ ] I don't bother upgrading Django, even if it becomes
unsupported.

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" 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/f14071d1-c570-483a-abd2-833e1b47ab4d%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  (Contributions to Django itself)" 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/553CC38C.6030802%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Wim Feijen]

Hi,

"How often would you like to see new major version of Django released?"
currently lists three options, which are close to one another. I would like 
to have: 12 months, as well as an open option. Is it an idea to add those? 
Detailed release schedules are not necessary, in my opinion.

"I follow Django development through:"
I would like to add "Newsletter" as an option. Lincoln Loop has a really 
nice newsletter I can recommend. 

Best regards,

Wim



On Sunday, 26 April 2015 08:34:15 UTC+2, Shai Berger wrote:
>
> Hi, 
>
> On Saturday 25 April 2015 15:29:30 Tim Graham wrote: 
> > Aymeric and I put together a draft: 
> > 
> > 
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxW 
> > w/viewform 
> > 
> > All questions are optional so you can just click through it to view the 
> > questions. We'll probably clear any responses before its finalized 
> anyway. 
> > 
> > Let us know if you think we should make any additions or changes. 
> > 
>
> This looks great, thanks for putting it together. There are only a few 
> things 
> I'd like to add. 
>
> First of all, a question I find interesting about the general use pattern: 
> "Do 
> you use Django mainly for one big project, or many small ones?" I'm not 
> sure 
> what's the best way to phrase it, but I think it may be important for 
> interpreting other answers (e.g. larger projects will probably tend to 
> move 
> slower w.r.t releases, will tend to use more contrib and 3rd-party apps, 
> etc). 
>
> In "components": Request processing (URLs, middleware, view decorators). 
> Also, while not a "component" per se, Django's documentation is often 
> cited as 
> a valuable resource, and a lot of effort goes into it; I'm not sure adding 
> it 
> as a component adds value, but perhaps we should ask about topic guides 
> vs. 
> reference or something of the sort. 
>  
> In the question about "contrib" apps, should we include the removed apps 
> (comments, markup, formtools, localflavor)? 
>
> In the list of 3rd-party backends: I'm not sure what are the criteria for 
> being in this list; two other 3rd-patyr backends I'm aware of are django- 
> pyodbc-azure (which I've used) and the proprietary mxODBC-django. 
>
> Again, thanks for the initiative, 
>
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/f4a58426-bdf8-47b4-9077-befc243c828b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.