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 0EDE81381F3 for ; Fri, 30 Aug 2013 12:54:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9D300E096C; Fri, 30 Aug 2013 12:53:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1EFABE08DC for ; Fri, 30 Aug 2013 12:53:55 +0000 (UTC) Received: from [127.0.0.1] (SSID-MASON-SECURE-219.wireless.gmu.edu [192.5.215.219]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: creffett) by smtp.gentoo.org (Postfix) with ESMTPSA id 2896833EB3D for ; Fri, 30 Aug 2013 12:53:54 +0000 (UTC) Message-ID: <522095D2.40301@gentoo.org> Date: Fri, 30 Aug 2013 08:53:38 -0400 From: Chris Reffett User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 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 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10 References: <21020.30575.805569.383992@a1i15.kph.uni-mainz.de> <20130829153413.GB3432@shimane.bonyari.local> <1642635.ALGgL2Qxou@kailua> <52205D4A.7060709@gentoo.org> In-Reply-To: <52205D4A.7060709@gentoo.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130830-0, 08/30/2013), Outbound message X-Antivirus-Status: Clean X-Archives-Salt: 3498d8e4-e2c2-4b69-a9e0-e28ac3c42061 X-Archives-Hash: 2d78d93e1541dc1120468b0263036fd4 On 8/30/2013 4:52 AM, Sergey Popov wrote: > 29.08.2013 19:57, Andreas K. Huettel пишет: >> The braindead thing is that the GLSA is only going out after all arches have >> stabilized. >> >> Meaning, the slowest arch in practice blocks the GLSA process. >> > > We have security-supported arches list with arch teams liassons. When > they are all stabilized package, we can begin to make GLSA even if there > are other arches pending(e.g. s390/sh/m68k are NEVER considered > security-stable arches, per out docs[1]). However i think we should > reconsider this list, probably throw some arches away(and add some new, > for example arm, for which i can became security liasson). > > [1] - http://www.gentoo.org/security/en/vulnerability-policy.xml > The problem here is one of workflow. Even if we ignore security-unsupported arches, our workflow is generally bump packages -> stabilize -> clean up -> release GLSA -> close bug. The problem is that while we can skip ahead and start drafting a GLSA, we can't clean up and close the bug until the slow arches catch up on stabilizing, so they hold us up regardless. I'm all for changing the officially supported list, but I'm not sure how much good it will do us. Chris Reffett