WANTED: bugzilla help (automated and semi-automated) closing bugs

[Andrew Bartlett]

On Thu, 2019-06-20 at 11:22 +0200, Björn JACKE wrote:
> On 2019-06-20 at 06:06 +1200 Andrew Bartlett sent off:
> >  1. push to autobuild
> >  2. wait for autobuild
> >  3. enter git hash and version into gitlab and close
> >  4. enter git hash and version into bugzilla and think about backport
> >  5. do backport
> >  6. get reviews
> >  7. assign to karolin
> >  8. Karolin then pushes to autobuild
> >  9. Karolin then updates bugzilla as pushed
> >  10. Kaorlin then updates bugzilla as in the release and closes.
> > 
> > Steps 1-4 and 7-10 are way to manual, and so much falls between the
> > cracks, and when it doesn't, it takes way too much time.
> > 
> > I think we should at least try to automate 1-4, so MRs and bugzilla
> > entries close as soon as they are plausibly merged, or we switch to
> > tooling that is joined-up, where this happens out of the box.  
> > 
> > If the developer really cares about the issue (and the automated
> > process was wrong) they can re-open things of course, but in the
> > meantime things are ready for the next major release. 
> 
> I go along with this reg. adding such an automation process for new bug
> activities because for currently open bugs with activity the process is
> "reviewable" via the samba-qa mails. I'm happy to help with this also.

Great, that sounds like a way forward!  I've found this script, which
while unmaintained might be a good place to start: 
https://github.com/gera/gitzilla

Could you have a look at that and see if it is viable?

> My concerns that I had and still have are about the automatic closing of huge
> numbers of existing bug reports, only because the bug number was mentioned in a
> commit message for example. For huge numbers this would not be verifyable.

I agree for huge numbers.  Thankfully printing the git commit (bonus
for a version) and not closing it would be a great start, and is pretty
harmless. 

Also with that much done a human or humans can review what is actually
only 100 bugs much faster, so there is hope we could even close them
manually.

> Last but not least we should have a look if the default assignees for the
> components are well chosen. It doesn't make sense for example, if a component
> has a default assignee, because he is responsible for that component but at the
> same time not reading mails from bugzilla regulary. The current list is
> attached as html to this mail. In order to not poisoning the "My Bugs" list
> mentioned above, maybe we should get away from personal default assignees
> completely?

I agree, default assignees are essentially pointless for the way we
work.

Thanks for putting thought into this!

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba