[gentoo-project] Items for Council Agenda, May 14

[gentoo-project] Items for Council Agenda, May 14

[Anthony G. Basile]

Hi everyone,

The Gentoo Council will be meeting in two weeks.  If anyone has any
issues we need to discuss, please let me know and I'll put it on the
agenda.  Thanks.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Items for Council Agenda, May 14

[Andreas K. Huettel]

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

Am Samstag, 29. April 2017, 19:00:34 CEST schrieb Anthony G. Basile:
> Hi everyone,
> 
> The Gentoo Council will be meeting in two weeks.  If anyone has any
> issues we need to discuss, please let me know and I'll put it on the
> agenda.  Thanks.

Guidelines for the council summaries

This is the result of reading (and improving) way too many horrible old 
council summaries [*]. I see it as recommendation for best practices, not 
really something we need a written-and-stamped-approved policy for. Anyway we 
should maybe talk about it once.

1] Anything that was decided by the council outside the logged council meeting 
within the last month (e.g. a vote on a bug) needs to be added to the summary 
with reference to the source. 

2] A link to the meeting agenda on archives.gentoo.org should be included in 
the log and/or summary.

3] Agendas and similar documents should be posted to the mailing list(s) as 
part of the main e-mail body, not as attachment (since the attachments are not 
shown on archives.gentoo.org).

4] Referenced documents (e.g. policy drafts available in somebody's devspace 
or on a pastebin) should be included in the log and/or summary (at the end). 
The only exception is texts available on archives.gentoo.org, in our VCSs or 
on our bugzilla.

5] If there was a formal vote, the summary should list voting results (x yes, 
y no, ...) and the exact wording that was voted on.

Anything else?

Cheers, Andreas

[*] http://dev.gentoo.org/~dilfridge/decisions.html  (work in progress)

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Daniel Campbell]

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

On 04/30/2017 06:52 AM, Andreas K. Huettel wrote:
> Am Samstag, 29. April 2017, 19:00:34 CEST schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> The Gentoo Council will be meeting in two weeks.  If anyone has any
>> issues we need to discuss, please let me know and I'll put it on the
>> agenda.  Thanks.
> 
> Guidelines for the council summaries
> 
> This is the result of reading (and improving) way too many horrible old 
> council summaries [*]. I see it as recommendation for best practices, not 
> really something we need a written-and-stamped-approved policy for. Anyway we 
> should maybe talk about it once.
> 
> 1] Anything that was decided by the council outside the logged council meeting 
> within the last month (e.g. a vote on a bug) needs to be added to the summary 
> with reference to the source. 
> 
> 2] A link to the meeting agenda on archives.gentoo.org should be included in 
> the log and/or summary.
> 
> 3] Agendas and similar documents should be posted to the mailing list(s) as 
> part of the main e-mail body, not as attachment (since the attachments are not 
> shown on archives.gentoo.org).
> 
> 4] Referenced documents (e.g. policy drafts available in somebody's devspace 
> or on a pastebin) should be included in the log and/or summary (at the end). 
> The only exception is texts available on archives.gentoo.org, in our VCSs or 
> on our bugzilla.
> 
> 5] If there was a formal vote, the summary should list voting results (x yes, 
> y no, ...) and the exact wording that was voted on.
> 
> Anything else?
> 
> Cheers, Andreas
> 
> [*] http://dev.gentoo.org/~dilfridge/decisions.html  (work in progress)
> 
This all sounds fantastic to me. It brings documentation to the
forefront, so if it's wrong we can correct or otherwise work on it. It
makes some council decisions easier for others (i.e. outsiders, new
Gentoo users/devs) to follow what's going on as well. I agree that
perhaps requiring it would be a bit too much, at least until we find
lazier ways to do it, but it can't hurt to start talking about it.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

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

Am Samstag, 29. April 2017, 19:00:34 CEST schrieb Anthony G. Basile:
> Hi everyone,
> 
> The Gentoo Council will be meeting in two weeks.  If anyone has any
> issues we need to discuss, please let me know and I'll put it on the
> agenda.  Thanks.

I've converted the arches.desc proposal into a GLEP, taking (some of) the 
mailing list comments into account.

https://wiki.gentoo.org/wiki/GLEP:72
https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72

(the texts are identical at the moment, but if there are additional comments I 
can more easily adapt the version in my user space).

I would like the council to talk about it and potentially give it a go-ahead. 

An implementation is still missing though.

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Michał Górny]

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

On sob, 2017-05-06 at 16:34 +0200, Andreas K. Huettel wrote:
> Am Samstag, 29. April 2017, 19:00:34 CEST schrieb Anthony G. Basile:
> > Hi everyone,
> > 
> > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > issues we need to discuss, please let me know and I'll put it on the
> > agenda.  Thanks.
> 
> I've converted the arches.desc proposal into a GLEP, taking (some of) the 
> mailing list comments into account.
> 
> https://wiki.gentoo.org/wiki/GLEP:72
> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
> 
> (the texts are identical at the moment, but if there are additional comments I 
> can more easily adapt the version in my user space).
> 
> I would like the council to talk about it and potentially give it a go-ahead. 
> 
> An implementation is still missing though.
> 

...and a rationale section to describe why you did the things this way.

Few notes:

1. I think your example is a bit misleading -- unless I'm missing
something, mips would be 'unstable' right now, and m68k would be
'testing'.

2. I can't say I like using magical keywords like 'testing'
and 'unstable'; they're going to be confusing long-term (compare:
the mess with stable/exp/dev for profiles). But I don't have a very good
idea how to it better right now.

3. What is the use case for 'broken'? Are we ever going to use that?

Plus, you have a few typos, you need to wikify it and other minor blah
blah.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

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

Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny:
>
> > An implementation is still missing though.
> 
> ...and a rationale section to describe why you did the things this way.

Well, that's more or less the Motivation section. Should I rename it?

> 1. I think your example is a bit misleading -- unless I'm missing
> something, mips would be 'unstable' right now, and m68k would be
> 'testing'.

Right. Fixed. 

> 2. I can't say I like using magical keywords like 'testing'
> and 'unstable'; they're going to be confusing long-term (compare:
> the mess with stable/exp/dev for profiles). But I don't have a very good
> idea how to it better right now.

Well, I pulled the two terms that are tradidionally used for ~arch... 
"testing" and "unstable". Testing implied to me that a transition is taking 
place, so that went to the "mixed state". 

There's also Kent's proposal where some more indirection is introduced (see 
the discussion threads). It more or less achives the same with even more 
flexibility. I dont like it so much because I want to keep things simple.

> 3. What is the use case for 'broken'? Are we ever going to use that?

