[gentoo-project] Council meeting 2021-07-11 - call for agenda items

[gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

The first council meeting of this election term will be on
Sunday 2021-07-11, 19:00 UTC in the #gentoo-council channel
on Libera Chat.

Preliminary agenda:

1. Roll call
2. Constitute the new council
   - Decide on time of meetings. The previous council had its meetings
     on the 2nd Sunday of every month at 19:00 UTC
   - Vote for continuing last council's workflow considering sending
     a call for agenda items (two weeks in advance), sending the
     agenda (one week in advance) and have the meeting focussed, i.e.
     have major discussions on the gentoo-project mailing list prior
     to the meeting
   - Appoint chairmen for this term's meetings
3. Approve GLEP 82 update [1]
4. Open bugs with council involvement [2]
5. Open floor

The agenda is still open for additional items that the council should
discuss or vote on. For agenda items, please respond to this message
on the gentoo-project mailing list.

The final agenda for the meeting will be sent on Thursday 2021-07-08.

Ulrich

[1] https://archives.gentoo.org/gentoo-dev/message/625505e15adfb532bf961076ad5f79ab
[2] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Mon, 05 Jul 2021, Ulrich Mueller wrote:

> The agenda is still open for additional items that the council should
> discuss or vote on. For agenda items, please respond to this message
> on the gentoo-project mailing list.

Replying to my own message. :)

Now that EAPI is supported by stable Portage (3.0.20-r6 went stable
on the last arch today), I would like to ask the council to deprecate
EAPI 6, both for ebuilds and for profiles.

In the past, the council had also banned EAPIs. However, that didn't
make much of a practical difference because an EAPI cannot be added
to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we
should have a rule like the following instead:
"A deprecated EAPI is considered banned when the Gentoo repository
no longer contains any ebuilds using it."

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Mon, 05 Jul 2021, Ulrich Mueller wrote:

> Now that EAPI is supported by stable Portage [...]

This should have been "EAPI 8" of course.

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Aaron Bauman]

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

On Mon, Jul 05, 2021 at 12:17:35PM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 05 Jul 2021, Ulrich Mueller wrote:
> 

<snip>

> In the past, the council had also banned EAPIs. However, that didn't
> make much of a practical difference because an EAPI cannot be added
> to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we
> should have a rule like the following instead:
> "A deprecated EAPI is considered banned when the Gentoo repository
> no longer contains any ebuilds using it."

Having the council vote to officially ban an EAPI does have
practicality. The work done by those porting ebuilds, removing old
packages, etc is hindered when other begin committing ebuilds deprecated
but not banned.

I would ask that the council continue the official motions and votes to
ban EAPI's prior to being "enforced" by tooling. This assists those doing
the work and the QA team to stop people from committing.

While it is an administrative control it does help, but a technical
solution would be preferred long term.

-Aaron


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Mon, 05 Jul 2021, Aaron Bauman wrote:

> On Mon, Jul 05, 2021 at 12:17:35PM +0200, Ulrich Mueller wrote:
>> In the past, the council had also banned EAPIs. However, that didn't
>> make much of a practical difference because an EAPI cannot be added
>> to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we
>> should have a rule like the following instead:
>> "A deprecated EAPI is considered banned when the Gentoo repository
>> no longer contains any ebuilds using it."

> Having the council vote to officially ban an EAPI does have
> practicality. The work done by those porting ebuilds, removing old
> packages, etc is hindered when other begin committing ebuilds
> deprecated but not banned.

> I would ask that the council continue the official motions and votes
> to ban EAPI's prior to being "enforced" by tooling. This assists those
> doing the work and the QA team to stop people from committing.

The point is that banning an EAPI doesn't have any noticeable effect.
For example, if you look at EAPI 0 (banned on 2016-01-10) and EAPI 4
(banned on 2018-04-08), there's neither a cusp nor any change of slope
visible for the curves plotted here:
https://www.akhuettel.de/~huettel/plots/eapi.php

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Aaron Bauman]

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

On Mon, Jul 05, 2021 at 11:42:36PM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 05 Jul 2021, Aaron Bauman wrote:
> 
> > On Mon, Jul 05, 2021 at 12:17:35PM +0200, Ulrich Mueller wrote:
> >> In the past, the council had also banned EAPIs. However, that didn't
> >> make much of a practical difference because an EAPI cannot be added
> >> to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we
> >> should have a rule like the following instead:
> >> "A deprecated EAPI is considered banned when the Gentoo repository
> >> no longer contains any ebuilds using it."
> 
> > Having the council vote to officially ban an EAPI does have
> > practicality. The work done by those porting ebuilds, removing old
> > packages, etc is hindered when other begin committing ebuilds
> > deprecated but not banned.
> 
> > I would ask that the council continue the official motions and votes
> > to ban EAPI's prior to being "enforced" by tooling. This assists those
> > doing the work and the QA team to stop people from committing.
> 
> The point is that banning an EAPI doesn't have any noticeable effect.
> For example, if you look at EAPI 0 (banned on 2016-01-10) and EAPI 4
> (banned on 2018-04-08), there's neither a cusp nor any change of slope
> visible for the curves plotted here:
> https://www.akhuettel.de/~huettel/plots/eapi.php
> 
> Ulrich

We have had the issue in the past. Taking 1 minute to vote on a ban of
an EAPI in a council meeting is a minute task and enforces the goals of
the project.

Doesn't really matter to me either way.

Cool data.

-Aaron


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Mon, 05 Jul 2021, Aaron Bauman wrote:

> On Mon, Jul 05, 2021 at 11:42:36PM +0200, Ulrich Mueller wrote:
>> The point is that banning an EAPI doesn't have any noticeable effect.
>> For example, if you look at EAPI 0 (banned on 2016-01-10) and EAPI 4
>> (banned on 2018-04-08), there's neither a cusp nor any change of slope
>> visible for the curves plotted here:
>> https://www.akhuettel.de/~huettel/plots/eapi.php

> We have had the issue in the past. Taking 1 minute to vote on a ban of
> an EAPI in a council meeting is a minute task and enforces the goals
> of the project.

But we don't actually enforce the ban. Doing so would mean adding the
EAPI to eapis-banned in layout.conf, which in turn would imply that
commits of (new or existing) ebuilds with a banned EAPI would be
rejected.

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Thomas Deutschmann]

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

On 2021-07-05 12:17, Ulrich Mueller wrote:
 > Now that EAPI is supported by stable Portage (3.0.20-r6 went stable
 > on the last arch today), I would like to ask the council to deprecate
 > EAPI 6, both for ebuilds and for profiles.

Could you please outline the consequences of that?

I mean, it's still allowed to rev bump an EAPI 6 ebuild to add an 
important patch (like fixing a security vulnerability) or fix deps, 
especially for non-maintainers without requiring ebuild to be ported to 
a non-deprecated EAPI first, right?

