Federico Bruni <address@hidden> writes:
2013/9/29 Eluze <address@hidden>
>> 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