None that I know of. I only added it because it was suggested on the list (and 
because it's simple to define and implement).

> 
> Plus, you have a few typos, you need to wikify it and other minor blah
> blah.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Michał Górny]

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

On sob, 2017-05-06 at 19:36 +0200, Andreas K. Huettel wrote:
> Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny:
> > 
> > > An implementation is still missing though.
> > 
> > ...and a rationale section to describe why you did the things this way.
> 
> Well, that's more or less the Motivation section. Should I rename it?

No. Motivation answers the question 'what is the problem being solved?',
and in your case it serves that purpose well. Rationale is 'why did I
choose this specific solution?' -- e.g. choice of file format, keywords
and basically answers to every useful question that has been raised.

> > 2. I can't say I like using magical keywords like 'testing'
> > and 'unstable'; they're going to be confusing long-term (compare:
> > the mess with stable/exp/dev for profiles). But I don't have a very good
> > idea how to it better right now.
> 
> Well, I pulled the two terms that are tradidionally used for ~arch... 
> "testing" and "unstable". Testing implied to me that a transition is taking 
> place, so that went to the "mixed state". 

I should point out that those terms are frequently used interchangeably,
and adding disjoint meanings to them is least misleading. Perhaps a name
like 'transitional' for the middle state would be better?

> There's also Kent's proposal where some more indirection is introduced (see 
> the discussion threads). It more or less achives the same with even more 
> flexibility. I dont like it so much because I want to keep things simple.

Yes, we don't need yet another python.eclass.

> > 3. What is the use case for 'broken'? Are we ever going to use that?
> 
> None that I know of. I only added it because it was suggested on the list (and 
> because it's simple to define and implement).

Well, I was mostly asking because:

a. without that, there would be no reason to repeat that dev/exp repoman
magic in all three definitions,

b. I fail to see any reason to have stable/exp/dev profile split for
arch where even the most basic package integrity is not guaranteed. It's
like having repoman check the profiles for nothing...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Kent Fredric]

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

On Sat, 06 May 2017 22:23:01 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > 
> > Well, I pulled the two terms that are tradidionally used for ~arch... 
> > "testing" and "unstable". Testing implied to me that a transition is taking 
> > place, so that went to the "mixed state".   
> 
> I should point out that those terms are frequently used interchangeably,
> and adding disjoint meanings to them is least misleading. Perhaps a name
> like 'transitional' for the middle state would be better?

If I was to compromise, I think:

[ 'strict', 'transitional', 'loose', 'ignore' ]

Would be slightly more descriptive for arches.desc than

[ 'stable', 'testing', 'unstable', 'broken' ]


Though, granted, the description here for "Unstable" I find confusing
as-is.


<< 

unstable

When a profile of an architecture is tested, then repoman treats "arch"
as an error and aborts. Consistency is only tested for "~arch".

>>

I find that a bit weird, and at odds with what I thought this was being
developed for, as I had the impression that "arch" was "EDONTCARE" for
"unstable".

And so I'd expected the descriptive behaviour to be more like "testing".

As is, that description would currently create significant discouragement
for people to test arches with that flag at all, due to the prevalence
of intermixed "arch" and "~arch" in those dists.


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

Re: arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Roy Bamford]

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

On 2017.05.06 15:34, Andreas K. Huettel wrote:
> Am Samstag, 29. April 2017, 19:00:34 CEST schrieb Anthony G. Basile:
> > Hi everyone,
> > 
> > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > issues we need to discuss, please let me know and I'll put it on the
> > agenda.  Thanks.
> 
> I've converted the arches.desc proposal into a GLEP, taking (some of)
> the 
> mailing list comments into account.
> 
> https://wiki.gentoo.org/wiki/GLEP:72
> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
> 
> (the texts are identical at the moment, but if there are additional
> comments I 
> can more easily adapt the version in my user space).
> 
> I would like the council to talk about it and potentially give it a
> go-ahead. 
> 
> An implementation is still missing though.
> 
> Cheers, 
> Andreas
> 
> -- 
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)
> 


Andreas,

First off I like the intent.  I think it will be useful, especially for arm64
which interests me.

I don't like the reuse of terms like stable, testing, and so on but
I'm not first to point that out.
It appears that the purpose of  arches.desc is to ease the pain
of transitions between ARCH, ~ARCH and even wilder states.
Names describing these transitions may things clearer to human 
readers.

I can see downsides to that too because trasitions will be in both 
directions. e.g. arm64 is heading toward stable from the unknown, 
and x86 will soon be going in the other direction.  

A few nits.  
Initial value in the gentoo repository,
On introduction, the setting will be "stable" for all stable architectures, "testing" for all architectures where "inofficial"
"inofficial" ->  "unofficial"

Meaning of the values for repoman
... 
This is the current behaviour and shall be the default if nothing is specified for an architecture.
This is the current behaviour and shall be the default if nothing is specified in arches.desc for an architecture.


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Michał Górny]

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

On sob, 2017-05-06 at 19:36 +0200, Andreas K. Huettel wrote:
> Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny:
> > 
> > 2. I can't say I like using magical keywords like 'testing'
> > and 'unstable'; they're going to be confusing long-term (compare:
> > the mess with stable/exp/dev for profiles). But I don't have a very good
> > idea how to it better right now.
> 
> Well, I pulled the two terms that are tradidionally used for ~arch... 
> "testing" and "unstable". Testing implied to me that a transition is taking 
> place, so that went to the "mixed state". 
> 

Oh, one more thing that I've forgot to mention in the original mail.
It'd probably be useful to solve two disjoint problems:

a. whether CI should enforce correct depgraph and how,

b. whether we should request stabilizing packages.

i.e. we need to be able to express differently the two possible
scenarios:

1. stable depgraph is broken but we want to fix it (i.e. should CC
the arch on stablereqs),

2. stable depgraph is broken and we don't care (i.e. we don't CC
the arch and drop old stable versions if necessary).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

Am Sonntag, 7. Mai 2017, 22:30:51 CEST schrieb Michał Górny:
> 
> Oh, one more thing that I've forgot to mention in the original mail.
> It'd probably be useful to solve two disjoint problems:
> 
> a. whether CI should enforce correct depgraph and how,
> 

Well, my approach for this would be that CI should enforce the same things as 
Repoman.

Which means
* stable: CI enforces separate deptrees for arch and ~arch
* (testing, now) mixed: CI enforces deptree for ~arch (treating arch as ~arch)
* unstable: CI enforces deptree for ~arch, CI errors on encountering arch

> 
> 2. stable depgraph is broken and we don't care (i.e. we don't CC
> the arch and drop old stable versions if necessary).

Keep the arch on "mixed", or drop all stable keywords in one commit and then 
set it to "unstable".


