W dniu sob, 06.01.2018 o godzinie 12∶10 +0100, użytkownik Michał Górny napisał: > So I'm thinking of an alternate idea: to start adding staging warnings > for additional profile class, combined with arch restriction. In other > words, change CI from: > > -p stable > > to: > > -p stable,something -a alpha,amd64,...,mips,... > > with a separate class for NonSolvableDeps in non-stable profiles (like > repoman's badindev/badinexp) that triggers only a staging-class warning. > > However, this means that: > > ১. We need to settle for either dev or exp being 'more' supported, > and drop all unsupported profiles to the other group. > > ২. We need to fix the appropriate class of profiles for stable arches > (or move them to the other group). > > ৩. The arches in question still need to generate reasonably low number > of warnings. >
I'd like to follow this with a more precise proposal. Namely, redefine the current profile statuses to apply the following: a. stable -> fully tested, all depgraph breakages are errors, b. exp -> fully tested, all depgraph breakages are warnings, c. dev -> developer's playground, not tested. This would specifically mean that: 1. Any 'exp' profiles with serious breakage will temporarily be downgraded to 'dev'. 2. A 'dev' profile can be upgraded to 'exp' if its scale of depgraph breakage is reasonable (i.e. doesn't clutter the QA report with too many warnings). 3. A 'exp' profile can be upgraded to 'stable' only if it has no depgraph breakages. I don't have a strong opinion on whether we should pursue marking all profiles 'stable', or if we support keeping 'exp' indefinitely. The CI would be updated to test 'exp' profiles and report staging warnings appropriately. Repoman would be updated to have warning-class dependency.badinexp (like it has for .badindev right now) and to check exp profiles by default. Your thoughts? -- Best regards, Michał Górny
