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: Eluze
Subject: Re: verification and bulk edit [Re: Unverified issues?]
Date: Sun, 29 Sep 2013 14:09:44 -0700 (PDT)

Phil Holmes-2 wrote
> ----- Original Message ----- 
> From: "David Kastrup" <

> dak@

> >
> To: "Federico Bruni" <

> fedelogy@

> >
> Cc: "Eluze" <

> eluzew@

> >; "lilypond-devel" <

> lilypond-devel@

> >
> Sent: Sunday, September 29, 2013 6:07 PM
> Subject: Re: verification and bulk edit [Re: Unverified issues?]
> 
> 
>> Federico Bruni <

> fedelogy@

> > writes:
>>
>>> 2013/9/29 Eluze <

> eluzew@

> >
>>>
>>>> >> 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
> 
> 
> Graham and I used to debate this.  His view was that all that is required
> of 
> Bug Squad members is to verify that a claimed fix was committed.  This
> would 
> lend itself well to autoverification, should someone have the time to
> write 
> an autoverify-bot.  I would live with that for Issues marked as something 
> like "Patch-pushed".  I do think that claimed fixes to real bugs should
> have 
> a tiny example, and the bug squad should confirm that the tiny example no 
> longer fails.  This could argue for a more rigorous approach to bug 
> acceptance: no example, no report.

that would make our life more pictoral!
Eluze



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



reply via email to

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