>
> b. whether we should request stabilizing packages.
> 
> 
> 1. stable depgraph is broken but we want to fix it (i.e. should CC
> the arch on stablereqs),

Well... so far my approach would have been, 
* keep arch (testing) mixed, until the arch team says "good to go", 
* then make hard switch to stable, and start with stablerequests

We could, however, add one more column *only* for the (testing) mixed case, 
which states whether stabilization requests are required.

(Only for the mixed case, since for "stable" this is always yes, and for 
"unstable" it makes no sense.)




-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-project] Items for Council Agenda, May 14

[Matthias Maier]

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

Hello all,

On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <blueness@gentoo.org> wrote:

> Hi everyone,
>
> The Gentoo Council will be meeting in two weeks.  If anyone has any
> issues we need to discuss, please let me know and I'll put it on the
> agenda.  Thanks.

I would like to make a last minute proposal.

Proposal:

  I ask the council to establish a procedure / team to moderate the
  gentoo-project@ and gentoo-dev@ mailing lists:

   - In general the amount of moderation shall as minimal as possible
     (in particular developers and long-time contributors
     unconditionally green-lighted), 
   - but for non-developers abusing the mailing lists for their own
     agenda their contributions shall be moderated.
   - Similar to irc operators there shall be a decicated moderator team
     to ensure a quick and timely response.
   - The moderator team shall be different from council members, and
     ideally also comrel, such that these groups can act as a check and
     balance.

Rationale:

  The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
  an important role for Gentoo development (e.g. mandatory announcement,
  RFCs, PATCH reviews). This function is currently severly impeded due
  to the high level of noise and unrelated personal agenda [1].

Best,
Matthias

[1] https://archives.gentoo.org/gentoo-project/

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

Re: [gentoo-project] Items for Council Agenda, May 14

[NP-Hardass]

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

On 05/11/2017 03:17 AM, Matthias Maier wrote:
> Hello all,
> 
> On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
>> Hi everyone,
>>
>> The Gentoo Council will be meeting in two weeks.  If anyone has any
>> issues we need to discuss, please let me know and I'll put it on the
>> agenda.  Thanks.
> 
> I would like to make a last minute proposal.
> 
> Proposal:
> 
>   I ask the council to establish a procedure / team to moderate the
>   gentoo-project@ and gentoo-dev@ mailing lists:
> 
>    - In general the amount of moderation shall as minimal as possible
>      (in particular developers and long-time contributors
>      unconditionally green-lighted), 
>    - but for non-developers abusing the mailing lists for their own
>      agenda their contributions shall be moderated.
>    - Similar to irc operators there shall be a decicated moderator team
>      to ensure a quick and timely response.
>    - The moderator team shall be different from council members, and
>      ideally also comrel, such that these groups can act as a check and
>      balance.
> 
> Rationale:
> 
>   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
>   an important role for Gentoo development (e.g. mandatory announcement,
>   RFCs, PATCH reviews). This function is currently severly impeded due
>   to the high level of noise and unrelated personal agenda [1].
> 
> Best,
> Matthias
> 
> [1] https://archives.gentoo.org/gentoo-project/
> 

I'm going to second the proposal.

As an aside, in considering this, I'd like a priori moderation
(whitelist+manual passthrough) to be weighed against a posteriori
moderation (automatic passthrough+reactionary blacklisting), assuming
that both are feasible with our ML system.

A priori moderation certainly reduces the amount of messages that need
to be filtered from getting through, but requires significantly more
effort from a moderation team.  Anyone not on the (semi)permanent
whitelist must be reviewed before their message gets through which might
be more effort than our moderators are willing or able to deal with.

A posteriori moderation means that the moderation team doesn't prevent
any messages from going through to begin with, reacting to messages that
are considered abusive by adding a user to a temporary (or in worst case
scenario, permanent) blacklist.  This means that an abusive user will
get some of their messages before being classified as needing moderation
through, because the moderation is reactionary. However, this
significantly reduces the moderation burden.

-- 
NP-Hardass


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

Re: [gentoo-project] Items for Council Agenda, May 14

[Michał Górny]

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

On czw, 2017-05-11 at 03:52 -0400, NP-Hardass wrote:
> On 05/11/2017 03:17 AM, Matthias Maier wrote:
> > Hello all,
> > 
> > On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <blueness@gentoo.org> wrote:
> > 
> > > Hi everyone,
> > > 
> > > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > > issues we need to discuss, please let me know and I'll put it on the
> > > agenda.  Thanks.
> > 
> > I would like to make a last minute proposal.
> > 
> > Proposal:
> > 
> >   I ask the council to establish a procedure / team to moderate the
> >   gentoo-project@ and gentoo-dev@ mailing lists:
> > 
> >    - In general the amount of moderation shall as minimal as possible
> >      (in particular developers and long-time contributors
> >      unconditionally green-lighted), 
> >    - but for non-developers abusing the mailing lists for their own
> >      agenda their contributions shall be moderated.
> >    - Similar to irc operators there shall be a decicated moderator team
> >      to ensure a quick and timely response.
> >    - The moderator team shall be different from council members, and
> >      ideally also comrel, such that these groups can act as a check and
> >      balance.
> > 
> > Rationale:
> > 
> >   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
> >   an important role for Gentoo development (e.g. mandatory announcement,
> >   RFCs, PATCH reviews). This function is currently severly impeded due
> >   to the high level of noise and unrelated personal agenda [1].
> > 
> > Best,
> > Matthias
> > 
> > [1] https://archives.gentoo.org/gentoo-project/
> > 
> 
> I'm going to second the proposal.
> 
> As an aside, in considering this, I'd like a priori moderation
> (whitelist+manual passthrough) to be weighed against a posteriori
> moderation (automatic passthrough+reactionary blacklisting), assuming
> that both are feasible with our ML system.
> 

The difference between the two is that the former causes 'every non-dev
is moderated, I guess that's fair' and the latter causes 'how dare you
restrict my freedom of speech, you bastards, I'm the most important
Gentoo developer since Daniel Robbins, you silly lives mean nothing
compared to me, you wouldn't have been born if it was not for me...!'


-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Raymond Jennings]

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

If I can throw my two cents in, I'd like to suggest, for the purposes of
whitelisting, that we consider the pros and cons of allowing a message from
X, where X is some individual.

The list of things X including, but not being limited to the following:

1.  A spambot
2.  An abusive commenter
3.  A completely new person with benign intentions
4.  A gentoo developer/staff member
5.  A gentoo user
6.  Anyone who has proven themselves benign through a history of non
abusive comments.
7.  Cases 3 through 6 where such sender's email account has been
compromised (presumably on a temporary basis) by a person of cases 1 or 2.

