Rename workloads according to new RHEL team nomenclature (kernel debug) (CASE-789)

[rlemosor]

No description provided.

[yselkowitz]

The changes to the content are fine, but I'm not thrilled about having to use the underscore as a separator between the SST name and the description in the filenames. Is it possible to still use underscores in the SST part of the filename while using hyphens in the content? (I see underscores as more connecting than hyphens, but maybe that's just me.)

[rlemosor]

The changes to the content are fine, but I'm not thrilled about having to use the underscore as a separator between the SST name and the description in the filenames. Is it possible to still use underscores in the SST part of the filename while using hyphens in the content? (I see underscores as more connecting than hyphens, but maybe that's just me.)

You had my thoughts exactly, Yaakov. But the hyphens are already used for the RHEL team names (this is because the underlying LDAP group doesn't admit underscores). So this left the underscores as the other "space-like" character to separate words.

In any case, you can also see hyphens as more connecting and underscores as space-like characters. In some languages (e.g. Portuguese), hyphens are used for the common language names of species that are compound (e.g. "peixe-espada-preto", black swordfish). Apparently this is a debatable convention in English for bird species.

[rlemosor]

For others who might encounter this PR and wonder what the logic applied was -- it was this:

• old YAML file name: sst_team_name-additional-workload-identifier.yaml
• new YAML file name: rhel-sst-team-name_additional_workload_identifier.yaml

[yselkowitz]

* new YAML file name: `rhel-sst-team-name_additional_workload_identifier.yaml`

I think my problem here is that it looks like name is connected to additional... in this way. What about rhel-sst-team-name-additional_workload_identifier.yaml?

[rlemosor]

But that way you can also argue that rhel-sst-team-name-additional are together and then workload_identifier is a separate thing.
What about this:
rhel-sst-team-name_additional-workload-identifier.yaml
?
This way, it's clear rhel-sst-team-name is one thing and additional-workload-identifier is another.
What do you think?

[yselkowitz]

In that case, what about rhel-sst-team-name--additional[-_]workload[-_]identifier.yaml, with two hyphens separating the SST name from the additional identifier, with either hyphens or underscores after that? That allows hyphens to be used in the SST name part and still provides a clear an unambiguous separator between the name and additional identifier.

[rlemosor]

That definitely works for me, thanks Yaakov.

[yselkowitz]

Blocking pending agreed-upon changes.

[rlemosor]

With your syntax it's even better: we won't have to rename the "additional workload identifier" bit at all.

[rlemosor]

Sorry for the noise here. Two weird things happened:

1. The GitHub web IDE wouldn't let me commit to my own main branch, it asked me to create a patch-1 branch in my fork. I did so, and was about to merge a PR between branches in my own fork and referenced this PR for context, unaware this PR would also show the cross-reference in the history (hence some noise). I then redid the changes directly in main.

2. However, I later realized this PR was referencing as base a master branch, which was my default. Wiling to redo the changes, I renamed it to main, GitHub seems to have now lost the reference with respect to the base branch of this PR (here it believes it's been deleted). Accordingly it won't let me change the base branch unless I restore the branch. I'll restore it just so this PR is still useful. In subsequent PRs, I'll use my main (renamed from master) as base.

[rlemosor]

@yselkowitz , I think this is finally where we want it. How is the "changes requested"' thing cleared? Is it with a manual ack from your side? If all's well here, I'd do a series of other PRs like it (also with Connie Betts).