On Fri, Jul 17, 2020 at 02:34:25PM -0400, Philip Balister wrote:

On 7/15/20 4:31 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 16:03 -0400, Trevor Woerner wrote:

On Wed 2020-07-15 @ 07:02:13 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:

....

The OE membership is primarily made from developers and is quite
different from the YP membership. They need/expect communication in
different forms too, this mailing list discussion would not work for
most YP members (although as ever some people overlap in both worlds).

The easiest way to think about the difference between the Yocto Project
and OpenEmbedded is: The Yocto Project members are companies and
OpenEmbedded members are individuals.

OpenEmbedded is represented in Yocto Project meetings (currently by me)
and we (OpenEmbedded members) vote for two of the YP TSC members. It is
safe to say that some individuals are both OpenEmbedded members and work
for Yocto Project members. If the person is elected by OpenEmbedded to
the YP TSC, I expect them to represent OpenEmbedded, and if a Yocto
Project selected rep, I would expect them to represent the member companies.

I realize this can be confusing, but for day to day work we do a good
job keeping things working as smoothly as possible.

If you want to become a members of OpenEmbedded, email a short bio to
board@... explaining your connection to the project. The
board will then approve your membership (practically speaking, we
haven't declined anyone, but would if there was no connection to
OpenEmbedded)

The OpenEmbedded members elect the Board to represent their interests,
including at the Yocto Project meetings. The Board then decides who attends
those YP meetings - usually there are 2 representatives, a Primary one and a
Backup, in case Primary is not able to attend and/or vote (I backup Philip).

The OpenEmbedded members elect the entire OpenEmbedded TSC, plus OpenEmbedded
has 2 seats at the Yocto Project TSC, which are also elected by OE members.

All of that is to ensure OpenEmbedded community has enough voice in different
aspects of the Yocto Project among other member organizations.

OpenEmbedded Organization, current Board and all individual members:
https://www.openembedded.org/wiki/Organization

OpenEmbedded TSC:
https://www.openembedded.org/wiki/TSC

Yocto Project Member Organizations:
https://www.yoctoproject.org/ecosystem/members/

Yocto Project TSC:
https://wiki.yoctoproject.org/wiki/TSC

--
Denys

Yeah, a bit long winded, but I wanted to make sure this was clear and
remind people how we select two of the YP TSC members.

Philip

Cheers,

Richard

On 7/15/20 4:31 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 16:03 -0400, Trevor Woerner wrote:

On Wed 2020-07-15 @ 07:02:13 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:

....

The OE membership is primarily made from developers and is quite
different from the YP membership. They need/expect communication in
different forms too, this mailing list discussion would not work for
most YP members (although as ever some people overlap in both worlds).

The easiest way to think about the difference between the Yocto Project
and OpenEmbedded is: The Yocto Project members are companies and
OpenEmbedded members are individuals.

OpenEmbedded is represented in Yocto Project meetings (currently by me)
and we (OpenEmbedded members) vote for two of the YP TSC members. It is
safe to say that some individuals are both OpenEmbedded members and work
for Yocto Project members. If the person is elected by OpenEmbedded to
the YP TSC, I expect them to represent OpenEmbedded, and if a Yocto
Project selected rep, I would expect them to represent the member companies.

I realize this can be confusing, but for day to day work we do a good
job keeping things working as smoothly as possible.

If you want to become a members of OpenEmbedded, email a short bio to
board@... explaining your connection to the project. The
board will then approve your membership (practically speaking, we
haven't declined anyone, but would if there was no connection to
OpenEmbedded)

Yeah, a bit long winded, but I wanted to make sure this was clear and
remind people how we select two of the YP TSC members.

Philip

Cheers,

Richard

On Wed, Jul 15, 2020 at 04:38:01PM -0400, Trevor Woerner wrote:

On Wed 2020-07-15 @ 04:10:04 PM, Josef Holzmayr-Khosh Amoz wrote:

Am Mi., 15. Juli 2020 um 16:00 Uhr schrieb Rich Persaud <persaur@...>:

