| 1 |
On Wed, Jul 29, 2020 at 4:09 AM Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> >>>>> On Wed, 29 Jul 2020, Aaron Bauman wrote: |
| 4 |
> |
| 5 |
> > # Aaron Bauman <bman@g.o> (2020-07-28) |
| 6 |
> > # More Py2 only stuff. Plz see -dev ML for discussions |
| 7 |
> > # Remove bindings, port to Py3, etc |
| 8 |
> > # Removal in 30 days |
| 9 |
> > [...] |
| 10 |
> > app-office/lyx |
| 11 |
> |
| 12 |
> I have unmasked this one again: |
| 13 |
> |
| 14 |
> "All python scripts distributed with LyX should now be compatible with |
| 15 |
> both python 2.x and python 3.x." |
| 16 |
> https://www.lyx.org/announce/2_3_1.txt |
| 17 |
|
| 18 |
Using package.mask in this way creates a TERRIBLE user experience. It |
| 19 |
causes users to look for alternatives and go through a lot of churn |
| 20 |
expecting the package to be removed, when it turns out there is |
| 21 |
nothing wrong and the package doesn't need to be removed. |
| 22 |
|
| 23 |
Bugs are a much more appropriate way to handle these situations. To |
| 24 |
start with, they ensure the maintainer even gets notified at all. A |
| 25 |
package mask doesn't actually notify the maintainer at all - it |
| 26 |
notifies anybody who has the package installed, and only when the host |
| 27 |
it is installed on is updated. It is possible (albeit less likely) |
| 28 |
that the maintainer might not have it installed, and more likely that |
| 29 |
they could have it installed in some container that they don't update |
| 30 |
daily. |
| 31 |
|
| 32 |
When the maintainer is able to fix the problem then users don't get |
| 33 |
the churn of a package mask. |
| 34 |
|
| 35 |
Obviously we're going to have packages that can't be migrated or which |
| 36 |
aren't maintained, and these should be treecleaned as with any other |
| 37 |
issue. |
| 38 |
|
| 39 |
If for some reason bugs are just THAT difficult to create, why not at |
| 40 |
least post the list on -dev-announce a few days before actually |
| 41 |
implementing the mask? You obviously have the list of packages if |
| 42 |
you're masking them, and you're even posting it on the list. So just |
| 43 |
post it on the list ahead of time so that people can react before they |
| 44 |
actually get masked. |
| 45 |
|
| 46 |
It seems like we're creating a terrible user experience simply because |
| 47 |
we can. This seems to be going back to how things were 10+ years ago |
| 48 |
when stuff broke for users often simply because nobody cared to even |
| 49 |
bother with communication and QA. |
| 50 |
|
| 51 |
-- |
| 52 |
Rich |
Archives