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 83941138334 for ; Tue, 4 Dec 2018 22:51:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E5F7E0DC6; Tue, 4 Dec 2018 22:51:29 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0614AE0DC4 for ; Tue, 4 Dec 2018 22:51:28 +0000 (UTC) Received: from sf (trofi-1-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 5F8AB335C7B for ; Tue, 4 Dec 2018 22:51:26 +0000 (UTC) Date: Tue, 4 Dec 2018 22:51:18 +0000 From: Sergei Trofimovich To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09 Message-ID: <20181204225118.5c84778f@sf> In-Reply-To: <20181204001604.GK16376@monkey> References: <1543149110.17973.1.camel@gentoo.org> <2a393e89-3156-9666-de46-2faf2fd1f7e3@gentoo.org> <20181204001604.GK16376@monkey> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: f581bb6b-1917-4d62-b6f5-3f7819fde037 X-Archives-Hash: ad944de7d32002e89ba0f6ea96ae2473 On Mon, 3 Dec 2018 19:16:04 -0500 Aaron Bauman wrote: > > On 25.11.2018 15:31, Mart Raudsepp wrote: > > > In two weeks from now, there will be a council meeting again. Now is > > > the time to raise and prepare agenda items that you want us to discuss > > > and/or vote upon. > > > > > > Please respond to this message on the gentoo-project mailing list with > > > agenda items. > > > The final agenda will be sent out on 2018-12-02, so please make sure > > > you post any agenda items before that, or we may not be able to > > > accommodate it into the next meeting. > > > > > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the > > > #gentoo-council FreeNode IRC channel. > > > > > > > > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19 > > > > > > > > > Thanks, > > > Mart Raudsepp > > I would like to propose, once again, that the council vote on the > following items: If it's not the first instance can you link to previous discussion of the problem? > 1. The council approves all architectures that are maintained as stable > architectures. > - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86. What is the definition of "maintained as stable architectures" in this context? I don't think Gentoo defines those today. The ones that have at least one stable profile in profiles.desc? "Security Project Structure" defines it in even more vague terms: 'the ebuilds in the Gentoo official ebuild repository marked as "stable"' Or you plan to introduce/maintain a separate list of stable arches? > Conversely, the council also may remove/drop such architectures as > needed (c.f. item 2). > > 2. The council approves that all stable architectures are subsequently > determined to be security supported. Thus, an architecture may not be > stable and *not* security supported. This disparity has implications in > processes and timeliness of actions taken to mitigate vulnerabilities > reported. > - e.g. amd64 is approved as stable arch and thus is security supported. > - e.g. arm is dropped as a stable arch thus is no longer security supported. > > Overall, both of these items will provide a much clearer understanding > of how security is able to proceed with mitigating vulnerabilities in > the tree, how users view and understand what architectures are stable > and security supported, and allow the security team and maintainers a > clearer/cleaner process to follow. > > Standing by to answer RFI's. > > -- > Cheers, > Aaron -- Sergei