On Tue, Nov 4, 2008 at 11:04 PM, mrts <[EMAIL PROTECTED]> wrote:
>
> Most other projects are managed by a priority queue and clear target
> set for releases ("this has to go into 1.0.1, this can wait until
> 1.0.2"). No problem if discussions on the mailing list are the
> preferred way of doing it instead of Trac tools -- until things really
> get done."Most other projects" is an ad hominem, so I won't respond to that. Let me lay out the alternatives to you. Let us assume that we have a milestone, and tickets get assigned to it: Option 1: We don't release until all tickets on the milestone are complete. Option 2: We release on a date, with as many bug fixes as we can manage. I can guarantee you that Option 1 will result in a release that is later than expected, for any value of "expected". The amount of time available for development to the core team is not a constant, nor is it particularly predictable. We (the core developers) wore a lot of flack for waiting too long between 0.96 and 1.0. If we end up delaying v1.0.1 so we can meet a milestone list, mark my words - there will be a cry of "Why not just release a v1.0.0.1 with the interim fixes". Option 2 gives us timely releases, each of which is better than the last (i.e., less bugs). However, this doesn't require a milestone tag - all bugs are targets, and the general level of noise on the mailing list helps to prioritize the bugs that require immediate attention. For example, the inline problems you mentioned, and the URL reversal problems that were resolved early in the v1.0.X process were both significant bugs. The decision to fix these was made without the need for a milestone tag. Yes - we set a milestone for v1.0, but that is a bad example of how (and why) milestones work. The fact that a milestone worked for the version 1.0 release is due to two extraordinary factors: 1) The mystique surrounding Version One ensured more attention than normal from the core developers 2) Malcolm and Jacob just about killed themselves in the last few weeks with the amount of effort they put in to make sure the 1.0 milestone list was complete. I wouldn't base any planning process on the assumption that either of these are guaranteed to happen again. On top of that, we (the core developers) committed ourself to backwards compatibility at the v1.0 release, and we had a lot of little things that needed to be cleaned up before we made that commitment. A milestone is a very convenient way to keep track of the subset of issues that stood in the way of that goal. Post v1.0, our only goal is "zarro boogs", delivered on a timely schedule - again, we don't need milestones to keep track of this goal, because every open ticket is a target. What we _do_ need is a community that works on triage and bug fixes, and draws the attention of the core devs to particularly annoying or confusing bugs. 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
