| 1 |
On Thu, 11 Oct 2018 19:14:00 +0200 |
| 2 |
Thomas Deutschmann <whissi@g.o> wrote: |
| 3 |
|
| 4 |
> > 1) Someone blind-stabled something on arm and it broke (doesn't |
| 5 |
> > build?) 2) The arm team failed to mark a package stable before a |
| 6 |
> > hard deadline (DNSSEC key rotation) |
| 7 |
|
| 8 |
"Blind-stabled"... |
| 9 |
|
| 10 |
> But that's not the point here. The point was to get some attention |
| 11 |
> that again we have a lacking architecture (net-dns/dnssec-root is not |
| 12 |
> the only package where ARM arch team is lacking behind) which affects |
| 13 |
> anyone "trusting" somehow in STABLE keywords. |
| 14 |
|
| 15 |
The trustworthiness of stable keywords has been eroding for years. |
| 16 |
|
| 17 |
It started when ago@g.o found ways to automate "compile-testing" |
| 18 |
on many architectures, taking work away from people who actually cared |
| 19 |
about those architectures, reducing arch team efforts to trying to |
| 20 |
catch up with ago's work. While it was a valiant effort to reduce |
| 21 |
architecture teams' backlogs, I couldn't stress enough at the time how |
| 22 |
taking decisions on behalf of all users of an architecture isn't |
| 23 |
something you can automate, for instance putting effort into |
| 24 |
stabilisations for (sets of) packages that may have ceased being useful |
| 25 |
on respective platforms, so that users would switch to cherry-picking |
| 26 |
their own stable targets instead of relying on stable keywords to still |
| 27 |
be meaningful. |
| 28 |
|
| 29 |
Where "compile-testing" failed as runtimes do not necessarily reflect |
| 30 |
that what is being compiled does actually work, architecture teams had |
| 31 |
to pick up those pieces of now incorrectly stable-keyworded packages |
| 32 |
that got strewn around in automation's wake. |
| 33 |
|
| 34 |
Even more recently a new trend arose where just about anybody who |
| 35 |
maintains a package takes stabilisation decisions, usually citing some |
| 36 |
"all arches" policy, and in this case "blind-stabled", on behalf of |
| 37 |
architecture teams. This new direction is likely based on the same |
| 38 |
backlog pressure[0], a sense of emergency because of security issues, |
| 39 |
and the desire to clean up obsolete ebuilds. |
| 40 |
|
| 41 |
Having mostly stepped away from concerted stabilisation efforts myself |
| 42 |
for those reasons among others, I can only speak for myself in stating |
| 43 |
that my trust in stable keywords is at its lowest ever ebb. |
| 44 |
|
| 45 |
|
| 46 |
Kind regards, |
| 47 |
jer |
| 48 |
|
| 49 |
|
| 50 |
[0] Wait, didn't we get rid of that? Ah no, the automation effort |
| 51 |
reduced architecture team involvement to the point of being |
| 52 |
non-existent. |
Archives