https://gcc.gnu.org/viewvc/gcc/hooks/ is how it was done. This used the incoming email handling for bugzilla i set up. These days, you could just use bugzilla's rest API IE a simple variant of https://github.com/mozilla/github-bugzilla-pr-linker/blob/master/app/app.py should work as a commit hook. That thing is written as a service, you just need the find/add parts of the rest api, rip them out, and use it as a post-commit hook. On Tue, Jun 12, 2018 at 5:49 PM, David Blaikie <dblaikie at gmail.com> wrote:> Nah, don't think we've ever had that in LLVM - certainly would be nice to > have :) > > On Tue, Jun 12, 2018 at 5:48 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Isn't svn set up to auto-parse and post to the bug so you can just say >> "fixes bug 44444" and it parses it out? >> >> I mean, i added that to gcc like 15 years ago, i'm surprised we don't do >> this :) >> >> Nobody should have to add this info manually unless someone forgot to put >> it in a commit message. >> >> >> On Tue, Jun 12, 2018 at 1:36 PM, Tom Stellard via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On 06/12/2018 07:51 AM, via llvm-dev wrote: >>> > TL;DR: It's okay to close a bug, if you can justify it properly. >>> > >>> > Recently there has been a spate of bug-closing with what I would call >>> > inadequate documentation. Comments such as "Obsolete?" or "I assume >>> > it's fixed" could be applied to nearly every open bug we have. While >>> > this does reduce the open bug count--something I have been watching >>> > with morbid fascination for years--I do fear that the reduction is >>> > potentially artificial, and incorrectly puts the onus on the original >>> > bug author to reopen the case. >>> > >>> > I suggest that closing a bug can be done IF AND ONLY IF you also state >>> > one of the following: >>> > - that revision NNNNNN actually fixed the bug >>> >>> There is a field in bugzilla called "Fixed By Commits" that I added >>> specifically for this information. >>> >>> -Tom >>> >>> > - that the bug cannot be reproduced with revision NNNNNN >>> > - that the circumstances for the bug don't apply anymore; e.g., >>> > "This is about the makefiles and we don't use makefiles anymore." >>> > - sound reasons for not fixing something (WONTFIX) >>> > - some specific and plausible reason to think that a given bug is >>> > otherwise inapplicable or obsolete >>> > >>> > In particular, "Obsolete?" and "I assume it's fixed" are NOT enough >>> > justification to close a bug. >>> > >>> > If people are okay with this, I'd expect adding a new section to the >>> > Developer Policy is probably the right place to put it. >>> > >>> > Comments/brickbats welcome... >>> > --paulr >>> > >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180612/8ac3c756/attachment.html>
That solution semi-automates the first item in my list, and sounds like a great idea. We still have the other 4 cases. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Daniel Berlin via llvm-dev Sent: Wednesday, June 13, 2018 1:11 AM To: David Blaikie Cc: llvm-dev Subject: Re: [llvm-dev] RFC: Bug-closing protocol https://gcc.gnu.org/viewvc/gcc/hooks/ is how it was done. This used the incoming email handling for bugzilla i set up. These days, you could just use bugzilla's rest API IE a simple variant of https://github.com/mozilla/github-bugzilla-pr-linker/blob/master/app/app.py should work as a commit hook. That thing is written as a service, you just need the find/add parts of the rest api, rip them out, and use it as a post-commit hook. On Tue, Jun 12, 2018 at 5:49 PM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote: Nah, don't think we've ever had that in LLVM - certainly would be nice to have :) On Tue, Jun 12, 2018 at 5:48 PM Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Isn't svn set up to auto-parse and post to the bug so you can just say "fixes bug 44444" and it parses it out? I mean, i added that to gcc like 15 years ago, i'm surprised we don't do this :) Nobody should have to add this info manually unless someone forgot to put it in a commit message. On Tue, Jun 12, 2018 at 1:36 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 06/12/2018 07:51 AM, via llvm-dev wrote:> TL;DR: It's okay to close a bug, if you can justify it properly. > > Recently there has been a spate of bug-closing with what I would call > inadequate documentation. Comments such as "Obsolete?" or "I assume > it's fixed" could be applied to nearly every open bug we have. While > this does reduce the open bug count--something I have been watching > with morbid fascination for years--I do fear that the reduction is > potentially artificial, and incorrectly puts the onus on the original > bug author to reopen the case. > > I suggest that closing a bug can be done IF AND ONLY IF you also state > one of the following: > - that revision NNNNNN actually fixed the bugThere is a field in bugzilla called "Fixed By Commits" that I added specifically for this information. -Tom> - that the bug cannot be reproduced with revision NNNNNN > - that the circumstances for the bug don't apply anymore; e.g., > "This is about the makefiles and we don't use makefiles anymore." > - sound reasons for not fixing something (WONTFIX) > - some specific and plausible reason to think that a given bug is > otherwise inapplicable or obsolete > > In particular, "Obsolete?" and "I assume it's fixed" are NOT enough > justification to close a bug. > > If people are okay with this, I'd expect adding a new section to the > Developer Policy is probably the right place to put it. > > Comments/brickbats welcome... > --paulr > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180613/0bee94a1/attachment-0001.html>
Dean Michael Berris via llvm-dev
2018-Jun-13 17:50 UTC
[llvm-dev] RFC: Bug-closing protocol
Hi Paul, I’m one of those that closed at least one bug in this manner, without citing exact DNNN nor rNNN numbers. I’d like to fix that and do better in the future. So I agree 100% with you that we really ought to be more thorough and diligent with the way we’re handling bugs. I for one would really like for the bug filing/tracking mechanisms to be easier/simpler/convenient/ergonomic. In particular: - Let’s automate as much of this as possible. I really like the idea of auto-closing bugs with some convention based on the commit message(s). - Let’s have a process/policy by which we handle un-acknowledged or mis-assigned bugs. A triage process would be really helpful, and I understand that a lot of us are volunteers and/or part-time working on things. - Let’s evaluate whether bugzilla is still the appropriate solution for issue tracking. Considering that there’s (huge) efforts for re-licensing and the proposal to move to using git (and a monorepo structure?) then maybe alternatives can be explored for the next iteration of the development process when those are done — including whether LLVM should stick with Bugzilla or use GitHub issues (as one example) instead with a lot of the automation features already in place. This is perhaps a longer conversation that needs to happen and I’m interested in having that conversation (it’s very relevant to my interests). Hope this helps.> On 14 Jun 2018, at 02:58, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > That solution semi-automates the first item in my list, and sounds like a great idea. > We still have the other 4 cases. > --paulr > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Daniel Berlin via llvm-dev > Sent: Wednesday, June 13, 2018 1:11 AM > To: David Blaikie > Cc: llvm-dev > Subject: Re: [llvm-dev] RFC: Bug-closing protocol > > https://gcc.gnu.org/viewvc/gcc/hooks/ > > is how it was done. > > This used the incoming email handling for bugzilla i set up. > > These days, you could just use bugzilla's rest API > > IE a simple variant of https://github.com/mozilla/github-bugzilla-pr-linker/blob/master/app/app.py should work as a commit hook. > > That thing is written as a service, you just need the find/add parts of the rest api, rip them out, and use it as a post-commit hook. > > > > On Tue, Jun 12, 2018 at 5:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > Nah, don't think we've ever had that in LLVM - certainly would be nice to have :) > > On Tue, Jun 12, 2018 at 5:48 PM Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Isn't svn set up to auto-parse and post to the bug so you can just say "fixes bug 44444" and it parses it out? > > I mean, i added that to gcc like 15 years ago, i'm surprised we don't do this :) > > Nobody should have to add this info manually unless someone forgot to put it in a commit message. > > > On Tue, Jun 12, 2018 at 1:36 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 06/12/2018 07:51 AM, via llvm-dev wrote: > > TL;DR: It's okay to close a bug, if you can justify it properly. > > > > Recently there has been a spate of bug-closing with what I would call > > inadequate documentation. Comments such as "Obsolete?" or "I assume > > it's fixed" could be applied to nearly every open bug we have. While > > this does reduce the open bug count--something I have been watching > > with morbid fascination for years--I do fear that the reduction is > > potentially artificial, and incorrectly puts the onus on the original > > bug author to reopen the case. > > > > I suggest that closing a bug can be done IF AND ONLY IF you also state > > one of the following: > > - that revision NNNNNN actually fixed the bug > > There is a field in bugzilla called "Fixed By Commits" that I added > specifically for this information. > > -Tom > > > - that the bug cannot be reproduced with revision NNNNNN > > - that the circumstances for the bug don't apply anymore; e.g., > > "This is about the makefiles and we don't use makefiles anymore." > > - sound reasons for not fixing something (WONTFIX) > > - some specific and plausible reason to think that a given bug is > > otherwise inapplicable or obsolete > > > > In particular, "Obsolete?" and "I assume it's fixed" are NOT enough > > justification to close a bug. > > > > If people are okay with this, I'd expect adding a new section to the > > Developer Policy is probably the right place to put it. > > > > Comments/brickbats welcome... > > --paulr > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Dean