| 1 |
On 08/04/2016 12:24 PM, William Hubbs wrote: |
| 2 |
> |
| 3 |
> We can allow maintainers to stabilize new versions of certain types of |
| 4 |
> packages on all arches where there is a previous version of the package stable |
| 5 |
> without filing stable requests. This would take a significant load off |
| 6 |
> of the arch teams. |
| 7 |
> |
| 8 |
> For packages that do not fit the first group, we could require stable |
| 9 |
> requests, but allow maintainers to stabilize the new versions after a |
| 10 |
> timeout (I would propose 30 days). |
| 11 |
> |
| 12 |
> What do folks think? |
| 13 |
> |
| 14 |
|
| 15 |
This is a good idea; there's a lot of low-hanging fruit here. We could |
| 16 |
write up a fairly restrictive list of exceptions and still accomplish a |
| 17 |
lot of good. |
| 18 |
|
| 19 |
For example, we've had an exception floating around for a while that |
| 20 |
says that maintainers can stabilize their own x86/amd64 packages. That's |
| 21 |
assuming they have the hardware, run a stable system themselves, and do |
| 22 |
the testing. This sounds reasonable to me -- as the maintainer, I'm |
| 23 |
likely to do a better job of testing a package than an arch tester will. |
| 24 |
For certain things like web/database servers, I'm using these things in |
| 25 |
production for weeks, and the additional build test performed by the |
| 26 |
arch team isn't going to add any new information. |
| 27 |
|
| 28 |
Can we at least agree on that exception? Let's codify it in |
| 29 |
|
| 30 |
https://bugs.gentoo.org/show_bug.cgi?id=510198 |
| 31 |
|
| 32 |
and move on from there. |
| 33 |
|
| 34 |
Assuming we go through with that exception, here's another one to |
| 35 |
consider: if a package would otherwise be stabilized ALLARCHES, then the |
| 36 |
maintainer can perform the stabilization on all arches himself under |
| 37 |
those same prior assumptions (he can test, etc). There's no point in |
| 38 |
making 8 different people test a new version of some PHP package that |
| 39 |
only changed pure PHP code. |
| 40 |
|
| 41 |
Another exception would be for maintainer-needed packages. If there's a |
| 42 |
revision that only fixes a bug, we should be able to get it stabilized |
| 43 |
and remove the old version even though there's no maintainer. |
| 44 |
|
| 45 |
I would like to add an exception for metadata changes, too, but honestly |
| 46 |
I don't trust people to use it wisely. I shouldn't have to bug the arch |
| 47 |
teams if I add a second LICENSE and revbump... maybe if this exception |
| 48 |
is worded strongly-enough it could do more good than harm. |
| 49 |
|
| 50 |
What I don't want to see is us changing the meaning of "stable" (cf. |
| 51 |
making a "D" a passing grade). We should never have maintainers doing |
| 52 |
stabilization of C programs on architectures they don't run. I'm only in |
| 53 |
favor of exceptions that speed things up without reducing the quality of |
| 54 |
the stable tree. This is met by the exceptions I've outlined above, if I |
| 55 |
really am doing more thorough testing than the arch teams, or if I have |
| 56 |
truly made a harmless metadata change. |
| 57 |
|
| 58 |
In any case, we should still have to wait a minimum of 30 days before |
| 59 |
moving a package stable (modulo security issues). |
Archives