| 1 |
El mié, 17-08-2016 a las 09:07 -0400, Rich Freeman escribió: |
| 2 |
> I'm not sure I agree. If it is scripted, then isn't it just a few |
| 3 |
> more cpu cycles? |
| 4 |
|
| 5 |
Well... until I see that script, I won't trust it. We are for a long |
| 6 |
time supposedly allowing people to move things to testing after 90 days |
| 7 |
and that is not working at all because of that. Simply try to go to our |
| 8 |
current pending gnome stabilization, and you will see how difficult |
| 9 |
does it turn (for example, another issue is with the optional reverse |
| 10 |
dependencies, that would require to use.mask some USE flags for some |
| 11 |
packages in some arches). |
| 12 |
|
| 13 |
Once that script is ready... I am unsure about why are we even |
| 14 |
discussing this as, after that dekeywording task can be feasible after |
| 15 |
90 days, the picture in all exotic arches with change so much that we |
| 16 |
would need to meet again in some months to evaluate the result |
| 17 |
|
| 18 |
The problem is that I don't think that is really feasible... and |
| 19 |
looking to that script still being unavailable and we still discussing |
| 20 |
about how to improve this makes me think it's a harder issue to achieve |
| 21 |
:( |
| 22 |
|
| 23 |
> Why even have a stable keyword? What does it even mean if everything |
| 24 |
> gets stabilized in 90 days whether it is tested or not, or whether it |
| 25 |
> even builds? |
| 26 |
> |
| 27 |
Well, personally I don't think why many of that arches are supposedly |
| 28 |
still having a reliable stable tree. Most of them are relying on Ago |
| 29 |
doing most of the work (that is mostly buildtime testing... and I have |
| 30 |
no issue with that, as adding also runtime testing to all the packages |
| 31 |
and arches is completely unrealistic). Anyway the "stable keyword" |
| 32 |
would still give the packages 90 days of being in the tree (at least) |
| 33 |
for the hypothetical bugs to appear. If they don't appear, maybe they |
| 34 |
don't exist (like in most cases) or, in the worst case, that arches are |
| 35 |
so few used that I am sure the burden would be high enough. |
| 36 |
|
| 37 |
|
| 38 |
> Take the degenerate case. Suppose an arch team is completely AWOL. |
| 39 |
> If we go with my route and de-stabilize packages then you end up with |
| 40 |
> an arch that is de-facto experimental with no stable packages (or |
| 41 |
> maybe @system only) after some period of time. If we instead |
| 42 |
> stabilize anything after 90 days if there is no response then the |
| 43 |
> AWOL |
| 44 |
> arch team ends up having more stable packages than any other arch, |
| 45 |
> because they're the only ones not reporting bugs. |
| 46 |
|
| 47 |
Well, if we have the script, I am the first one preferring your |
| 48 |
route... but that route is of dekeywording stuff is allowed for a long |
| 49 |
time and we still have nothing, then, until that script is even a |
| 50 |
draft, I don't consider it a real option. |
Archives