Preemptively blocking someone of case 3 or 5, for example, out of fear that
they may be cases 1 or 2, may be detrimental to Gentoo's openness.

I find it likely that there may be plenty of people in cases 3, 5, or 6,
who are not in case 4 and who it might cause harm to the project if they
were preemptively moderated.

In my very humble opinion, only cases 1 or 2 need dumped into the "ignore
all further postings" blacklist, and once an unknown new sender has been
vetted or proven themselves fit they should be provisionally whitelisted so
as not to burden the moderation team.

Finally I'd like to advise flexibility, both in terms of how decisions are
made and also when they are made.  Except in cases of blatant abuse or
spam, a person's helpful or harmful influence is a highly subjective
judgement that may even vary over time given the changing attitudes of the
person in question.



On Thu, May 11, 2017 at 1:02 AM, Michał Górny <mgorny@gentoo.org> wrote:

> On czw, 2017-05-11 at 03:52 -0400, NP-Hardass wrote:
> > On 05/11/2017 03:17 AM, Matthias Maier wrote:
> > > Hello all,
> > >
> > > On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <
> blueness@gentoo.org> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > > > issues we need to discuss, please let me know and I'll put it on the
> > > > agenda.  Thanks.
> > >
> > > I would like to make a last minute proposal.
> > >
> > > Proposal:
> > >
> > >   I ask the council to establish a procedure / team to moderate the
> > >   gentoo-project@ and gentoo-dev@ mailing lists:
> > >
> > >    - In general the amount of moderation shall as minimal as possible
> > >      (in particular developers and long-time contributors
> > >      unconditionally green-lighted),
> > >    - but for non-developers abusing the mailing lists for their own
> > >      agenda their contributions shall be moderated.
> > >    - Similar to irc operators there shall be a decicated moderator team
> > >      to ensure a quick and timely response.
> > >    - The moderator team shall be different from council members, and
> > >      ideally also comrel, such that these groups can act as a check and
> > >      balance.
> > >
> > > Rationale:
> > >
> > >   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
> > >   an important role for Gentoo development (e.g. mandatory
> announcement,
> > >   RFCs, PATCH reviews). This function is currently severly impeded due
> > >   to the high level of noise and unrelated personal agenda [1].
> > >
> > > Best,
> > > Matthias
> > >
> > > [1] https://archives.gentoo.org/gentoo-project/
> > >
> >
> > I'm going to second the proposal.
> >
> > As an aside, in considering this, I'd like a priori moderation
> > (whitelist+manual passthrough) to be weighed against a posteriori
> > moderation (automatic passthrough+reactionary blacklisting), assuming
> > that both are feasible with our ML system.
> >
>
> The difference between the two is that the former causes 'every non-dev
> is moderated, I guess that's fair' and the latter causes 'how dare you
> restrict my freedom of speech, you bastards, I'm the most important
> Gentoo developer since Daniel Robbins, you silly lives mean nothing
> compared to me, you wouldn't have been born if it was not for me...!'
>
>
> --
> Best regards,
> Michał Górny
>

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Kent Fredric]

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

On Thu, 11 May 2017 02:17:59 -0500
Matthias Maier <tamiko@gentoo.org> wrote:

> I would like to make a last minute proposal.

I'm +0 on the proposal, partly because I can't see it having any
measurable gain.

All these moderation processes work well in regulating well behaved
operators.

But for regulating misbehaving operators who can trivially find a new
identity to hide behind, these tools as presented so far seem a bit
toothless.

Unless this proposal suggests that all new senders are themselves,
defacto-censored.

But if we set up a system where new contributors are defacto-censored, ...
that's not really the sort of Gentoo I want to be part of.

Introducing barriers and penalties for the many to deal with the *perceived* threats
of a few just isn't worth it to me.

I despise artificial barriers that only provide a misguided sense of
utility while having negative net value.

[Analogous to security theatre]

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Rich Freeman]

On Thu, May 11, 2017 at 6:08 AM, Kent Fredric <kentnl@gentoo.org> wrote:
>
> But for regulating misbehaving operators who can trivially find a new
> identity to hide behind, these tools as presented so far seem a bit
> toothless.
>
> Unless this proposal suggests that all new senders are themselves,
> defacto-censored.
>

++

As many have pointed out, people can just get around bans by creating
new identities.  That won't be an issue for devs, but certainly it is
an issue for non-devs.

I don't really see the point in doing moderation unless it is
before-the-fact.  We'll just be playing whack-a-mole and making people
upset without actually changing anything.

Yes, doing it before the fact has both philosophical and practical
challenges.  We need to accept those and make a decision one way or
the other.  I think this is one of those cases where either decision
is better than compromise.  If we don't have the manpower to moderate
posts by non-devs then we shouldn't moderate them at all.  If we
consider it against our values then we shouldn't.

I also think we need to be consistent.  If we're going to moderate,
then do it everywhere, or at least be prepared to do it everywhere
without further debate when problems arise.  If we're not going to
moderate, then we should just embrace the results.  I think that
having more moderation on some forums than others just creates the
inevitable complaint on one forum when somebody can't post on another,
and we have no principle to fall back on.

> But if we set up a system where new contributors are defacto-censored, ...
> that's not really the sort of Gentoo I want to be part of.

Honestly, I think we'll lose people either way (and we probably have
been losing them for years with the status quo).  Certainly they'll be
different people, but there isn't really any hard data one way or the
other as to which will have the larger impact.  Trying to collect some
kind of data around preferences might help here, though I'm not sure
it will make anybody more/less happy with the outcome either way.

-- 
Rich

Re: [gentoo-project] Items for Council Agenda, May 14

[Gregory Woodbury]

On Thu, May 11, 2017 at 6:52 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, May 11, 2017 at 6:08 AM, Kent Fredric <kentnl@gentoo.org> wrote:
...
>> Unless this proposal suggests that all new senders are themselves,
>> defacto-censored.
>>
...
> Yes, doing it before the fact has both philosophical and practical
> challenges.  We need to accept those and make a decision one way or
> the other.  I think this is one of those cases where either decision
> is better than compromise.  If we don't have the manpower to moderate
> posts by non-devs then we shouldn't moderate them at all.  If we
> consider it against our values then we shouldn't.
>
...
> Honestly, I think we'll lose people either way (and we probably have
> been losing them for years with the status quo).  Certainly they'll be
> different people, but there isn't really any hard data one way or the
> other as to which will have the larger impact.  Trying to collect some
> kind of data around preferences might help here, though I'm not sure
> it will make anybody more/less happy with the outcome either way.

