Getting PRs fixed [ was: Re: The future of fortune(6) ]

[Mike Remski]

On Fri, 01 Dec 2017 11:44:31 +0100
"Kristof Provost" <kp at FreeBSD.org> wrote:

> On 1 Dec 2017, at 11:24, Mike Remski wrote:
> > Bug databases need to be scrubbbed periodically.  Even if it's just
> > to close ones that can't be reproduced or have been fixed by other 
> > changes (after due diligence in verifying it so there is no absurd 
> > excuse).
> >
> > There are a lot of foks with the ability and desire to help, fixing 
> > PRs and sending in patches should be a good way to involved, but
> > that still depends on the owner of a piece to look at a patch, ask 
> > questions, get revisions and commit it.  If that never happens or
> > the submitter never gets any feedback, it winds up discouraging the
> > new people.
> >
> > Fixing bugs, espeically on !CURRENT, is not glamorous, but
> > necessary. Often actually root causing the bug and patching it
> > gives one a better understanding of the overall system and a sense
> > of satisfaction.
> >
> > Yes, I realize that everyone is a volunteer and has a real life,
> > but at least acknowledging a submission should be done, even if it
> > is automated.  This goes both ways:  originator of a bug (or patch)
> > needs to be responsive to the FreeBSD committer if they request
> > more data or clarification.
> >  
> Good bug reports are enormously valuable. A bug report with a clear 
> reproduction scenario is vastly more likely to get fixed (quickly).
> My own experience is that usually I spend more time on trying to 
> reproduce the problem than actually fixing it. Sometimes by orders of 
> magnitude.
> 
> Patches are fantastic, but a bug report with a simple reproduction 
> scenario is often just as good (and sometimes even better).
> 
> Regards,
> Kristof
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"

Apologies for the long text lines in my original, stupid webmail client
didn't wrap them.

I agree that bugs with steps to reproduce are invaluable.  I don't mind
getting bug reports at work when QA includes that information without
me needing to ask a million questions.
Core files are often priceless because you can get a better picture of
what happened.

Maybe the problem needs to be approached from both sides?  Clear
documentation on what makes a useful bug report so submitters give
developers better info up front and maybe a little bit of prodding to
get bugs looked at?

mike