On Mon, 10 Apr 2017 10:57:43 -0400 > > You are: when you find out that a stable package doesn't work with > the next version of python, you have to figure out who the maintainer > of that package is, and file a bug.
That is how things are done for Java, and I think Perl as well. There tend to be tracker bugs for the next version. https://bugs.gentoo.org/show_bug.cgi?id=384609 > Then, whenever he decides to fix > it, you have to wait 30 days and file a stabilization request. Wait > another few months for that to go through, and repeat however many > times to fix every broken package. This has nothing to do with stable. A new version would not go direct to stable. That version would not be marked stable so not effecting stable packages till it is marked stable. > You can either spend months/years doing that for all affected > packages and every new version of python, or just commit the new > version of python and let things break. Neither option is an > improvement over the way things work now. The idea is to stop touching every ebuild per every new python or ruby release. Or when an old is removed. Also to stop having users mess with TARGETS. > We have it your way for PHP packages, and I wish it was like > Python/Ruby instead. That makes PHP, Perl, and Java. Just Python and Ruby are handled differently. -- William L. Thomson Jr.
pgppGP54QJSNw.pgp
Description: OpenPGP digital signature