There are folks I know that use Gentoo but don't get involved in discussions
or as developers because of the "politics and annoyance" of the procedures
and policies that currently prevail. I occasionally present a "News from Gentoo"
mini-talk at various tech meetings in this part of NC [RTP] that filter out a
lot of chatter and focus on the technical issues; and the interest is
still quite
high by users, as Gentoo is their development platform.

If there is a perceived lack of people to do the job of moderating, I
might suggest
that insisting the moderators have to be developers may be too high a
qualification
for getting people involved. I hesitate proposing that another class
of involvement
be implemented -- that of some sort of 'certified user' of
'technician' -- but it has
been successful for some other projects.  This might expand the amount
of trust in the project, both within and without the system.
Certainly, the vetting
process should be at a lower level than the 'developer' title requires.

Finally, perhaps a "robo-moderator" system could be implemented that
would know the trusted posters (developers + others) and refer new posters
to moderators by an email alert so that there is minimal delay in looking
at the new poster's material.  This worked well on several USENET groups
for a long time. [James Levine wrote one that could be easily adapted.]

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-project] Items for Council Agenda, May 14

[Luis Ressel]

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

On Thu, 11 May 2017 02:17:59 -0500
Matthias Maier <tamiko@gentoo.org> wrote:

>   I ask the council to establish a procedure / team to moderate the
>   gentoo-project@ and gentoo-dev@ mailing lists:

I really don't see the point of this. Yes, there are a few messages on
our mailing lists that some of us don't want to see. But as long as
we're not drowning in in a tsunami of spam that practically DOSes our
infrastructure, I think we're better of letting the *readers* take care
of filtering.

All MUAs I've used so far provide filtering tools to enact policies
such as "ignore all mails by <user>", or even "ignore all threads
started by <user>" without too much effort. Why do you think this isn't
sufficient?

IMHO, if there's one problem with our MLs we should strive to solve,
it's the unfortunate tendency of technial discussions devolving into
huge bikeshedding contests that achieve nothing other than making
everyone angry.

Cheers,
Luis Ressel

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Roy Bamford]

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

On 2017.05.11 08:17, Matthias Maier wrote:
> Hello all,
> 
> On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile"
> <blueness@gentoo.org> wrote:
> 
> > Hi everyone,
> >
> > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > issues we need to discuss, please let me know and I'll put it on the
> > agenda.  Thanks.
> 
> I would like to make a last minute proposal.
> 
> Proposal:
> 
>   I ask the council to establish a procedure / team to moderate the
>   gentoo-project@ and gentoo-dev@ mailing lists:
> 
>    - In general the amount of moderation shall as minimal as possible
>      (in particular developers and long-time contributors
>      unconditionally green-lighted), 
>    - but for non-developers abusing the mailing lists for their own
>      agenda their contributions shall be moderated.
>    - Similar to irc operators there shall be a decicated moderator
> team
>      to ensure a quick and timely response.
>    - The moderator team shall be different from council members, and
>      ideally also comrel, such that these groups can act as a check
> and
>      balance.
> 
> Rationale:
> 
>   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
>   an important role for Gentoo development (e.g. mandatory
> announcement,
>   RFCs, PATCH reviews). This function is currently severly impeded due
>   to the high level of noise and unrelated personal agenda [1].
> 
> Best,
> Matthias
> 
> [1] https://archives.gentoo.org/gentoo-project/
> 

Team,

We've been there and done that, lets not do it again.
For those that want the history, read up on the Proctors procject.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Raymond Jennings]

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

On Thu, May 11, 2017 at 11:55 AM, Roy Bamford <neddyseagoon@gentoo.org>
wrote:

> On 2017.05.11 08:17, Matthias Maier wrote:
> > Hello all,
> >
> > On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile"
> > <blueness@gentoo.org> wrote:
> >
> > > Hi everyone,
> > >
> > > The Gentoo Council will be meeting in two weeks.  If anyone has any
> > > issues we need to discuss, please let me know and I'll put it on the
> > > agenda.  Thanks.
> >
> > I would like to make a last minute proposal.
> >
> > Proposal:
> >
> >   I ask the council to establish a procedure / team to moderate the
> >   gentoo-project@ and gentoo-dev@ mailing lists:
> >
> >    - In general the amount of moderation shall as minimal as possible
> >      (in particular developers and long-time contributors
> >      unconditionally green-lighted),
> >    - but for non-developers abusing the mailing lists for their own
> >      agenda their contributions shall be moderated.
> >    - Similar to irc operators there shall be a decicated moderator
> > team
> >      to ensure a quick and timely response.
> >    - The moderator team shall be different from council members, and
> >      ideally also comrel, such that these groups can act as a check
> > and
> >      balance.
> >
> > Rationale:
> >
> >   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
> >   an important role for Gentoo development (e.g. mandatory
> > announcement,
> >   RFCs, PATCH reviews). This function is currently severly impeded due
> >   to the high level of noise and unrelated personal agenda [1].
> >
> > Best,
> > Matthias
> >
> > [1] https://archives.gentoo.org/gentoo-project/
> >
>
> Team,
>
> We've been there and done that, lets not do it again.
> For those that want the history, read up on the Proctors procject.


I move that we table the actual discussion for the actual meeting.  I think
at this point we're just gathering topics FOR discussion?

Should mailing list moderation be added to the agenda or not?

I may be out of place here but it seems an involved discussion about it
would defeat the purpose of having a meeting.

At the least, wouldn't a change of subject line or list might help keep
*this* topic about the meeting itself less cluttered?

--
> Regards,
>
> Roy Bamford
> (Neddyseagoon) a member of
> elections
> gentoo-ops
> forum-mods
>

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Rich Freeman]

On Thu, May 11, 2017 at 3:09 PM, Raymond Jennings <shentino@gmail.com> wrote:
>
> I may be out of place here but it seems an involved discussion about it
> would defeat the purpose of having a meeting.

Not at all.  Usually the goal is to have the discussion on the lists,
and focus more on voting/etc in meetings.  It is a lot easier for more
people to participate in discussions on the lists.

>
> At the least, wouldn't a change of subject line or list might help keep
> *this* topic about the meeting itself less cluttered?
>

Certainly.

-- 
Rich

Re: [gentoo-project] Items for Council Agenda, May 14

[Rich Freeman]

On Thu, May 11, 2017 at 12:45 PM, Luis Ressel <aranea@aixah.de> wrote:
> On Thu, 11 May 2017 02:17:59 -0500
> Matthias Maier <tamiko@gentoo.org> wrote:
>
>>   I ask the council to establish a procedure / team to moderate the
>>   gentoo-project@ and gentoo-dev@ mailing lists:
>
> I really don't see the point of this. Yes, there are a few messages on
> our mailing lists that some of us don't want to see. But as long as
> we're not drowning in in a tsunami of spam that practically DOSes our
> infrastructure, I think we're better of letting the *readers* take care
> of filtering.
>