Since monoculture is the opposite of multiculture, hopefully each
community can make choices appropriate to their project, rather than
replacing an accidental/historical monoculture with an external
monoculture that is equally a snapshot of time and space.

This is exactly what I wanted to convey. Couldn't word it any better way.

Can you find _any_ example of a thing that stands the test of time? Everything
we do, make, or say places us at this specific time and place in history.

We used python as the basis of bitbake and send patches for git on a mailing
list?! That'll be hilariously "so early 2000's" to digital historians a
thousand years from now. Everything we do today is a snapshot of the here and
now.

I guess I'm more of a "go with the flow" sort of person; I reject the notion
that we need to act only when pressured with financial reprisals or boycotts.
I'm not trying to lead the change, but I don't think we should come in last
either.

Standing the test of time is the opposite of reacting to whatever
is trending on social media.

In a few months the Twitter mob will have found something else to attack,
the sane action is to lie low and try to avoid being targeted until then.

Using primary/secondary or master/replica or master/standby instead of
master/slave for new code is a reasonable suggestion, and terms like
"replica" or "standby" can actually be better descriptions than "slave".

But all the urgency and pressure are just performative activism,
not solving any actual problem.

Confederate flags and statues of confederate soldiers have a history of
being used as a symbol to celebrate the fight for slavery.

Usage of "master/slave" in technical context is not intended or
considered a symbol against Slavs or any other people with a past
history of being enslaved.

cu
Adrian

On Wed 2020-07-15 @ 04:10:04 PM, Josef Holzmayr-Khosh Amoz wrote:

Am Mi., 15. Juli 2020 um 16:00 Uhr schrieb Rich Persaud <persaur@...>:

Since monoculture is the opposite of multiculture, hopefully each
community can make choices appropriate to their project, rather than
replacing an accidental/historical monoculture with an external
monoculture that is equally a snapshot of time and space.

This is exactly what I wanted to convey. Couldn't word it any better way.

Can you find _any_ example of a thing that stands the test of time? Everything
we do, make, or say places us at this specific time and place in history.

We used python as the basis of bitbake and send patches for git on a mailing
list?! That'll be hilariously "so early 2000's" to digital historians a
thousand years from now. Everything we do today is a snapshot of the here and
now.

I guess I'm more of a "go with the flow" sort of person; I reject the notion
that we need to act only when pressured with financial reprisals or boycotts.
I'm not trying to lead the change, but I don't think we should come in last
either.

On Wed, 2020-07-15 at 16:03 -0400, Trevor Woerner wrote:

On Wed 2020-07-15 @ 07:02:13 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:
What may also be a bigger issue is member companies placing
requirements on the project.

According to https://www.yoctoproject.org/ecosystem/members/ the
following companies are YP members:

- Intel
- Texas Instruments
- Comcast
- ARM
- Cisco
- Facebook
- Xilinx
- Microsoft
- Windriver
- Mentor
- Juniper
- Renesas
- Automotive Grade Linux
- ST
- Lineo
- Enea
- MontaVista
- Dell
- LG Electronics
- NXP
- Linaro
- AMD

Do we have contacts at all these companies?

Yes, there are specific mailing lists and meetings the members have.
Philip represents OE at those meetings.

How do I draw them into the conversation (or is this a job for the
advocacy people)?

I believe this matter falls under the remit of the YP TSC. If the
members want to represent anything to the TSC they can and this will
get discussed at future meetings with the members and factored in by
the TSC. OE is also strongly represented on the YP TSC.

I would ask those discussions be left to the members and the YP TSC as
they are the correct people to have them. I believe member companies
would only get involved if they don't see the "right"
answers/direction/messaging coming from the TSC/project. Anyone
concerned about this and not wanting to talk to me or the YP TSC
members can talk to the YP Chair (Andy Wafaa) or YP Community Manager
(Nico) amongst others.

I don't know that there is a similar list for OE? The OE members
appear to be a list of interested developers?
https://www.openembedded.org/wiki/Organization#Current_Members

