Re: verification and bulk edit [Re: Unverified issues?]

[Federico Bruni]

2013/9/29 David Kastrup <address@hidden>

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.

This makes sense for issues marked as defects.. Well, some of them: for example, issue 3553 doesn't have a minimal example (I guess it cannot be produced) and I have no idea about how to verify it "in depth". In such cases I'll follow the CG:

"Quite a few of these will be issues tracking patches. You do not have to prove these patches work - simply that they have been pushed into the code base." BTW, what are "tracking patches"?

On the other hand, all the doc issues don't require other than checking that the committish is in master.

 

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.

Because of the release delay, the issues to verify for 2.17.27 were way over the average, which is around 15 issues per release AFAICS.

So probably my proposal is not needed.

I'm curious to hear the opinion of Eluze