On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote: > On 07/12/2017 01:59 PM, Michael Palimaka wrote: > > If it's not a stable candidate then why do you use this as an example > > against build testing-based stabilisations? If there are known issues it > > should never reach the arch teams in the first place. > > This might be the crux of things, as long as automatic stabilization is > not triggered by some set of rules (e.g 30 days in ~arch) , and still > requires manual trigger by, preferably, the maintainer there is likely > no issue.
This doesn't make sense. If I have to trigger automatic stabilization, it isn't automatic any more. I think with an appropriate set of rules automatic stabilization would be fine. For example: - foo-2.0 has been in ~arch for 30 days - there are no open bugs against foo-2.0 - an older version of foo is stable - all of the dependencies of foo-2.0 are stable If those conditions are met, in theory there shouldn't be any problem with stabilizing foo-2.0. If foo-2.0 is not a stabilization candidate, there probably should be an open bug in bugzilla stating why it isn't. Thanks, William
signature.asc
Description: Digital signature
