| 1 |
On 07/25/2017 06:22 AM, Rich Freeman wrote: |
| 2 |
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensington@g.o> wrote: |
| 3 |
>> |
| 4 |
>> The 30 day waiting period is useful for smoking out major upstream bugs, |
| 5 |
>> but can't replace stabilisation integration testing. For example, |
| 6 |
>> package foobar may build fine in ~arch but fails in stable because it |
| 7 |
>> needs a newer libbaz. |
| 8 |
>> |
| 9 |
> |
| 10 |
> I think this is a good reason why everything should be at least |
| 11 |
> build-tested on a stable tree before getting stabilized. Now, that |
| 12 |
> might not be on each arch if it is truly arch-independent (and if |
| 13 |
> arches keep the dependencies reasonably in sync). |
| 14 |
> |
| 15 |
> This might be a situation where a compromise could exist. Have some |
| 16 |
> kind of flag (in metadata, or maybe the ebuild) that indicates that |
| 17 |
> the maintainer believes the package is low-risk to stabilize purely on |
| 18 |
> a build test. Then after 30 days in testing a tinderbox could |
| 19 |
> build-test the package and stabilize it automatically. |
| 20 |
> |
| 21 |
> If the package is considered at-risk then it goes through manual |
| 22 |
> testing, either by the maintainer or an arch team. |
| 23 |
> |
| 24 |
> This will also encourage the teams doing testing to actually do more |
| 25 |
> testing on the packages that would benefit from it. |
| 26 |
> |
| 27 |
> We wouldn't set hard criteria but leave it up to maintainer |
| 28 |
> discretion, with a guideline being that past performance is probably a |
| 29 |
> good predictor of future results. |
| 30 |
> |
| 31 |
This reads like a practical use of both developer time and machine time. |
| 32 |
Build testing at a minimum, imo, is necessary if the word "stable" is |
| 33 |
going to mean anything for us. So +1. |
| 34 |
|
| 35 |
Since there are bound to be fewer manually tested packages than |
| 36 |
automatic "it builds, ship it" packages, I think it would make a bit |
| 37 |
more sense to add a "manually test this please" tag to metadata.xml, |
| 38 |
rather than expect auto-stabilizers to have additional tags, which will |
| 39 |
outnumber the manual packages and inflate the size of the tree (albeit |
| 40 |
slightly). |
| 41 |
|
| 42 |
Since maintainers also manage their packages in various ways, could we |
| 43 |
extend this to a general <policy> element? Maintainers can specify how |
| 44 |
they'd prefer bugs or commits to be done, and an additional element to |
| 45 |
indicate hand-testing. This would solve two problems instead of just |
| 46 |
one: indicate a package is ready for auto-stabilization, and give a |
| 47 |
single, canonical location for a maintainer to put maintenance policy. |
| 48 |
|
| 49 |
Just my 2ยข, |
| 50 |
|
| 51 |
~zlg |
| 52 |
-- |
| 53 |
Daniel Campbell - Gentoo Developer |
| 54 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 55 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
Archives