The OE membership is primarily made from developers and is quite
different from the YP membership. They need/expect communication in
different forms too, this mailing list discussion would not work for
most YP members (although as ever some people overlap in both worlds).

Cheers,

Richard

On Wed, Jul 15, 2020 at 3:11 PM Trevor Woerner <twoerner@...> wrote:

Hi George, nice to hear from you :-)

On Wed 2020-07-15 @ 12:58:20 PM, George McCollister wrote:

If people find the terms whitelist/blacklist offensive I encourage
them to communicate this to the community. Other than the obvious
(which seems may be a coincidence?) I don't understand these words to
have racial connotations based on my interpretation of the etymology.

From an etymological point of view the original, and only, meaning of the word
"sinister" was "left-handed"! Consider how the meaning of that simple word has
changed over time wrt people's aversion and hostility towards left-handed
people! Unfortunately I don't think the etymology is relevant.

The change in the meaning of sinister is reflected in all major
English language dictionaries.
This is not the case with whitelist/blacklist. I really question if
this is just a misunderstanding.

It would be strange to name a variable, for example, "sinister" if your only
intent was to say it represented something on the left side of a project :-)

Hi George, nice to hear from you :-)

On Wed 2020-07-15 @ 12:58:20 PM, George McCollister wrote:

If people find the terms whitelist/blacklist offensive I encourage
them to communicate this to the community. Other than the obvious
(which seems may be a coincidence?) I don't understand these words to
have racial connotations based on my interpretation of the etymology.

From an etymological point of view the original, and only, meaning of the word
"sinister" was "left-handed"! Consider how the meaning of that simple word has
changed over time wrt people's aversion and hostility towards left-handed
people! Unfortunately I don't think the etymology is relevant.

It would be strange to name a variable, for example, "sinister" if your only
intent was to say it represented something on the left side of a project :-)

On Wed 2020-07-15 @ 07:02:13 PM, Richard Purdie wrote:

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:
What may also be a bigger issue is member companies placing
requirements on the project.

According to https://www.yoctoproject.org/ecosystem/members/ the following
companies are YP members:

- Intel
- Texas Instruments
- Comcast
- ARM
- Cisco
- Facebook
- Xilinx
- Microsoft
- Windriver
- Mentor
- Juniper
- Renesas
- Automotive Grade Linux
- ST
- Lineo
- Enea
- MontaVista
- Dell
- LG Electronics
- NXP
- Linaro
- AMD

Do we have contacts at all these companies?

How do I draw them into the conversation (or is this a job for the advocacy
people)?

I don't know that there is a similar list for OE? The OE members appear to be
a list of interested developers? https://www.openembedded.org/wiki/Organization#Current_Members

On Wed 2020-07-15 @ 12:25:23 PM, akuster808 wrote:

On 7/15/20 10:45 AM, Trevor Woerner wrote:

On Wed 2020-07-15 @ 08:33:56 PM, Adrian Bunk wrote:

On Wed, Jul 15, 2020 at 01:31:34AM -0400, Trevor Woerner wrote:

...
4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.
...

If the word "master" alone is considered non-inclusive for people in
the US then CVs are also affected, like speaker bios at conferences.

What replacement term are US universities using for their M-word degrees?

This is a good question.

Some projects are replacing "master" in isolation; such as when used as a branch
name. Other projects are only replacing "master" when paired with "slave".

 "Master" has been used in commit headers, so do we intend on re-writing
git history?

Right now we're in the discussion phase.

As far as I'm concerned, if most people who speak up decide that's what we
should do, then that's what I'll work towards; although (from the feedback so
far) I doubt that's the path we'll take.

On Wed 2020-07-15 @ 08:33:56 PM, Adrian Bunk wrote:

On Wed, Jul 15, 2020 at 01:31:34AM -0400, Trevor Woerner wrote:

...
4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.
...

If the word "master" alone is considered non-inclusive for people in
the US then CVs are also affected, like speaker bios at conferences.

