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

[Eluze]

Federico Bruni-5 wrote
> 2013/9/29 David Kastrup <

> dak@

> >
> 
>> 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

I have not much to add - yes it *is* boring if you only check that the
committish is there: a machine would do this faster and is probably less
error prone. but as dak observed, a few issues have been found to not really
solve the whole problem, just a part of it.

I have added a few issues to the tracker and many of them were originated by
myself. so it seems natural that I'm interested how the solution looks like
and not only that the patch has been committed.

I must confess that not every topics are of the same interest to me - that's
where I simply check the pre-/absence of the patch (and that's the boring
part). however that doesn't take much time (except for developers still
having a googlemail-account… because then you don't fall back to the issue
list) and I think it's a confirmation for the developers that their patch
has been definitely approved and confirmed. that's better than waiting for
days or weeks for a - maybe never coming - feedback. they may feel much
freer to put their energy into solving other issues.

a final remark: in the beginning of my bug squad member career it took me
much longer to verify a single issue - now with some routine I can open an
issue, search the commit, copy it, swap to Phil's tab, paste, check there is
something there, swap back, select verified and submit in clearly less than
a minute (and nearly blindly…).

Eluze




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/verification-and-bulk-edit-Re-Unverified-issues-tp151595p151613.html
Sent from the Dev mailing list archive at Nabble.com.