| 1 |
Ryan Hill posted on Wed, 04 Nov 2009 21:48:23 -0600 as excerpted: |
| 2 |
|
| 3 |
> Is there any interest in allowing certain packages to be stabilized by |
| 4 |
> the maintainer without going through the arch teams? I always feel |
| 5 |
> guilty when i file stabilization bugs for app-doc pkgs. |
| 6 |
|
| 7 |
Weren't there already arrangements for this in some cases? I distinctly |
| 8 |
recall a thread on it some time ago, with the conclusion being that |
| 9 |
various maintainers can get permission from the arch teams to keyword |
| 10 |
their own packages. |
| 11 |
|
| 12 |
Now that was in the /general/ context of having access to the arch either |
| 13 |
directly/personally or thru available testing resource machines, but (as |
| 14 |
klausman accounts for in his post) that really doesn't apply to (for |
| 15 |
example) docs packages that don't require fancy build-chains or (with |
| 16 |
some sanity margin) where the build chain dependencies have been long |
| 17 |
stable, so "required testing resources" are virtually zero. |
| 18 |
|
| 19 |
Thus, I'd say it's probably an extension of the previous arrangement -- |
| 20 |
but of course that does still require an initial one-time permission |
| 21 |
grant per arch, either per-package, or depending on arch/pkg-maintainer |
| 22 |
trust level, possible per category or similar. |
| 23 |
|
| 24 |
-- |
| 25 |
Duncan - List replies preferred. No HTML msgs. |
| 26 |
"Every nonfree program has a lord, a master -- |
| 27 |
and if you use the program, he is your master." Richard Stallman |
Archives