[gentoo-project] Call for agenda items - Council meeting 2018-12-09

[gentoo-project] Call for agenda items - Council meeting 2018-12-09

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2018-12-09

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Sun, Nov 25, 2018 at 02:31:50PM +0200, 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.

I would like to discuss the addition of an AUTHORS file to the portage
repository [1].

As shown in the link, I propose that this file be opt-in. This means it
would be extremely low overhead to maintain. Any organization or
individual with contributions in the tree who wishes to be listed would
request it by any of the normal channels.

This is needed for the simplified copyright notice in the tree.

The discussion on the link of the CLA and contributors files is not
relevant to us, so ignore that part of it.

William

[1] https://opensource.google.com/docs/releasing/authors/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2018-12-09

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Fri, Nov 30, 2018 at 11:17 AM William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Nov 25, 2018 at 02:31:50PM +0200, 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.
>
> I would like to discuss the addition of an AUTHORS file to the portage
> repository [1].
>
> As shown in the link, I propose that this file be opt-in. This means it
> would be extremely low overhead to maintain. Any organization or
> individual with contributions in the tree who wishes to be listed would
> request it by any of the normal channels.
>
> This is needed for the simplified copyright notice in the tree.
>

Just for 100% clarity here.

If we adopt this AUTHORS proposal, employees of SEI can use simplified
copyright notices?

-A


>
> The discussion on the link of the CLA and contributors files is not
> relevant to us, so ignore that part of it.
>
> William
>
> [1] https://opensource.google.com/docs/releasing/authors/
>

[-- Attachment #2: Type: text/html, Size: 1992 bytes --]

[gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Mikle Kolyada]

[-- Attachment #1.1: Type: text/plain, Size: 824 bytes --]


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


13.0 profiles removal, 17,0 set was added a year ago, and even arm has
been migrated successfully.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[grozin]

On Sat, 1 Dec 2018, Mikle Kolyada wrote:
> 13.0 profiles removal, 17,0 set was added a year ago, and even arm has
> been migrated successfully.
dev-lisp/clozurecl is broken in 17.0. On ~x86 compiling it loops forever. 
I heard that on ~amd64 it compiles but the resulting binary is broken: it 
fails to compile maxima. The upstream says that this is related to Gentoo 
specific compilation options, and they recommend to use the upstream 
options. In 13.0 clozurecl works fine.

I think those who introduced 17.0 should fix what they have broken. I use 
13.0, and cannot switch so far.

Andrey Grozin

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

On Sun, 2018-12-02 at 16:30 +0700, grozin@gentoo.org wrote:
> On Sat, 1 Dec 2018, Mikle Kolyada wrote:
> > 13.0 profiles removal, 17,0 set was added a year ago, and even arm has
> > been migrated successfully.
> 
> dev-lisp/clozurecl is broken in 17.0. On ~x86 compiling it loops forever. 
> I heard that on ~amd64 it compiles but the resulting binary is broken: it 
> fails to compile maxima. The upstream says that this is related to Gentoo 
> specific compilation options, and they recommend to use the upstream 
> options. In 13.0 clozurecl works fine.
> 
> I think those who introduced 17.0 should fix what they have broken. I use 
> 13.0, and cannot switch so far.
> 

I think that if there's one package that doesn't work with profiles
(compared to the very large number of packages which just work fine),
it's not the profiles but the package being broken (read: doing silly
assumptions).  Therefore, it's not 17.0 profiles being the problem but
the package in question.

Claiming that people doing any change to Gentoo are required to fix all
the problematic packages is just silly.  This is basically saying that
it's fine to add bad quality packages and then demand others to fix them
for you.  People who worked on the profile can fix bugs in the profile. 
 Don't expect them to pursue whatever broken packages you like just
because they happened to change the fragile conditions under which they
worked.

That said, if you insist I'll fix this package.  But I'm pretty sure you
won't like my fix.

Disclaimer: I haven't took part in introducing 17.0 profiles.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Sun, 2018-12-02 at 16:30 +0700, grozin@gentoo.org wrote:
> On Sat, 1 Dec 2018, Mikle Kolyada wrote:
> > 13.0 profiles removal, 17,0 set was added a year ago, and even arm has
> > been migrated successfully.
> 
> dev-lisp/clozurecl is broken in 17.0. On ~x86 compiling it loops forever. 
> I heard that on ~amd64 it compiles but the resulting binary is broken: it 
> fails to compile maxima. The upstream says that this is related to Gentoo 
> specific compilation options, and they recommend to use the upstream 
> options. In 13.0 clozurecl works fine.
> 
> I think those who introduced 17.0 should fix what they have broken. I use 
> 13.0, and cannot switch so far.
> 

Also, could you please kindly point the relevant bug reports to us? 
Because I don't see a single bug report saying that clozurecl fails to
compile, and the bug report about maxima doesn't even CC the clozurecl
maintainer.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

> 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:

1. The council approves all architectures that are maintained as stable
architectures.
 - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2838 bytes --]