What replacement term are US universities using for their M-word degrees?

This is a good question.

Some projects are replacing "master" in isolation; such as when used as a branch
name. Other projects are only replacing "master" when paired with "slave".

 "Master" has been used in commit headers, so do we intend on re-writing git history?

-armin

On Wed, 2020-07-15 at 09:09 -0700, akuster wrote:

Well, as I see it, the LF will make a ruling and then the Yocto
Project with have to follow. If OE decides not to change then this
put the two projects at odds.

To be really clear, whilst you keep saying this, I have heard of no
such plans from the LF and I have asked. Yes, the LF is a strong
believer in diversity and does take these issues seriously but as I
understand it, it is for the individual LF projects to find their way
in this as there is no "one size fits all" solution. I expect there
will be some guidance but the decisions rest with the TSCs, the OE one
for git.oe.org and YP one for git.yp.org.

What may also be a bigger issue is member companies placing
requirements on the project.

Since we have deferred most issues regarding repos to the Maintainers
of those repos, so I would say we see what the maintainers want to
do. If there is no action from the maintainers then this would be
escalated to the appropriate TSC's and then the Board. Community
input is always helpful.

For layers not on project infrastructure, yes. For repos hosted on our
infrastructure I suspect the TSCs will aim for consistency. We do
mirror a number of repos which may be harder.

I would like OE and YP to align on whatever we decide to do and whilst
I can't say for sure they will, my voice on the TSCs will certainly be
aiming for that.

As a maintainer of a few layers, I plan on aligning with what the
kernel does and will be in-sync with the transition plan from OE/YP.

To be honest I'm not so interested what the kernel does. I'm more
interested in what git (as the tooling we rely upon) does.

I think what the kernel changes its master branch name to we should
follow. Regarding the other name changes, maybe aligning with
terminology changes the kernel does and what is left, maybe we
define those at that time. There is nothing we can do with recipes
that pull from dead projects that use some sort of cloning.

I think variable naming is for us to determine as appropriate. The
kernel's plans on branch names are one data point, I think git itself
is the most relevant.

6. Terminology. The Linux kernel project has put out some
recommendations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

We already reference the kernel for processes so what they do, I
think we just pick up unless we don't like what they did.

For some things we did look at what the kernel did and did something
different for very good reasons. Its a data point but I think its only
that.

Cheers,

Richard

On Wed, Jul 15, 2020 at 12:03 PM Eil?s N? Fhlannag?in
<pidge@...> wrote:

On Wed, Jul 15, 2020 at 6:31 AM Trevor Woerner <twoerner@...> wrote:

Hi,

As most are aware, there are efforts in many open-source/free-software
communities to adjust the language that is used throughout a given project
to be more inclusive.

We discussed this briefly at the most recent YP Technical Team/Engineering
Sync Meeting. Many good points were raised. I'd like to start a discussion on
this topic via email in order to enumerate and keep track of these efforts.

1. As a project we need to decide whether or not to undertake this work. Not
all projects have decided to make any changes. The discussions we had at the
last meeting made it feel as though it was a forgone conclusion by those who
spoke up that we would take on this work. Is that the consensus? Silence
represents agreement?

A note here, as I was talking with Paul Barker about this last week.

We've already done this in part of YP, in the now retired autobuilder
code base (about 6 years ago), removing master/slave terminology. So
there is precedent. I think it should be done, as much as it can be
done. Certainly WHITELIST/BLACKLIST type terminology at minimum.

If people find the terms whitelist/blacklist offensive I encourage
them to communicate this to the community. Other than the obvious
(which seems may be a coincidence?) I don't understand these words to
have racial connotations based on my interpretation of the etymology.

See this upvoted reply:
https://www.reddit.com/r/AskHistorians/comments/866ynp/what_are_the_origins_of_the_words_blacklist_and/

If this is incorrect or incomplete information I encourage others to
provide information which might help me broaden my understanding.

