On Wed, Jul 15, 2020 at 3:12 AM Josef Holzmayr-Khosh Amoz <[email protected]> wrote: > > Howdy! > > See opinions and comments inline and below. > > Am Mi., 15. Juli 2020 um 07:31 Uhr schrieb Trevor Woerner > <[email protected]>: > > 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? > > I 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" > > 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" > > Fully 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? > > This 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, > > 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. > > 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: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb > > 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?
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 > > 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. > > > > > 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 > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1129): https://lists.openembedded.org/g/openembedded-architecture/message/1129 Mute This Topic: https://lists.openembedded.org/mt/75515261/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