On 04/12/18 00:16, 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:
>
> 1. The council approves all architectures that are maintained as stable
> architectures.
>  - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
>
> 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
By all means correct me if I'm wrong, but my understanding was that a
stable *arch* meant that there was a consistent dependency tree, and this
was maintained to ensure there was some integrity to that arch's packages.
It had/has nothing to do with security-supported which was another separate
classification entirely.

I see merit in simplifying the categorisation of arch package sets, but I'm
not sure this particular change/proposal will serve much of a purpose,
other than further reinforcing that amd64 is the only arch that Gentoo
officially supports; and sets the wheels in motion for eventual bitrot of
anything else, streamlining the way for deprecation and treecleaning
anything which is not relevant for amd64 arch.
Please clarify that this is not, and will not be the case with this
policy/proposal.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]

On Tue, Dec 04, 2018 at 12:39:07AM +0000, M. J. Everitt wrote:
> On 04/12/18 00:16, 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:
> >
> > 1. The council approves all architectures that are maintained as stable
> > architectures.
> >  - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> >
> > 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
> By all means correct me if I'm wrong, but my understanding was that a
> stable *arch* meant that there was a consistent dependency tree, and this
> was maintained to ensure there was some integrity to that arch's packages.

Correct.  Which directly correlates to how the security team and
maintainers are able to proceed with security related matters. Very
simply put:

Vulnerability Identified->Package patched/bumped->Stabilization
occurs->Vulnerable package (read... ebuild) is removed->GLSA issued if
required->Bug closed.

> It had/has nothing to do with security-supported which was another separate
> classification entirely.
> 

Correct. Historically, it has been treated separately, but due to the
previous statement above it is quite interdependent.

> I see merit in simplifying the categorisation of arch package sets, but I'm
> not sure this particular change/proposal will serve much of a purpose,
> other than further reinforcing that amd64 is the only arch that Gentoo
> officially supports; and sets the wheels in motion for eventual bitrot of

Our intent is not bitrot of any arch. Many "alt-arches"
(uncommon/exotic... pick a description) keep up just fine... if not
exceed more common arches.

> anything else, streamlining the way for deprecation and treecleaning
> anything which is not relevant for amd64 arch.
> Please clarify that this is not, and will not be the case with this
> policy/proposal.
>

This is *not* the case and will never be the case for this proposal.  I
don't believe anyone would vote/recommend such a thing if an arch is
capable of being supported.

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

On Mon, 2018-12-03 at 19:16 -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:
> 
> 1. The council approves all architectures that are maintained as stable
> architectures.
>  - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> 
> Conversely, the council also may remove/drop such architectures as
> needed (c.f. item 2).

What happens if Council votes 'no' to this item?  Do all arches become
unstable?

Don't introduce votes for confirming status quo because they make no
sense.  If there's a specific change you're proposing, propose it
and be specific so that people can discuss it ahead of time.

> 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.
> 

Are you asking the Council to make a policy for security team,
or to override the existing policy of security team?  Because this
sounds like you're implying that security team can't make up their mind.

Also, if the Council votes 'yes', what happens next?  Does security
accept all stable arches?  Do stable arches get demoted implicitly based
on security project considerations?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Kristian Fiskerstrand]

On 12/4/18 4:41 AM, Michał Górny wrote:
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team?  Because this
> sounds like you're implying that security team can't make up their mind.

This is indeed part of the ongoing discussion surrounding the GLEP for
the security team; Before anything should go to council on this we need
to put the the current draft up for a public discussion on the -project
mailing list.

> 
> Also, if the Council votes 'yes', what happens next?  Does security
> accept all stable arches?  Do stable arches get demoted implicitly based
> on security project considerations?

The assumption would be that security needs to have a say for whenever
an arch is added or if requesting to remove an arch. To balance this a a
GLEP48-style/QA-style lead approval process is added and criteria to be
used for such determination is included.

Personally I don't see a problem with the status quo where security
supported arches is listed as part of security project's documentation,
and removals announced etc. The actual security implication for a lot of
these arches will anyways be impacted by members of the team having
limited knowledge of particulars, in particular when it come to auditing
due to difference in assembly etc, so the major arches will anyways have
a better foundation for being handled by the team, so security is
relative to what we claim to know and do.

