On Wed, Jul 15, 2020 at 6:31 AM Trevor Woerner <[email protected]> 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 >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1134): https://lists.openembedded.org/g/openembedded-architecture/message/1134 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]] -=-=-=-=-=-=-=-=-=-=-=-
