Django 1.2 feature voting
Jacob Kaplan-Moss
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
Joshua Russo
Yuri Baburov
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.
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Yuri Baburov
yeah, found django-filters mentioned few times at Admin-02 notes.
Ok, nice, idea isn't abandoned.
Cornbread
Column X
On Oct 13, 6:38 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
Jeremy Dunck
...
> 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. :)
Phillip Temple
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.
James Bennett
<phillip...@gmail.com> 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."
Tobias McNulty
>
> On Thu, Oct 22, 2009 at 10:27 AM, Phillip Temple
> <phillip...@gmail.com> 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
(919) 951-0052
http://www.caktusgroup.com
Russell Keith-Magee
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 %-)
Bas van Oostveen
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)
rjc
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...@gmail.com>
wrote:
>
James Bennett
> 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?
rjc
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...@gmail.com> wrote:
Luke Plant
> 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/
Tobias McNulty
> 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
kugutsumen
See http://groups.google.com/group/django-developers/browse_thread/thread/fcf501d073ae33f
for reference.
James Bennett
> 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.
Jacob Kaplan-Moss
> On Mon, Oct 26, 2009 at 6:53 AM, kugutsumen <kugut...@gmail.com> 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