On Wed, Jul 29, 2020 at 4:09 AM Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Wed, 29 Jul 2020, Aaron Bauman wrote:
> > # Aaron Bauman <b...@gentoo.org> (2020-07-28)
> > # More Py2 only stuff. Plz see -dev ML for discussions
> > # Remove bindings, port to Py3, etc
> > # Removal in 30 days
> > [...]
> > app-office/lyx
> I have unmasked this one again:
> "All python scripts distributed with LyX should now be compatible with
> both python 2.x and python 3.x."
> https://www.lyx.org/announce/2_3_1.txt

Using package.mask in this way creates a TERRIBLE user experience.  It
causes users to look for alternatives and go through a lot of churn
expecting the package to be removed, when it turns out there is
nothing wrong and the package doesn't need to be removed.

Bugs are a much more appropriate way to handle these situations.  To
start with, they ensure the maintainer even gets notified at all.  A
package mask doesn't actually notify the maintainer at all - it
notifies anybody who has the package installed, and only when the host
it is installed on is updated.  It is possible (albeit less likely)
that the maintainer might not have it installed, and more likely that
they could have it installed in some container that they don't update

When the maintainer is able to fix the problem then users don't get
the churn of a package mask.

Obviously we're going to have packages that can't be migrated or which
aren't maintained, and these should be treecleaned as with any other

If for some reason bugs are just THAT difficult to create, why not at
least post the list on -dev-announce a few days before actually
implementing the mask?  You obviously have the list of packages if
you're masking them, and you're even posting it on the list.  So just
post it on the list ahead of time so that people can react before they
actually get masked.

It seems like we're creating a terrible user experience simply because
we can.  This seems to be going back to how things were 10+ years ago
when stuff broke for users often simply because nobody cared to even
bother with communication and QA.


Reply via email to