For example below features is useful?

Feature 1

For modules/foo/foo.yaml
Set default: true to use it as default profile.

data:
    profiles:
        foo:
            rpms:
                - foo
        foobar:
            default: true
            rpms:
                - foo
                - bar

Feature 2

Just 1st element of /data/profiles array object becomes the default profile.

data:
    profiles:
        foo: <== recognized as a default profile by system.
            rpms:
                - foo
        foobar:
            rpms:
                - foo
                - bar

I like to minimize a operation to manage each module.

Why the module's default profile information is managed in this repository separately from each modules/foo/foo.yaml like https://src.fedoraproject.org/modules/ruby/blob/master/f/ruby.yaml?
Is it better that each modules/foo/foo.yaml can manage this info in their file, isn't it?

It cannot be part of the dist-git repo because this information can be different for different releases of Fedora. Fedora 30 and Fedora 31 can each have nodejs:10 and nodejs:12 module streams available, but the default on F30 and F31 will be different.

It's less likely (but not impossible) for the default profiles of a stream to differ between releases as well.

Fedora 30 and Fedora 31 can each have nodejs:10 and nodejs:12 module streams available, but the default on F30 and F31 will be different.

I guess this is the setting of nodejs:10 and nodejs:12 F31.
https://pagure.io/releng/fedora-module-defaults/blob/master/f/nodejs.yaml
I guess this is the setting of nodejs:10 and nodejs:12 F30.
https://pagure.io/releng/fedora-module-defaults/blob/f30/f/nodejs.yaml

It looks both are same.
How the settings describe the status "the default on F30 and F31 will be different"?

modues/*/mudulemd.yaml has already had a yaml element to control different platform's situation with /data/depenencies/*/platform.
I think controlling the default profile for different platform such as F30, F31 is natural in the same scope.

