| 1 |
On Sun, May 1, 2016 at 9:32 AM, Jeroen Roovers <jer@g.o> wrote: |
| 2 |
> And it means we're missing opportunities where "pure" interpreted |
| 3 |
> packages may test corner cases of the language implementation and find |
| 4 |
> bugs in (JIT or previously) "compiled" code. And that means we're |
| 5 |
> calling things "stable" that may expose such bugs that turn out not to |
| 6 |
> be corner cases at all and affect running systems in unpleasant ways. |
| 7 |
|
| 8 |
While this is a risk, I still think the cleanest solution here is to |
| 9 |
encourage maintainers to be aware of the packages they maintain and |
| 10 |
exercise the appropriate discretion when they think these corner cases |
| 11 |
exist and are important. Understanding the nuances of a package and |
| 12 |
how it works and how it is used is really a core purpose of having a |
| 13 |
maintainer in the first place. Of course no maintainer is perfect, |
| 14 |
but I think the upside is more than the downside here and as with |
| 15 |
anything we'll learn. |
| 16 |
|
| 17 |
-- |
| 18 |
Rich |
Archives