I.e. "just like before".

You are not talking about changing that.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Tue, 06 Jul 2021, Thomas Deutschmann wrote:

> On 2021-07-05 12:17, Ulrich Mueller wrote:
>> Now that EAPI is supported by stable Portage (3.0.20-r6 went stable
>> on the last arch today), I would like to ask the council to deprecate
>> EAPI 6, both for ebuilds and for profiles.

> Could you please outline the consequences of that?

> I mean, it's still allowed to rev bump an EAPI 6 ebuild to add an
> important patch (like fixing a security vulnerability) or fix deps, 
> especially for non-maintainers without requiring ebuild to be ported
> to a non-deprecated EAPI first, right?

> I.e. "just like before".

> You are not talking about changing that.

Deprecated means that usage of the EAPI will be discouraged, and that
QA tools (e.g. repoman) will warn about it. [1]

Ulrich

[1] https://projects.gentoo.org/council/meeting-logs/20130409-summary.txt

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Aaron Bauman]

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

On Tue, Jul 06, 2021 at 09:02:14AM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 05 Jul 2021, Aaron Bauman wrote:
> 
> > On Mon, Jul 05, 2021 at 11:42:36PM +0200, Ulrich Mueller wrote:
> >> The point is that banning an EAPI doesn't have any noticeable effect.
> >> For example, if you look at EAPI 0 (banned on 2016-01-10) and EAPI 4
> >> (banned on 2018-04-08), there's neither a cusp nor any change of slope
> >> visible for the curves plotted here:
> >> https://www.akhuettel.de/~huettel/plots/eapi.php
> 
> > We have had the issue in the past. Taking 1 minute to vote on a ban of
> > an EAPI in a council meeting is a minute task and enforces the goals
> > of the project.
> 
> But we don't actually enforce the ban. Doing so would mean adding the
> EAPI to eapis-banned in layout.conf, which in turn would imply that
> commits of (new or existing) ebuilds with a banned EAPI would be
> rejected.
> 
> Ulrich

I know we don't technically enforce the ban as there is no mechanism to
do so. It is a terrible in-between.

So, it is a formality that takes a minute to vote on. Then, if someone
should be an asshole and keep committing things that are deprecated it
can be enforced by the QA team or other developers.

I ask to keep the formality until a technical solution is in place as we
*have* had the issue before. While it is not statistically significant
it did cause undue pain for others.

-Aaron


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Tue, 06 Jul 2021, Aaron Bauman wrote:

> I know we don't technically enforce the ban as there is no mechanism to
> do so. It is a terrible in-between.

> So, it is a formality that takes a minute to vote on. Then, if someone
> should be an asshole and keep committing things that are deprecated it
> can be enforced by the QA team or other developers.

> I ask to keep the formality until a technical solution is in place as we
> *have* had the issue before. While it is not statistically significant
> it did cause undue pain for others.

Noted. Let's add "Ban EAPI 5" as an alternative motion.

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Tue, Jul 6, 2021 at 1:42 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> So, it is a formality that takes a minute to vote on. Then, if someone
> should be an asshole and keep committing things that are deprecated it
> can be enforced by the QA team or other developers.
>

++ - I think the goal here isn't to make people doing security bumps
jump through hoops.  It is more to empower QA to actually do something
when somebody introduces a new EAPI 6 package to the repo when there
are only 5 left, and not have to listen to "well, it is only
deprecated, so..."  Obviously this is a long process but we get to the
end by making steady progress...

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Michał Górny]

On Mon, 2021-07-05 at 12:17 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 05 Jul 2021, Ulrich Mueller wrote:
> 
> > The agenda is still open for additional items that the council
> > should
> > discuss or vote on. For agenda items, please respond to this message
> > on the gentoo-project mailing list.
> 
> Replying to my own message. :)
> 
> Now that EAPI is supported by stable Portage (3.0.20-r6 went stable
> on the last arch today), I would like to ask the council to deprecate
> EAPI 6, both for ebuilds and for profiles.
> 
> In the past, the council had also banned EAPIs. However, that didn't
> make much of a practical difference because an EAPI cannot be added
> to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we
> should have a rule like the following instead:
> "A deprecated EAPI is considered banned when the Gentoo repository
> no longer contains any ebuilds using it."

While I understand your point, I agree with others that there is a value
in having a non-technically-enforced ban, i.e. keeping the overall
process as:

1) deprecate the EAPI (i.e. "please avoid using this EAPI"),

2) formally ban the EAPI (i.e. "do not use it in new ebuilds, unless you
have
a really good reason to"),

3) entirely ban the EAPI (i.e. technically prevent ebuilds with it).

I agree that technically 2) doesn't change much but I'd prefer if we
could avoid "EAPI n is only deprecated, so it's fine to still use it!"
argument.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Mon, Jul 5, 2021 at 5:20 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> The agenda is still open for additional items that the council should
> discuss or vote on. For agenda items, please respond to this message
> on the gentoo-project mailing list.
>

Short version of request: can action be taken to re-align IRC nicks
with Gentoo uids?  (Those with common sense should stop reading here.)

Longer version: since everything needs discussion, bikeshedding, and
actionable resolutions for the council to pass...

I'd like the council to vote on one of the following, or some other
approach, preferably to get IRC/email/usernames to match once more:

* On 2021-08-01 the LDAP user database will be queried to compare
their IRC nickname to uid/email addresses.  If these do not match,
then the developer will lose their IRC cloak and all IRC roles on
Gentoo channels, and will not be eligible to obtain these again until
the IRC nickname matches.

* On 2021-08-01 the LDAP user database will be queried to compare
their IRC nickname to uid/email addresses.  If these do not match,
then a process will be initiated to change their Gentoo uid/email to
match their newly chosen IRC nickname.

* On 2021-08-01 the LDAP user database will be queried to compare
their IRC nickname to uid/email addresses.  If these do not match,
then the retirement process for that developer will commence.  Users
who are unable to obtain a matching nick should contact <foo> to have
this addressed with Libera/Infra prior to this date.

* The Council recognizes that during the transition to Libera a number
of individuals decided to change their IRC nicks and this is causing
confusion.  The council kindly asks all developers to voluntarily
re-align their nicks and Gentoo uids so that it is not necessary to
endure further requests asking us to address this problem.

* The Council recognizes that during the transition to Libera a number
of individuals decided to change their IRC nicks and this is causing
confusion as to what Gentoo policy is on this matter.  There is no
requirement that Gentoo uids and IRC nicks match, and any dev is free
to change their IRC nick and register the new one in LDAP.  The public
Gentoo developer list will be updated to list the IRC username of each
developer to help everybody identify who is who, and everybody is
encouraged to keep the list handy as it will likely change frequently.