The obvious counterargument is that they'll take care of the filtering
by simply unsubscribing.  We don't want people to avoid us.  If
somebody looks at our list archives and see lots of flames, they may
be discouraged from participating.  If somebody posts a bug and
somebody replies saying that xyz on Gentoo is dead and that you'd be
better off on another distro, they'll probably take that advice
ensuring xyz remains dead.  Etc.

It is a bit of "we will not hide problems" vs "not hiding problems
actually causes those problems."  Suicide by social contract?

-- 
Rich

Re: [gentoo-project] Items for Council Agenda, May 14

[William L. Thomson Jr.]

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

On Thu, 11 May 2017 15:57:52 -0400
Rich Freeman <rich0@gentoo.org> wrote:
>  We don't want people to avoid us.

I myself have been there and done that. I left for many years.
Very few things if anything  improved. I was even accused of not doing
more over those years. Despite how people handicap my ability to
contribute. Which I stopped some time ago.

My recent activity on Github was simply trying to address
contributors that Gentoo Developers were ignoring...

This person ignored for 11 months. Does this guy sound happy? Did
anyone other than me reply to address his concerns?
https://github.com/gentoo/gentoo/pull/1721#issuecomment-300155991

Good reason for me to be blocked from Github right? What does that say
to that guy? I had NOTHING to do with Gentoo Devs ignoring that pull
request.

Why is this one still open? Mgorny has superior skills to my pathetic
ones. Why does he not merge that request? Why has Chewi not?
Anyone even talking to the contributor?
https://github.com/gentoo/gentoo/pull/1358

While that pull request addresses a number of Tomcat bugs. There are
still many more Tomcat related bugs people are reporting.
https://bugs.gentoo.org/buglist.cgi?quicksearch=tomcat&list_id=3530490

What about this guy? Did anyone reach out to him?
He showed in IRC as well....
http://marc.info/?l=gentoo-dev&m=149194941632740&w=2

Those are just a few and all 3 have NOTHING to do with me. That is
Gentoo Developers neglecting their own contributors. Upsetting them and
driving them away. Do you think any of them will contribute more?

I feel bad for all three.... They were not treated right!

>  If  somebody looks at our list archives and see lots of flames, they
> may be discouraged from participating.

Rarely will chaos drive someone away from a superior product and
offering. More so if one is technically superior to another. If such
does they then were not interested in the technical aspects or did not
consider them superior.

Why do I still run Gentoo after how I am treated and seen? For
technical reasons clearly not social.

>  If somebody posts a bug and  somebody replies saying that xyz on
> Gentoo is dead and that you'd be better off on another distro,
> they'll probably take that advice ensuring xyz remains dead.  Etc.

Or when the bug and/or fix for said issue goes ignored for a very long
time. It shows that the Distro is being neglected. That alone will
drive people away. Even if a package is alive, it can be dead on a
given distro.

> It is a bit of "we will not hide problems" vs "not hiding problems
> actually causes those problems."  Suicide by social contract?

People are intuitive and can see problems hidden or not.

Gentoo Developers and people within are creating FAR more problems than
anyone on the outside.... There are 3 clear examples above. Where is
the clear example of say my actions driving another away? Any evidence?

-- 
William L. Thomson Jr.

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

Re: [gentoo-project] Items for Council Agenda, May 14

[William L. Thomson Jr.]

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

On Thu, 11 May 2017 02:17:59 -0500
Matthias Maier <tamiko@gentoo.org> wrote:
>
> Proposal:
> 
>   I ask the council to establish a procedure / team to moderate the
>   gentoo-project@ and gentoo-dev@ mailing lists:

Moderation is simply a way to  suppress free speech and expression.

-- 
William L. Thomson Jr.

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Michał Górny]

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

On czw, 2017-05-11 at 15:57 -0400, Rich Freeman wrote:
> On Thu, May 11, 2017 at 12:45 PM, Luis Ressel <aranea@aixah.de> wrote:
> > On Thu, 11 May 2017 02:17:59 -0500
> > Matthias Maier <tamiko@gentoo.org> wrote:
> > 
> > >   I ask the council to establish a procedure / team to moderate the
> > >   gentoo-project@ and gentoo-dev@ mailing lists:
> > 
> > I really don't see the point of this. Yes, there are a few messages on
> > our mailing lists that some of us don't want to see. But as long as
> > we're not drowning in in a tsunami of spam that practically DOSes our
> > infrastructure, I think we're better of letting the *readers* take care
> > of filtering.
> > 
> 
> The obvious counterargument is that they'll take care of the filtering
> by simply unsubscribing.  We don't want people to avoid us.  If
> somebody looks at our list archives and see lots of flames, they may
> be discouraged from participating.  If somebody posts a bug and
> somebody replies saying that xyz on Gentoo is dead and that you'd be
> better off on another distro, they'll probably take that advice
> ensuring xyz remains dead.  Etc.
> 
> It is a bit of "we will not hide problems" vs "not hiding problems
> actually causes those problems."  Suicide by social contract?
> 

There is a fair difference between admitting a problem and spamming
the mailing lists (and other media) with someone's personal vengeance.
It is bad for Gentoo if users are relentlessly harassed by someone's
problem with Gentoo. It is even worse when Gentoo does not even attempt
to prevent that.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Daniel Campbell]

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

On 05/11/2017 12:17 AM, Matthias Maier wrote:
> Hello all,
> 
> On Sat, Apr 29, 2017, at 12:00 CDT, "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
>> Hi everyone,
>>
>> The Gentoo Council will be meeting in two weeks.  If anyone has any
>> issues we need to discuss, please let me know and I'll put it on the
>> agenda.  Thanks.
> 
> I would like to make a last minute proposal.
> 
> Proposal:
> 
>   I ask the council to establish a procedure / team to moderate the
>   gentoo-project@ and gentoo-dev@ mailing lists:
> 
>    - In general the amount of moderation shall as minimal as possible
>      (in particular developers and long-time contributors
>      unconditionally green-lighted), 
>    - but for non-developers abusing the mailing lists for their own
>      agenda their contributions shall be moderated.
>    - Similar to irc operators there shall be a decicated moderator team
>      to ensure a quick and timely response.
>    - The moderator team shall be different from council members, and
>      ideally also comrel, such that these groups can act as a check and
>      balance.
> 
> Rationale:
> 
>   The gentoo-dev@ and gentoo-project@ mailing lists nowadays serve
>   an important role for Gentoo development (e.g. mandatory announcement,
>   RFCs, PATCH reviews). This function is currently severly impeded due
>   to the high level of noise and unrelated personal agenda [1].
> 
> Best,
> Matthias
> 
> [1] https://archives.gentoo.org/gentoo-project/
> 

