| 1 |
On 04/12/18 00:16, Aaron Bauman wrote: |
| 2 |
>> On 25.11.2018 15:31, Mart Raudsepp wrote: |
| 3 |
>>> In two weeks from now, there will be a council meeting again. Now is |
| 4 |
>>> the time to raise and prepare agenda items that you want us to discuss |
| 5 |
>>> and/or vote upon. |
| 6 |
>>> |
| 7 |
>>> Please respond to this message on the gentoo-project mailing list with |
| 8 |
>>> agenda items. |
| 9 |
>>> The final agenda will be sent out on 2018-12-02, so please make sure |
| 10 |
>>> you post any agenda items before that, or we may not be able to |
| 11 |
>>> accommodate it into the next meeting. |
| 12 |
>>> |
| 13 |
>>> The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the |
| 14 |
>>> #gentoo-council FreeNode IRC channel. |
| 15 |
>>> |
| 16 |
>>> |
| 17 |
>>> 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19 |
| 18 |
>>> |
| 19 |
>>> |
| 20 |
>>> Thanks, |
| 21 |
>>> Mart Raudsepp |
| 22 |
> I would like to propose, once again, that the council vote on the |
| 23 |
> following items: |
| 24 |
> |
| 25 |
> 1. The council approves all architectures that are maintained as stable |
| 26 |
> architectures. |
| 27 |
> - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86. |
| 28 |
> |
| 29 |
> Conversely, the council also may remove/drop such architectures as |
| 30 |
> needed (c.f. item 2). |
| 31 |
> |
| 32 |
> 2. The council approves that all stable architectures are subsequently |
| 33 |
> determined to be security supported. Thus, an architecture may not be |
| 34 |
> stable and *not* security supported. This disparity has implications in |
| 35 |
> processes and timeliness of actions taken to mitigate vulnerabilities |
| 36 |
> reported. |
| 37 |
> - e.g. amd64 is approved as stable arch and thus is security supported. |
| 38 |
> - e.g. arm is dropped as a stable arch thus is no longer security supported. |
| 39 |
> |
| 40 |
> Overall, both of these items will provide a much clearer understanding |
| 41 |
> of how security is able to proceed with mitigating vulnerabilities in |
| 42 |
> the tree, how users view and understand what architectures are stable |
| 43 |
> and security supported, and allow the security team and maintainers a |
| 44 |
> clearer/cleaner process to follow. |
| 45 |
> |
| 46 |
> Standing by to answer RFI's. |
| 47 |
> |
| 48 |
> -- |
| 49 |
> Cheers, |
| 50 |
> Aaron |
| 51 |
By all means correct me if I'm wrong, but my understanding was that a |
| 52 |
stable *arch* meant that there was a consistent dependency tree, and this |
| 53 |
was maintained to ensure there was some integrity to that arch's packages. |
| 54 |
It had/has nothing to do with security-supported which was another separate |
| 55 |
classification entirely. |
| 56 |
|
| 57 |
I see merit in simplifying the categorisation of arch package sets, but I'm |
| 58 |
not sure this particular change/proposal will serve much of a purpose, |
| 59 |
other than further reinforcing that amd64 is the only arch that Gentoo |
| 60 |
officially supports; and sets the wheels in motion for eventual bitrot of |
| 61 |
anything else, streamlining the way for deprecation and treecleaning |
| 62 |
anything which is not relevant for amd64 arch. |
| 63 |
Please clarify that this is not, and will not be the case with this |
| 64 |
policy/proposal. |
Archives