Rationale: I do not believe that recruiters would accept a new
developer's request to have a uid that doesn't match their nick on
IRC.  I suspect that recruiters also screen these nicks for
acceptability.  It doesn't make sense to have these suddenly diverge,
but only for a handful of existing developers whose IDs used to match,
but not for new devs going forward.  The current state is confusing at
best.  I do not pretend that all of these options are equally pretty
to implement from either a people or technical standpoint, and if
somebody has a better way to accomplish the goal by all means speak
up...

Obviously it would be best to just have devs fix this on their own
initiative, and I hate that this even has to be brought up ... again.
Perhaps devs holding leadership roles can lead the way.

Alternatively, if the intent is to just take advantage of the fact
that table lookups are cheap, at least for devs who are lacking
humanity, then just say so in order that we can stop talking about
it...

(FWIW, it is getting late, and some items above are intended as
genuine humor because not everything around here needs to be grim.
Now I'm off to sleep where I can hopefully dream up some more creative
IRC nicks...)

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Sam Jorna (wraeth)]

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

On 7/7/21 11:59 am, Rich Freeman wrote:
> I'd like the council to vote on one of the following, or some other
> approach, preferably to get IRC/email/usernames to match once more:
> 
> * On 2021-08-01 the LDAP user database will be queried to compare
> their IRC nickname to uid/email addresses.  If these do not match,
> then the developer will lose their IRC cloak and all IRC roles on
> Gentoo channels, and will not be eligible to obtain these again until
> the IRC nickname matches.

This would mean some developers would need to change their Gentoo
uid/address because their nick is not available on Libera.  I'm also
assuming this only applies to Libera as our official IRC location, since
a users nick may be different across networks.

> * On 2021-08-01 the LDAP user database will be queried to compare
> their IRC nickname to uid/email addresses.  If these do not match,
> then a process will be initiated to change their Gentoo uid/email to
> match their newly chosen IRC nickname.

How would this work for people with multiple nicks?  I occasionally
change my nick to something different for events, like 'darth_wraeth'
for May the 4th/5th.  I know others have alternate nicks they use
longer-term.  Would there be a time limit someone can use an alternate
nick for?

> * On 2021-08-01 the LDAP user database will be queried to compare
> their IRC nickname to uid/email addresses.  If these do not match,
> then the retirement process for that developer will commence.  Users
> who are unable to obtain a matching nick should contact <foo> to have
> this addressed with Libera/Infra prior to this date.

Would this be an ongoing thing?  This also ties into my previous point -
if I temporarily switch nicks, would I be in violation?  What if my
connection drops/reconnects and I end up as 'wraeth_' and don't notice,
would I be in violation and risk retirement (an extreme example, but
hopefully you get my point)?

Each of the above three options also mean available Gentoo uids is
dependent on whether a given nick is available on Libera.

> * The Council recognizes that during the transition to Libera a number
> of individuals decided to change their IRC nicks and this is causing
> confusion.  The council kindly asks all developers to voluntarily
> re-align their nicks and Gentoo uids so that it is not necessary to
> endure further requests asking us to address this problem.

What if developers kindly say 'no'?

> * The Council recognizes that during the transition to Libera a number
> of individuals decided to change their IRC nicks and this is causing
> confusion as to what Gentoo policy is on this matter.  There is no
> requirement that Gentoo uids and IRC nicks match, and any dev is free
> to change their IRC nick and register the new one in LDAP.  The public
> Gentoo developer list will be updated to list the IRC username of each
> developer to help everybody identify who is who, and everybody is
> encouraged to keep the list handy as it will likely change frequently.

