Django 1.2 feature voting

[Jacob Kaplan-Moss-2]

Hey folks --

Like last time 'round, if you'd like to express an opinion about
features for Django 1.2, go and vote:

http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en

I've reorganized the 1.2 feature list
(http://code.djangoproject.com/wiki/Version1.2Features) into a
spreadsheet, and added short codes so we can have a shortcut when we
talk about things. I've put my votes, and comments, into that sheet,
and I'd like to invite you to share yours.

I'd like to ask committers and anyone else to send me their own rankings. The
easiest way is just to copy the spreadsheet and send it to me when you're
done, but if you're anti-google just email me something I can read with codes,
scores, and any notes. I'll add other folks' rankings to the master page as I
get 'em.

Committers: please get me your thoughts ASAP. I'd like to have a draft
feature list for 1.2 out by October 20th.

Please use the standard +1/+0/-0/-1 ranking. In this case the scores
have some additional meaning:

+1 -- "Yes!"
    For "must-have" features.

    A +1 from a committer means that s/he will champion the feature, guide
    the implementor (or implement it personally), review the patch, and commit
    the feature personally.

    A +1 from a non-committer is an offer to personally work on the feature,
    or to help the person working on it by reviewing the patch, testing, etc.

+0 -- "OK"

    For features that are a "good idea".

    A +0 from a committer means that s/he will not stand in the way of the
    feature, but also won't personally invest much effort in it.

-0 -- "Meh"

    For features that don't seem all that hot.

    A -0 from a committer indicates disapproval, but that s/he won't argue
    against the feature if another committer approves it.

-1 -- "No!"
    A strong vote against.

    A -1 from a committer essentially is a veto. No features will be checked
    in with a -1 vote from a committer; only if s/he gets talked up to a -0
    or better will the feature happen.

Using these votes, we'll make lists of "high", "medium", and
"low" priority, and "rejected" features. These lists will be based on the
following criteria, but remember there's a holistic aspect to this process.
We'll use the votes to draft a feature list, but we'll also open up the list
for discussion and make changes accordingly.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joshua Russo-2]

On Tue, Oct 13, 2009 at 12:38 PM, Jacob Kaplan-Moss <jacob@...> wrote:

Hey folks --

Like last time 'round, if you'd like to express an opinion about
features for Django 1.2, go and vote:

http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en

