| 1 |
On Mon, 10 Apr 2017 10:57:43 -0400 |
| 2 |
> |
| 3 |
> You are: when you find out that a stable package doesn't work with |
| 4 |
> the next version of python, you have to figure out who the maintainer |
| 5 |
> of that package is, and file a bug. |
| 6 |
|
| 7 |
That is how things are done for Java, and I think Perl as well. There |
| 8 |
tend to be tracker bugs for the next version. |
| 9 |
|
| 10 |
https://bugs.gentoo.org/show_bug.cgi?id=384609 |
| 11 |
|
| 12 |
> Then, whenever he decides to fix |
| 13 |
> it, you have to wait 30 days and file a stabilization request. Wait |
| 14 |
> another few months for that to go through, and repeat however many |
| 15 |
> times to fix every broken package. |
| 16 |
|
| 17 |
This has nothing to do with stable. A new version would not go direct |
| 18 |
to stable. That version would not be marked stable so not effecting |
| 19 |
stable packages till it is marked stable. |
| 20 |
|
| 21 |
> You can either spend months/years doing that for all affected |
| 22 |
> packages and every new version of python, or just commit the new |
| 23 |
> version of python and let things break. Neither option is an |
| 24 |
> improvement over the way things work now. |
| 25 |
|
| 26 |
The idea is to stop touching every ebuild per every new python or ruby |
| 27 |
release. Or when an old is removed. Also to stop having users mess with |
| 28 |
TARGETS. |
| 29 |
|
| 30 |
> We have it your way for PHP packages, and I wish it was like |
| 31 |
> Python/Ruby instead. |
| 32 |
|
| 33 |
That makes PHP, Perl, and Java. Just Python and Ruby are handled |
| 34 |
differently. |
| 35 |
|
| 36 |
-- |
| 37 |
William L. Thomson Jr. |
Archives