Re: git: c112b84fd807 - main - Revert "x11/fvwm3: Fix FvwmIconMan module segfault"

El mar., 19 jul. 2022 19:53, Alexey Dokuchaev <danfe@freebsd.org> escribió:

> On Tue, Jul 19, 2022 at 10:40:00AM -0700, Cy Schubert wrote:
> > In message <YtbrUdyCPAlM6dCZ@FreeBSD.org>, Alexey Dokuchaev writes:
> > > On Tue, Jul 19, 2022 at 01:34:43PM +0000, Cy Schubert wrote:
> > > > commit c112b84fd8076a19f30f0705a3c139ef360b101e
> > > >
> > > >  Revert "x11/fvwm3: Fix FvwmIconMan module segfault"
> > > >
> > > >  The maintainer misunderstood the meaning of the maintainer-feedback
> > > >  flag in bugzilla.
> > >
> > > This still does not explain if the fix was wrong or not.  If it's
> wrong,
> > > it should've been explained in the commit log, if it's correct then how
> > > does reverting it help?
> >
> > The fix was not wrong. According to the maintainer, the patch fixed the
> > bug.
>
> I presume that anyone who committed this did read the code and made a
> clear judgment whether it was correct or not, prior to committing.
>
> > The maintainer didn't want it committed yet so more people could test it.
>
> I don't see how this can work: those who'd hit the segfault would confirm,
> those who'd not would not.  How does it help?  There's either a bug in the
> code or not.  At this point it looks like a fix was reverted only to be
> recommitted again, resulting in nothing but a needless repochurn. :-/
>

Or not. Maybe the fix didn't fix the issue completely or created a new one.
That's why the maintainer wanted confirmation first.

The committer mixed up two fields. That happens. We're human beings. I
think our repo can keep up with two extra commits :-)



> ./danfe
>