| 1 |
El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió: |
| 2 |
> [...] |
| 3 |
> Well, I wasn't suggesting that breaking the depgraph is great. Just |
| 4 |
> that I think it is better than calling things stable which aren't. |
| 5 |
> |
| 6 |
> A better approach is a script that does the keyword cleanup. |
| 7 |
> |
| 8 |
> So, if you want to reap an ebuild you run "destabilize |
| 9 |
> foo-1.2.ebuild". It searches the tree for all reverse deps and |
| 10 |
> removes stable keywords from those. Then you commit all of that in |
| 11 |
> one commit. |
| 12 |
> |
| 13 |
> If you want to be extra nice you stick it in a pull request in github |
| 14 |
> and point it out to the arch team and ask them if they're sure they |
| 15 |
> don't want to stabilize your package... :) |
| 16 |
> |
| 17 |
|
| 18 |
Well, the reason I was suggesting to allow maintainers to stabilize |
| 19 |
after the 90 days timeout over *current* policy of allowing the |
| 20 |
dekeywording is that the dekeywording is completely unrealistic to do |
| 21 |
as some packages have a huge amount of reverse deps. Even with the |
| 22 |
script (and, well, I would like to see that script existing... because |
| 23 |
we are having this issue for ages, and that is the reason that nobody |
| 24 |
is moving things to testing actively), you will find many many cases of |
| 25 |
packages having so many reverse dependencies that if you try to move it |
| 26 |
to testing it becomes soon a hell. |
| 27 |
|
| 28 |
The main issue is that, once you start dekeywording one package, you |
| 29 |
jump to, for example, dekeywording another 3 reverse deps, then you |
| 30 |
need to continue with the reverse deps of that reverse deps... and at |
| 31 |
the end, it's completely impossible to manage it (I still remember how |
| 32 |
hard was to move to testing most of Gnome... and we even were lucky as |
| 33 |
we were able to do that with the jump to Gnome3). |
| 34 |
|
| 35 |
Then, my point it to allow the maintainer to keep stabilizing it |
| 36 |
*after* the 90 days timeout. If after that time, the arch team is |
| 37 |
unable to even reply, nobody has reported any build/runtime issues |
| 38 |
related with that arch, I would go ahead. Otherwise, it looks pretty |
| 39 |
evident to me that that arch is near to be used by nobody and maybe it |
| 40 |
should be moved completely to testing (or most of their packages moved |
| 41 |
to testing and only the core apps in stable). |
Archives