1 |
On Mon, 3 Dec 2018 19:16:04 -0500 |
2 |
Aaron Bauman <bman@g.o> wrote: |
3 |
|
4 |
> > On 25.11.2018 15:31, Mart Raudsepp wrote: |
5 |
> > > In two weeks from now, there will be a council meeting again. Now is |
6 |
> > > the time to raise and prepare agenda items that you want us to discuss |
7 |
> > > and/or vote upon. |
8 |
> > > |
9 |
> > > Please respond to this message on the gentoo-project mailing list with |
10 |
> > > agenda items. |
11 |
> > > The final agenda will be sent out on 2018-12-02, so please make sure |
12 |
> > > you post any agenda items before that, or we may not be able to |
13 |
> > > accommodate it into the next meeting. |
14 |
> > > |
15 |
> > > The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the |
16 |
> > > #gentoo-council FreeNode IRC channel. |
17 |
> > > |
18 |
> > > |
19 |
> > > 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19 |
20 |
> > > |
21 |
> > > |
22 |
> > > Thanks, |
23 |
> > > Mart Raudsepp |
24 |
> |
25 |
> I would like to propose, once again, that the council vote on the |
26 |
> following items: |
27 |
|
28 |
If it's not the first instance can you link to previous discussion of |
29 |
the problem? |
30 |
|
31 |
> 1. The council approves all architectures that are maintained as stable |
32 |
> architectures. |
33 |
> - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86. |
34 |
|
35 |
What is the definition of "maintained as stable architectures" in this |
36 |
context? I don't think Gentoo defines those today. |
37 |
|
38 |
The ones that have at least one stable profile in profiles.desc? |
39 |
"Security Project Structure" defines it in even more vague terms: |
40 |
'the ebuilds in the Gentoo official ebuild repository marked as "stable"' |
41 |
|
42 |
Or you plan to introduce/maintain a separate list of stable arches? |
43 |
|
44 |
> Conversely, the council also may remove/drop such architectures as |
45 |
> needed (c.f. item 2). |
46 |
> |
47 |
> 2. The council approves that all stable architectures are subsequently |
48 |
> determined to be security supported. Thus, an architecture may not be |
49 |
> stable and *not* security supported. This disparity has implications in |
50 |
> processes and timeliness of actions taken to mitigate vulnerabilities |
51 |
> reported. |
52 |
> - e.g. amd64 is approved as stable arch and thus is security supported. |
53 |
> - e.g. arm is dropped as a stable arch thus is no longer security supported. |
54 |
> |
55 |
> Overall, both of these items will provide a much clearer understanding |
56 |
> of how security is able to proceed with mitigating vulnerabilities in |
57 |
> the tree, how users view and understand what architectures are stable |
58 |
> and security supported, and allow the security team and maintainers a |
59 |
> clearer/cleaner process to follow. |
60 |
> |
61 |
> Standing by to answer RFI's. |
62 |
> |
63 |
> -- |
64 |
> Cheers, |
65 |
> Aaron |
66 |
|
67 |
|
68 |
-- |
69 |
|
70 |
Sergei |