modues/*/mudulemd.yaml

data:
    dependencies:
        - buildrequires:
            platform: [-f28]
          requires:
            platform: [-f28]

For example, in case of nodejs:10 and nodejs:12, below logic can describe different default profiles for different stream branch (10, 12) and different platform (f30, f31).

The logic is

For example, with below modules/nodejs "10" branch's nodejs.yaml.

• If /data/profiles/<profile_name>/default exists and the instance's class is boolean and "true", set the as default profile.

default_profile_dict = {
  "f31": "foo"
  "f30": "foo"
  "f29": "foo"
}

• Then if /data/profiles/<profile_name>/defaultexists and the instance's class is array, check the value, and override by the value.

default_profile_dict = {
  "f31": "foobar"
  "f30": "foo"
  "f29": "foo"
}

modules/nodejs
"10" branch's nodejs.yaml

data:
    profiles:
        foo:
            default: true
            rpms:
                - foo
        foobar:
            default:
                - f31
            rpms:
                - foo
                - bar

modules/nodejs
"11" branch's nodejs.yaml can be also managed with different settings like this.

data:
    profiles:
        aaa:
            default: true
            rpms:
                - foo
        bbb:
            default:
                - f30
            rpms:
                - foo
                - bar

I think covering everything about modules/* by a modulemd.yaml is a better experience for users to manage.
Seeing how Travis CI have been used widely nowadays. Users can manage Travis CI by focusing only .travis.yml file's content.
You can also stop to merge addtional yaml files in fedora-module-defaults repo manually.

Fedora 30 and Fedora 31 can each have nodejs:10 and nodejs:12 module streams available, but the default on F30 and F31 will be different.

I guess this is the setting of nodejs:10 and nodejs:12 F31.
https://pagure.io/releng/fedora-module-defaults/blob/master/f/nodejs.yaml
I guess this is the setting of nodejs:10 and nodejs:12 F30.
https://pagure.io/releng/fedora-module-defaults/blob/f30/f/nodejs.yaml
It looks both are same.
How the settings describe the status "the default on F30 and F31 will be different"?

Pay attention to the tense. I said "will be", not "are". They will be different before F31 ships, but we're still updating dependencies so they can run with 12.x, so we haven't swapped the default yet.

modues//mudulemd.yaml has already had a yaml element to control different platform's situation with /data/depenencies//platform.
I think controlling the default profile for different platform such as F30, F31 is natural in the same scope.

One fundamental problem with this is that it means you have to force a rebuild of a module to change the defaults.

Another is that we have policies that require FESCo approval on changes to default streams, which is far easier to manage with a central location to set them.

Keeping the defaults in fedora-module-defaults is analogous to how we keep system service defaults in the fedora-release package; it's one place to pay attention to and to make changes without needing to rebuild packages.

Pay attention to the tense. I said "will be", not "are". They will be different before F31 ships, but we're still updating dependencies so they can run with 12.x, so we haven't swapped the default yet.

Sorry. I understood it.

One fundamental problem with this is that it means you have to force a rebuild of a module to change the defaults.

I do not understand why it is a problem.
Changing a module setting, release the new build. What can be the problem?

Another is that we have policies that require FESCo approval on changes to default streams, which is far easier to manage with a central location to set them.

Default streams?
Is it not default profiles?
I am talking about default profiles. not about default streams.
And I think this repository manages the default profile information, right?

When FESCo can manage the default profiles, each packager can change a list of /data/profiles/default/rpms in their responsibilities.

Nodejs module packager change the list of rpms of default profile without an approval of FESCo.

https://src.fedoraproject.org/modules/nodejs/blob/12/f/nodejs.yaml

data:
...
  profiles:
    default:
      rpms:
      - nodejs
      - npm

to

data:
...
  profiles:
    default:
      rpms:
      - nodejs
      - npm
      - foo

So, this can not say that FESCo manages the content of the profile.

Keeping the defaults in fedora-module-defaults is analogous to how we keep system service defaults in the fedora-release package; it's one place to pay attention to and to make changes without needing to rebuild packages.

What is the system service defaults? Where is the actual code in below file?
I do not understand it.
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-release.spec

Thanks for your replying.

Pay attention to the tense. I said "will be", not "are". They will be different before F31 ships, but we're still updating dependencies so they can run with 12.x, so we haven't swapped the default yet.

Sorry. I understood it.

One fundamental problem with this is that it means you have to force a rebuild of a module to change the defaults.

I do not understand why it is a problem.
Changing a module setting, release the new build. What can be the problem?

Well, the biggest one is that module builds can take an extremely long time. Node.js for example tends to take around four hours to rebuild. Doing so for a trivial metadata change would be unpleasant.

Another is that we have policies that require FESCo approval on changes to default streams, which is far easier to manage with a central location to set them.

Default streams?
Is it not default profiles?
I am talking about default profiles. not about default streams.
And I think this repository manages the default profile information, right?

Same arguments apply. While uncommon, it's not impossible for us to want different default profiles for a stream on different releases.

When FESCo can manage the default profiles, each packager can change a list of /data/profiles/default/rpms in their responsibilities.
Nodejs module packager change the list of rpms of default profile without an approval of FESCo.

Keeping the defaults in fedora-module-defaults is analogous to how we keep system service defaults in the fedora-release package; it's one place to pay attention to and to make changes without needing to rebuild packages.

What is the system service defaults? Where is the actual code in below file?
I do not understand it.
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-release.spec
Thanks for your replying.

https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/90-default.preset

Well, the biggest one is that module builds can take an extremely long time. Node.js for example tends to take around four hours to rebuild. Doing so for a trivial metadata change would be unpleasant.

I think the program to build a module does not have to build every time.

Instead, the building program can check some YAML elements of a modulemd.yaml,
Then if necessary elements are changed, execute the build. otherwise does not build.

I suppose the program has database of the latest build for each module.

Just compare both the info in database and current build, then build it conditionally.
If only stream or profile are changed, do not build.

There is an another ticket for user to control the build.
https://pagure.io/fm-orchestrator/issue/1274

It 's good option. But I prefer the centralized program does this than that.

I think this fedora-module-defaults workflow become harder when the number of module increase. Do you like to check each module's change, considering the conflict manually in this repository.

Same arguments apply. While uncommon, it's not impossible for us to want different default profiles for a stream on different releases.

The default profile can connect for the stream branch.
So, if we can implement it, I would prefer the logic to modulemd.yaml.

$ sudo dnf module install ruby:2.5

=> Then a profile "default" is used in case of ruby.

default stream is common across stream branches.

$ sudo dnf module install ruby

The stream "2.5" is used for example.

If we can implement it, I prefer the config file is put on the default (master?) branch of the modules/ruby.

This approach is used for GitHub's issue template. This is good example.

Issue template feature is common across branches.
https://help.github.com/en/articles/about-issue-and-pull-request-templates

Issue templates are stored on the repository's default branch, in a hidden .github/ISSUE_TEMPLATE directory. If you create a template in another branch, it will not be available for collaborators to use.

Another is that we have policies that require FESCo approval on changes to default streams, which is far easier to manage with a central location to set them.

Yes, I just found that it was approved like this. This opertion looks hard when the number of modules will be increased.

set default module stream for cri-o
https://pagure.io/fesco/issue/2135