Hi @yulng. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Just curious, what is driving this PR? Is this standard practice? Does half our code base use uppercase and we are standardizing?

Just curious, what is driving this PR? Is this standard practice? Does half our code base use uppercase and we are standardizing?

I referred to this PR:https://github.com/containerd/containerd/pull/7668/files
, and I modified all the rest of it
Thanks

LOL, I was curious as well; do we know what drove #7668 ? (I see it was merged, but didn't explain "why" it was there)

LOL, I was curious as well; do we know what drove #7668 ? (I see it was merged, but didn't explain "why" it was there)

I LGTMed it after spot checking a number of common Linux userspace commands; all use lowercase for first letter in help/usage text, so maybe that was the original purpose--to align with a general/common practice.

Yeah, doesn't look like there's a common convention. GNU standards doesn't describe it; https://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces

I always considered them to use uppercase, as (in some cases) the description may not be / fit a single sentence, so punctuation could be needed. Looking at some random tools;

cURL: uppercase;

curl --help

 curl --help
Usage: curl [options...] <url>
 -d, --data <data>   HTTP POST data
 -f, --fail          Fail silently (no output at all) on HTTP errors
 -h, --help <category>  Get help for commands
...

kubectl; "paragraphs"

kubectl apply --help
...
Options:
    --all=false:
	Select all resources in the namespace of the specified resource types.

    --allow-missing-template-keys=true:
	If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to
	golang and jsonpath output formats.

runc: lowercase

runc create --help

...

OPTIONS:
   --bundle value, -b value  path to the root of the bundle directory, defaults to the current directory
   --console-socket value    path to an AF_UNIX socket which will receive a file descriptor referencing the master end of the console's pseudoterminal
...

docker: uppercase

docker run --help

...

Options:
      --add-host list                  Add a custom host-to-IP mapping (host:ip)
  -a, --attach list                    Attach to STDIN, STDOUT or STDERR

...

git (outputs man page content)

git commit --help

...

OPTIONS
       -a, --all
           Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
...

well, given we are half one way and half the other, we should either merge this PR or revert the other one :) I really don't have a strong opinion nor do I think there is any significant value in one or the other. We should just pick and move on @containerd/maintainers

slightly more formal and easier to read when adhering to case rules..

Not to deflect to another topic, but it is also easier to understand definitions/explanations of words when they do not repeat the word in the definition/explanation :-)

@containerd/maintainers we should come up with an overall opinion here and migrate them one direction or another

I also prefer uppercase as @thaJeztah mentioned "as (in some cases) the description may not be / fit a single sentence, so punctuation could be needed". Otherwise it'll be the 1st sentence starts lowercase but the 2nd sentence starts uppercase. An example:

$ runc create -h
...
OPTIONS:
... 
   --no-pivot                do not use pivot root to jail process inside rootfs.  This should be used whenever the rootfs is on top of a ramdisk
   --no-new-keyring          do not create a new session keyring for the container.  This will cause the container to inherit the calling processes session key

Also nerdctl uses uppercase (so does docker):

$ nerdctl -h
...
Management commands:
  apparmor   Manage AppArmor profiles
  builder    Manage builds
  container  Manage containers
  image      Manage images
  ipfs       Distributing images on IPFS
  namespace  Manage containerd namespaces
  network    Manage networks
  system     Manage containerd
  volume     Manage volumes

Commands:
  build       Build an image from a Dockerfile. Needs buildkitd to be running.
  commit      Create a new image from a container's changes
  completion  Generate the autocompletion script for the specified shell
  compose     Compose
  cp          Copy files/folders between a running container and the local filesystem.
  create      Create a new container. Optionally specify "ipfs://" or "ipns://" scheme to pull image from IPFS.
  events      Get real time events from the server
  exec        Run a command in a running container
...

Another case is kubectl which uses uppercase and seems use the same Usage to render their doc website. We probably won't do that but I feel uppercase does look better if they're used for this purpose :)

If there's no common convention, my 2c's is I'd prefer uppercase. Re-hashing the above comments, but most (meant to be ran by a user) container cmdline programs seem to be uppercase (adding in limactl for another example lima actually funnily enough has uppercase command blurbs, and lowercase flags), and it looks much nicer if we need to have > 1 sentence as already stated.

Modify all to uppercase
Thanks