lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: verification and bulk edit [Re: Unverified issues?]
Date: Sun, 29 Sep 2013 19:07:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]