On Sat, Nov 1, 2008 at 9:14 PM, Tai Lee <[EMAIL PROTECTED]> wrote: > > #8898 and #9482 are both simple bug fixes with patches that remain > unreviewed. #9214 is a simple backwards compatible enhancement with > patch. > > I'm reluctant to mark them "ready for checkin" as I am the reporter, > but it's been 1-2 months for some of these with no review from > anybody, and at least the first two are very simple fixes for bugs > with no change in functionality. > > How should one get attention for these tickets?
For each of these you mention, I see a reason it has not been committed, which I'll describe below. In general, what will get fastest attention for 1.0.1 are clear bugs with patches that include tests and doc if appropriate. If it sounds more like an enhancement than a bug, it's not likely a candidate for 1.0.1. If it doesn' t have tests, it stands less chance of getting in. If there's confused discussion in the ticket that doesn't seem to have come to a clear consensus on the right answer, that'll likely slow things down. http://code.djangoproject.com/ticket/8898 I suspect this one may be stalled because it is in design decision needed state with a last comment that makes it sound like the existing patch (added before the last comment) is not correct and that the right fix will require changes that are potentially backwards-incompatible ("users should be guided to use X if they want to use Y"...how is that different from what users are guided to do today and is there something they can do today that won't be allowed after this fix is made?) The bug sounds like it should be fixed, but that last comment makes it sound like a proper fix is not yet available. Therefore not something that can easily be simply committed but rather will require someone to spend some time researching the history of this type of field to make sure the right fix is developed. This rather conflicts with what you say above about this being a simple fix, so please clarify in the ticket if that last comment and move to design decision needed was not meant to raise a red flag that the initially posted fix was not all that was necessary to fix this problem. > http://code.djangoproject.com/ticket/9482 This one is only two days old. Give it time. But there's an easy workaround (set the environment variable yourself before calling whatever script you are runnig), this is not something covered by the test suite so can't be tested to ensure it really doesn't break anything ("I can't see how this could possibly break anything" are some famous last words, and believe me I've said them myself), and it seems like a bit of an edge case (I haven't heard a lot of people needing to put code in a project's __init__.py file) all of which argue to me that it might not be a good candidate for 1.0.1. But that's just me, and it is only two days old. > http://code.djangoproject.com/ticket/9214 This one reads to me like a feature request, not a bugfix. (You even say above it is an enhancement.) 1.0.X is bugfixes only so I'd be surprised if something like this goes into it. Karen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
