From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3653013832E for ; Fri, 5 Aug 2016 16:11:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2119721C04D; Fri, 5 Aug 2016 16:11:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8E62F21C046 for ; Fri, 5 Aug 2016 16:11:25 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id BAC45340A38 for ; Fri, 5 Aug 2016 16:11:23 +0000 (UTC) Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 To: gentoo-project@lists.gentoo.org References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> From: Michael Orlitzky Message-ID: Date: Fri, 5 Aug 2016 12:11:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160804162443.GA7048@whubbs1.gaikai.biz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8e15c645-901b-4fc1-a964-f2ae5a866b62 X-Archives-Hash: 7db9910e399a71d81a9c39f23023533d On 08/04/2016 12:24 PM, William Hubbs wrote: > > We can allow maintainers to stabilize new versions of certain types of > packages on all arches where there is a previous version of the package stable > without filing stable requests. This would take a significant load off > of the arch teams. > > For packages that do not fit the first group, we could require stable > requests, but allow maintainers to stabilize the new versions after a > timeout (I would propose 30 days). > > What do folks think? > This is a good idea; there's a lot of low-hanging fruit here. We could write up a fairly restrictive list of exceptions and still accomplish a lot of good. For example, we've had an exception floating around for a while that says that maintainers can stabilize their own x86/amd64 packages. That's assuming they have the hardware, run a stable system themselves, and do the testing. This sounds reasonable to me -- as the maintainer, I'm likely to do a better job of testing a package than an arch tester will. For certain things like web/database servers, I'm using these things in production for weeks, and the additional build test performed by the arch team isn't going to add any new information. Can we at least agree on that exception? Let's codify it in https://bugs.gentoo.org/show_bug.cgi?id=510198 and move on from there. Assuming we go through with that exception, here's another one to consider: if a package would otherwise be stabilized ALLARCHES, then the maintainer can perform the stabilization on all arches himself under those same prior assumptions (he can test, etc). There's no point in making 8 different people test a new version of some PHP package that only changed pure PHP code. Another exception would be for maintainer-needed packages. If there's a revision that only fixes a bug, we should be able to get it stabilized and remove the old version even though there's no maintainer. I would like to add an exception for metadata changes, too, but honestly I don't trust people to use it wisely. I shouldn't have to bug the arch teams if I add a second LICENSE and revbump... maybe if this exception is worded strongly-enough it could do more good than harm. What I don't want to see is us changing the meaning of "stable" (cf. making a "D" a passing grade). We should never have maintainers doing stabilization of C programs on architectures they don't run. I'm only in favor of exceptions that speed things up without reducing the quality of the stable tree. This is met by the exceptions I've outlined above, if I really am doing more thorough testing than the arch teams, or if I have truly made a harmless metadata change. In any case, we should still have to wait a minimum of 30 days before moving a package stable (modulo security issues).