2013/9/29 David Kastrup <[email protected]> > 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
_______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
