On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich <sly...@gentoo.org> wrote:
> TL;DR;TL;DR: > ------------ > > This email seeks for one step towards less toil tied to gentoo's > keywording/stabilization process. I've CCed a few groups who > might be interested in making this area better: > > - gentoo-dev@ as it affects most devs (and non-devs!) > - wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ > (should I join? :) > - arch-leads@ as it directly helps (or breaks everything for) arch teams > - all individual arches for wider visibility > Thanks for kicking off this discussion. As a stable user, this is an important topic to me. Your email is kind of long, and I wonder if we can condense the problem back to simpler first principles. 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. 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. Cheers, Dirkjan
