On Fri, 2019-12-13 at 21:31 +0100, Fabian Groffen wrote:
> On 13-12-2019 14:24:33 -0500, Michael Orlitzky wrote:
> > On 12/13/19 9:28 AM, Fabian Groffen wrote:
> > > We are providing those patches, maybe.  In reality very often the
> > > patches originate from somewhere else though.  And you don't want to
> > > have to respin all of those just because.  At least that's what I feel.
> > > 
> > 
> > Just because... the context changed? A new "!" in a line of context can
> > be the difference between letting someone log in with the right password
> > and letting them log in with the wrong password. You should at least
> > have to stop and verify that the patch does what you think it does when
> > it "gains" fuzz. And at that point, git diff will give you a clean
> > version of it.
> 
> Counter argument is that we've been doing this for decades, and always
> relied on maintainers to check the contents of their patches, without
> problems.  We didn't introduce a predictable random number generator or
> something.

Is this really an argument for or *against* it?  Developers are entirely
capable of keeping seds that do nothing for years, as well as patches
that -- while apparently applying correctly -- are entirely meaningless.
Should I remind you that epatch was entirely capable of creating
meaningless files by randomly applying the wrong patch level?

> Your very specific example just illustrates the niche this proposal is
> targetting.
> 
> As with many of the proposals lately, they just seem to aim at more work
> for individual maintainers, with a very low gain ratio.
> Better, allow this to be a FEATURE, or whatever, that devs should enable,
> but don't spit this in the user's face by default.
> 

Just like 'many of the proposals lately', developers are going to be
the ones disabling it (because they don't care), and users will be the
ones enabling it (because they do care), just to learn that developers
don't care and go complaining to the mailing lists that users dare
report issues they don't care about.


-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to