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-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? The 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" > 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" 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, 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? The 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, > 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. 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: > 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. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1125): https://lists.openembedded.org/g/openembedded-architecture/message/1125 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]] -=-=-=-=-=-=-=-=-=-=-=-
