RFC: Django 1.0 roadmap and timeline
Jacob Kaplan-Moss
Note that though this is worded in the future perfect tense, it is only a draft;
I'm looking for feedback and comments from the community before the core
developers and I post a the final version of this document (which I will do
over the weekend).
What's will be in 1.0?
======================
The primary reason we've not yet released 1.0 is the long feature
wish-list. We need to balance this list of features against the need
for a timly release and speedy process. To that end, we'll categorize
all the features of 1.0 thusly:
* Must-haves: features that, if not completed, are worth delaying the
release. That is, if the work on this list is not completed by a
release date, we'll push the date.
This of course means that these features are the "A" features, and we'll
ask anyone who can help to focus on these features *first*.
* "Maybe" features: things that *should* be in 1.0 and should be worked on
in the run up to the release. If, however, features on this list aren't
completed, they will be dropped.
* "No" features: things that specifically will *not* be in 1.0, and which
we'll ask developers not to focus on. We need to trim down to hit dates,
after all.
Must-have features
------------------
1. ``newforms-admin``.
It's clear from discussion on this list that most consider a release without
``newforms-admin`` to be a bad idea. Further, ``newforms-admin`` is nearly
done; we've already started talking about merging it to trunk.
2. Replacement of ``oldforms`` throughout Django.
Nothing in Django 1.0 should rely on the deprecated ``oldforms`` package.
We'll need to replace ``oldforms`` usage in generic views, and in
``django.contrib.auth``
``django.contrib.comments`` still uses ``oldforms`` as well, but there's
special situation here; see below.
3. Making Django 100% WSGI compliant.
This simply involves fixing ticket #285. We've delayed doing this to avoid
the backwards-incompatible change, but we must make this change before 1.0.
"Maybe" features
----------------
Again, these are features that *should* be in 1.0. In most cases, they're
actively being worked on by members of the development community and simply need
focus by committers (more about how that process will work below).
These features are arranged in *rough* order of importance.
1. Signal performance improvements (#6814).
2. Large file uploads (#2070).
3. ``INSTALLED_APPS`` refactoring (i.e. ``app()`` objects) (#3591).
4. File storage refactoring (#5361).
5. Model-level validation (#6845).
6. Full ``GenericForeignKey`` support in newforms-admin (#4667).
7. Land GeoDjango as ``django.contrib.gis``.
8. Many-to-many intermediates (#6905).
9. Fix all known bugs preventing Django from running on alternate Python
implementations. In practice this means fixing any bugs filed before 1.0 beta
from people working on running Django on an alternate VM.
10. De-cruftify custom template tag loading (including removing custom template
tag ``__path__`` hacking) (#6587, etc.).
11. Better support for controlling middleware ordering (#3591).
12. Syntax for self-referencing fields in queries (#7210).
13. Finish documentation refactoring.
Features not in 1.0
-------------------
Unfortunately, the only way to get this done is to say no a lot. Let's start
now:
1. Aggregation support. Although this is a Summer of Code project that's looking
*very* promising, the timeline for SoC won't fit with the aggressive schedule
we're setting for 1.0. Further, it's a "dangerous" change in that it modifies
parts of Django's query engine, and that needs to be rock-solid for a 1.0
release.
The good news is that it'll make a kick-ass 1.1 feature!
2. Any other additions to ``django.contrib``. Though there are many nice
candidates out there, we simply don't have time to roll them into Django
in time for a release. We'll come up with a "contrib process" post-1.0
and start looking at this then.
3. Any additional database backends. Again, the overhead in integrating a new
database backend is too much. These will need to remain external backends
until after 1.0.
4. Any features not on this list.
We want to ship bug-free, so we'll dedicate as much of our time to bug
stomping as possible. This means that feature requests will need to be
deferred.
Schedule
========
Django 1.0 will be released in early September.
The general release process will be:
* An alpha release containing all must-have features, but likely not
bug-free. We'll push hard to have all the must-haves done in time
for ample testing.
The alpha release will also promote any "pending deprecation" warnings to
full-blown deprecation warnings.
* Two beta releases.
All "maybe" features must be completed by the first beta; after that,
Django will enter feature freeze for about a month while we kill bugs.
* At least one -- and hopefully only one --release candidate. The candidate
release will mark a total freeze (as well as a string freeze for
translators); only outright bug fixes will be accepted past this point.
* A final release.
* A big fucking party.
We will hold development sprints in between each release to focus on the next
release.
Dates
-----
July 10-12 ``newforms-admin`` sprint in person at EuroPython and around
the world in IRC.
July 18 or 19 Push to 1.0 alpha sprint in the San Francisco area, and in IRC.
July 20 **1.0 alpha.**
August 1 or 2 Push to beta sprint in Lawrence, and etc.
August 5 **1.0 beta 1.**
August 8/9 Push to beta 2 sprint, location TBA.
August 12 **1.0 beta 2.**
August 15/16 Release candidate sprint, location TBA.
August 19 **1.0 rc 1.**
August 22/23 Final release sprint, location TBA.
August 26 Earliest possible 1.0 release date, or perhaps rc2.
September 2 **1.0**
All the releases until 1.0 will be "snapshot" releases: we won't be backporting
fixes -- even security fixes -- but will just be fixing bugs in the next
release.
Process
=======
Each feature on the list (both "must-have" and "maybe") gets a "lieutenant" (to
steal of term from the Linux community) and a committer assigned. It's OK if
this is the same person, but the idea is that one committer can keep an eye and
commit from patches from a number of trusted lieutenants. In most cases, the
features on the todo list have obvious lieutenants; we'll need to assign missing
ones and also committers. I'll start putting together this list tonight; right
now it's mostly in my head.
James, as the release manager, will be in charge of keeping the schedule. He'll
keep track of who's working on what issues so that bug reports can be
efficiently routed; he'll also nag, cajole and (if necessary) berate developers
who are in danger of missing deadlines.
Once 1.0 is out we'll appoint a "version manager" (thanks for the idea, Rob).
This person will be responsible for maintaining the 1.0 release series, which
means backporting security fixes and "important" bugs and releasing 1.0.1, etc.
Similarly, as soon as we have a volunteer we'll appoint a 0.96 version manger
who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.
With the 1.0 release, however, we will stop support 0.95 and earlier. This is
somewhat flexible; if someone has a stake in one of those older versions we'll
happily let them continue to maintain those releases, but if nobody steps up the
core team won't be able to do it.
--------------------------------------------
Comments are, of course, highly welcome. Fire away.
Jacob
Russell Keith-Magee
<jacob.ka...@gmail.com> wrote:
>
> ``django.contrib.comments`` still uses ``oldforms`` as well, but there's
> special situation here; see below.
Jacob - unless I'm going blind, you've missed out the 'below' section
that this refers to.
Russ %-)
Jacob Kaplan-Moss
You are not blind; I, however, have mad wicked copy-paste skillz. Ahem.
On comments
-----------
``django.contrib.comments`` is a bit of special case here: ideally, Django 1.0
will ship with *no* core use of oldforms. However, refactoring the comment
system -- not just replacing forms -- is overdue, and is the subject of a Summer
of Code project.
So we'd like to deal with that situation a bit specially. I've unfortunately not
had a chance to ask Thejaswi (the student working on comments) or Jannis (his
mentor) about this, so obviously they'll need to be OK with the idea. But,
assuming this works, I'd like to do the following:
August 11 is the suggested pencils down date for GSOC. This means that if
Thejaswi is on track, he will be completed around the time of the beta 2 freeze
date. July 14 is the midterm evaluation date for Summer of Code; we should be
able to get a good idea then whether completion on schedule is likely.
If the midterm evaluation says that the project is going badly, we abandon ship
and paper over the problem by simply replacing the form components with
newforms.
If the midterm evaluation is positive -- which I expect it to be -- we work on
the assumption that it will be merged around beta 2 (or earlier, if Thejaswi has
something ready). We encourage people to push newforms-comments pretty hard,
especially during sprints.
If we get to August 11 and we don't have a newforms-comments release candidate,
we can simply release with oldforms comments: it'll be annoying but not a
deal-breaker.
This does mean newforms-comments will be a late feature to the trunk (although
only 3 weeks after the feature cutoff for other features), but if we encourage
testing in its own branch, we should be able to mitigate the risk. I would also
hope that the last 3 weeks of GSOC development would be mostly bugfixing anyway,
rather than substantial changes.
[With thanks to Russ -- the idea's originally his, and most of the
above is coppied out of something he wrote yesterday.]
Jacob
Marty Alchin
sure I can get it done in time. I do have one suggestion, though.
On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss
<jacob.ka...@gmail.com> wrote:
> * "Maybe" features: things that *should* be in 1.0 and should be worked on
> in the run up to the release. If, however, features on this list aren't
> completed, they will be dropped.
I think I know what you mean here, but "dropped" sounds an awful lot
like an all or nothing deal: either it makes it into 1.0 or it never
makes it at all. It's probably best to clarify that "dropped" just
means "dropped from 1.0, to be added in the next release after it's
completed." Yeah, it might be obvious to some of us, but a lot of
people could read it the wrong way.
-Gul
Jeff Anderson
> This is a call for comments on the proposed Django 1.0 roadmap and schedule.
>
> Note that though this is worded in the future perfect tense, it is only a draft;
> I'm looking for feedback and comments from the community before the core
> developers and I post a the final version of this document (which I will do
> over the weekend).
>
on the trac page?
Would it be good/beneficial to put these "must-haves" in a 1.0
milestone, and (some of) the "No" features in a 1.1 milestone?
One of the first things I looked for when I got interested in Django 1.0
was look for the milestone page in trac. I know that there are similar
things in the wiki page, but the status on several of the tickets listed
seem to be stale.
Hopefully my curiosity represents curiosity of others, and I am doing
what I can to push along 1.0, although I'm still getting up to speed on
the development process. :)
Cheers!
Jeff Anderson
Jacob Kaplan-Moss
> I think I know what you mean here, but "dropped" sounds an awful lot
> like an all or nothing deal: either it makes it into 1.0 or it never
> makes it at all. It's probably best to clarify that "dropped" just
> means "dropped from 1.0, to be added in the next release after it's
> completed."
Indeed. I expect that anything on that list that doesn't make it into
1.0 will be in 1.1.
Jacob
James Bennett
<jacob.ka...@gmail.com> wrote:
> This does mean newforms-comments will be a late feature to the trunk (although
> only 3 weeks after the feature cutoff for other features), but if we encourage
> testing in its own branch, we should be able to mitigate the risk. I would also
> hope that the last 3 weeks of GSOC development would be mostly bugfixing anyway,
> rather than substantial changes.
Also, it's worth noting that because contrib.comments is an
application rather than a core part of Django, it will be easy to keep
it available for those who want to stick to it, and if someone in the
community wants to offer continuing support for it I wouldn't be
averse to letting them do so (though of course django.oldforms will
eventually disappear, at which point any third-party maintenance
effort will probably need to do some porting).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Brian Rosner
On Jun 11, 2008, at 8:03 PM, Jacob Kaplan-Moss wrote:
> 2. Replacement of ``oldforms`` throughout Django.
>
> Nothing in Django 1.0 should rely on the deprecated ``oldforms``
> package.
> We'll need to replace ``oldforms`` usage in generic views, and in
> ``django.contrib.auth``
Just wanted to point out that the newforms-admin branch has already
ported django.contrib.auth to newforms.
> * A big fucking party.
A *really* big fucking party ;)
Brian Rosner
http://oebfare.com
Eugene Lazutkin
matches my expectations. +1.
Thanks,
Eugene
Karen Tracey
This is a call for comments on the proposed Django 1.0 roadmap and schedule.
......
Must-have features
------------------
2. Replacement of ``oldforms`` throughout Django.
Nothing in Django 1.0 should rely on the deprecated ``oldforms`` package.
We'll need to replace ``oldforms`` usage in generic views, and in
``django.contrib.auth``
The django.contrib.auth case has already been done in the newforms-admin branch, so don't anybody run out and starting working on it for trunk.
One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance doesn't work in the admin" (whereas GenericForeignKey admin support is specifically called out). I don't know if #6755 is classified as must have for newforms-admin to land (it's not even specifying newforms-admin as the release anymore), or in the "maybe" category? It's gotten a fair amount of interest from people who have started using inheritance so it would be nice to have its status be specified.
Karen
Jacob Kaplan-Moss
> One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance
> doesn't work in the admin" (whereas GenericForeignKey admin support is
> specifically called out). I don't know if #6755 is classified as must have
> for newforms-admin to land (it's not even specifying newforms-admin as the
> release anymore), or in the "maybe" category? It's gotten a fair amount of
> interest from people who have started using inheritance so it would be nice
> to have its status be specified.
I'd say it's pretty important and should be considered part of the
todo list for newforms-admin. However, since MI doesn't work in the
old admin, either, there's no reason that it particularly has to be
done before or after landing NFA on trunk.
Jacob
Jacob Kaplan-Moss
> I'm curious: is there a reason that the milestone feature was disabled on
> the trac page?
> Would it be good/beneficial to put these "must-haves" in a 1.0 milestone,
> and (some of) the "No" features in a 1.1 milestone?
Probably because we haven't really needed the feature until now :)
I'll make some milestones; we can add tickets to them as we go.
Jacob
Julien
uncertainty some people may have.
In the must-have features, or at least in the maybes, I'd put the bugs
introduced by, or not properly fixed by, the merge of the queryset-
refactor branch. A list of related open tickets has been given in [1].
Thanks again for clarifying the roadmap to 1.0.
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/43e025656481cfe6/a8c0feaf7f76cddd?lnk=gst&q=queryset+django+releases#a8c0feaf7f76cddd
On Jun 12, 12:46 pm, "Karen Tracey" <kmtra...@gmail.com> wrote:
> On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss <
>
George Vilches
On Jun 11, 2008, at 10:03 PM, Jacob Kaplan-Moss wrote:
> 8. Many-to-many intermediates (#6905).
>
Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095
George
Jacob Kaplan-Moss
> In the must-have features, or at least in the maybes, I'd put the bugs
> introduced by, or not properly fixed by, the merge of the queryset-
> refactor branch. A list of related open tickets has been given in [1].
A better list is at
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=%7Eqsrf-cleanup&order=priority.
This falls under "fix outstanding bugs"; if at all possible we should
ship 1.0 with zarro known boogs.
Jacob
Jacob Kaplan-Moss
>> 8. Many-to-many intermediates (#6905).
>>
> Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095
Yup; thanks.
Jacob
flo...@gmail.com
help on the sprint, so if #6095 isn't merged by then I can focus on
whatever needs to be done to get it to where it needs to be.
-Eric Florenzano
Russell Keith-Magee
I've just updated the ticket to reflect this.
Russ %-)
Karen Tracey
You marked it nfa-blocker, which doesn't match my understanding of the meaning of that tag and what Jacob said. nfa-blocker I thought meant something that has to be fixed before a merge to trunk, but this is not in that class.
With the focus on 1.0 now, the two (main) tags that have been in use on newforms-admin are missing a category, perhaps. There's nfa-blocker for stuff that has to be done before merge to trunk and nfa-someday for everything else. That doesn't given any way to specify the middle ground of after trunk merge but before 1.0. Actually there's nothing newforms-admin specific about this problem, people will be wanting to know what tickets are considered essential for 1.0 and I don't know what mechanism will be used to track that in general?
If the meaning of nfa-blocker is now going to be broader than "essential for merge to trunk" than that should be spelled out, and existing defects perhaps reclassified...there may be some in nfa-someday that really should be nfa-blocker if that now means "before 1.0". Personally I'd prefer not changing the meaning and just including the newforms-admin tickets in whatever sweep is done (I'm assuming a ticket sweep will be needed to figure out which are the essential must-fix tickets for 1.0) of tickets in general to classify them as pre- or post-1.0 concerns.
Karen
meta...@gmail.com
> Must-have features
I love that this list is small and concentrated. This is exactly what
is needed in order to get a release out quickly and focus development
effort.
+1 from me.
> "Maybe" features
These all seem reasonable. Certainly anything important to me on this
list is worth me making sure it gets done. #2070 is one that we deal
with a lot. It's not that I need support for "large" files, but if
someone accidentally does upload a large file, it can take out the
server. So for me this isn't as much about large file support as
preventing downtime due to silly users.
> Features not in 1.0
You have to draw the line somewhere, of course.
> 3. Any additional database backends. Again, the overhead in integrating a new
> database backend is too much. These will need to remain external backends
> until after 1.0.
could allow work to continue but somehow label it experimental? I'm
thinking of Python's way of dealing with this in particular: from
__future__ import blah. I don't see why integrating a new backend
places any workload on any other part of Django. Let those willing
hackers attempt to make something experimental for the release. This
will help them get feedback from early adopters and encourage people
who need the support to seek it out and discuss.
> We want to ship bug-free, so we'll dedicate as much of our time to bug
> stomping as possible. This means that feature requests will need to be
> deferred.
runs into this problem all the time, and their releases are delayed
for years because of it. Certainly Django is not as complex, but I
think that doing the best we can to sprint out all the bugs possible
is the best solution. If it turns out that you missed something,
well, that's what point releases are for.
[snip the schedule]
The schedule looks good. I think you should be hardlined about the
dates and not as hardlined on what makes it in. No one expects an
alpha to be production ready, so if you have to merge newforms-admin a
little earlier than you would like, just do it and fix the bugs before
the next alpha.
If the schedule must slip, I suggest adding a another release rather
than delaying one. Ie, let the number of alphas or betas be variable,
but keep up the schedule of releases every week.
I will commit to having several of my team participate in one of the
sprints (barring death or natural disaster, etc) leading up to the
release. We're building new stuff with Django, and we have old stuff
on Django, and in general we depend on Django to get things done. I
just *hate* having to maintain a private fork of 0.96.
[lack of support for 0.95 and older]
I would even consider dropping all but security patches to 0.96. That
is practically the limit of support anyway it seems, and is not likely
to cause much work. Those of us on 0.96 don't expect you to support
our private branches anyway, and maintaining that mess ourselves is a
huge incentive to bite the bullet and upgrade. You also might
consider letting whoever can spare the time apply patches to 0.96 and
do point releases for those people who will stay there forever (and
I'm sure there will be plenty). You lose nothing as long as there are
volunteers willing to do that work.
jack.
PS. I'm glad at least some of you thought my criticism today
constructive. These are hard things to get right, and I've certainly
made the same mistakes on previous projects. I took me _years_ to get
Ogg Vorbis 1.0 out the door, and I still deeply regret some of the
release decisions we made there. Live and learn.
James Bennett
> I have to ask why must Django prevent work in this regard?
To be perfectly fair, it's not really "prevented". Django supports the
use of database backends not defined in Django itself, so third-party
development of backends is unimpaired. And for the one most people
mention wanting -- MS SQL -- I think that's a good idea; that backend
has a history of people stepping up, putting in a burst of work and
then fading away, leaving the code dead and the Django dev team
responsible for maintaining it as long as it's in Django's codebase.
What really needs to happen there is much the same as what happened
with Oracle: some people who are really clamoring for it need to
organize and start pooling their efforts to develop something that can
comfortably become a part of Django (and now that external backends
are supported and qs-rf made the underlying mechanics of custom Query
classes much simpler, anyone wanting to do a new backend probably
faces a much easier time of it than the Oracle folks did).
Post-1.0, any externally-maintained backend that has a good track
record of support and a commitment from a developer to maintain it
into the future can easily be considered for integration, but until
then such projects should stay external.
> I would even consider dropping all but security patches to 0.96. That
> is practically the limit of support anyway it seems, and is not likely
> to cause much work. Those of us on 0.96 don't expect you to support
> our private branches anyway, and maintaining that mess ourselves is a
> huge incentive to bite the bullet and upgrade. You also might
> consider letting whoever can spare the time apply patches to 0.96 and
> do point releases for those people who will stay there forever (and
> I'm sure there will be plenty). You lose nothing as long as there are
> volunteers willing to do that work.
Personally, so long as folks are OK with the fact that it'll only ever
get security fixes I'd be happy with setting a time-based official
support window for 0.96, after which a community effort can pick it up
if desired. At that point I'd imagine it wouldn't be too hard to set
up one or two folks with commit access to the 0.96-bugfixes branch for
that purpose (and we've had good experience with clients who are on
legacy 0.91 Django installs and quite happily just run off a
0.91-bugfixes checkout, which makes pushing security updates to them
insanely easy).
Gábor Farkas
<jacob.ka...@gmail.com> wrote:
>
> "Maybe" features
> ----------------
>
.
.
.
>
> 5. Model-level validation (#6845).
hi,
it always seems quite ugly, that you can create a model with invalid data,
and save it. so when you want to validate it's content, you have to hack around
and create a form for it, etc...
as far as i understand, this change is a backwards-incompatible change,
and also touches quite the basic parts of the whole
models/forms/validation system,
and i thought it's in the plan to have this in 1.0.....
so i wonder, that if the WSGI-conformance ticket is a must-have, then
why this isn't too...
perhaps the WSGI-change is smaller...
anyway, would be great to have the how-can-we-help data
(liutenant/committer/etc)
published as soon as possible...
gabor
Rajeev J Sebastian
On Thu, Jun 12, 2008 at 5:03 AM, Jacob Kaplan-Moss
<jacob.ka...@gmail.com> wrote:
> 7. Land GeoDjango as ``django.contrib.gis``.
Not that I have any right to say anything ... but should this really
be a django contrib ? Isn't it more of an external application ?
Regards
Rajeev J Sebastian
Ivan Sagalaev
> Django 1.0 will be released in early September.
Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature
called "1.0 release" and you schedule 3 months for it, you are doomed".
Jacob, honestly, where this date has come from? It can as easily be
August or October. You've outlined a good feature list and seem resolute
to stick to it. But unless all those lieutenants would plan their
features *in work hours*, you just can't know the date.
I was refraining from saying this because it's not that important after
all. However since Simon had (and others will) announce this date all
over the internet, we as a community will feel obliged to meet it
somehow, e.g. by throwing out really important things that we don't want
to. So may be it's not too late to state clearly that we have a plan but
it's not a schedule.
Jannis Leidel
> So we'd like to deal with that situation a bit specially. I've
> unfortunately not
> had a chance to ask Thejaswi (the student working on comments) or
> Jannis (his
> mentor) about this, so obviously they'll need to be OK with the idea.
I can only answer this preliminarily at the moment due to Thejaswi's
absence this week. But I'm confident of his progress and personally
think we can meet the schedule.
> We encourage people to push newforms-comments pretty hard,
> especially during sprints.
Good idea.
Cheers,
Jannis
Forest Bond
On Jun 11, 10:03 pm, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> release. That is, if the work on this list is not completed by a
> release date, we'll push the date.
#285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
Incidentally, so did Adrian. The text is copied from his post with
subject "Django 1.0 features -- the definitive list".
http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca
It's in important change and is backwards-incompatible.
Thanks,
Forest
Ville Säävuori
> August or October. You've outlined a good feature list and seem resolute
> to stick to it. But unless all those lieutenants would plan their
> features *in work hours*, you just can't know the date.
But I'm very much +1 on locking down spesific dates for any given
milestone. It's vital to have firm schedule and dates for making it
all happen in a relatively short period of time.
As what would those dates exactly be, I couldn't care less. As long as
they're not too far in the future, lets jazz on! :)
And FWIW, I think the proposed roadmap is brilliant. Not too many
features but still enough to make most of us very happy. Especially if
we can get at least few of the maybes in.
- VS
Nick
> And FWIW, I think the proposed roadmap is brilliant. Not too many
> features but still enough to make most of us very happy. Especially if
> we can get at least few of the maybes in.
months. Hopefully, this will reassure the worriers, as well as giving
everyone a real target to aim for.
The fact that a roadmap exists is the important thing, more than the
particular dates that have been chosen. Early September does
sound ambitious, but if there is a good level of participation in the
sprints, and if the output from those sprints can be reviewed and
checked in efficiently enough, it should be achievable.
I missed the last sprint and haven't contributed any patches for a
while now, but I'm certainly going to try and do my bit to get 1.0 out
the door...
N.
Marty Alchin
> I think that this is a must-have:
>
> #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
Then you'll be glad to know that it's #3 the list of "Must-have
features" in Jacob's email, just a bit below the portion you quoted.
-Gul
Luke Plant
> 11. Better support for controlling middleware ordering (#3591).
First, I think you meant #730
Second, I think this needs to be a must have, or at least the current
behaviour must be *documented*. See discussion on #749
Thanks,
Luke
--
"Don't mention it. Oh, you didn't." (Marvin the paranoid android)
Luke Plant || http://lukeplant.me.uk/
Ivan Sagalaev
> Firstly, as Jacob said, the schedule is just a draft at this point.
> But I'm very much +1 on locking down spesific dates for any given
> milestone. It's vital to have firm schedule and dates for making it
> all happen in a relatively short period of time.
If this is vital (for which I'm not a great judge) then it can only
happen by actually calculating the date, not just by choosing something
"motivating". And calculating means that every feature should be divided
into pieces that are fully designed and scheduled. It's very hard and,
you know, *boring* and it's why I think nobody will do this (I wouldn't
:-) ). So what's the point of hoping for September if it's not real?
Remco Wendt
On Jun 12, 4:03 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> * An alpha release containing all must-have features, but likely not
> bug-free. We'll push hard to have all the must-haves done in time
> for ample testing.
release thing?
From the must haves list it is mainly clearing the new-forms admin
blockers list. So if alpha is a (soft) API freeze, do the newforms-
admin people think we can work away all those tickets before july
20th?
Also I it may be interesting to show some love to the sprintideas page
(http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page
up for the Europython sprint (I couldn't find it). If you want me to
take care of this stuff, let me know.
Remco
Jacob Kaplan-Moss
It's not so much about "preventing" work -- nobody here works *for*
me, and I can't really tell anybody what to do. It's more about
focusing priorities. So the idea is that if someone comes along
wanting to help, we can show them a todo list of features that'll
actually help us hit 1.0 on schedule.
If people are excited about other database backends they of *course*
can work on them, but we'll simply defer discussion of including the
backend in Django until after 1.0 ships. I'm OK doing this since
database backends can be external (i.e.
http://code.google.com/p/django-mssql/).
> The schedule looks good. I think you should be hardlined about the
> dates and not as hardlined on what makes it in.
That's the plan. Only the "blocker" features actually can delay the
release, and I expect them to be done (sans bug fixes) by that alpha
date.
> I would even consider dropping all but security patches to 0.96. That
> is practically the limit of support anyway it seems, and is not likely
> to cause much work.
Good thoughts, but let's table this discussion until we actually get
around to appointing version managers; if we try to tackle too much
process now my head asplode.
Jacob
Jacob Kaplan-Moss
<man...@softwaremaniacs.org> wrote:
> Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature
> called "1.0 release" and you schedule 3 months for it, you are doomed".
> Jacob, honestly, where this date has come from? It can as easily be
> August or October. You've outlined a good feature list and seem resolute
> to stick to it. But unless all those lieutenants would plan their
> features *in work hours*, you just can't know the date.
Remember back in math class where you'd get marked down despite the
correct answer because you didn't "show your work"? I always hated
that. Still do, apparently, because although I just threw those dates
out there, I really did work very hard on them, and I do think they're
feasible.
First, it's not "a had-wavy feature": only the blocker items *must* be
done for 1.0. So if we'll all extremely lazy, we've got one
big-but-mostly-done feature (nfa), one medium-but-easy-and-also-almost
done feature (newforms in generic views), and one
trivial-and-done-but-not-merged feature (#285). I think it's perfectly
reasonable to expect to get those done in three months, don't you?
I didn't, though, just plunk a date three months out; the idea is to
take about a month to get to the alpha -- that is, one month to finish
the blocker features (but not necessarily make them bug-free), then
two weeks to the first beta, then a week each between each snapshot
until 1.0.
Further, I actually *can* predict at least one person's time in "work
hours": mine. Thanks to my kick-ass job, I get to spend most of my
work hours on Django. On top of that, I have firm commitments to
attend the sprints from a number of talented developers; I know from
experience that sprints are incredibly productive. We'll have *six* of
them between now and September.
Now, of course only time will tell whether I'm nuts or not, but I'm
pretty confidant that we can hit these dates. More important, though,
is that having firm dates will force the people working on "maybe"
features to put up or shut up, and it'll make our jobs as integrators
much easier -- only having a handful of things to merge will make that
process *much* less fraught.
> So may be it's not too late to state clearly that we have a plan but
> it's not a schedule.
Well, I tried to do that with the disclaimer about this being a draft
at the top. But, yeah, of course this is just a draft. That said, I
don't hear alternate timeline proposals -- do you have one? If you do,
you might want to learn from my mistake and "show your work" :)
Jacob
Jacob Kaplan-Moss
> First, I think you meant #730
> Second, I think this needs to be a must have, or at least the current
> behaviour must be *documented*. See discussion on #749
Yup, I meant #730, and I think you're right that we should figure out
something to do on #749 as well. Added to the todo list.
Jacob
Jacob Kaplan-Moss
>
>> 5. Model-level validation (#6845).
[...]
> and i thought it's in the plan to have this in 1.0.....
It is, assuming it gets done. Last I check Honza was working on it,
and if he's still interested I expect he'd be able to wrap it up.
However, while it would suck to ship 1.0 without it, there's nothing
about the API that has to be backwards-incompatible, and it's a
potentially "dangerous" feature in that it could spawn a lot of work.
So, if we can get there, great; if not, well, you've got a reason to
look forward to 1.1 :)
> so i wonder, that if the WSGI-conformance ticket is a must-have, then
> why this isn't too...
>
> perhaps the WSGI-change is smaller...
Exactly -- the WSGI change is very small, and actually done (see the
latest patch on #295). It basically just needs to be applied.
> anyway, would be great to have the how-can-we-help data
> (liutenant/committer/etc)
> published as soon as possible...
Yup, that's the next step!
Jacob
Jacob Kaplan-Moss
> Will the API be frozen from the alpha release? Or is this a beta
> release thing?
I'm not sure... I think probably beta 1 should be the API freeze, but
it's possible that with all the new features due at that point we
might need to tweak the APIs to fix bugs afterwards. I'd say that best
plan should be that any backwards-incompatible API changes after beta
1 need a quick discussion here; sound good?
> Also I it may be interesting to show some love to the sprintideas page
> (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page
> up for the Europython sprint (I couldn't find it). If you want me to
> take care of this stuff, let me know.
That would be awesome -- thanks!
Jacob
meta...@gmail.com
>
> To be perfectly fair, it's not really "prevented". Django supports the
> use of database backends not defined in Django itself, so third-party
> development of backends is unimpaired.
from the many eyes of the Django community is sort of an impairment.
It's a lot easier to get traction on a project that is in the Django
repo somewhere than to get it for a project on Google Code.
> And for the one most people
> mention wanting -- MS SQL -- I think that's a good idea; that backend
> has a history of people stepping up, putting in a burst of work and
> then fading away, leaving the code dead and the Django dev team
> responsible for maintaining it as long as it's in Django's codebase.
code in the repository. Surely it is quite easy to not include MS SQL
in the default list of backends and/or mention in the documentation
that MS SQL support is unsupported and experimental until such time as
it improves. Plenty of projects have bits of code that are crufty and
get labeled as such, and don't burn cycles maintaining it themselves.
To give a concrete example, the Xiph.org repositories have several
experimental codecs that are completely abandoned (unless someone
shows up to hack on them). We leave them there because they show
people that we foster creativity and community contribution, and there
are many good ideas there that should be kept around for reference.
And who knows, someday the guy who worte most of the Tarkin code may
come back and give MPEG-4 video a run for its money. But he certainly
won't if we just throw out his code. Communities are inclusive.
> What really needs to happen there is much the same as what happened
> with Oracle: some people who are really clamoring for it need to
> organize and start pooling their efforts to develop something that can
> comfortably become a part of Django (and now that external backends
> are supported and qs-rf made the underlying mechanics of custom Query
> classes much simpler, anyone wanting to do a new backend probably
> faces a much easier time of it than the Oracle folks did).
maintainer. By forcing the project outside the codebase, you've
eliminated (almost) the possibility of a bunch of random people
helping a little bit and getting the code in shape. It may be that
there won't be some dedicated single person who is willing to champion
this. But I bet there are a lot of people who are willing to help.
If you search on MS SQL support and Django, you find people talking
about how it doesn't work because of pagination problems. If you
search on RoR and MS SQL support, people are talking about the best
ways to do replication. It would be good for the project to attract
the poor developers using MS SQL (not by choice in many case) who work
at corporations and academia. I know people at the University of New
Mexico who would love to use Django, but the only requirement it must
fulfill is MS SQL support. Neither they nor I have the time to invest
to make MS SQL support happen, but removing MS SQL support from the
repository makes them think Django doesn't. When it was not working
so great, but still included, at least they had hope that by the time
they were ready someone would have fixed it.
jack.
Remco Wendt
On Jun 12, 4:43 pm, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> > Will the API be frozen from the alpha release? Or is this a beta
> > release thing?
>
> I'm not sure... I think probably beta 1 should be the API freeze, but
> it's possible that with all the new features due at that point we
> might need to tweak the APIs to fix bugs afterwards. I'd say that best
> plan should be that any backwards-incompatible API changes after beta
> 1 need a quick discussion here; sound good?
release. And from thereon shift towards stabilizing the API by giving
people as much time as possible to test and debug (before the final
release). The more you push the API freeze towards the final release,
the less time people have to test against a stable API. But I honestly
don't know whether this is a feasible option. So other people will
have to respond to this.
> > Also I it may be interesting to show some love to the sprintideas page
> > (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page
> > up for the Europython sprint (I couldn't find it). If you want me to
> > take care of this stuff, let me know.
>
> That would be awesome -- thanks!
Remco
meta...@gmail.com
> > dates and not as hardlined on what makes it in.
>
> That's the plan. Only the "blocker" features actually can delay the
> release, and I expect them to be done (sans bug fixes) by that alpha
> date.
release instead of having a giant block of time with no external
releases. So the 1.0 may slip a week, but at least the world knows
that it is moving forward as fast as ever. Hopefully it won't be a
problem at all :)
jack.
Ivan Sagalaev
> I didn't, though, just plunk a date three months out; the idea is to
> take about a month to get to the alpha -- that is, one month to finish
> the blocker features (but not necessarily make them bug-free), then
> two weeks to the first beta, then a week each between each snapshot
> until 1.0.
>
> Further, I actually *can* predict at least one person's time in "work
> hours": mine. Thanks to my kick-ass job, I get to spend most of my
> work hours on Django.
Jacob, your explanations has cleared things up, thanks!
BTW, judging by your reply I think that you might take my questioning as
an assault of some sort. If yes, let me say that I didn't mean it like
that. Your proposal just didn't have clues about where the date has come
from.
> On top of that, I have firm commitments to
> attend the sprints from a number of talented developers; I know from
> experience that sprints are incredibly productive. We'll have *six* of
> them between now and September.
Speaking of sprints... At our company (Yandex, Russian search engine) we
long have an idea to host a Django sprint for local developers. The
biggest problem was always that most Django core developers live either
in US or Australia which is equally far from Moscow time zone. Seeing
that one of the sprints is planned on EuroPython I think it's a good
chance for us to participate. Don't you think?
Forest Bond
-Forest
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
most of the tickets mentioned were assigned to someone. I am the one
working on 6845 and the how-can-anybody-help is attached to the
ticket:
the missing parts:
1. *feedback* !! (works, does what everybody expects it to do, has
all the options neede)
2. *documentation* and code clenup
3. tests (the existing tests were adapted, but more are needed)
>
> gabor
>
> >
>
Honza Král
<jacob.ka...@gmail.com> wrote:
>
> On Thu, Jun 12, 2008 at 3:32 AM, Gábor Farkas <ga...@nekomancer.net> wrote:
>>
>>> 5. Model-level validation (#6845).
> [...]
>> and i thought it's in the plan to have this in 1.0.....
>
> It is, assuming it gets done. Last I check Honza was working on it,
> and if he's still interested I expect he'd be able to wrap it up.
> However, while it would suck to ship 1.0 without it, there's nothing
> about the API that has to be backwards-incompatible, and it's a
> potentially "dangerous" feature in that it could spawn a lot of work.
> So, if we can get there, great; if not, well, you've got a reason to
> look forward to 1.1 :)
I will be around at europython with few people from our team and we
will try hard to finish the patch, along with anything we can
contribute to nfa since we use that A LOT ;). I will also be giving a
talk at EuroPython on newforms-admin.
80% of the work is done, I believe, and time has come to test that. I
strongly believe that it should be part of 1.0, because it can change
the behavior of the models (if not the entire API), since now you can
do pretty nasty stuff to the models without anybody noticing and
applying it later might thus create some nasty backwards-incompatible
changes.
Right now I would appreciate any help from the general public in
testing the feature set and the design principles. The patch is far
from complete, but the main ideas are there. I have attached a new
version of the patch to the ticket.
>> so i wonder, that if the WSGI-conformance ticket is a must-have, then
>> why this isn't too...
>>
>> perhaps the WSGI-change is smaller...
>
> Exactly -- the WSGI change is very small, and actually done (see the
> latest patch on #295). It basically just needs to be applied.
>
>> anyway, would be great to have the how-can-we-help data
>> (liutenant/committer/etc)
>> published as soon as possible...
>
> Yup, that's the next step!
count me in for #6845. Since the timeline is finally up, I can set
aside some time each day for work on this feature.
>
> Jacob
>
> >
>
James Bennett
> And this is great of course. But having to develop externally away
> from the many eyes of the Django community is sort of an impairment.
> It's a lot easier to get traction on a project that is in the Django
> repo somewhere than to get it for a project on Google Code.
If somebody wants a branch in which to do the work, I wouldn't have
any problem setting it up; that's how we did it for Oracle, and merged
it back to trunk when it was ready.
> No one says the Django team must exhaustively maintain every bit of
> code in the repository. Surely it is quite easy to not include MS SQL
> in the default list of backends and/or mention in the documentation
> that MS SQL support is unsupported and experimental until such time as
> it improves. Plenty of projects have bits of code that are crufty and
> get labeled as such, and don't burn cycles maintaining it themselves.
Having dead, non-functional code in Django is something I'd like to
avoid. And there's a world of difference between "here's an
experimental feature" and "here's something that was abandoned by the
person who developed it, and we don't know much about it".
Ville Säävuori
true. If there is something that I've learned as a project manager
during all the years that I've worked as one, it's that deadlines are
important.
Its not as important *when* the deadline is, as long as there is one.
If the proposed timeline is in the lines of "it would be great if we
would have 1.0 by the end of this year", we'll still be having this
same conversation about deadlines next year at this time :)
- VS
Matt Davies
Do what you think is right, django has been brilliant so far.
The jump to version 1(lightspeed) has been a bit of a nightmare, but let's all remember a pre django world.
I for one trust Jacob's judgement.
Just do it mate, there's good good people who want to help.
Chewie fixed the falcon with a blow from a spanner.
mrts
Currently Django has over 1000 active tickets. Some of them are
relevant to oldforms-admin, some are from pre-qsrf merge, some are
features for 1.1. But quite a few are small bugs that should be fixed
before 1.0.
Putting up milestones in trac would spark a community effort to sort
them properly. Assuming one minute per ticket, the sorting alone takes
17 hours from a single person. Hence community effort is clearly
required. Having a defined ticket set for 1.0 and all the intermediate
alphas is very important IMHO and using a single VersionOneFeatures
wiki page for that is practically impossible. That page is great for a
general vision and major issues that span tickets, but as I said, we
have to deal with the multitude of small issues as well.
Milestones should be set up according to Jacob's post (+ a legacy
milestone, e.g. 0.96-legacy for capturing tickets that are made
irrelevant after nfa merge etc).
Ivan Sagalaev
> The point of deadlines are that people tend to try to make them come
> true. If there is something that I've learned as a project manager
> during all the years that I've worked as one, it's that deadlines are
> important.
My main point was that the deadline should be real. Failing that, having
no deadline is just better than having a false one.
However Jacob have already cleared up that early September wasn't chosen
arbitrarily so there's no argument anymore.
mamcx
http://code.djangoproject.com/ticket/5062
I must say that I sell a internal semi-store with that code, integrate
later http://code.djangoproject.com/ticket/5246 and work fine.
But feel that the django people discourage the work at all. First, to
get this work is necesary put some lines in the core files of the DB
side. And later, that get erased, so is necesary do patching, and
patching not work because if we need do svn update to get something
fixed the work get lost. Patching is not fun with a project working
only in numerical revisions.
Then, other start the project and remove the good work that tickets do
(using a module workable on linux, doing paggination - is a complete
MYTH that is impossible in sql server - and stuff like that) and that
is depressing. Plus none of the actual code on google work at all...
*IF* the small but necesary modifications to the core DB files get
there - seriously, some fix bad assumptions or simply ad "if is
msssql" - I can do the mssql engine itself. In fact 5246 & 5062 are
coded in similar ways to the oracle backend.
---
In short the only & only thing pushing this back again and again is
that until now is necesary patch the core django. Tell me how that
could be avoided, and the mssql integration can be done very fast.
Bryan Veloso
what will be done when and what features will get pushed off to 1.0.
Milestones, at least for me as a growing developer, have always
provided that extra motivation as the progress meter approaches 100%.
Just seems more organized too.
Marc Fargas
El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió:
> * Two beta releases.
>
> All "maybe" features must be completed by the first beta; after that,
> Django will enter feature freeze for about a month while we kill bugs.
>
> * At least one -- and hopefully only one --release candidate. The candidate
> release will mark a total freeze (as well as a string freeze for
> translators); only outright bug fixes will be accepted past this point.
Disclaimer: I don't want to say anything bad about the triaging process
neither stale tickets. I'm trying to bringup an issue that could either
screw the Schedule or leave us with rc tickets after release. So,
please, do not interpret this as a critic.
On my today's triaging session (64 unreviewed left now) I spotted a few
bugs in Unreviewed of those kind that should be fixed before 1.0, first
examples:
* #6710, sslmod ignored in psycopg2
* #6997, Paginator fails with one element
* #7064, Decimal validator fails when both params are equal.
* #6948, join filter, string literal escaped (it should not).
* #6928, commit_on_succes + KeyboardInterrupt hide exceptions.
Those five have been in Unreviewed for between 2 and 3 months and, I
believe, are those kind of bugs that we'd like to fix before 1.0
Now, the thing is that we all know that core developers can't take a
look at the 1111 patches currently open to pick those that should be
fixed before 1.0 and there's no way right now that triagers can pick
those for them (except compilling a list and mailling it).
But the issue is not with the 1111 tickets, it's on the fact that bugs
filled againts the beta/rc releases and that should be fixed could stay
in the limbo too long, and that what can screw the Schedule. If core
developers miss a ticket that has to be pre-1.0 it will be missed.
The point is, as triagers are supposed to have good criteria on that, to
enable the "Milestones" again and restrict the Milestone field to be
only settable by Triagers?
I think somebody asked for the milestones in these thread, I'm just
telling one reason to have it.
Regards,
Marc
PS: Note: telenieko in TRAC is me (Regarding [7632])
--
http://www.marcfargas.com -- will be finished some day.
Charlie
resources" in Django, especially before the 1.0 release.
See discussion here:
http://lethain.com/entry/2008/jun/13/a-django-anti-pattern-rolling-your-own-rest/
Marc Fargas
> I'm curious if there are any plans to support simple urls for "RESTful
> resources" in Django, especially before the 1.0 release.
It's not on the roadmap to 1.0 so it won't be there, there's a project
around that see this list archives on this same week.
Thejaswi Puthraya
wrote:
> On Wed, Jun 11, 2008 at 9:13 PM, Russell Keith-Magee
> On comments
> -----------
>
> ``django.contrib.comments`` is a bit of special case here: ideally, Django 1.0
> will ship with *no* core use of oldforms. However, refactoring the comment
> system -- not just replacing forms -- is overdue, and is the subject of a Summer
> of Code project.
>
> So we'd like to deal with that situation a bit specially. I've unfortunately not
> had a chance to ask Thejaswi (the student working on comments) or Jannis (his
> mentor) about this, so obviously they'll need to be OK with the idea. But,
> assuming this works, I'd like to do the following:
I will try to get most of the code done by the first alpha 1.0
release, so that some of us can sit down and work on it during the
sprints. I know it sounds a little unrealistic but I will try my best.
I am in the process of relocating to another city and don't have
regular access to an internet connection but I can assure you that
work is still going on(at a slower pace
but I have quite a few items of the ToDo list that Jacob wrote about
sorted). I would also love people to suggest new features or code
changes apart from help during sprints.
--
Cheers
Thejaswi Puthraya
Russell Keith-Magee
> Hi there,
>
> El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió:
> On my today's triaging session (64 unreviewed left now) I spotted a few
> bugs in Unreviewed of those kind that should be fixed before 1.0, first
> examples:
>
> * #6710, sslmod ignored in psycopg2
> * #6997, Paginator fails with one element
> * #7064, Decimal validator fails when both params are equal.
> * #6948, join filter, string literal escaped (it should not).
> * #6928, commit_on_succes + KeyboardInterrupt hide exceptions.
>
> Those five have been in Unreviewed for between 2 and 3 months and, I
> believe, are those kind of bugs that we'd like to fix before 1.0
Based purely upon the ticket titles, they certainly sound like good candidates.
> Now, the thing is that we all know that core developers can't take a
> look at the 1111 patches currently open to pick those that should be
> fixed before 1.0 and there's no way right now that triagers can pick
> those for them (except compilling a list and mailling it).
We may not have time to look at 1111 tickets, but if someone has taken
the time to go through the database looking at all the tickets, we are
willing to take a list of suggested tickets as a starting point. You
have been doing a lot of good triage work over the last few days -
have you got a list of the tickets that _you_ think are 'must have'
for v1.0? We probably won't take your list verbatim, but having a
starting point is a good way to focus the attention of the community,
especially during sprints (speaking of which - the old sprint pages
also have lists of tickets that are probably good candidates for
v1.0).
Another way to approach this problem - it would be good to know how
many of the 1111 tickets are bugs, and how many are features. Adding a
'bug' or 'feature' as a keyword on the tickets is one way to track
this. Obviously, we'd like the 'bug' list to be empty (or at least
small) by final release, but the first step is to know how many bugs
are actually out there.
> The point is, as triagers are supposed to have good criteria on that, to
> enable the "Milestones" again and restrict the Milestone field to be
> only settable by Triagers?
>
> I think somebody asked for the milestones in these thread, I'm just
> telling one reason to have it.
Agreed. If I understand Jacob's comments, I think Jacob is agreed too;
he just needs to flick the switch on the trac install.
In the meantime, an alternative is to use a common keyword in the
ticket. As an example, "qsrf-cleanup" is already being used for issues
that have been identified after the merge of Queryset Refactor. These
keywords are searchable, so you can easily find all the related
tickets.
> PS: Note: telenieko in TRAC is me (Regarding [7632])
Apologies - my brain didn't make the connection. Consider it getting
twice the credit for your excellent work :-)
Yours,
Russ Magee %-)
Marc Fargas
> Based purely upon the ticket titles, they certainly sound like good candidates.
> You have been doing a lot of good triage work over the last few days
Thanks again :)
> have you got a list of the tickets that _you_ think are 'must have'
> for v1.0?
No, but I can do it while triaging and sent it to you. But then I'll
move to the full ticket list, not only Unreviewed ;)
> Adding a 'bug' or 'feature' as a keyword on the tickets is one way to track
> this.
I thought about that, but the same that happened with priorities could
happen there, that is: People could add those keywords trying to give
visibility to their tickets. That's what I asked for a field only
seteable by triagers ;)
Regards,
Marc
Remco Wendt
For those of us attending the EuroPython 2008 conference or wishing to
join online through IRC: W'll be holding a sprint during the
EuroPython sprint days to get newforms-admin merged into trunk asap
(see Jacob's roadmap that started this thread). If you want to help
out, please add yourself to the EuroPython 2008 sprint page (see:
http://code.djangoproject.com/wiki/SprintEuroPython2008).
Cheers,
Remco
Russell Keith-Magee
This is a reasonable concern, but it probably isn't as big a problem
as you think. Marking a ticket 'ready for checkin' is the most
immediate path to getting attention, yet we're not flooded with
malicious state changes. Yes, it does occur, but it is easy to
identify and easy to fix when it happens. A bug/feature keyword won't
give you anywhere as much attention, but it will help us filter out
features from the list of work we need to focus on.
Yours
Russ Magee %-)
Marc Fargas
> A bug/feature keyword won't
> give you anywhere as much attention, but it will help us filter out
> features from the list of work we need to focus on.
I took the other way around, I'm adding the keyword "post10" for tickets
that can wait until 1.0 so a negative filter would give you "pre10" and
"yet-to-be-marked-tickets". Hope that makes life a bit easier (but I've
only marked about 5 tickets).
Russell Keith-Magee
> El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
>> A bug/feature keyword won't
>> give you anywhere as much attention, but it will help us filter out
>> features from the list of work we need to focus on.
>
> I took the other way around, I'm adding the keyword "post10" for tickets
> that can wait until 1.0 so a negative filter would give you "pre10" and
> "yet-to-be-marked-tickets". Hope that makes life a bit easier (but I've
> only marked about 5 tickets).
Marking everything that _wont_ be in v1.0 will be a lot more work than
making sure we can find everything that _will_ be v1.0.
We would like to aspire to having Zero Bugs (or, at least, Zarro
Boogs) for v1.0. Therefore, all we need to be able to do is eliminate
any feature proposal (whether accepted, DDR or someday/maybe) from a
'todo list' search.
There are already 26 tickets marked 'feature'; IMHO, the best tagging
approach would be to continue this trend. Tag any feature specifically
included for v1.0 with a v1 keyword, any feature without the v1
keyword will be ignored, and assume everything else is a bug, and
needs to be addressed for v1.0.
Yours,
Russ Magee %-)
Join.T...@gmail.com
exploded since this thread was created? In the weeks/months after the
qs-rf merge, several days would go by when there wasn't a single
change committed, but suddenly there have been like 10 per day in the
last few days.
James Bennett
Like most development processes, it runs in cycles. After qsrf there
was a lull while people were shaking it out and reporting bugs, but
before that there was a whole lot more activity. And now, once again,
there's activity.
Such is the nature of what we do.
alex....@gmail.com
refactoring work comes in?
Marc Fargas
> I really like the roadmap, but I'm wondering where the docs-
> refactoring work comes in?
It in "Maybe" features, second from the bottom on
http://code.djangoproject.com/wiki/VersionOneFeatures