This would be my understanding of the status quo, though it isn't
codified (that I'm aware of off-hand) nor enforced - that when someone
changes their nominal handle, they should update LDAP to reflect it.
It's also the most flexible, since it allows Gentoo uid and IRC nick to
be different.  I think it's also the most reasonable since IRC isn't the
only platform Gentoo has an official presence on (eg Github).  Still, it
only accounts for a single nick, when people may have multiple, for
varying lengths of time.

Perhaps, rather than forcing either nicks or uids to change, this last
option should be properly codified and enforced?  Should there also be
some guideline on how long someone can use a nick before it's considered
"their nick"?  Alternatively, can LDAP support multiple nick entries?

I think at least the issues of multiple/temporary nicks could be
mitigated if you replace 'nick' with 'account' - their Libera account
name must match their Gentoo uid in order to be eligible for a cloak.
That way the cloak matches their Gentoo uid (since the format is
gentoo/developer/$account) making them easier to identify, and you can
look up a nick in nickserv to see which account owns it (though you
can't look up an account and see what nicks it owns, nor if they are
currently online).  If going with one of the options that requires IRC
presence to match uid, it still means that available Gentoo uids is
dependent on what accounts haven't been claimed on Libera.

More generally, how would this apply to people who don't use IRC and
thus would never have their IRC nick in LDAP match their uid?

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Wed, Jul 7, 2021 at 2:55 AM Sam Jorna (wraeth) <wraeth@gentoo.org> wrote:
>
> On 7/7/21 11:59 am, Rich Freeman wrote:
> > I'd like the council to vote on one of the following, or some other
> > approach, preferably to get IRC/email/usernames to match once more:
>
> > * On 2021-08-01 the LDAP user database will be queried to compare
> > their IRC nickname to uid/email addresses.  If these do not match,
> > then the retirement process for that developer will commence.  Users
> > who are unable to obtain a matching nick should contact <foo> to have
> > this addressed with Libera/Infra prior to this date.
>
> Would this be an ongoing thing?  This also ties into my previous point -
> if I temporarily switch nicks, would I be in violation?  What if my
> connection drops/reconnects and I end up as 'wraeth_' and don't notice,
> would I be in violation and risk retirement (an extreme example, but
> hopefully you get my point)?

See above.  Nick collisions/etc have always been a thing and I don't
think having an underscore at the end really creates confusion,
especially with autocomplete and most IRC clients recognizing your
nominal nick in highlights.  The issue is that we have a fair number
of devs (including ones who were among the first to change networks)
who chose completely different nicks.

> Each of the above three options also mean available Gentoo uids is
> dependent on whether a given nick is available on Libera.

That was always the case with Freenode.  It isn't an accident that
they matched before.  New devs would be assigned a uid that matched
their nick.   So, the namespace was already constrained.

> Perhaps, rather than forcing either nicks or uids to change, this last
> option should be properly codified and enforced?  Should there also be
> some guideline on how long someone can use a nick before it's considered
> "their nick"?  Alternatively, can LDAP support multiple nick entries?

IMO this is a pretty bad option.  It basically means that the only way
to go ping somebody on IRC is to first do a table scan to figure out
what they're called at that particular moment.

The next obvious step is adding bot commands to facilitate this, so
now we have more bot spam in our channels as people are constantly
asking bots whether somebody is already in the channel (since the
channel member list is now useless), or to relay messages which means
everybody gets to read the channel twice.  Or people are first posting
"foo, are you here?" hoping to catch them with highlighting rules.
Then they say "willikins: is foo here?"

The whole point of having things like IRC channels is to facilitate
communication.  Having a level of indirection obfuscates
communication.  In more rich applications like github/bugzilla/etc
there are often search functions for things like authors which help
alleviate this.  Your typical IRC client doesn't have LDAP integration
so that we can dynamically map nicknames that change according to
mood.

If we were using something like Matrix then we could have a Federated
Gentoo identity that is linked to LDAP and so there is never a
discrepancy.  I agree that there is an argument for the simplicity of
IRC.  However, having a level of indirection in nicknames goes against
that argument for simplicity.  If you want a fancy communications
system that relies on LDAP lookups then at least automate this vs just
having everybody constantly scanning a webpage.

> I think at least the issues of multiple/temporary nicks could be
> mitigated if you replace 'nick' with 'account' - their Libera account
> name must match their Gentoo uid in order to be eligible for a cloak.
> That way the cloak matches their Gentoo uid (since the format is
> gentoo/developer/$account) making them easier to identify, and you can
> look up a nick in nickserv to see which account owns it (though you
> can't look up an account and see what nicks it owns, nor if they are
> currently online).

As you point out, this lets you use whois to figure out who some
random nick on Freenode is.  It doesn't let you figure out what nick
to use to ping somebody about something when it happens to be May the
4th, June the 7th, August the 13th, or whatever other days of the year
various random individuals decide to celebrate various random
holidays.  When you have hundreds of people in an org you can't just
expect to know that this guy celebrates Ewok day and goes by Wicket
when the death star is in the waning crescent phase.

> More generally, how would this apply to people who don't use IRC and
> thus would never have their IRC nick in LDAP match their uid?

The same way we handle people who don't answer the question in their
dev application about what their IRC nick is: presumably we don't give
them dev accounts already.

It isn't just hundreds of cases of coincidence that everybody used to
have matching Freenode nicks/Gentoo uids.  This was very much designed
into the process before.

I realize this whole situation seems a bit silly, but the whole point
of sticking with IRC was to keep things simple, and people changing
their nicks is actually hindering communications.  Some examples:

1. I had a conversation with a random person who ended up being a
Council member, where I wasted everybody's time adding context that I
didn't realize was unnecessary.
2. I've seen devs say on IRC that they need to go talk to somebody
when they were already on the channel (just under an obfuscated name),
resulting in delay/etc.
3. Most recently I was reading an IRC chat log posted in a separate
thread where it wasn't apparent until the second reading that somebody
else in the discussion was being quoted.  I ended up using /whois just
to confirm this.  Of course, if I were to do this using the list
archives six months from now who knows what /whois would say.

Yes, these are all relatively minor issues, but again, the whole point
of IRC is communication, and designing our system to practically
guarantee a future of minor communication problems seems suboptimal.

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Sam Jorna (wraeth)]

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

On 7/7/21 9:25 pm, Rich Freeman wrote:
> On Wed, Jul 7, 2021 at 2:55 AM Sam Jorna (wraeth) <wraeth@gentoo.org> wrote:
>>
>> On 7/7/21 11:59 am, Rich Freeman wrote:
>>> I'd like the council to vote on one of the following, or some other
>>> approach, preferably to get IRC/email/usernames to match once more:
>>
>>> * On 2021-08-01 the LDAP user database will be queried to compare
>>> their IRC nickname to uid/email addresses.  If these do not match,
>>> then the retirement process for that developer will commence.  Users
>>> who are unable to obtain a matching nick should contact <foo> to have
>>> this addressed with Libera/Infra prior to this date.
>>
>> Would this be an ongoing thing?  This also ties into my previous point -
>> if I temporarily switch nicks, would I be in violation?  What if my
>> connection drops/reconnects and I end up as 'wraeth_' and don't notice,
>> would I be in violation and risk retirement (an extreme example, but
>> hopefully you get my point)?
> 
> See above.  Nick collisions/etc have always been a thing and I don't
> think having an underscore at the end really creates confusion,
> especially with autocomplete and most IRC clients recognizing your
> nominal nick in highlights.  The issue is that we have a fair number
> of devs (including ones who were among the first to change networks)
> who chose completely different nicks.

Not sure what you mean by 'see above'.

The issue in that example isn't that my nick would have an underscore,
or whatever my client chose as the next available nick, but that it
would be different from what LDAP lists me as since the goal here is to
regulate what nicks people are allowed to use, potentially with the
threat of retirement if it's different.  What if my client picks
'the_wraeth' - it's (arguably) just as trivial as an underscore, but
it'd mess with autocomplete.

You also raise the point that IRC clients typically highlight primary
nicks by default (not to mention you can add custom highlights).
Perhaps the answer should be that whatever nick one is using, they are
expected to respond to their nominated LDAP nick (ie ensure their client
will highlight for it regardless of current nick)?  You might not get
autocomplete, but provided they're present they should still see it.

I'll concede, though, that if they're using a different nick, you
couldn't know they actually got the message.

>> Each of the above three options also mean available Gentoo uids is
>> dependent on whether a given nick is available on Libera.
> 
> That was always the case with Freenode.  It isn't an accident that
> they matched before.  New devs would be assigned a uid that matched
> their nick.   So, the namespace was already constrained.

I don't think this is true - bkohler@g.o is typically known on IRC as
iamben, for example, and searching the current developer list[1] for
"iamben" returns nothing.

It may be that people typically chose their IRC handle as their Gentoo
uid, but I'm not aware of any policy that says they must match.

>> Perhaps, rather than forcing either nicks or uids to change, this last
>> option should be properly codified and enforced?  Should there also be
>> some guideline on how long someone can use a nick before it's considered
>> "their nick"?  Alternatively, can LDAP support multiple nick entries?
> 
> IMO this is a pretty bad option.  It basically means that the only way
> to go ping somebody on IRC is to first do a table scan to figure out
> what they're called at that particular moment.

How often do you go to ping someone on IRC and find they're using a
different nick you didn't know about since the last time you talked to
them?  You would really only need to look up a nick if the nicks you
knew about weren't present.

> The next obvious step is adding bot commands to facilitate this, so
> now we have more bot spam in our channels as people are constantly
> asking bots whether somebody is already in the channel (since the
> channel member list is now useless), or to relay messages which means
> everybody gets to read the channel twice.  Or people are first posting
> "foo, are you here?" hoping to catch them with highlighting rules.
> Then they say "willikins: is foo here?"

