Re: CVS commit: src/usr.bin/gzip

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Tue, Jun 12, 2018 at 12:00:01PM +0200, Kamil Rytarowski wrote:
> On 12.06.2018 11:51, matthew green wrote:
> >> On 12.06.2018 10:28, Kamil Rytarowski wrote:
> >>> On 12.06.2018 09:04, Martin Husemann wrote:
> >>>> On Tue, Jun 12, 2018 at 05:47:35AM +0300, Valery Ushakov wrote:
> >>>>> To sum it up, out of 30+ lines of the commit message, the relevant
> >>>>> information is contained only in (part of) one line.
> >>>>
> >>>> FWIW, I fully agree with uwe here.
> >>>>
> >>>> Martin
> >>>
> >>> I find keeping reproducers for issues very useful. Keeping track of them
> >>> helps to check whether fixes are functional.
> >>>
> >>> Also introduction of refactoring without a note in the message is not
> >>> acceptable in my opinion.
> >>>
> >>> Thanks to the verbose message people have the whole context.
> >>
> >> To be clear, I will keep introducing fixes in the same form. I'm
> >> catching e.g. bugs in programs only in specific usage and input. If I
> >> will refactor something I will keep including it in messages too.
> > 
> > that's a pity.
> > 
> > i don't mind having a little more detail that uwe is talking
> > about, but i don't think we need nearly as much.  it's worth
> > mentioning the sanitizer used as the finding-tool, but there
> > is no need to repeat the basic fix 3 times, or to reproduce
> > the code change itself.
> > 
> > please reconsider and use a shorter form.
> > 
> 
> I will keep messages within 20 lines.

That's missing the point. A short description of why the specific
undefined behavior is seen is useful. Pasting random program output is
not.

Joerg