On Feb 21, 4:35 pm, Gabriel Hurley <gab...@gmail.com> wrote: > I'm still in favor of adding the "needsinfo" resolution and would love to > see that happen... I guess technically I could even do that one myself via > Trac's web admin if we're all agreed on it.
I agree this is a good idea. By the way, for reference it is #14702. > I'm ambivalent about adding the "ticket type" field back in, though. It can > be useful, but it *is* an extra item to keep managed and argue about... My > bigger concern, though, is the 1700+ existing tickets which will be > uncategorized. It would end up meaning that using that flag for queries in > Trac wouldn't give you a complete picture (at least not for a very long time > while things catch up). I share your concern about the existing tickets but I think that things would catch up reasonably quickly. This would be mostly helpful in conjunction with the milestone flag for coordinating the alpha, beta and final releases in the future (There seems to have been "only" about 2-300 tickets floating around for 1.3 in recent months). Perhaps this is something that could be trialled for the next cycle until the 1.4 release and see whether it helps or not. While I'm at it, I've also recently felt there was a gap between the "Accepted" and "Ready for checkin" stages, which might coincide with the 'needs feedback' state that Russell has mentioned in an earlier reply to this thread. When one posts a patch and believes that it is correct (or closed to be so), there is no easy and persistent way to request that someone else review the patch and then potentially promote it to RFC. Currently the only ways are transient (e.g. posting on the django-dev mailing list or IRC channel) and as such not very efficient if no one is both interested and available exactly at that time. RFC'ing one's own patch is bad form unless the patch is absolutely straightforward, and more generally it is always better to have an extra pair of eyes cast over it. I fear that because of this gap in the process, too many good patches go unnoticed and then grow stale or forgotten, whereas had those been staged to, for example, "Patch ready for review" they would have gotten noticed, reviewed and eventually checked-in much quicker. I know there already is a "Has patch" flag, but I actually find that one a bit useless since there's no way to distinguish from the mass of tickets where there are good, solid patches (whose authors themselves think could be RFC or simply in need for review) versus the draft or tentative patches. In fact, I'd make both the "Has patch" and "Patch needs improvement" flags redundant and instead introduce a new "Patch ready for review" stage. Here's a typical example scenario: - A reports a bug #123. - B verifies the bug and stages #123 to "Accepted". - B posts a patch and is pretty confident it works. B then stages #123 to "Patch ready for review". - C has a few minutes on his hands and pulls the list of tickets with patches ready for review, opens #123, scans the patch and sees a few issues. C stages #123 back to "Accepted" (or in fact may as well leave it as "Patch ready for review") and writes a comment explaining the issues with the patch. - B posts a new updated patch (and re-stages #123 to "Patch ready for review" if it has been staged back to "Accepted"). - D verifies the patch is now correct and then stages #123 to "RFC". To illustrate this, I've got two patches currently in this virtual "Patch ready for review" state: #13091 and #12475 :-) What do you think? Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
