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