I've reorganized the 1.2 feature list
(http://code.djangoproject.com/wiki/Version1.2Features) into a
spreadsheet, and added short codes so we can have a shortcut when we
talk about things. I've put my votes, and comments, into that sheet,
and I'd like to invite you to share yours.

I'd like to ask committers and anyone else to send me their own rankings. The
easiest way is just to copy the spreadsheet and send it to me when you're
done, but if you're anti-google just email me something I can read with codes,
scores, and any notes. I'll add other folks' rankings to the master page as I
get 'em.

Committers: please get me your thoughts ASAP. I'd like to have a draft
feature list for 1.2 out by October 20th.

Please use the standard +1/+0/-0/-1 ranking. In this case the scores
have some additional meaning:

+1 -- "Yes!"
   For "must-have" features.

   A +1 from a committer means that s/he will champion the feature, guide
   the implementor (or implement it personally), review the patch, and commit
   the feature personally.

   A +1 from a non-committer is an offer to personally work on the feature,
   or to help the person working on it by reviewing the patch, testing, etc.

+0 -- "OK"

   For features that are a "good idea".

   A +0 from a committer means that s/he will not stand in the way of the
   feature, but also won't personally invest much effort in it.

-0 -- "Meh"

   For features that don't seem all that hot.

   A -0 from a committer indicates disapproval, but that s/he won't argue
   against the feature if another committer approves it.

-1 -- "No!"
   A strong vote against.

   A -1 from a committer essentially is a veto. No features will be checked
   in with a -1 vote from a committer; only if s/he gets talked up to a -0
   or better will the feature happen.

Using these votes, we'll make lists of "high", "medium", and
"low" priority, and "rejected" features. These lists will be based on the
following criteria, but remember there's a holistic aspect to this process.
We'll use the votes to draft a feature list, but we'll also open up the list
for discussion and make changes accordingly.

Jacob

What are the prospects for tickets that have patches and docs that are not on this list? Forgive my ignorance. I went back through the Contributing to Django page but I still don't quite understand. 

I have about 6 tickets, some of which would qualify as bug fixes and others as features. Most of them are sitting as unreviewed. Does that mean that mean that they are just not that important for the current cycle or should I have posted them on the wiki? I didn't want to be too overbearing, I am just curious about the process. I understand that there are only so many commiters with only so much bandwidth.

Thanks,

Josh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[buriy]

Hi Jacob,

Could you please add "Add Alex's django-filters
(http://github.com/alex/django-filter) instead of admin filters and
#5833 Custom FilterSpecs proposal" feature idea into your google
spreadsheets doc and vote for it.
I was "late to the party" when you told you're going to vote on
features, so added this option to Version1.2 Features very recently,
and seems it didn't pass into your final list.
If you think it should be "rejected procedurally", like "it was added
too late" or "too inconcrete", please move it there.

For me it's an alternative and better solution of #5833, and since
original idea is under consideration, I believe it is significant
reason to add alternative solution into Version 1.2 Features
consideration list even though it seems it didn't attract much core
devs attention when proposed in django-developers (might be not right
time or not much flaming topic...) and it might seem inconcrete (maybe
it really is). I just feel it's unfair not to look at it while
considering another #5833 solution.
Proposed changeset summary: Admin filtering split into small classes,
separates filtering widgets from current FilterSpecs interface, making
possible to subclass existing filters, ability to add custom filters
(last one is #5833), while not losing any backward compatibility,
exposing new filtering API for both user and admin views as FilterSet
class with the same form-like interface.
Drawbacks: current implementation adds some more complexity to admin filters.

This is some proof-of-concept implementation of admin integration:
http://github.com/gearheart/django-filter/commits/model-admin

Main reason to consider inclusion of the feature is the same as for
#5833: users can't now easily add their own filters into admin
interface.

On Tue, Oct 13, 2009 at 5:38 PM, Jacob Kaplan-Moss <jacob@...> wrote:

>
> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
>
> I've reorganized the 1.2 feature list
> (http://code.djangoproject.com/wiki/Version1.2Features) into a
> spreadsheet, and added short codes so we can have a shortcut when we
> talk about things. I've put my votes, and comments, into that sheet,
> and I'd like to invite you to share yours.
>
> I'd like to ask committers and anyone else to send me their own rankings. The
> easiest way is just to copy the spreadsheet and send it to me when you're
> done, but if you're anti-google just email me something I can read with codes,
> scores, and any notes. I'll add other folks' rankings to the master page as I
> get 'em.
>
> Committers: please get me your thoughts ASAP. I'd like to have a draft
> feature list for 1.2 out by October 20th.
>
> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
> have some additional meaning:
>
> +1 -- "Yes!"
>    For "must-have" features.
>
>    A +1 from a committer means that s/he will champion the feature, guide
>    the implementor (or implement it personally), review the patch, and commit
>    the feature personally.
>
>    A +1 from a non-committer is an offer to personally work on the feature,
>    or to help the person working on it by reviewing the patch, testing, etc.
>
> +0 -- "OK"
>
>    For features that are a "good idea".
>
>    A +0 from a committer means that s/he will not stand in the way of the
>    feature, but also won't personally invest much effort in it.
>
> -0 -- "Meh"
>
>    For features that don't seem all that hot.
>
>    A -0 from a committer indicates disapproval, but that s/he won't argue
>    against the feature if another committer approves it.
>
> -1 -- "No!"
>    A strong vote against.
>
>    A -1 from a committer essentially is a veto. No features will be checked
>    in with a -1 vote from a committer; only if s/he gets talked up to a -0
>    or better will the feature happen.
>
> Using these votes, we'll make lists of "high", "medium", and
> "low" priority, and "rejected" features. These lists will be based on the
> following criteria, but remember there's a holistic aspect to this process.
> We'll use the votes to draft a feature list, but we'll also open up the list
> for discussion and make changes accordingly.
>
> Jacob
>
> >
>

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: buriy@...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[buriy]

Jacob,

yeah, found django-filters mentioned few times at Admin-02 notes.
Ok, nice, idea isn't abandoned.

On Wed, Oct 14, 2009 at 2:38 AM, Yuri Baburov <burchik@...> wrote:

> Hi Jacob,
>
> Could you please add "Add Alex's django-filters
> (http://github.com/alex/django-filter) instead of admin filters and
> #5833 Custom FilterSpecs proposal" feature idea into your google
> spreadsheets doc and vote for it.
> I was "late to the party" when you told you're going to vote on
> features, so added this option to Version1.2 Features very recently,
> and seems it didn't pass into your final list.
> If you think it should be "rejected procedurally", like "it was added
> too late" or "too inconcrete", please move it there.
>
> For me it's an alternative and better solution of #5833, and since
> original idea is under consideration, I believe it is significant
> reason to add alternative solution into Version 1.2 Features
> consideration list even though it seems it didn't attract much core
> devs attention when proposed in django-developers (might be not right
> time or not much flaming topic...) and it might seem inconcrete (maybe
> it really is). I just feel it's unfair not to look at it while
> considering another #5833 solution.
> Proposed changeset summary: Admin filtering split into small classes,
> separates filtering widgets from current FilterSpecs interface, making
> possible to subclass existing filters, ability to add custom filters
> (last one is #5833), while not losing any backward compatibility,
> exposing new filtering API for both user and admin views as FilterSet
> class with the same form-like interface.
> Drawbacks: current implementation adds some more complexity to admin filters.
>
> This is some proof-of-concept implementation of admin integration:
> http://github.com/gearheart/django-filter/commits/model-admin
>
> Main reason to consider inclusion of the feature is the same as for
> #5833: users can't now easily add their own filters into admin
> interface.
>
> On Tue, Oct 13, 2009 at 5:38 PM, Jacob Kaplan-Moss <jacob@...> wrote:
>>
>> Hey folks --
>>
>> Like last time 'round, if you'd like to express an opinion about
>> features for Django 1.2, go and vote:
>>
>> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
>>
>> I've reorganized the 1.2 feature list
>> (http://code.djangoproject.com/wiki/Version1.2Features) into a
>> spreadsheet, and added short codes so we can have a shortcut when we
>> talk about things. I've put my votes, and comments, into that sheet,
>> and I'd like to invite you to share yours.
>>
>> I'd like to ask committers and anyone else to send me their own rankings. The
>> easiest way is just to copy the spreadsheet and send it to me when you're
>> done, but if you're anti-google just email me something I can read with codes,
>> scores, and any notes. I'll add other folks' rankings to the master page as I
>> get 'em.
>>
>> Committers: please get me your thoughts ASAP. I'd like to have a draft
>> feature list for 1.2 out by October 20th.
>>
>> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
>> have some additional meaning:
>>
>> +1 -- "Yes!"
>>    For "must-have" features.
>>
>>    A +1 from a committer means that s/he will champion the feature, guide
>>    the implementor (or implement it personally), review the patch, and commit
>>    the feature personally.
>>
>>    A +1 from a non-committer is an offer to personally work on the feature,
>>    or to help the person working on it by reviewing the patch, testing, etc.
>>
>> +0 -- "OK"
>>
>>    For features that are a "good idea".
>>
>>    A +0 from a committer means that s/he will not stand in the way of the
>>    feature, but also won't personally invest much effort in it.
>>
>> -0 -- "Meh"
>>
>>    For features that don't seem all that hot.
>>
>>    A -0 from a committer indicates disapproval, but that s/he won't argue
>>    against the feature if another committer approves it.
>>
>> -1 -- "No!"
>>    A strong vote against.
>>
>>    A -1 from a committer essentially is a veto. No features will be checked
>>    in with a -1 vote from a committer; only if s/he gets talked up to a -0
>>    or better will the feature happen.
>>
>> Using these votes, we'll make lists of "high", "medium", and
>> "low" priority, and "rejected" features. These lists will be based on the
>> following criteria, but remember there's a holistic aspect to this process.
>> We'll use the votes to draft a feature list, but we'll also open up the list
>> for discussion and make changes accordingly.
>>
>> Jacob
>>
>> >>
>>
>
>
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: buriy@...
>

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: buriy@...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Timboy]

http://spreadsheets.google.com/ccc?key=txJx3_oLeRwrk8SwnoWc88w

Column X

On Oct 13, 6:38 am, Jacob Kaplan-Moss <ja...@...> wrote:

> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpN...
>
> I've reorganized the 1.2 feature list
> (http://code.djangoproject.com/wiki/Version1.2Features) into a
> spreadsheet, and added short codes so we can have a shortcut when we
> talk about things. I've put my votes, and comments, into that sheet,
> and I'd like to invite you to share yours.
>
> I'd like to ask committers and anyone else to send me their own rankings. The
> easiest way is just to copy the spreadsheet and send it to me when you're
> done, but if you're anti-google just email me something I can read with codes,
> scores, and any notes. I'll add other folks' rankings to the master page as I
> get 'em.
>
> Committers: please get me your thoughts ASAP. I'd like to have a draft
> feature list for 1.2 out by October 20th.
>
> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
> have some additional meaning:
>
> +1 -- "Yes!"
>     For "must-have" features.
>
>     A +1 from a committer means that s/he will champion the feature, guide
>     the implementor (or implement it personally), review the patch, and commit
>     the feature personally.
>
>     A +1 from a non-committer is an offer to personally work on the feature,
>     or to help the person working on it by reviewing the patch, testing, etc.
>
> +0 -- "OK"
>
>     For features that are a "good idea".
>
>     A +0 from a committer means that s/he will not stand in the way of the
>     feature, but also won't personally invest much effort in it.
>
> -0 -- "Meh"
>
>     For features that don't seem all that hot.
>
>     A -0 from a committer indicates disapproval, but that s/he won't argue
>     against the feature if another committer approves it.
>
> -1 -- "No!"
>     A strong vote against.
>
>     A -1 from a committer essentially is a veto. No features will be checked
>     in with a -1 vote from a committer; only if s/he gets talked up to a -0
>     or better will the feature happen.
>
> Using these votes, we'll make lists of "high", "medium", and
> "low" priority, and "rejected" features. These lists will be based on the
> following criteria, but remember there's a holistic aspect to this process.
> We'll use the votes to draft a feature list, but we'll also open up the list
> for discussion and make changes accordingly.
>
> Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Tue, Oct 13, 2009 at 8:38 AM, Jacob Kaplan-Moss <jacob@...> wrote:
...
>    A +1 from a non-committer is an offer to personally work on the feature,
>    or to help the person working on it by reviewing the patch, testing, etc.

Holy smokes, there are gonna be some busy people.  :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Phillip Temple-2]

Two apps I would like to see in contrib are:
mptt - this has been stable for a long time, integrates well into
django, and is now a dependency for a few apps out there
django-registration - rewritten to have pluggable work flow, this is a
fundamental feature of so many web sites

Phillip.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

On Thu, Oct 22, 2009 at 10:27 AM, Phillip Temple
<phillipinfrance@...> wrote:
> django-registration - rewritten to have pluggable work flow, this is a
> fundamental feature of so many web sites

I'm -1 on adding django-registration to contrib.


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Thu, Oct 22, 2009 at 2:30 PM, James Bennett <ubernostrum@...> wrote:
>
> On Thu, Oct 22, 2009 at 10:27 AM, Phillip Temple
> <phillipinfrance@...> wrote:
>> django-registration - rewritten to have pluggable work flow, this is a
>> fundamental feature of so many web sites
>
> I'm -1 on adding django-registration to contrib.

Agreed.  The "pluggable work flow" that is Django itself works quite
well for me.

--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Thu, Oct 22, 2009 at 11:27 PM, Phillip Temple
<phillipinfrance@...> wrote:
>
> Two apps I would like to see in contrib are:
> mptt - this has been stable for a long time, integrates well into
> django, and is now a dependency for a few apps out there
> django-registration - rewritten to have pluggable work flow, this is a
> fundamental feature of so many web sites

I'm -1 on adding django-registration to contrib. The Django core gains
nothing from this being in trunk.

I'm -0 on mptt. Adding support for tree-based structures in Django is
an interesting proposition, but I'm not convinced that mptt is the
single right solution. I can think of several others tree solutions
off the top of my head. We need to have a public discussion about
whether this is something we need to add to core, and if so, which
approach we will adopt.

However, you should note that your email was a response to a call for
_votes_, not a call for proposals - if you want to advocate for the
inclusion of mptt in trunk, you will need to wait until the proposal
window for v1.3, which will open when v1.2 is finalized.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[rjc-2]

The only reason I will migrate to 1.2 is if you include schema
migration. It is that important for us (we have a lot of production
code out). Anyway, why did we pick south instead of django-evolution ?
I'm +1 (+1 +1) for any db schema migration.

I'm +1 for admin ui branch integration. Django stands out because of
its admin ui, this improves-it :)

I'm +0 for custom filterspecs and debug toolbar.

Best regards,
Rui

On Oct 22, 11:45 pm, Russell Keith-Magee <freakboy3...@...>
wrote:

> On Thu, Oct 22, 2009 at 11:27 PM, Phillip Temple
>
> <phillipinfra...@...> wrote:
>
> > Two apps I would like to see in contrib are:
> > mptt - this has been stable for a long time, integrates well into
> > django, and is now a dependency for a few apps out there
> > django-registration - rewritten to have pluggable work flow, this is a
> > fundamental feature of so many web sites
>
> I'm -1 on adding django-registration to contrib. The Django core gains
> nothing from this being in trunk.
>
> I'm -0 on mptt. Adding support for tree-based structures in Django is
> an interesting proposition, but I'm not convinced that mptt is the
> single right solution. I can think of several others tree solutions
> off the top of my head. We need to have a public discussion about
> whether this is something we need to add to core, and if so, which
> approach we will adopt.
>
> However, you should note that your email was a response to a call for
> _votes_, not a call for proposals - if you want to advocate for the
> inclusion of mptt in trunk, you will need to wait until the proposal
> window for v1.3, which will open when v1.2 is finalized.
>
> Yours,
> Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[trbs]

Sorry about the late reply.

Hope this is still useful, I've attached a ods and csv versions to this
mail.

I might just be a humble user (of django), maintainer of
django-extensions and submitted just a few patches for django itself but
hopefully the input is useful somehow :)

Might have been overly positive on the sheet, because there many good
features in there :) And if possible (specially time wise) I would love
to help with the +1 onces.

Thanks for everything,
Regards,
Bas (trbs)


On Tue, 2009-10-13 at 08:38 -0500, Jacob Kaplan-Moss wrote:

> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
>
> I've reorganized the 1.2 feature list
> (http://code.djangoproject.com/wiki/Version1.2Features) into a
> spreadsheet, and added short codes so we can have a shortcut when we
> talk about things. I've put my votes, and comments, into that sheet,
> and I'd like to invite you to share yours.
>
> I'd like to ask committers and anyone else to send me their own rankings. The
> easiest way is just to copy the spreadsheet and send it to me when you're
> done, but if you're anti-google just email me something I can read with codes,
> scores, and any notes. I'll add other folks' rankings to the master page as I
> get 'em.
>
> Committers: please get me your thoughts ASAP. I'd like to have a draft
> feature list for 1.2 out by October 20th.
>
> Please use the standard +1/+0/-0/-1 ranking. In this case the scores
> have some additional meaning:
>
> +1 -- "Yes!"
>     For "must-have" features.
>
>     A +1 from a committer means that s/he will champion the feature, guide
>     the implementor (or implement it personally), review the patch, and commit
>     the feature personally.
>
>     A +1 from a non-committer is an offer to personally work on the feature,
>     or to help the person working on it by reviewing the patch, testing, etc.
>
> +0 -- "OK"
>
>     For features that are a "good idea".
>
>     A +0 from a committer means that s/he will not stand in the way of the
>     feature, but also won't personally invest much effort in it.
>
> -0 -- "Meh"
>
>     For features that don't seem all that hot.
>
>     A -0 from a committer indicates disapproval, but that s/he won't argue
>     against the feature if another committer approves it.
>
> -1 -- "No!"
>     A strong vote against.
>
>     A -1 from a committer essentially is a veto. No features will be checked
>     in with a -1 vote from a committer; only if s/he gets talked up to a -0
>     or better will the feature happen.
>
> Using these votes, we'll make lists of "high", "medium", and
> "low" priority, and "rejected" features. These lists will be based on the
> following criteria, but remember there's a holistic aspect to this process.
> We'll use the votes to draft a feature list, but we'll also open up the list
> for discussion and make changes accordingly.
>
> Jacob
>
>

--~--~---------~--~----~------------~-------~--~----~

You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

---

"Code","Short description","Vote","Notes"
"Admin-01","#494 Option for classes on admin inlines",,
"Admin-02","#5833 Custom FilterSpecs",,
"Admin-03","#10871 Support for input arguments on admin actions.","+0",
"Contrib-01","Add South (http://south.aeracode.org/) to contrib","-0",
"Contrib-02","#4604 Message Passing For Anonymous Users (See also: SessionMessages)","+0",
"Contrib-03","#11698 Add Django Debug Toolbar to contrib","+1",
"Contrib-04","#11982 Integrate Reversion as a django contrib app","+0","With important note that is must support changing models. If it is serialized and breaks completely when changing of extending the model, then I'm -1 "
"Contrib-05","Syndication feed views: http://github.com/bfirsh/syndication-view/",,
"Contrib-06","#3011 Allow for extendable auth_user module","+1",
"Contrib-07","#9200 Session-based FormWizard","+1",
"Contrib-08","#11010 Support row-level permissions by updating the User-Object and Authbackends","+1",
"Contrib-09","#2507, #11526 LDAP authentication backend","+0",
"Contrib-10","#11625 Add admin actions to the CommentsAdmin",,
"Contrib-11","#3569 Implement Atom Publishing Protocol","+0",
"Core-01","Improved/reworked CsrfProtection (see #9977, #10816)","+0",
"Core-02","Add support for Signing and Signed Cookies","+0",
"Core-04","Add IBM DB2 django adapter django.db.backends",,"Would want to vote +0 on this, but should refrain from voting before everything is +0 :)"
"Core-05","Integrate the Python standard library logging module with Django","+0",
"Email-01","#10355 Add support for pluggable email backends.","+0",
"Forms-01","#342 Read-only form fields","+0",
"Forms-02","#3512 Add ""required"" & ""error"" CSS classes to form rows in as_* methods","+0",
"Forms-03","#6630 Fieldsets for newforms","+0",
"GSoC-1","Merge admin-ui branch","+0",
"GSoC-2","Merge http-wsgi-improvements branch","+0",
"GSoC-3","Merge i18n-improvements branch","+0",
"GSoC-4","Merge model-validation branch","+0",
"GSoC-5","Merge multidb branch","+0",
"GSoC-6","Merge test-improvements branch",,
"ORM-01","Support for non-relational databases (AppEngine, #10192) &c","-0",
"ORM-02","#17 Identity mapping in the ORM",,
"ORM-03","#373 Multi-part primary keys",,
"ORM-04","#399 Support 8-byte integer DB-fields (bigint)","+1",
"ORM-06","#1480, #2626 Store datetime values as UTC",,
"ORM-07","#2443 Implement DurationFields","+0",
"ORM-08","#6148 Add support for database schemas",,
"ORM-09","#7539 Add ON DELETE and ON UPDATE support","+0",
"ORM-10","#11402 exists() method on QuerySets",,
"ORM-11","#11156 Remove unnecessary savepoints with Oracle",,
"ORM-12","#11863 Model.objects.raw(SQL)","+0",
"ORM-13","Search support in the ORM: http://github.com/bfirsh/django/tree/search",,
"Serialization-01","Support using lookup dictionaries as foreign keys in serializers (#7052)",,
"Templates-01","Add {% doctype %} and {% field %} template tags from http://github.com/simonw/django-html/","+0",
"Templates-02","Smarter {% if %} tag from http://www.djangosnippets.org/snippets/1350/","+0",
"Templates-03","Easier conditional template tags (http://www.djangosnippets.org/snippets/1538/)","+0",
"Templates-04","#3349, #6587 Better template tag loading","+0",
"Templates-05","#6262 Support caching compiled templates","+0",
"Templates-06","#6378 Capture arbitrary output as a template variable (or add a capture ttag)",,
"Templates-07","#7806 django.template refactoring",,"Leave this to people more knowledgeable about django.template :)"
"URLs-01","Replace get_absolute_url() (see ReplacingGetAbsoluteUrl)","-0",
"URLs-02","#8896 Support for subdomains in the url patterns","+1",
"Views-01","#6735 Class-based generic views","+0",

---

[James Bennett]

On Fri, Oct 23, 2009 at 5:12 AM, rjc <coelho.rui@...> wrote:
> The only reason I will migrate to 1.2 is if you include schema
> migration. It is that important for us (we have a lot of production
> code out). Anyway, why did we pick south instead of django-evolution ?
> I'm +1 (+1 +1) for any db schema migration.

Guess you're gonna stay with 1.1 for a while.

Seriously, why is it so difficult to use a solution you already have?


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[rjc-2]

Schema migration is not an option, it is required for any production
code (we ship
a lot of code to out customer's site and regularly publish patches
that include schema
changes). You cannot make a site without ORM or schema migration, I
see both at the
same level.

BTW, we use django evolution since south doesn't support python 2.3
(again a lot of
enterprise code is stuck at RHEL4 which is py2.3)

Rui

On Oct 23, 8:35 pm, James Bennett <ubernost...@...> wrote:

> On Fri, Oct 23, 2009 at 5:12 AM, rjc <coelho....@...> wrote:
> > The only reason I will migrate to 1.2 is if you include schema
> > migration. It is that important for us (we have a lot of production
> > code out). Anyway, why did we pick south instead of django-evolution ?
> > I'm +1 (+1 +1) for any db schema migration.
>
> Guess you're gonna stay with 1.1 for a while.
>
> Seriously, why is it so difficult to use a solution you already have?
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

On Saturday 24 October 2009 14:32:58 rjc wrote:
> Schema migration is not an option, it is required for any
>  production code (we ship
> a lot of code to out customer's site and regularly publish patches
> that include schema
> changes). You cannot make a site without ORM or schema migration, I
> see both at the
> same level.

You mean that *you* cannot make a site without schema migration :-)
Other people may get on just fine without it, or have strategies other
than a Python based solution for dealing with it. And as other people
have mentioned, there is nothing stopping you from having schema
migration.

> BTW, we use django evolution since south doesn't support python 2.3
> (again a lot of
> enterprise code is stuck at RHEL4 which is py2.3)

Python 2.3 support will be dropped for Django 1.2, so it sounds like
you will be stuck with Django 1.1.X for other reasons.

I was going to add that this was documented somewhere, but I can't
find it anywhere.  I think we did agree that it would be in the 1.1
release notes:

http://groups.google.com/group/django-developers/msg/0888b1c8f2518059

But it's not there, which is an unfortunate oversight.

Nonetheless, I don't think that oversight will change the plan.  
Python 2.4 was released nearly 5 years ago, so it's hardly
unreasonable for us to drop support for 2.3.

Luke

--
Noise proves nothing.  Often a hen who has merely laid an egg
cackles as if she laid an asteroid.
        -- Mark Twain

Luke Plant || http://lukeplant.me.uk/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Sat, Oct 24, 2009 at 9:32 AM, rjc <coelho.rui@...> wrote:
> BTW, we use django evolution since south doesn't support python 2.3
> (again a lot of
> enterprise code is stuck at RHEL4 which is py2.3)

It sounds to me like you already have a solution and some special
needs that make the current choice you have in schema evolution tools
a Good Thing.  Integrating something into the core may tie to you to a
specific implementation that doesn't really suite your needs.  So
what's the big rush?

Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Kugutsumen]

Support for non-relational databases (AppEngine, #10192)  +1

See http://groups.google.com/group/django-developers/browse_thread/thread/fcf501d073ae33f
for reference.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

On Mon, Oct 26, 2009 at 6:53 AM, kugutsumen <kugutsumen@...> wrote:
> Support for non-relational databases (AppEngine, #10192)  +1

Repeating once again: the voting's over and done with. The proposals
have been assigned their priorities. Time to move on.


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Mon, Oct 26, 2009 at 7:42 AM, James Bennett <ubernostrum@...> wrote:
> On Mon, Oct 26, 2009 at 6:53 AM, kugutsumen <kugutsumen@...> wrote:
>> Support for non-relational databases (AppEngine, #10192)  +1
>
> Repeating once again: the voting's over and done with. The proposals
> have been assigned their priorities. Time to move on.

... to doing work. If you're serious about seeing a feature in 1.2,
then the best way to get it done is to step up and help out.

Waldemar Kornewald seems to be doing a great job coordinating work
around non-relational backends, so I'd suggest reading through the
thread he started last week and figuring out how you can pitch in and
help out.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---