verification and bulk edit [Re: Unverified issues?]
2013/9/29 Eluze elu...@gmail.com 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 copypaste 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? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
Federico Bruni fedel...@gmail.com writes: 2013/9/29 Eluze elu...@gmail.com 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 copypaste 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
2013/9/29 David Kastrup d...@gnu.org 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
- Original Message - From: David Kastrup d...@gnu.org To: Federico Bruni fedel...@gmail.com Cc: Eluze elu...@gmail.com; lilypond-devel lilypond-devel@gnu.org Sent: Sunday, September 29, 2013 6:07 PM Subject: Re: verification and bulk edit [Re: Unverified issues?] Federico Bruni fedel...@gmail.com writes: 2013/9/29 Eluze elu...@gmail.com 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 copypaste 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. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
Federico Bruni-5 wrote 2013/9/29 David Kastrup lt; dak@ gt; 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
Phil Holmes-2 wrote - Original Message - From: David Kastrup lt; dak@ gt; To: Federico Bruni lt; fedelogy@ gt; Cc: Eluze lt; eluzew@ gt;; lilypond-devel lt; lilypond-devel@ gt; Sent: Sunday, September 29, 2013 6:07 PM Subject: Re: verification and bulk edit [Re: Unverified issues?] Federico Bruni lt; fedelogy@ gt; writes: 2013/9/29 Eluze lt; eluzew@ gt; 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 copypaste 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
Eluze wrote 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…). this just crossed Phil's last ten or so verifications - all in a minutes' cadence - chapeau! Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/verification-and-bulk-edit-Re-Unverified-issues-tp151595p151616.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
On Sun, Sep 29, 2013 at 09:49:07PM +0100, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org 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. Well, it's nice to have pleasant surprises? :) 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. Don't forget that using the issue tracker for patch submission is a bit of a hack. It was added because we were losing too many patches. If an issue is actual bug report, i.e. contains a minimal example, then of course the bug squad member should check that the minimal example no longer produces the flawed graphical output. I just don't think it's worth inventing a lot of extra work for patch-only issues. 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. Don't we already have a no example, no report policy for bugs?! We certainly should. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