I guess this brings up another philosophical question. Should
terminology be changed to prevent people from possibly being offended
(due to misunderstanding) even if the words weren't used in an
offensive context or have an offensive origin?

2. Scope Creep. From the dawn of the OE project, there have been "discussions"
around variable/function names. In order to keep this work sane and concise, I
must insist that the scope of this work is "inclusive language" not "PN is too
cryptic for beginners, we should expand it to PACKAGENAME"

Agreed.

3. Deprecation Plan. Given the layered nature of the ecosystem, inevitably
there will be not-so-frequently-used layers out there that could stop working
entirely depending on how this work is implemented. Do we continue to support
the "old" language indefinitely? Do we have a flag day where everything
changes at once? Do we give warnings for X releases then have a cut off?

I think we need to do this responsibly, so yes, I'd be in favour of a
"here is our ideal, here is our deadline" and communicating that out
to all layer maintainers in layers.openembedded.org as well as the
mailing lists with a clearly defined set of goals and dates and doing
the things we can do to minimize build breakage between now and that
point.

-b

4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.

5. Backports. How far back do we make changes?

6. Terminology. The Linux kernel project has put out some recommendations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

To start the discussion, can we please get a consensus on item #1? If
positive, can we then work on whether we agree with the list of items (have I
forgotten anything, are there things to add to the list, or things to remove
from the list)? THEN can we please focus on each of the items from the list we
create?

I think that would be a more sane approach rather than trying to do everything
at once.

Best regards,
Trevor

On Wed 2020-07-15 @ 08:33:56 PM, Adrian Bunk wrote:

On Wed, Jul 15, 2020 at 01:31:34AM -0400, Trevor Woerner wrote:

...
4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.
...

If the word "master" alone is considered non-inclusive for people in
the US then CVs are also affected, like speaker bios at conferences.

What replacement term are US universities using for their M-word degrees?

This is a good question.

Some projects are replacing "master" in isolation; such as when used as a branch
name. Other projects are only replacing "master" when paired with "slave".

On Wed, Jul 15, 2020 at 01:31:34AM -0400, Trevor Woerner wrote:

...
4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.
...

If the word "master" alone is considered non-inclusive for people in
the US then CVs are also affected, like speaker bios at conferences.

What replacement term are US universities using for their M-word degrees?

Best regards,
Trevor

cu
Adrian

On Wed, Jul 15, 2020 at 6:31 AM Trevor Woerner <twoerner@...> wrote:

Hi,

As most are aware, there are efforts in many open-source/free-software
communities to adjust the language that is used throughout a given project
to be more inclusive.

We discussed this briefly at the most recent YP Technical Team/Engineering
Sync Meeting. Many good points were raised. I'd like to start a discussion on
this topic via email in order to enumerate and keep track of these efforts.

1. As a project we need to decide whether or not to undertake this work. Not
all projects have decided to make any changes. The discussions we had at the
last meeting made it feel as though it was a forgone conclusion by those who
spoke up that we would take on this work. Is that the consensus? Silence
represents agreement?

A note here, as I was talking with Paul Barker about this last week.

We've already done this in part of YP, in the now retired autobuilder
code base (about 6 years ago), removing master/slave terminology. So
there is precedent. I think it should be done, as much as it can be
done. Certainly WHITELIST/BLACKLIST type terminology at minimum.

2. Scope Creep. From the dawn of the OE project, there have been "discussions"
around variable/function names. In order to keep this work sane and concise, I
must insist that the scope of this work is "inclusive language" not "PN is too
cryptic for beginners, we should expand it to PACKAGENAME"

Agreed.

3. Deprecation Plan. Given the layered nature of the ecosystem, inevitably
there will be not-so-frequently-used layers out there that could stop working
entirely depending on how this work is implemented. Do we continue to support
the "old" language indefinitely? Do we have a flag day where everything
changes at once? Do we give warnings for X releases then have a cut off?

