| 1 |
On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote: |
| 2 |
> First, the assumption in our processes seems to be that many or |
| 3 |
> important bugs will be due to architecture-specific differences, and I |
| 4 |
> wonder if that assumption really holds up. Do arch testers for a smaller |
| 5 |
> arch often find problems that were not noticed on one of the larger |
| 6 |
> arches? With the languages and tools that we have today, it seems like |
| 7 |
> for many of our packages, bugs due to architectural differences |
| 8 |
> represent a minority of the problems we found. In this case, the whole |
| 9 |
> idea of per-arch stabilization does not really make sense, and doing |
| 10 |
> away with that idea could drastically shortcut our process. |
| 11 |
|
| 12 |
This would be really interesting to know. |
| 13 |
|
| 14 |
> Second, I believe a lot of the value in our stable tree comes *just* |
| 15 |
> from the requirement that stabilization is only requested after 30 days |
| 16 |
> without major bugs/changes in the unstable tree. Assuming there are |
| 17 |
> enough users of a package on unstable, that means important bugs can be |
| 18 |
> shaken out before a version hits stable. This could mean that |
| 19 |
> potentially, even if we inverted our entire model to say we |
| 20 |
> "automatically" stabilize after a 30-day period without major bugs, we |
| 21 |
> hit most of the value of the stable tree with again drastically reduced |
| 22 |
> pain/work. |
| 23 |
|
| 24 |
The 30 day waiting period is useful for smoking out major upstream bugs, |
| 25 |
but can't replace stabilisation integration testing. For example, |
| 26 |
package foobar may build fine in ~arch but fails in stable because it |
| 27 |
needs a newer libbaz. |
Archives