| 1 |
On Fri, 2019-12-13 at 21:56 +0000, Michael 'veremitz' Everitt wrote: |
| 2 |
> On 13/12/19 21:42, Michał Górny wrote: |
| 3 |
> > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: |
| 4 |
> > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny <mgorny@g.o> wrote: |
| 5 |
> > > > Just like 'many of the proposals lately', developers are going to be |
| 6 |
> > > > the ones disabling it (because they don't care), and users will be the |
| 7 |
> > > > ones enabling it (because they do care), just to learn that developers |
| 8 |
> > > > don't care and go complaining to the mailing lists that users dare |
| 9 |
> > > > report issues they don't care about. |
| 10 |
> > > I care if the patch is actually broken, which the warning doesn't |
| 11 |
> > > really tell me. It's just not a very reliable indicator, and will |
| 12 |
> > > produce false-positives frequently. |
| 13 |
> > > |
| 14 |
> > You can also take less context into the patch and use -F0. Then you'll |
| 15 |
> > have the same effect, no warnings to bother you and no pretending that |
| 16 |
> > the patch applies when it doesn't. |
| 17 |
> > |
| 18 |
> Is there any mileage in having a similar scheme to which we already apply |
| 19 |
> '-p' increments to the -F variable? |
| 20 |
> eg. |
| 21 |
> 1) attempt patch with -F0 |
| 22 |
> 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice |
| 23 |
|
| 24 |
That is precisely what my patch does and what people are complaining |
| 25 |
about. |
| 26 |
|
| 27 |
> 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning |
| 28 |
> and QA notice |
| 29 |
|
| 30 |
That makes no sense as it exceeds context provided in most patches. |
| 31 |
|
| 32 |
-- |
| 33 |
Best regards, |
| 34 |
Michał Górny |
Archives