I agree, using a bot to work around this isn't the best solution.  That
being said, from an end-user perspective it would be easy to '/query
willikins whois <dev>' when autocomplete doesn't complete the nick
you're looking for (but obviously would require some amount of effort to
actually implement).

> The whole point of having things like IRC channels is to facilitate
> communication.  Having a level of indirection obfuscates
> communication.  In more rich applications like github/bugzilla/etc
> there are often search functions for things like authors which help
> alleviate this.  Your typical IRC client doesn't have LDAP integration
> so that we can dynamically map nicknames that change according to
> mood.
> 
> If we were using something like Matrix then we could have a Federated
> Gentoo identity that is linked to LDAP and so there is never a
> discrepancy.  I agree that there is an argument for the simplicity of
> IRC.  However, having a level of indirection in nicknames goes against
> that argument for simplicity.  If you want a fancy communications
> system that relies on LDAP lookups then at least automate this vs just
> having everybody constantly scanning a webpage.

I do see the difficulty it can cause with communication, but I don't
think LDAP integration with IRC clients or switching platform entirely
is the right solution either.

>> I think at least the issues of multiple/temporary nicks could be
>> mitigated if you replace 'nick' with 'account' - their Libera account
>> name must match their Gentoo uid in order to be eligible for a cloak.
>> That way the cloak matches their Gentoo uid (since the format is
>> gentoo/developer/$account) making them easier to identify, and you can
>> look up a nick in nickserv to see which account owns it (though you
>> can't look up an account and see what nicks it owns, nor if they are
>> currently online).
> 
> As you point out, this lets you use whois to figure out who some
> random nick on Freenode is.  It doesn't let you figure out what nick
> to use to ping somebody about something when it happens to be May the
> 4th, June the 7th, August the 13th, or whatever other days of the year
> various random individuals decide to celebrate various random
> holidays.  When you have hundreds of people in an org you can't just
> expect to know that this guy celebrates Ewok day and goes by Wicket
> when the death star is in the waning crescent phase
I think the Death Star has been waning for a while now... :)

>> More generally, how would this apply to people who don't use IRC and
>> thus would never have their IRC nick in LDAP match their uid?
> 
> The same way we handle people who don't answer the question in their
> dev application about what their IRC nick is: presumably we don't give
> them dev accounts already.

Is a developer actually required to be on IRC?  My understanding was
that it was technically optional, same as membership on Github or
subscription to most lists.

> It isn't just hundreds of cases of coincidence that everybody used to
> have matching Freenode nicks/Gentoo uids.  This was very much designed
> into the process before.
> 
> I realize this whole situation seems a bit silly, but the whole point

I do get the concern in terms of ease of communication, and I'm not
trying to make light of it, but if the intent is to regulate IRC
presence I want to understand it properly.

> of sticking with IRC was to keep things simple, and people changing
> their nicks is actually hindering communications.  Some examples:
> 
> 1. I had a conversation with a random person who ended up being a
> Council member, where I wasted everybody's time adding context that I
> didn't realize was unnecessary.
> 2. I've seen devs say on IRC that they need to go talk to somebody
> when they were already on the channel (just under an obfuscated name),
> resulting in delay/etc.
> 3. Most recently I was reading an IRC chat log posted in a separate
> thread where it wasn't apparent until the second reading that somebody
> else in the discussion was being quoted.  I ended up using /whois just
> to confirm this.  Of course, if I were to do this using the list
> archives six months from now who knows what /whois would say.

These are each valid points, but I suspect they're each a symptom/result
of the move to Libera and changes related to that, such as a desired
nick becoming free.  Again, how often is this actually a problem?

> Yes, these are all relatively minor issues, but again, the whole point
> of IRC is communication, and designing our system to practically
> guarantee a future of minor communication problems seems suboptimal.

[1] https://www.gentoo.org/inside-gentoo/developers/

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Joonas Niilola]

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

On 7.7.2021 4.59, Rich Freeman wrote:
> On Mon, Jul 5, 2021 at 5:20 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>> The agenda is still open for additional items that the council should
>> discuss or vote on. For agenda items, please respond to this message
>> on the gentoo-project mailing list.
>>
> 
> Short version of request: can action be taken to re-align IRC nicks
> with Gentoo uids?  (Those with common sense should stop reading here.)

At first I wasn't sure if you asked this seriously, due to

> (FWIW, it is getting late, and some items above are intended as
> genuine humor because not everything around here needs to be grim.

But looks like you are.

I'm not opposing the idea, but I also don't like it that some org I
volunteer for starts controlling how I should behave everywhere. I IRC
on other channels beside Gentoo. If this suggestion goes through, we
might as well set up our own irc.gentoo.org network, or some of us are
forced to connect to Libera with 2 different clients/nicks.

Yes, finding bman or dilfridge from IRC lately has been difficult. But
if they choose to make it difficult, you can always catch them via e-mail.

Maybe, as you suggested, there could be an LDAP entry for IRC nick which
then gets automatically queried into wiki page? But for sure not
everyone will be updating that either, and maybe this could also be opt-in.

I just think the price is too high for the benefits. There's life
outside Gentoo.

-- juippis


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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Wed, Jul 7, 2021 at 7:40 AM Joonas Niilola <juippis@gentoo.org> wrote:
>
> I'm not opposing the idea, but I also don't like it that some org I
> volunteer for starts controlling how I should behave everywhere. I IRC
> on other channels beside Gentoo. If this suggestion goes through, we
> might as well set up our own irc.gentoo.org network, or some of us are
> forced to connect to Libera with 2 different clients/nicks.

Well, this was already addressed in the past by letting people pick
any IRC nick they wish, and then assigning them a Gentoo uid that
matched.  The IRC nicks came first.

That is still an option, albeit a painful one I am guessing, and we
probably don't want to let everybody just arbitrarily change their
uids on a whim if it takes effort by Infra and others to accommodate
this.

> I just think the price is too high for the benefits. There's life
> outside Gentoo.

I ack that this is an opinion others may have as well, which is why I
did leave open the door to simply formalizing this.  I for one welcome
our robot overlords.

> At first I wasn't sure if you asked this seriously

I wasn't intending to troll.  My intent was to just try to make a
somewhat annoying/bikeshedding topic a bit lighter, as I knew it was
destined to be this.  There was also a bit of inside humor in there as
well (genuinely not intended to re-open wounds and I hope this was the
case).

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ben Kohler]