I think we need to do this responsibly, so yes, I'd be in favour of a
"here is our ideal, here is our deadline" and communicating that out
to all layer maintainers in layers.openembedded.org as well as the
mailing lists with a clearly defined set of goals and dates and doing
the things we can do to minimize build breakage between now and that
point.

-b

4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.

5. Backports. How far back do we make changes?

6. Terminology. The Linux kernel project has put out some recommendations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

To start the discussion, can we please get a consensus on item #1? If
positive, can we then work on whether we agree with the list of items (have I
forgotten anything, are there things to add to the list, or things to remove
from the list)? THEN can we please focus on each of the items from the list we
create?

I think that would be a more sane approach rather than trying to do everything
at once.

Best regards,
Trevor

Hi,

As most are aware, there are efforts in many open-source/free-software
communities to adjust the language that is used throughout a given project
to be more inclusive.

We discussed this briefly at the most recent YP Technical Team/Engineering
Sync Meeting. Many good points were raised. I'd like to start a discussion on
this topic via email in order to enumerate and keep track of these efforts.

1. As a project we need to decide whether or not to undertake this work. Not
all projects have decided to make any changes. The discussions we had at the
last meeting made it feel as though it was a forgone conclusion by those who
spoke up that we would take on this work. Is that the consensus? Silence
represents agreement?

Well, as I see it, the LF will make a ruling and then the Yocto Project with have to follow.  If OE decides not to change then this put the two projects at odds.

Since we have deferred most issues regarding repos to the Maintainers of those repos, so I would say we see what the maintainers want to do.  If there is no action from the maintainers then this would be escalated to the appropriate TSC's and then the Board.  Community input is always helpful.

As a maintainer of a few layers, I plan on aligning with what the kernel does and will be in-sync with the transition plan from OE/YP.

2. Scope Creep. From the dawn of the OE project, there have been "discussions"
around variable/function names. In order to keep this work sane and concise, I
must insist that the scope of this work is "inclusive language" not "PN is too
cryptic for beginners, we should expand it to PACKAGENAME"

3. Deprecation Plan. Given the layered nature of the ecosystem, inevitably
there will be not-so-frequently-used layers out there that could stop working
entirely depending on how this work is implemented. Do we continue to support
the "old" language indefinitely? Do we have a flag day where everything
changes at once? Do we give warnings for X releases then have a cut off?

I think a switch over plan and how that is communicated is the challenge.  We can not enforce bad actors in layers today so doing what we have done in the past seems more appropriate like, warns first then error out. This then places the burden on the user of the bad layers to go get them fixed.

4. What will be affected? Branch names, variable names, function names,
fetchers, patch file names, documentation… Given the fact we build code from
upstream projects, if we currently build from an upstream's master branch and
that upstream project never changes the name of their main branch away from
"master", I don't think there's anything we can do in those cases.

I think what the kernel changes its master branch name to we should follow. Regarding the other name changes, maybe aligning with terminology  changes the kernel does and what is left, maybe we define those at that time.  There is nothing we can do with recipes that pull from dead projects that use some sort of cloning. 

5. Backports. How far back do we make changes?

I would not suggest this as it  has the potential destabilize the current LTS version.  Not only that, there is product in the field already so altering older branches may introduce some instability.

6. Terminology. The Linux kernel project has put out some recommendations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

We already reference the kernel for processes so what they do, I think we just pick up unless we don't like what they did.

-armin

To start the discussion, can we please get a consensus on item #1? If
positive, can we then work on whether we agree with the list of items (have I
forgotten anything, are there things to add to the list, or things to remove
from the list)? THEN can we please focus on each of the items from the list we
create?

I think that would be a more sane approach rather than trying to do everything
at once.

Best regards,
	Trevor

Thank you Rich,

Am Mi., 15. Juli 2020 um 16:00 Uhr schrieb Rich Persaud <persaur@...>:

Since monoculture is the opposite of multiculture, hopefully each community can make choices appropriate to their project, rather than replacing an accidental/historical monoculture with an external monoculture that is equally a snapshot of time and space.

This is exactly what I wanted to convey. Couldn't word it any better way.