On Fri, 2019-12-06 at 10:11 +0200, Mart Raudsepp wrote: > Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert: > > When we started removing Qt4, tons of code still used it. To put > > things > > in perspective: > > > > grep -rl 'IUSE.*python_targets_python2_7' > > /usr/portage/metadata/md5- > > cache/ | wc -l > > > > gives me 7070 ebuilds currently. 7070 is easily more than one and > > closer to two orders of magnitude more ebuilds using python 2 than > > Qt4 > > back in the days. > > You are dramatizing things too much on purpose here. That gives you a > list of almost all PYTHON_COMPAT packages, the majority of which > support python3 already, and will happily continue working after the > user drops python2_7 from PYTHON_TARGETS or it gets dropped from the > _PYTHON_ALL_IMPLS list in python-utils-r1.eclass.
Dramatizing that a significant portion of those need to be checked? Are you going to be doing that work? Are you going to check that the depgraph is valid? This is unlike py3.6 -> py3.7, where you just disable the impl in python-utils and stuff keeps working. This is going to trigger an avalanche. > > > Removing maintainer-needed and other semi-dead > > packages is part of a proactive strategy in continuously removing > > and > > treecleaning stale stuff from the tree. > > That's the problem right here. The mask included packages that are > not > maintainer-needed, nor maintained by python@ or other projects you or > Aaron are active members of. And it was a careless mask, masking even > some things that aren't even affected, merely had python2 mentioned > in > some commented out stuff, afaiu. > > I don't think there would be such a huge outcry if this was done > right > - involving the actual maintainers of these packages, not just going > ahead and package.masking them from under them 150+ days ahead of > time > of actual upstream python2 last release. Presumably most of these > maintainers would already know whether the package is in the progress > of being ported upstream (and just needs probably less than 120 days > to > complete that work and make a release), or know that it's dead and go > away. Or they don't respond, and you can p.mask them on a maintainer > honoring timeout. All the examples people name (abcde, eyeD3) are either maintained by sound, for which I gave Aaron an explicit sign-off, or they're m-n. This really boils down to what Rich called "somebody should maintain it, but it's not going to be me". The best example is probably sabnzbd, which people want, but don't want to maintain. > > As this was done is completely unacceptable. Honor your fellow > maintainers and don't trample over them like this. We already are in > a > lack of manpower, don't chase more away by trying to take the easy > route and doing stuff like this without involving them via a tracker > bug or other proper ways. > If you don't maintain a package, you get to work with the maintainer, > not do as you please without involving them at all. I am not aware of > QA having such blanket authority either for such a case. > > > I don't think anyone can have a valid problem with package.mask of > some > of the things mentioned (sabnzbd, abcde, etc), because they were > indeed > maintainer-needed or sound@ (which David is part of, and is known > crickets territory) or whatnot. It seems to have found interested > maintainers, as is normal with last-rite type of package.masks. > But by including things that are actually maintained, without any > apparent involvement of those maintainers, you allow for such outcry > even for things that shouldn't be a problem, because you display ill > intent and dishonoring towards your fellow maintainers. > > Honor your fellow Gentoo maintainers. Period. > > > Mart