On 7/7/21 6:51 AM, Rich Freeman wrote:
> On Wed, Jul 7, 2021 at 7:40 AM Joonas Niilola <juippis@gentoo.org> wrote:
>> I'm not opposing the idea, but I also don't like it that some org I
>> volunteer for starts controlling how I should behave everywhere. I IRC
>> on other channels beside Gentoo. If this suggestion goes through, we
>> might as well set up our own irc.gentoo.org network, or some of us are
>> forced to connect to Libera with 2 different clients/nicks.
> Well, this was already addressed in the past by letting people pick
> any IRC nick they wish, and then assigning them a Gentoo uid that
> matched.  The IRC nicks came first.
>
> That is still an option, albeit a painful one I am guessing, and we
> probably don't want to let everybody just arbitrarily change their
> uids on a whim if it takes effort by Infra and others to accommodate
> this.
>
>> I just think the price is too high for the benefits. There's life
>> outside Gentoo.
> I ack that this is an opinion others may have as well, which is why I
> did leave open the door to simply formalizing this.  I for one welcome
> our robot overlords.
>
>> At first I wasn't sure if you asked this seriously
> I wasn't intending to troll.  My intent was to just try to make a
> somewhat annoying/bikeshedding topic a bit lighter, as I knew it was
> destined to be this.  There was also a bit of inside humor in there as
> well (genuinely not intended to re-open wounds and I hope this was the
> case).
>

I would propose some middle-ground where your IRC nick can diverge from 
your @gentoo.org ID, but your IRC nick must be the one registered in 
LDAP (semi-)permanently, and not changing from week to week.  I think 
that it's the week-to-week changes that are causing the problem.


I am speaking as someone who has had the same IRC nick for 15+ years, 
but chooses to use a more professional ID in other contexts like 
official gentoo dev work.


-Ben (bkohler iamben)

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Michał Górny]

On Tue, 2021-07-06 at 21:59 -0400, Rich Freeman wrote:
> On Mon, Jul 5, 2021 at 5:20 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > 
> > The agenda is still open for additional items that the council should
> > discuss or vote on. For agenda items, please respond to this message
> > on the gentoo-project mailing list.
> > 
> 
> Short version of request: can action be taken to re-align IRC nicks
> with Gentoo uids?  (Those with common sense should stop reading here.)
> 

While I applaud the goal, I don't think this is something we can really
do.  I mean, yes, we can politely ask people to make themselves easier
to find but that's about it.

Forcing people to use specific nicknames on IRC and trying to put it
into some bureaucratic ramifications sounds like aiming at a dystopian
Gentoo to me.  Even if the goal is clearly beneficial to Gentoo users,
it's just not something I would pursue.