This proposal, while well-intentioned, will only have an effect of
chilling conversation. If that's the desired outcome, then that's fine
(and we'll get to keep the pieces of what's left), but if the leadership
of Gentoo cares about non-developers, we shouldn't be cutting them off
from one of the more open fora we operate.

At the core, whoever's moderating this will either be following the CoC
(defined and enforced by comrel), or following direct council decisions
like calling for the ban of a person on the ML. So despite attempts for
a separate balance of power, it still has to filter through comrel and
the council or any decision will be vetoed.

I think there are a handful of Gentoo developers that would greatly
enjoy this, but they're only focusing on the bad parts of interfacing
with the public. We also need to consider how this will make us look to
other communities and projects. Do we want to be among distros that
moderate and expel dissenting opinions? Do we want to project an image
that "Gentoo doesn't care or listen to outsiders"?

I'd be open to a trial -- try it out for a few months and see what
happens. I have a feeling I'll be right and activity will plummet, but
the only way to know for sure is to try it. Then nobody can argue over
it because we'll have facts to work with.

Just my 2¢.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-project] Items for Council Agenda, May 14

[Roy Bamford]

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

On 2017.05.12 00:07, Daniel Campbell wrote:
[snip]
> 
> I'd be open to a trial -- try it out for a few months and see what
> happens. I have a feeling I'll be right and activity will plummet, but
> the only way to know for sure is to try it. Then nobody can argue over
> it because we'll have facts to work with.
> 
> Just my 2¢.
> -- 
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> 

Its been tried and and was judged a failure by a past council.

The problem then was not the people who thought for a bit
and agreed with the censure. They might even have learned
from the experience. 

The lists were in far worse shape then they are today when
moderation was trialled.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Andreas K. Huettel]

Am Freitag, 12. Mai 2017, 10:52:01 CEST schrieb Roy Bamford:
> On 2017.05.12 00:07, Daniel Campbell wrote:
> [snip]
> 
> > I'd be open to a trial -- try it out for a few months and see what
> > happens. I have a feeling I'll be right and activity will plummet, but
> > the only way to know for sure is to try it. Then nobody can argue over
> > it because we'll have facts to work with.
> > 
> > Just my 2¢.
> 
> Its been tried and and was judged a failure by a past council.
> 

And the number of people who are still around from back then is not that big 
anymore.
In addition, if you are going to cite prehistory (roughly 9 years ago) here, 
let me correct you... (1)

* The proctors team was indeed considered a failure and disbanded back then; 
in my opinion that went rather idiotically, with lots of egos clashing.

* The council back then agreed that 
 -> gentoo-dev should be moderated for non-@gentoo adresses
 -> gentoo-project should be created to attract all the bikeshedding
    interpersonal flamebaits ...
Thus gentoo-project came into being. And suddenly it was so quiet on gentoo-
dev that the moderation proposal seemed unnecessary...


(1) As you know I've been reading the logs and at least part of the archived 
mail. 

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

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

Lots of improvements implemented, see
https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72

and the notes below for what was done...


Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny:
> 1. I think your example is a bit misleading -- unless I'm missing
> something, mips would be 'unstable' right now, and m68k would be
> 'testing'.

Fixed. 

> 2. I can't say I like using magical keywords like 'testing'
> and 'unstable'; they're going to be confusing long-term
> I should point out that those terms are frequently used interchangeably,
> and adding disjoint meanings to them is least misleading. Perhaps a name
> like 'transitional' for the middle state would be better?

I replaced "testing" with "mixed". So now the three values are "stable", 
"mixed", "unstable". I think that should be more clear. 

> 3. What is the use case for 'broken'? Are we ever going to use that?

I don't really know of any, so I've removed this again. 

> Rationale is 'why did I
> choose this specific solution?' -- e.g. choice of file format, keywords
> and basically answers to every useful question that has been raised.

Added, though I'm not sure it's really complete. 

> > a. whether CI should enforce correct depgraph and how,
> 
> Well, my approach for this would be that CI should enforce the same things
> as
> Repoman.

Changed the wording such that it's not repoman-specific anymore. 


> > b. whether we should request stabilizing packages.
> 
> We could, however, add one more column *only* for the (testing) mixed case,
> which states whether stabilization requests are required.

Implemented this, now we have a third column. That makes the specs a bit more 
complex, but it's probably worth it. And the third column will nearly always 
be empty.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Michał Górny]

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

On sob, 2017-05-13 at 02:03 +0200, Andreas K. Huettel wrote:
> Lots of improvements implemented, see
> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
> 
> and the notes below for what was done...
> 
> 
> Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny:
> > 1. I think your example is a bit misleading -- unless I'm missing
> > something, mips would be 'unstable' right now, and m68k would be
> > 'testing'.
> 
> Fixed. 
> 
> > 2. I can't say I like using magical keywords like 'testing'
> > and 'unstable'; they're going to be confusing long-term
> > I should point out that those terms are frequently used interchangeably,
> > and adding disjoint meanings to them is least misleading. Perhaps a name
> > like 'transitional' for the middle state would be better?
> 
> I replaced "testing" with "mixed". So now the three values are "stable", 
> "mixed", "unstable". I think that should be more clear. 
> 
> > 3. What is the use case for 'broken'? Are we ever going to use that?
> 
> I don't really know of any, so I've removed this again. 
> 
> > Rationale is 'why did I
> > choose this specific solution?' -- e.g. choice of file format, keywords
> > and basically answers to every useful question that has been raised.
> 
> Added, though I'm not sure it's really complete. 
> 
> > > a. whether CI should enforce correct depgraph and how,
> > 
> > Well, my approach for this would be that CI should enforce the same things
> > as
> > Repoman.
> 
> Changed the wording such that it's not repoman-specific anymore. 
> 
> 
> > > b. whether we should request stabilizing packages.
> > 
> > We could, however, add one more column *only* for the (testing) mixed case,
> > which states whether stabilization requests are required.
> 
> Implemented this, now we have a third column. That makes the specs a bit more 
> complex, but it's probably worth it. And the third column will nearly always 
> be empty.

Looks mostly good. Aside to some typos:

a. 'Meaning of the second column values for other tools' says that
stabilization requests on bugzilla are based on second column; I think
you should update this to account for the third column.

b. Do we need a fourth column for keyword requests? I guess not since if
we stop supporting specific ~arch, we can probably remove it completely.
 Which brings the next question....

c. What should be the behavior for arches that are not listed
in arches.desc when the file is present?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Kent Fredric]

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

On Thu, 11 May 2017 12:09:00 -0700
Raymond Jennings <shentino@gmail.com> wrote:

