| 1 |
On Fri, Jul 10, 2015 at 1:11 PM, William Hubbs <williamh@g.o> wrote: |
| 2 |
> |
| 3 |
> The problem is, it isn't clear which path is official. The qa team |
| 4 |
> approved the global policy, but every time the council tries to back it |
| 5 |
> architecture teams seem to step up and say they will catch up and |
| 6 |
> convince the council to back down. |
| 7 |
> |
| 8 |
|
| 9 |
Without re-reading the logs, my recollection wasn't that arch teams |
| 10 |
convinced the council to back down so much as arch teams went out and |
| 11 |
proactively de-stabilized packages strategically so that the new |
| 12 |
stable set was maintainable, and then proceeded to maintain the rest. |
| 13 |
That is a win/win, and mooted any need to take action. |
| 14 |
|
| 15 |
I've been in support of the 90-day policy with maintainers having |
| 16 |
discretion to extend it. The issue will no doubt come up again, and |
| 17 |
we should probably formalize the policy in the devmanual. If that |
| 18 |
needs a council vote so be it, but I don't really see it as essential. |
| 19 |
|
| 20 |
The bottom line is that arch teams shouldn't stabilize more than they |
| 21 |
can keep up with. Stabilization is a contract between a maintainer |
| 22 |
not to be disruptive to an arch, and an arch team to partner in |
| 23 |
maintaining the package. If either side can't keep up their end (for |
| 24 |
many possible reasons) then a package shouldn't be stable on the arch. |
| 25 |
Users can still install unstable packages, but either way they know |
| 26 |
what they're getting into quality-wise. |
| 27 |
|
| 28 |
-- |
| 29 |
Rich |
Archives