Furthermore, how do people who don't use IRC at all fit into it?  If IRC
is not obligatory (and while I really prefer to be able to reach other
devs on IRC, I don't think we should make it obligatory), then IMO
the proposal is moot.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Tue, Jul 06, 2021 at 09:59:33PM -0400, Rich Freeman wrote:
> On Mon, Jul 5, 2021 at 5:20 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> >
> > The agenda is still open for additional items that the council should
> > discuss or vote on. For agenda items, please respond to this message
> > on the gentoo-project mailing list.
> >
> 
> Short version of request: can action be taken to re-align IRC nicks
> with Gentoo uids?  (Those with common sense should stop reading here.)
> 
> Longer version: since everything needs discussion, bikeshedding, and
> actionable resolutions for the council to pass...
No.

All developers should update their LDAP entries to state what their IRC
nick is:
https://wiki.gentoo.org/wiki/Project:Infrastructure/LDAP_Guide#Add_gentooIM_with_your_Libera.Chat_handle

It supports multiple nicks, multiple networks, multiple protocols.

I would ask that the group contacts ensure that the cloaks reflect the
developer nicks, and that anybody who cares about the person they are
talking to check the cloaks.

If you're looking for somebody, look them up in LDAP first!

(and Infra will consider an action item to expose some parts of
GentooIM)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Mon, Jul 05, 2021 at 11:20:43AM +0200, Ulrich Mueller wrote:
> The agenda is still open for additional items that the council should
> discuss or vote on. For agenda items, please respond to this message
> on the gentoo-project mailing list.
Hi,


TL;DR:
Please change the format of metadata/AUTHORS to yaml-based list of "key:
[value,...]" where key is the identity of a Gentoo developer, and the
list is copyright holders that the developer has worked for.

Longer:
metadata/AUTHORS was never specified in any GLEP, so I'm asking Council
rather than proposing a GLEP.

I'd like the council to consider improving the formatting of the
metadata/AUTHORS file, per bug #730200. Specifically comment 1:
https://bugs.gentoo.org/730200#c1

The existing format specifies the name of a legal entity, but doesn't
explicitly associate a given developer with that entity. Some
bikeshedding suggested that new entries could associate via the git
commit messages, but that doesn't account for historical entries.

I've contributed to Gentoo while on the employment income and/or
consulting work for at least 9 different organizations in the past 18
years, and some of them should be recognized as potential copyright
holders for my works.

I think the suggested format should become YAML-based for ease of
validation and parsing. I don't have opinions on the format within the
data. Should it be alphabetical or cronological? Should explicit date
ranges be possible?

Example of potential new file, with existing header omitted for brevity.

---
mgorny:
- Michał Górny <mgorny@gentoo.org>
williamh:
- Sony Interactive Entertainment Inc.
dolsen:
- Sony Interactive Entertainment Inc.
chutzpah:
- Sony Interactive Entertainment Inc.
wizardedit:
- Sony Interactive Entertainment Inc.
zmedico:
- Sony Interactive Entertainment Inc.
gyakovlev:
- Sony Interactive Entertainment Inc.
robbat2:
- Technical University Of British Columbia (TechBC)
- Simon Fraser University
- Net-Conex Business Solutions Inc
- Epik Networks Inc
- IsoHunt Web Technologies Inc.
- Global NetOptex Inc
- Merkle: The Gallery Group
- BC Libraries Cooperative 2009
- MappingBook Ltd
- Experq Oy

# vim: ft=yaml:
---

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:

> TL;DR:
> Please change the format of metadata/AUTHORS to yaml-based list of "key:
> [value,...]" where key is the identity of a Gentoo developer, and the
> list is copyright holders that the developer has worked for.

Have you run this by the Sony people? The current AUTHORS file is a
compromise resulting from long discussions, so I'd rather have any
potential issues resolved before the Council votes on any change.

> I think the suggested format should become YAML-based for ease of
> validation and parsing. I don't have opinions on the format within the
> data. Should it be alphabetical or cronological? Should explicit date
> ranges be possible?

Using the Gentoo uid as the key would imply that contributors other than
developers cannot be listed in the file. Is this a valid assumption?

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Wed, Jul 7, 2021 at 5:27 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
>
> > TL;DR:
> > Please change the format of metadata/AUTHORS to yaml-based list of "key:
> > [value,...]" where key is the identity of a Gentoo developer, and the
> > list is copyright holders that the developer has worked for.
>
> Using the Gentoo uid as the key would imply that contributors other than
> developers cannot be listed in the file. Is this a valid assumption?

I would say no.  Also, you can't assume that somebody introducing
commits owned by some entity is employed or even associated with that
entity.

Think about the eudev fiasco, which was also something that drove the
copyright policy.  Suppose I want to add some 3rd party copyrighted
material to the repo and have done my homework to ensure it is
license-compatible.  I may need to add them to the AUTHORS file so
that we're not just removing their copyright attribution and causing a
huge controversy.  However, I'm not associated with them in any way,
and neither are any of my other commits.  I'm just adding their stuff
to the repo in this one commit.  I don't want to be listed in the
AUTHORS file implying in some way that I am employed by EvilCorp.  I'm
just borrowing their code, legally.

The AUTHORS file is just a list of anybody who wishes (or who we
assume might wish) to be acknowledged in the copyright attributions.

If you want to be able to map commits to original copyright owners it
would probably be better to add a git header for this.

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Wed, Jul 07, 2021 at 07:31:22AM -0400, Rich Freeman wrote:
> On Wed, Jul 7, 2021 at 5:27 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> >
> > >>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
> >
> > > TL;DR:
> > > Please change the format of metadata/AUTHORS to yaml-based list of "key:
> > > [value,...]" where key is the identity of a Gentoo developer, and the
> > > list is copyright holders that the developer has worked for.
> >
> > Using the Gentoo uid as the key would imply that contributors other than
> > developers cannot be listed in the file. Is this a valid assumption?
> 
> I would say no.  Also, you can't assume that somebody introducing
> commits owned by some entity is employed or even associated with that
> entity.
I populated the example list based on tying the "Copyright: Sony Interactive
Entertainment Inc." commit messages to the author of those commits.

> The AUTHORS file is just a list of anybody who wishes (or who we
> assume might wish) to be acknowledged in the copyright attributions.
I'm not changing that, just associating for which contributor the
attributions MIGHT apply.

> If you want to be able to map commits to original copyright owners it
> would probably be better to add a git header for this.
And I note in my email that this does NOT replace the Copyright headers,
it simply tries to track in a single place all of the historical
assigned holders.

Some of my entries tie back to CVS commits a decade ago. It's not
possible to add headers on those entries.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Wed, Jul 7, 2021 at 4:28 PM Robin H. Johnson <robbat2@gentoo.org> wrote:
>
> On Wed, Jul 07, 2021 at 07:31:22AM -0400, Rich Freeman wrote:
> > On Wed, Jul 7, 2021 at 5:27 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > >
> > > >>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
> > >
> > > > TL;DR:
> > > > Please change the format of metadata/AUTHORS to yaml-based list of "key:
> > > > [value,...]" where key is the identity of a Gentoo developer, and the
> > > > list is copyright holders that the developer has worked for.
> > >
> > you can't assume that somebody introducing
> > commits owned by some entity is employed or even associated with that
> > entity.
> I populated the example list based on tying the "Copyright: Sony Interactive
> Entertainment Inc." commit messages to the author of those commits.

I was responding to the wording of your proposal: "the list is
copyright holders that the developer has worked for."

If I commit something copyrighted by Google, that doesn't make me a
Google employee, or suggest that I've done work on their behalf in any
way.  I (probably without their knowledge) just copy/pasted their code
into the repo, under the terms of whatever license they released the
code under.

You could change the wording to:

"...where key is the identify of a Gentoo developer, and the list are
entities who own the copyright to parts of commits the developer has
made."

I really don't see the value though in making this association.  What
good is it to know that somewhere in somebody's long list of commits
that there might be a few lines originally created by the Apache
Foundation or whatever?

In the case of actual employment it might make more sense if there are
extensive works for hire, but not if somebody just one time committed
one patch file that held somebody else's copyright.


--
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Wed, Jul 07, 2021 at 05:24:04PM -0400, Rich Freeman wrote:
> > I populated the example list based on tying the "Copyright: Sony Interactive
> > Entertainment Inc." commit messages to the author of those commits.
> 
> I was responding to the wording of your proposal: "the list is
> copyright holders that the developer has worked for."
> 
> If I commit something copyrighted by Google, that doesn't make me a
> Google employee, or suggest that I've done work on their behalf in any
> way.  I (probably without their knowledge) just copy/pasted their code
> into the repo, under the terms of whatever license they released the
> code under.
I didn't say it did, read further below.

> You could change the wording to:
> 
> "...where key is the identify of a Gentoo developer, and the list are
> entities who own the copyright to parts of commits the developer has
> made."
> 
> I really don't see the value though in making this association.  What
> good is it to know that somewhere in somebody's long list of commits
> that there might be a few lines originally created by the Apache
> Foundation or whatever?
I agree it should be substantial works that could reach the threshold of
copyright notability, and that's what I feel my list is.

> In the case of actual employment it might make more sense if there are
> extensive works for hire, but not if somebody just one time committed
> one patch file that held somebody else's copyright.
I'd say all of my entries do fall under more extensive works for hire,
as multiple organizations I listed were my full-time employers for
years, and I contributed to Gentoo on work time, for work purposes,
under open-source licenses, with the approval of the company (easy in
small companies).
The separate list of consulting work I did also featured extensive
works, e.g. one of the entries there funded my work to make Open-iSCSI
work with LDAP authentication in Gentoo.

Revised suggestion taking into account your concern as well as the
separate thread that contributors without @gentoo.org addresses should
be recognized:
===
key: 
  name of contributor and/or their associated unique email address
  (emails should not be duplicated in the keys)
value:
  a list of entities who may own the copyright to parts of commits
  the developer has made
===

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Thu, 08 Jul 2021, Robin H Johnson wrote:

> key: 
>   name of contributor and/or their associated unique email address
>   (emails should not be duplicated in the keys)
> value:
>   a list of entities who may own the copyright to parts of commits
>   the developer has made

Can value be empty, if the contributor themself holds the copyright?
IIUC, YAML syntax would allow it.

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Thu, Jul 08, 2021 at 07:43:08PM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 08 Jul 2021, Robin H Johnson wrote:
> 
> > key: 
> >   name of contributor and/or their associated unique email address
> >   (emails should not be duplicated in the keys)
> > value:
> >   a list of entities who may own the copyright to parts of commits
> >   the developer has made
> Can value be empty, if the contributor themself holds the copyright?
> IIUC, YAML syntax would allow it.
Yes, I feel that would be a valid entry.

We'd just have to add an explicit ":" on the end of the lines we have
right now.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Thu, 08 Jul 2021, Robin H Johnson wrote:

> On Thu, Jul 08, 2021 at 07:43:08PM +0200, Ulrich Mueller wrote:
>> >>>>> On Thu, 08 Jul 2021, Robin H Johnson wrote:
>> 
>> > key: 
>> >   name of contributor and/or their associated unique email address
>> >   (emails should not be duplicated in the keys)
>> > value:
>> >   a list of entities who may own the copyright to parts of commits
>> >   the developer has made
>> Can value be empty, if the contributor themself holds the copyright?
>> IIUC, YAML syntax would allow it.
> Yes, I feel that would be a valid entry.

> We'd just have to add an explicit ":" on the end of the lines we have
> right now.

As discussed in the meeting:

<@ulm> my impression is that this is not ready for a vote yet, because
       there was no feedback from the entity listed in the AUTHORS file
<@dilfridge> this proposal is somewhat pointless if we do not have any
             feedback from $CORPORATION people first
<@ulm> yes :)
<@gyakovlev> I have a feeling not enough discussion happened yet.
<@sam_> agreed
<@gyakovlev> especially with copyright holders in that file
<@ulm> let's postpone then
<@mgorny> do we want to assign someone from the Council to work on it?
<@dilfridge> so I suggest we ask robbat2 to obtain that feedback in
             detail first 