In any case, too early for the council to do anything here.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]

Ühel kenal päeval, T, 04.12.2018 kell 10:54, kirjutas Kristian
Fiskerstrand:
> On 12/4/18 4:41 AM, Michał Górny wrote:
> > Are you asking the Council to make a policy for security team,
> > or to override the existing policy of security team?  Because this
> > sounds like you're implying that security team can't make up their
> > mind.
> 
> This is indeed part of the ongoing discussion surrounding the GLEP
> for
> the security team; Before anything should go to council on this we
> need
> to put the the current draft up for a public discussion on the
> -project
> mailing list.
> 
> > 
> > Also, if the Council votes 'yes', what happens next?  Does security
> > accept all stable arches?  Do stable arches get demoted implicitly
> > based
> > on security project considerations?
> 
> The assumption would be that security needs to have a say for
> whenever
> an arch is added or if requesting to remove an arch. To balance this
> a a
> GLEP48-style/QA-style lead approval process is added and criteria to
> be
> used for such determination is included.
> 
> Personally I don't see a problem with the status quo where security
> supported arches is listed as part of security project's
> documentation,
> and removals announced etc. The actual security implication for a lot
> of
> these arches will anyways be impacted by members of the team having
> limited knowledge of particulars, in particular when it come to
> auditing
> due to difference in assembly etc, so the major arches will anyways
> have
> a better foundation for being handled by the team, so security is
> relative to what we claim to know and do.
> 
> In any case, too early for the council to do anything here.

Given this subthread and the points about GLEP, I'm not sure how we can
discuss these things without even having seen the security GLEP update
proposal yet. Thus I will not add these items to the agenda (we can
also call them proposed over a day late, if you want), but rather
explicitly bring out the open bug about the GLEP update, as it keeps
getting delayed from meeting to meeting. Hopefully this (and it being a
prerequisite for the "rejected" agenda items) brings more attention to
it and at least something becomes ready and appears to the public.

That said, I would very much welcome b-man with this topic to the open
floor.


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

On Tue, Dec 04, 2018 at 04:41:32AM +0100, Michał Górny wrote:
> On Mon, 2018-12-03 at 19:16 -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:
> > 
> > 1. The council approves all architectures that are maintained as stable
> > architectures.
> >  - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86.
> > 
> > Conversely, the council also may remove/drop such architectures as
> > needed (c.f. item 2).
> 
> What happens if Council votes 'no' to this item?  Do all arches become
> unstable?
>

Of course not, that would be silly. I suppose better wording would have
been something like:

"The council will begin approving the addition and removal of all
architectures considered stable. Upon approval of this item, all
current stable architectures will remain."

> Don't introduce votes for confirming status quo because they make no
> sense.  If there's a specific change you're proposing, propose it
> and be specific so that people can discuss it ahead of time.
>

Ugh... status quo? I am not sure how this is status quo...

> > 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.
> > 
> 
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team?  Because this
> sounds like you're implying that security team can't make up their mind.
>

Absolutely, but we have the GLEP draft in the open now. So, here we go.

> Also, if the Council votes 'yes', what happens next?  Does security
> accept all stable arches?  Do stable arches get demoted implicitly based
> on security project considerations?
>

Yes, we would accept all stable arches as security supported. 

No, security would simply petition the council should an arch need to be
removed from stable.

> -- 
> Best regards,
> Michał Górny



-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09

[Sergei Trofimovich]

On Mon, 3 Dec 2018 19:16:04 -0500
Aaron Bauman <bman@gentoo.org> 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

Re: [gentoo-project] Call for agenda items - Council meeting 2018-12-09

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

On Fri, Nov 30, 2018 at 11:24:24AM -0500, Alec Warner wrote:
> On Fri, Nov 30, 2018 at 11:17 AM William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Sun, Nov 25, 2018 at 02:31:50PM +0200, 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.
> >
> > I would like to discuss the addition of an AUTHORS file to the portage
> > repository [1].
> >
> > As shown in the link, I propose that this file be opt-in. This means it
> > would be extremely low overhead to maintain. Any organization or
> > individual with contributions in the tree who wishes to be listed would
> > request it by any of the normal channels.
> >
> > This is needed for the simplified copyright notice in the tree.
> >
> 
> Just for 100% clarity here.
> 
> If we adopt this AUTHORS proposal, employees of SEI can use simplified
> copyright notices?

The answer I received to this question is Yes.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]