From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id CFC5113888F for ; Tue, 20 Oct 2015 22:25:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75D3F21C028; Tue, 20 Oct 2015 22:25:31 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 741E4E07AE for ; Tue, 20 Oct 2015 22:25:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZofLT-00008L-OO for gentoo-dev@lists.gentoo.org; Wed, 21 Oct 2015 00:25:27 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Oct 2015 00:25:27 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Oct 2015 00:25:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: stabilization commits and atomicity Date: Tue, 20 Oct 2015 22:25:19 +0000 (UTC) Message-ID: References: <5624D22A.8030806@gentoo.org> <5625002B.2010202@gentoo.org> <5625069A.9070206@gentoo.org> <56250BFC.7070705@gentoo.org> <562524CE.2080602@gentoo.org> <56252B09.4030103@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT c9c83f3) X-Archives-Salt: b4aa0242-5de9-4c85-9904-45c021154b46 X-Archives-Hash: 581ca36d6919c9487d938087eb814201 Rich Freeman posted on Mon, 19 Oct 2015 13:52:58 -0400 as excerpted: > On Mon, Oct 19, 2015 at 1:40 PM, hasufell wrote: >> On 10/19/2015 07:37 PM, Rich Freeman wrote: >>> >>> However, stabilizing a single package really is an impactful change. >>> The fact that you're doing 100 of them at one time doesn't really >>> diminish the impact of each one. Any of them could break a system or >>> need to be reverted. >>> >>> >> Since when do we allow reverting stabilization? The package needs to be >> fixed and possibly revbumped instead. >> >> > It would really depend on the nature of the break. If it is a serious > upstream problem and no fix is available, then reverting might be the > only practical solution. It is of course not a preferred solution. Didn't a semi-minor arch (arm, AFAIK) recently revert a major lib stabilizing, as it was clearly broken on at least some arm variants, the maintainer that did it either didn't consult with the arm-arch folks or signals got crossed and he stabilized without approval, and it was caught within an hour or less, such that the quickest and most effective way to fix the breakage was to do an immediate revert, before even figuring out a more long term fix? The commit log said something like, "Not trying to be rude, but this is the quickest way to limit the damage", and within just a few days (two?), the package and several deps were stabilized by the arch team in question, properly this time, with fixes as appropriate to keep whole sub- archs from breaking as they were doing with the previous stabilization attempt. [So yes, this demonstrates the point someone made above about people actually reading these things, too. =:^) And I too have been frustrated trying to do so, but IMO this is fixing the bit that's /not/ broken, not what is. More about that in a response I'll be posting elsewhere on- thread.] -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman