Federico Bruni <[email protected]> writes: > 2013/9/29 Eluze <[email protected]> > >> >> Traditionally Eluze works through these on a Monday. Let's check the >> >> situation on Tuesday. >> > >> > Ah, ok. >> >> I will treat what's left tomorrow (I'm not the only bug squad member >> allowed >> to do it!) > > > I've cleared some of them, you won't have to work too much tomorrow :-) > This is a boring task and it should be shared as possible between all bug > squad members. > > Also, I'm thinking about a way of making it easier. > Most of the times we have only to check if the committish pasted by the > developer is really in master. If we add a field "Committish" (where the > developer should paste the committish), then the bug squad can show the > column Committish and work on the list page instead of having to open each > issue. > Then we copy&paste each committish in gitk and when we have verified all of > them we can use the bulk edit to mark all the issues as Verified in one > shot (never tried but I hope it works). > > What do you think about it?
It matches the theory. In practice, I've been startled quite a few times when bug squad members not just verified the commit to be present but also reported back when it turned out that the claimed functionality did not actually accompany the commit. The verification you spell out here could be done by a web crawler and would be done in seconds. The verification from the bug squad appears to do a more thorough job on average. When changing the issue tracker, you get a field for specifying what the tracker should do next after changing the current issue. If you use "go to next issue", it will move to the next issue matching the search. That seems rather efficient, and it would appear that the bug squad reading the issue description and possibly more leads to an improvement of the results. The question is whether we can significantly improve the efficiency without sacrificing more quality than desirable. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
