On Thursday, September 30, 2010, Ivan Sagalaev <man...@softwaremaniacs.org> wrote: > On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: > > Accepted tickets can be: > > * Purely accepted, indicating that someone has verified that the > problem exists, but not how to solve it > > * Accepted with a patch that is wrong in some way (e.g., fixing the > symptom, not the problem) > > * Accepted with a patch that is missing documentation or tests > > * Accepted with a valid patch, just awaiting review by someone else. > > A ticket in the first three conditions patently isn't ready for > checkin. A ticket in the last condition *may* be ready for checkin; we > ask for independent verification before it gets moved to RFC. > > So - IMHO "Accepted" plays a very important role in our triage system. > > > To me this shows exactly the opposite: a status that has so many meanings > doesn't really mean anything useful :-). I'm not new in Django development > yet as you see I managed to misunderstand its meaning in my previous mail.
Accepted means exactly one thing - the issue has been verified as a real problem (or acknowledged as a reasonable feature request), but isn't yet ready for inclusion in trunk. If viewed in combination with the other flags on a ticket, you can work out why a ticket isn't ready for inclusion in trunk - it needs documentation, it needs tests, it needs a patch, or the patch that exists needs improvement. As Waylan noted, this probably indicates that our documentation needs to be improved. > Anyway, what I'm saying is that we have this huge gap between someone writing > a good patch (with docs & tests) and the moment it gets into trunk. Current > mechanism of volunteer triagers who are supposed to move such tickets from > 'accepted' into 'ready for checkin' doesn't seem to work. The officially documented practice is that the "triage team" moves tickets to RFC. However, this hasn't been actual practice for some time. The effective practice is that anyone other than the submitted of a patch can m ove a ticket to RFC if they feel confident that it is ready. This is certainly an area where the documentation needs to be improved, in order to reflect common practice. What is also needed is a whole lot more people volunteering. Any suggestions on how to get more people doing the entirely unglamorous, but completely necessary work will be gratefully accepted. > So let me mend my suggestion to better fit reality. Instead of removing > 'accepted' altogether (though I still think it's a good idea) I think each > committer has to do this routinely. I know that every programmer would rather > code instead of applying patches and running tests but the development > process simply won't scale otherwise. So, let me be clear on what you're proposing: you acknowledge that the triage process is backlogged. Your proposal is to put extra workload onto the core team - the one group that is already a bottleneck in the process. During the 1.2 release cycle, I had to spend almost 2 weeks checking tickets in the unreviewed state in order to check that no release blocking bugs had been reported. This amounts to something like 50 hours of development effort - 50 hours that I didn't spend closing bugs. If you estimate that it takes an hour to close a ticket, that means 1.2 has 50 more bugs in it than it would have had if someone not on the core team had performed the triage task. As I write this, there are 215 tickets in the unreviewed state. There is plenty of triage work to do, and absolutely no reason that the core team has to be the group to do it. > BTW, Bazaar guys use the approach with a "champion of the week". Every week a > person from core committers volunteers to actively do triaging and committing > new and old tickets in the tracker. May be such explicit approach would work > for Django too. Especially since we're about to have more committers than we > do now. The core team volunteers the time that they have available. Some weeks that means a lot of time; some weeks it means no time. Sometimes time is spent closing tickets, and sometimes - when it's clear that there is a backlog of unreviewed tickets blocking a release, for example - the core team will do triage. The core team isn't wanting for things to do. There a plenty of tickets in RFC; there is lots of mailing list traffic that needs attention; there are new features that need to be designed, built and reviewed; and yes, there is triage. Forcing core developers to do triage exclusively simply takes energy away from other, equally important tasks that form part of the development process. On top of that, I can't speak for anyone else in the core team, but I fail to see see how a formal "this week is my week" arrangement will increase the time I have available to volunteer to the project. If anything, I see it decreasing the quantity of volunteered time, because if I don't think I will be able to dedicate an entire week, I probably won't put my hand up for fear of raising false expectations. 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.
