On Sat, May 1, 2010 at 1:03 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > > On Apr 30, 2010, at 10:56 AM, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: > >> On Fri, Apr 30, 2010 at 11:11 PM, Jeremy Dunck <jdu...@gmail.com> wrote: >>> >>> As long as I'm here, how much interest is there in review board? >>> http://code.google.com/p/reviewboard/ >> >> ... >> 5) The patch is missing some critical component like tests or docs >> ... >> Cases 5 is annoying, particularly if it looks like the patch would be >> in case 1 or 2 if only the contributor had written a test case. This >> is a major time sink, but a code review tool isn't needed here - the >> 'needs tests' flag is all that is required. >> > > I guess I didn't realize that commiters were writing tests and docs for > otherwise good patches. I assumed those just immediately got a needs_* flag > and sat until an interested party finished it.
Depends on where we are in the development cycle. When we're in normal development and I'm looking for bug-squashing work to do, I will generally ignore non-ready tickets unless there's a particularly compelling reason. However, when we're in release crunch mode, the list of release blocking tickets takes priority over the tickets that are technically ready, and I'll do the development work if nobody else has contributed something. There's also a healthy dose of human intuition to the process. Regardless of where we are in the development cycle, if I see a bug that doesn't have a good patch, but I can see how the problem will have a widespread effect (or I'm seeing a lot of reports on django-users that are stemming from a particular problem), I will put the time into completing any patch that already exists. > Ideas how we can fix this? There are really two problems that need to be solved: 1. Provide better encouragement for people to contribute to release candidate blocking bugs in the leadup to a release (where contribute == implement patches, review patches, improve patches, or recommend patches as ready) 2. Provide better feedback to the core on which bugs are ready for commit during normal development. I'm not sure how to improve (1) beyond what we're already doing. Suggestions certainly welcome. As for (2), the 'me too' features I've spoken about before would solve that. 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-develop...@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.