> I move that we table the actual discussion for the actual meeting.  I
> think at this point we're just gathering topics FOR discussion?

This is one of those cases where "what the people collectively want" is
important, so the people have to make their voices heard and
effectively make their cases for the members of the council, and then
the members of the council are suggested to factor in their own
opinions in conjunction with the general demand the users indicated
they wanted, in some retrospect.

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

Re: [gentoo-project] Items for Council Agenda, May 14

[Kent Fredric]

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

On Thu, 11 May 2017 15:57:52 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> It is a bit of "we will not hide problems" vs "not hiding problems
> actually causes those problems."  Suicide by social contract?

As an alternative approach, how easy is it to rewrite emails to inject
footer text?

Like a bog standard:

Problem with this email? Don't reply and make it worse.
Explore the alternatives:
http://someurl.gentoo.org/report?ml=gentoo-dev&msgid=12345

Where the ml/msgid parts are filled in.

That page can contain a list of options, including making a formal
complaint, but it can also help document and assist people with
avoiding seeing that email in future, including a list of instructions
for specific mail clients, pre-filled with tokens from the email
identified by the msgid.

The idea is to lower the barrier to reporting your disapproval, or
lowering the barrier to making it so you don't have to see it any more.

We could, in theory, even extend this service to allow subscribers to
add gentoo-side filtering, wherein gentoo doesn't block the offending
user, but only blocks the relay of matching messages to subscribers who
opted out.

That way you're not relying on their MUA in any way.

And that is far less "orwellian" in concept, but still has the desired
effect.

Give users the power to do what they want, as opposed to isolating
users from everyone because a subset of users didn't like them.



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

Re: [gentoo-project] Items for Council Agenda, May 14

[Daniel Campbell]

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

On 05/12/2017 03:41 AM, Andreas K. Huettel wrote:
> Am Freitag, 12. Mai 2017, 10:52:01 CEST schrieb Roy Bamford:
>> On 2017.05.12 00:07, Daniel Campbell wrote:
>> [snip]
>>
>>> I'd be open to a trial -- try it out for a few months and see what
>>> happens. I have a feeling I'll be right and activity will plummet, but
>>> the only way to know for sure is to try it. Then nobody can argue over
>>> it because we'll have facts to work with.
>>>
>>> Just my 2¢.
>>
>> Its been tried and and was judged a failure by a past council.
>>
> 
> And the number of people who are still around from back then is not that big 
> anymore.
> In addition, if you are going to cite prehistory (roughly 9 years ago) here, 
> let me correct you... (1)
> 
> * The proctors team was indeed considered a failure and disbanded back then; 
> in my opinion that went rather idiotically, with lots of egos clashing.
> 
> * The council back then agreed that 
>  -> gentoo-dev should be moderated for non-@gentoo adresses
>  -> gentoo-project should be created to attract all the bikeshedding
>     interpersonal flamebaits ...
> Thus gentoo-project came into being. And suddenly it was so quiet on gentoo-
> dev that the moderation proposal seemed unnecessary...
> 
> 
> (1) As you know I've been reading the logs and at least part of the archived 
> mail. 
> 

Thank you both for the bit of insight. If we've already tried this and
it didn't work, history suggests it will be ineffective at best.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

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

Am Samstag, 13. Mai 2017, 09:44:29 CEST schrieb Michał Górny:
> Looks mostly good. Aside to some typos:
> 
> a. 'Meaning of the second column values for other tools' says that
> stabilization requests on bugzilla are based on second column; I think
> you should update this to account for the third column.

Done (actually I just deleted the reference to bz there).

> b. Do we need a fourth column for keyword requests? I guess not since if
> we stop supporting specific ~arch, we can probably remove it completely.

We don't even have this case now. 
(Which is why I'm accumulating open m68k keyword requests...)

>  Which brings the next question....
> c. What should be the behavior for arches that are not listed
> in arches.desc when the file is present?

That's defined - stable. (see the paragraph on the meaning of second column 
stable, or the backwards compatibility.)

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-project] Items for Council Agenda, May 14

[M. J. Everitt]

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

On 13/05/17 10:26, Kent Fredric wrote:
> On Thu, 11 May 2017 15:57:52 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> It is a bit of "we will not hide problems" vs "not hiding problems
>> actually causes those problems."  Suicide by social contract?
> As an alternative approach, how easy is it to rewrite emails to inject
> footer text?
>
> Like a bog standard:
>
> Problem with this email? Don't reply and make it worse.
> Explore the alternatives:
> http://someurl.gentoo.org/report?ml=gentoo-dev&msgid=12345
>
> Where the ml/msgid parts are filled in.
>
> That page can contain a list of options, including making a formal
> complaint, but it can also help document and assist people with
> avoiding seeing that email in future, including a list of instructions
> for specific mail clients, pre-filled with tokens from the email
> identified by the msgid.
>
> The idea is to lower the barrier to reporting your disapproval, or
> lowering the barrier to making it so you don't have to see it any more.
>
> We could, in theory, even extend this service to allow subscribers to
> add gentoo-side filtering, wherein gentoo doesn't block the offending
> user, but only blocks the relay of matching messages to subscribers who
> opted out.
>
> That way you're not relying on their MUA in any way.
>
> And that is far less "orwellian" in concept, but still has the desired
> effect.
>
> Give users the power to do what they want, as opposed to isolating
> users from everyone because a subset of users didn't like them.
>
>
This should be trivial to achieve with the mailing list software .. I've
seen similar done elsewhere.

I think having a self-censorship mechanism is much better than a
draconian 'thou shalt not....' system, and like other web platforms 'out
there', can be quite effective.

Even if there ends up being an option to 'refer to moderator' I think
this is better & easier than requiring such a moderator to 'vet'
everything that is posted, or blindly black-/white-listing with no
automatic reset mechanism. Diversity and good automation should reduce
this problem quite easily.

MJE



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

Re: arches.desc & GLEP 72 (was: Re: [gentoo-project] Items for Council Agenda, May 14)

[Andreas K. Huettel]

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

Am Sonntag, 7. Mai 2017, 17:47:52 CEST schrieb Roy Bamford:
> I don't like the reuse of terms like stable, testing, and so on but
> I'm not first to point that out.

Semi-fixed...

> I can see downsides to that too because trasitions will be in both
> directions. e.g. arm64 is heading toward stable from the unknown,
> and x86 will soon be going in the other direction.

I don't understand where the downside in your opinion is.

> "testing" for all architectures where "inofficial" "inofficial" -> 
> "unofficial"

Done

> specified for an architecture. This is the current behaviour and shall be
> the default if nothing is specified in arches.desc for an architecture.

Done

https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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