On Tue, Feb 1, 2011 at 7:47 AM, Stephen Kelly <[email protected]> wrote: > Klaas van Schelven wrote: > >> Hi all, >> >> Maybe I wasn't clear enough last time... I've provided patches for >> both these old problems and would appreciate either a brutal Linus >> style rant for being such an idiot or would like to see the patches >> applied. Silence... not so much. >> > > Hi Klass, > > Your post is understandable but unfortunately timed. I am in the same boat > as you in that I would like my issues attended to. > > However, a feature of the django development process, as far as I can tell, > is that once a future django version has had blockers assigned and tickets > marked with that milestone, nothing else is likely to get attention unless > it sparks someones particular interest, even tickets which are 'done', > 'obvious' or 'trivial'.
This is true of blockers, but not of milestone tickets. Milestones are helpful suggestions for what to look at next. Especially at this late stage in the process, we only pay close attention to the blockers. We have limited resources. We have a deadline for a 1.3 release that has sailed by quite nicely. It's not like we're sitting around waiting for work to do. I'm sorry that I haven't personally had time to look at these tickets -- but in that respect, your tickets are in the same boat as about 500 others. That means we have to prioritize. About a month ago, we identified about a dozen tickets that were problems that were so bad that we couldn't release 1.3 without addressing them. These tickets were either serious regressions, caused data loss, or were flaws in newly added features. Those tickets get the highest priority for attention. Next on the list is the list of RFC tickets. Ideally, we want to make sure that there are no RFC bugfix tickets when we release 1.3, because this represents work where at least two sets of eyes have looked at a ticket. Next, there are issues that the core team have experienced in their day to day travels. If a committer experiences a bug and needs it fixed for their own projects, it will probably get fixed. Alternatively, if someone is in IRC at the right time and place and can stir the interest of a committer (possibly by engaging the committer in some quid pro quo), then the ticket may jump the queue. Unfortunately, at the bottom of the list is everything else. > Another feature of the django development process is that issues with > tickets don't get forgotten. The best we can do is wait a week after the 1.3 > release and then re-post if you think they're still overlooked. This is true, but misses an important intermediate step. The core team aren't the only people who can review tickets. In fact, all you need is for someone who isn't you to review your ticket and say that it looks good (by Django's standards -- which means documentation, tests, PEP8 etc). Once you've reviewed a ticket and you're happy, you can promote it to RFC -- which puts it much closer to being committed. So... Stephen, meet Klaas. Klaas, meet Stephen. You both have tickets than need review. Why don't you review each others tickets? That way you both end up with tickets in RFC. Remember -- this is a community project. There is a core team with the commit bit, but we really do rely on the rest of the community to help us organize those tickets. 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 [email protected]. 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.