@robbat2: Could you try to get feedback from the currently listed
entities whether they are fine with the proposed change?

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Rich Freeman]

On Thu, Jul 8, 2021 at 12:57 PM Robin H. Johnson <robbat2@gentoo.org> wrote:
>
> Revised suggestion taking into account your concern as well as the
> separate thread that contributors without @gentoo.org addresses should
> be recognized:
> ===
> key:
>   name of contributor and/or their associated unique email address
>   (emails should not be duplicated in the keys)
> value:
>   a list of entities who may own the copyright to parts of commits
>   the developer has made

I still don't like the idea of making this association, because
somebody might want to commit some entity's code without being
memorialized as the person who did a commit for associated with some
organization that they might have serious ethical concerns with.

For example, I might borrow code from a company that manufactures
cigarettes, weapons, is political in nature, or which otherwise is
controversial.  I have no association with the organization.  The code
just happens to have been written by them, and for some reason I need
to use it.

So, if this change is made, developers are now stuck with having to
choose between having their name go into this file next to the
organization they want no association with, or not using the code
(which might benefit users in some way - eg security patches/etc).
There is no organizational need to make these associations, so why do
it?

However, your change does address my concern with not having some way
to include organizations in the AUTHORS file when they do not employ
the Gentoo developer making the commit.

In the case of developers who wish to list their own names in the
file, presumably they can just list their name as both the key and
value.

-- 
Rich

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Wed, Jul 07, 2021 at 11:27:52AM +0200, Ulrich Mueller wrote:
> >>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
> > TL;DR:
> > Please change the format of metadata/AUTHORS to yaml-based list of "key:
> > [value,...]" where key is the identity of a Gentoo developer, and the
> > list is copyright holders that the developer has worked for.
> Have you run this by the Sony people? The current AUTHORS file is a
> compromise resulting from long discussions, so I'd rather have any
> potential issues resolved before the Council votes on any change.
Sony is still listed.

chutzpah, zmedico, gyakovlev: Can you please weigh in on this
modification of the file format? I've populated the Sony entries in it
based on the "Copyright: Sony Interactive Entertainment Inc." in the git
history for the repo.

> > I think the suggested format should become YAML-based for ease of
> > validation and parsing. I don't have opinions on the format within the
> > data. Should it be alphabetical or cronological? Should explicit date
> > ranges be possible?
> Using the Gentoo uid as the key would imply that contributors other than
> developers cannot be listed in the file. Is this a valid assumption?
Accepted, I will say we can use email address instead, because that
uniquely identifies both the Committer & Signed-Off by entries.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Ulrich Mueller]

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

>>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
>> Using the Gentoo uid as the key would imply that contributors other than
>> developers cannot be listed in the file. Is this a valid assumption?

> Accepted, I will say we can use email address instead, because that
> uniquely identifies both the Committer & Signed-Off by entries.

Typically one wouldn't put (only) an e-mail address in a copyright
notice, but the author's real name.

How about using the author's name plus (optional?) e-mail address as the
key? This would also stay close to what the file says for the current
single-line entries: "the entity's name and an optional e-mail address".

Ulrich

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

Re: [gentoo-project] Council meeting 2021-07-11 - call for agenda items

[Robin H. Johnson]

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

On Thu, Jul 08, 2021 at 01:00:35AM +0200, Ulrich Mueller wrote:
> >>>>> On Wed, 07 Jul 2021, Robin H Johnson wrote:
> >> Using the Gentoo uid as the key would imply that contributors other than
> >> developers cannot be listed in the file. Is this a valid assumption?
> 
> > Accepted, I will say we can use email address instead, because that
> > uniquely identifies both the Committer & Signed-Off by entries.
> 
> Typically one wouldn't put (only) an e-mail address in a copyright
> notice, but the author's real name.
> 
> How about using the author's name plus (optional?) e-mail address as the
> key? This would also stay close to what the file says for the current
> single-line entries: "the entity's name and an optional e-mail address".
I've merged this suggestion into the other thread.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

[gentoo-project] Council meeting 2021-07-11 - agenda

[Ulrich Mueller]

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

The first council meeting of this election term will be on
Sunday 2021-07-11, 19:00 UTC in the #gentoo-council channel
on Libera Chat.

Agenda:

1. Roll call
2. Constitute the new council
   - Decide on time of meetings. The previous council had its meetings
     on the 2nd Sunday of every month at 19:00 UTC
   - Vote for continuing last council's workflow considering sending
     a call for agenda items (two weeks in advance), sending the
     agenda (one week in advance) and have the meeting focussed, i.e.
     have major discussions on the gentoo-project mailing list prior
     to the meeting
   - Appoint chairmen for this term's meetings
3. GLEP 82 update [1]
4. Old EAPIs
   - Deprecate EAPI 6 [2]
   - Update policy for banning EAPIs [2] / ban EAPI 5 [3]
5. IRC nicknames [4]
6. Format of metadata/AUTHORS file [5]
7. Open bugs with council participation [6]
8. Open floor


[1] https://archives.gentoo.org/gentoo-dev/message/625505e15adfb532bf961076ad5f79ab
[2] https://archives.gentoo.org/gentoo-project/message/4a504a0b7aa9199bac3ebcaf54064841
[3] https://archives.gentoo.org/gentoo-project/message/c8af2e54368436885bc6b681367ff00c
[4] https://archives.gentoo.org/gentoo-project/message/38fa6888e595165c8521e62becb1daf0
[5] https://archives.gentoo.org/gentoo-project/message/2c6dc0d82147e8e7b572e3390b051b4d
[6] https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation

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