| 1 |
On Sun, 24 Jul 2016 12:17:56 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> So what's the alternative? Design another eclass where ebuilds will |
| 5 |
> fail just the same because people will ignore the more explicit |
| 6 |
> requirement just the same as they do ignore the API? |
| 7 |
|
| 8 |
Sometimes you don't need a "new path", you just need to transition from |
| 9 |
the old behaviour to the new behaviour at a slower rate with more |
| 10 |
visibility. |
| 11 |
|
| 12 |
Option 1: Start off with them being QA Warnings instead of fatal errors |
| 13 |
and encourage end users to report them where they see them. |
| 14 |
|
| 15 |
Then after a cycle of warnings, you go through and fatalise them |
| 16 |
incrementally in order of "least likely to break the build in dangerous |
| 17 |
ways". |
| 18 |
|
| 19 |
Option 2: Bind the behaviour to an EAPI version that is not yet in use. |
| 20 |
|
| 21 |
Then, when that EAPI gets rolled out to the ebuilds getting upgrades, |
| 22 |
the strictures come into effect when the EAPI changes, giving |
| 23 |
maintainers fair opportunity to fix the problem before it rolls out to |
| 24 |
users. |
| 25 |
|
| 26 |
For me neither of these options say "don't do this thing", they're just |
| 27 |
"manage the bleeding better" |
Archives