Date
1 - 20 of 33
inclusive language
|
Trevor Woerner
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? 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? 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 |
|
|
|
Jacob Kroon
On 7/15/20 7:31 AM, Trevor Woerner wrote:
Hi,I guess one way to answer that question would be an anonymous voting ? Jacob |
|
|
|
Rich Persaud
On Jul 15, 2020, at 01:31, Trevor Woerner <twoerner@...> wrote:
Is there a YP mailing list where the minutes of the YP meeting were posted? 1. As a project we need to decide whether or not to undertake this work. NotAlso discussed at the June 24th, 2020 OpenEmbedded Happy Hour, where many points were raised without foregone conclusions. 6. Terminology. The Linux kernel project has put out some recommendations:From the Linux coding style diff, "avoid introducing new usage", refers to new names, rather than changing existing systems with consequential impact on distributed supply chains for live systems. To start the discussion, can we please get a consensus on item #1?It would be helpful to define the work being proposed ("whether or not to undertake this work"), before seeking new funding for the proposed work, from YP or OE stakeholders. Rich |
|
|
|
Josef Holzmayr
Howdy!
See opinions and comments inline and below. Am Mi., 15. Juli 2020 um 07:31 Uhr schrieb Trevor Woerner <twoerner@...>: As most are aware, there are efforts in many open-source/free-softwareI explicitly welcome the awareness and think we should go forward with this. 2. Scope Creep. From the dawn of the OE project, there have been "discussions"Fully agreed. 3. Deprecation Plan. Given the layered nature of the ecosystem, inevitablyThis is the first time where I'll cite Torvalds "WE DO NOT BREAK USERSPACE!". And any name-shuffling that breaks builds just for the sake of "inclusion" will have the exact opposite effect: it "excludes" the users, and we get the not-so-benevolent dictator label. Plus, we serve a business case. Name-shuffling is fine if we're talking about a hobbyist project that can break whatever it likes, but for the industrial use case breaking stuff just for the sake of "we decided that this name is not cool anymore" is a total no-go in my opinion. 4. What will be affected? Branch names, variable names, function names,Everything that is newly introduced shall be affected, Whenever something new gets into the system, we shall take care to make sure all best naming practises at the time of the introduction are adhered. But once it is in, it is in. 5. Backports. How far back do we make changes?Not at all. 6. Terminology. The Linux kernel project has put out some recommendations:Hopefully not getting into a flamewar now, but I have to point out that these recommendations are, again, extremely US-centric. For example, me being German, the term "leader"(Führer) is highly loaded. So who has the right to decide that this is better than "master" which is the exact opposite of loaded in German ("Meister") , and only denotes a somewhat high degree of competence at something? So in a nutshell, I agree with the conclusion Jon draw in https://lwn.net/Articles/823224/ - we must go forward and improve, but not at the very real cost of breaking stuff and making on part of the users unhappy just to make another group of people happy. My $.02, you may beat me now.
|
|
|
|
Trevor Woerner
On Wed 2020-07-15 @ 03:05:38 AM, Rich Persaud wrote:
On Jul 15, 2020, at 01:31, Trevor Woerner <twoerner@...> wrote:I post them on the yocto mailing list in plain text with formatting, or youWe discussed this briefly at the most recent YP Technical Team/EngineeringIs there a YP mailing list where the minutes of the YP meeting were posted? can see them all collected here in google docs: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit I haven't done today's posting yet. They usually have a title something along the lines of: Yocto Technical Team Minutes, Engineering Sync, for <date> This email is my attempt to get everyone together on this topic since,1. As a project we need to decide whether or not to undertake this work. NotAlso discussed at the June 24th, 2020 OpenEmbedded Happy Hour for now, email is one of this project's main channels for communication. Yesterday's call was the first time I had heard anyone bring it up (except for Richard's email about some upstream projects no longer having a master branch). where manyI'm merely pointing out the conversation went straight into getting a feeling for what was involved. Fair enough.6. Terminology. The Linux kernel project has put out some recommendations:From the Linux coding style diff, "avoid introducing new usage", refers to new names, rather than changing existing systems with consequential impact on distributed supply chains for live systems. Where did you read anything about looking for funding? |
|
|
|
Trevor Woerner
Hi Josef,
On Wed 2020-07-15 @ 09:11:44 AM, Josef Holzmayr-Khosh Amoz wrote: My $.02, you may beat me now.Not at all, your opinion is very much appreciated! Thank you for your input. I think, as a project, we need to have a position on this, and you've contributed to the discussion in a positive way. I'm sure there are others who will agree with you (whether or not we hear from them is another story); my hope is that we reach _some_ consensus. Best regards, Trevor |
|
|
|
Trevor Woerner
Hi Jacob,
On Wed 2020-07-15 @ 09:02:57 AM, Jacob Kroon wrote: I guess one way to answer that question would be an anonymous voting ?Good point. I wonder where we are on the topic of anonymous voting? I think someone was working on this for various other purposes (electing TSC members, various voting for OE things). Anyone have more info? Best regards, Trevor |
|
|
|
On Wed, 15 Jul 2020 at 06:31, Trevor Woerner <twoerner@...> wrote:
Review comments will likely appear when patches are submitted. On that note, I recommend we move the coding style documentation from the wiki into the oe-core git repository so that changes can be reviewed in the normal way. Right now it's at https://www.openembedded.org/wiki/Styleguide and https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines which have no review process for changes and are often missed by new contributors who don't know where to find them. Agreed. Also, we should focus on Bitbake and OpenEmbedded terminology, we can't fix the terminology of all packages for which we have recipes. I recommend we introduce new terminology with backwards-compatible aliases in the 3.2 release if possible, 3.3 if not. Some magic may be needed for variable flags if we rename PNBLACKLIST. At this point the documentation should use new terminology with old naming used only in a migration guide. Backwards-compatible aliases should be removed in release N+1 or even N+2 if necessary. Let's focus on terminology introduced by Bitbake and OpenEmbedded itself. That should be enough to get us started, if we want to change anything else we can do that in a later phase. We should leave existing releases as-is. I think this is an excellent list. Note that it doesn't say anything about the use of 'master' alone without corresponding 'slave' terminology. GitHub has championed using 'main' instead of 'master', personally I'd prefer 'dev' as it's more descriptive of the status but this is how bikeshedding begins. I recommend we start by adopting the changes in the kernel commit above, if we want to rename 'master' we can do that in a later phase. I recommend we start by having someone submit a patch to add a coding style document to the oe-core repository. That can be reviewed in the usual way. We can then proceed to implement the new coding style in a backwards compatible way over the next few months as development resources permit.
-- Paul Barker Konsulko Group |
|
|
|
Richard Purdie
Thanks for bringing this up and writing a summary. The OE and YP TSCs
are aware of this and are starting to have discussions about it. I have also been looking at what other projects and the Linux Foundation are doing. As yet there aren't any real conclusions, I've been kind of waiting for git itself to make a decision as that could significantly influence what we do for practical reasons. On Wed, 2020-07-15 at 01:31 -0400, Trevor Woerner wrote: As most are aware, there are efforts in many open-source/free-softwareThe challenge with this topic is that anyone arguing against it potentially ends up being branded as unsupportive of certain groups at best and racist and worse at worst. That is not a good position to have to make decisions from, it does feel like there is no choice in the matter and we'll have to do something or perhaps anything and everything. 2. Scope Creep. From the dawn of the OE project, there have been "discussions"Shouldn't that be RECIPENAME? ;-) I think my reply (which was my first thought) proves your point! :) There is a valid argument that some variable names are problematic and we don't change them simply due to the pain involved. If we are changing them, we should aim to get them right? As one of the maintainers, I actually get really depressed when people say "what kind of a person picked a name like this". Naming is much harder than people think. I've been responsible for some of it and don't like some of the end results we've had, equally, I struggle to come up with better ideas for some areas. 3. Deprecation Plan. Given the layered nature of the ecosystem, inevitablyThe good news is that there is a way for layers to mark what they're compatible with and they have to opt in with each new release. As such I suspect we could move fairly quickly and in most cases just error out if/where old names were used? 4. What will be affected? Branch names, variable names, function names,We are not responsible for other other upstreams, we will just follow their lead. As such for example I don't think we should take patches changing terminology in upstream software. I think all the things you mention are things we will have to look at. Some aren't a big issues and easy to change, the branch and variable names are probably the most problematic. 5. Backports. How far back do we make changes?This is where it gets potentially most worrying. For example, does the project promote racism if it doesn't take the changes back into the LTS? Does having the LTS and master diverge make things more or less difficult to maintain. We might make a decision now but what will 'peer' pressure look like 1 or 2 years into the LTS? 6. Terminology. The Linux kernel project has put out some recommendations:I don't see that anyone can realistically argue against 1 for the reasons I mention above, regardless of what they might think. My personal position (not a project one) is that I do see the issues in the terminology and I appreciate the community's desire to want to do something about it, I want to support that. I do however worry that its going to cause weeks of work in dealing with the fallout from changes and a lot of that will end up falling to me personally as few people step up to do that kind of thing beyond the first patch. The kind of thing I'm referring to isn't writing the patches to change something, or coming up with a plan for that. Its writing replies like this to discussion on the mailing list or explaining to a user on irc that they're using docs for "pre-change" and they need the "post- change" docs, updating the docs themselves (we don't have a docs maintainer right now, I'm kind of doing it) or attending the bug triage call and figuring out how to deal with issues (who takes these bugs?). Is this a good way to spend the time? Would that time be better spent helping some new users and getting new active maintainers involved with the project? Difficult to say. Assuming the answer is yes, we need to do something (I really can't see any other way forward), some logical next steps and places to start are: a) Find a list of patches that need renaming and send patches to rename them. This shouldn't be an issue. b) Create a list of function names that need renaming. Patches to handle those also shouldn't be too invasive. c) Create a list of problematic variable names so we can understand the scope of that problem. We can then formulate plans around them on a case by case basis. For branch naming there is potential impact on the infrastructure and demands on Michael's time as well as mine, depending on what we might do there. There are large chunks of code like the autobuilder codebase which have limited numbers of contributors yet are key to the project's health. I think its going to be the most invasive area to change, how invasive will depend on exactly what we do, assuming we do it. Cheers, Richard |
|
|
|
Josef Holzmayr
Just focusing on points that are prominent to me. Comments inline.
Am Mi., 15. Juli 2020 um 11:12 Uhr schrieb Richard Purdie <richard.purdie@...>: I don't see that anyone can realistically argue against 1 for theFully agreed. One of the things I loathe most is that someone puts burdens on us (and you specifically, Richard!), just to make themselves feel better, like "Hey, I did the rename, I'm awesome!". This has to be avoided. And I do not realistically see that happening, hence I oppose renaming just for the sake of renaming. On a more philosophical note, this sounds very much like "rewriting" history. Not in the exact sense as git does not forget anything, but in the face-value meaning. And, again in my explicitly own opinion, that has never ever worked. I always vote for old errors and mistakes to be kept visible, so there can be lessons learned. This should not be taken too easily. "We have always been at war with Eastasia". My $.02 |
|
|
|
Philip Balister
toggle quoted message
Show quoted text
On 7/15/20 4:33 AM, Trevor Woerner wrote:
Hi Jacob, |
|
|
|
Philip Balister
On 7/15/20 4:38 AM, Paul Barker wrote:
I'm old we should rename "master" to "trunk".6. Terminology. The Linux kernel project has put out some recommendations:I think this is an excellent list. Philip I recommend we start by having someone submit a patch to add a coding |
|
|
|
Bruce Ashfield
On Wed, Jul 15, 2020 at 3:12 AM Josef Holzmayr-Khosh Amoz
<jester@...> wrote: This is actually the most interesting point to me. In anything we undertake, the higher level goals should be stated (not just a technical document with rename mappings), that the effort is being done with the best intentions, if mistakes happen the effort will evolve over time, and the language that is being used as the baseline. Living in an officially bilingual country, speaking 3 (or 4 if you are generous) languages, there are many words which are offensive to one language/culture and not to others (or are just downright funny when heard to the non native speakers' ears). I'd think our European community members are very familiar with this (even more than some other regions). My main point is that deciding to do something is the easy part, coming up with the plan will take some time (due to the above and many more issues) and the implementation/stabilization even more time (I'm stating the obvious). So we should go into this with eyes wide open that it won't be trivial or necessarily quick to do. Cheers, Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II |
|
|
|
Rich Persaud
On Jul 15, 2020, at 05:12, Richard Purdie <richard.purdie@...> wrote:
In comparison to Github (hundreds of employees, sold for billions) or the Linux kernel with contributors from large commercial ecosystems (e.g. RedHat/IBM and Google/Android), OE was architected by a smaller set of volunteers and companies. With less resources, careful scheduling can reduce disruption and maximize confidence in shared decisions. Practically: are there companies who would stop contributing to OE until names are changed? Are there consumers of OE-based equipment who would boycott said equipment until names are changed? If yes, would those companies offer funding to make their requested changes? If not, such change requests could join the backlog for de-dupe alongside related changes to core components. If there were a negative campaign planned against OE, it would inadvertently provide OE with much-needed publicity, especially after appropriate changes could be agreed by the community in a shared decision. Rushed, pre-emptive changes in fear of such a campaign would be more effort for less impact. And no, this is not a challenge! The context of decisions matter. At this halfway point of 2020, it feels less coherent than previous years, with unpredictable events competing for reduced financial and psychological resources, among geographies and companies. This year is also missing in-person meetings like OEDAM, for consensus-building on complex issues. U.S. FTC mandates [1] a cooling-off period for some transactions made in temporary locations. With many people isolated from in-person social interaction, and the unfettered power of social media to propagate ideas online without substantive debate, the "temporary locations" of 2020 are not conducive to making decisions with long-lasting stability. A cooling-off period would enable limited OE resources to be later deployed in service of a broader consensus.
We could aim for the next LTS, which would be released in late 2021? The time between now and early 2021 could be used to learn from the broader OE ecosystem and reach consensus on naming-related changes, with May 2021 commit to the release that will become YP LTS in late 2021. Ideally with the benefit of an in-person OEDAM in early 2021.
OpenEmbedded's uniquely flexible layer mechanism enables granular overrides and "loose coupling" of requirements that would otherwise lead to forks. Although OE is more bazaar than cathedral, there can be periods of focus which consolidate organic patterns. How might OE evolve to be less fragile to some name changes? While the project is incurring the cost of intrusive changes and validation for non-regression, can we use this rare opportunity to make namespace-related improvements that would otherwise be difficult to coordinate? In terms of matching donations: contrition for the past can be matched with an architectural investment in future flexibility. Finally, for a diversion into semantics and perception of language, consider this 1960s variant of English, E-Prime, which excluded the verb "to be". It's a thought experiment about our expectations of language. The more we understand the limits of a tool, the better we can use the tool appropriately. Rich |
|
|
|
Rich Persaud
On Jul 15, 2020, at 09:20, Philip Balister <philip@...> wrote:
Here's the etymology of "main", which does not inspire non-Borg feelings of inclusiveness: Old English mægen (Mercian megen) "power, bodily strength; force, violent effort; strength of mind or will; efficacy; supernatural power," from Proto-Germanic *maginam "power" (source also of Old High German megin "strength, power, ability"), suffixed form of PIE root *magh- "to be able, have power." Original sense of "power" is preserved in phrase might and main. Also used in Middle English for "royal power or authority" (c. 1400), "military strength" (c. 1300), "application of force" (c. 1300). |
|
|
|
Josef Holzmayr
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. |
|
|
|
On 7/14/20 10:31 PM, Trevor Woerner
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? 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. 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.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 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.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 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.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 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 |
|
|
|
Eilís Ní Fhlannagáin
On Wed, Jul 15, 2020 at 6:31 AM Trevor Woerner <twoerner@...> wrote:
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. Agreed. 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
|
|
|
|
Adrian Bunk
On Wed, Jul 15, 2020 at 01:31:34AM -0400, Trevor Woerner wrote:
...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,cu Adrian |
|
|
|
Trevor Woerner
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:This is a good question....If the word "master" alone is considered non-inclusive for people in 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". |
|
|