depends... in the current state of things, it should be opposite. Because every single day in master appear some new Requires/BuildRequires and so on. so tracking commits is way safer if you don't want to deal with huge amount of problems everytime someone pushes something to dist-git.

But generally I agree that packagers should use branches as refs

Ideally "arbitrary" branches that track upstream release schedules (like with modules, ahem).

Given the constraints of the traditional Fedora releases when it comes to dist-git branch names, perhaps we can find a way to recommend the use of named "module inclusion" tags instead?

For example, the system Python in Fedora 27 is 3.6, so all of the packages in the python3 and python3-ecosystem could have a "py3.6" tag that tracked the HEAD of their f27 branch. The python3:3.6 and python3-ecosystem:3.6 streams could then be defined as tracking those "py3.6" module inclusion tags, rather than any specific branch of the packages they need.

Once Fedora 28 happens, the "py3.6" tags in the various packages would switch over to the f28 branches, since the system Python will still be 3.6 at that point.

However, Fedora 29 will presumably be switching to Python 3.7, so the f29 branch would get a new py3.7 module inclusion tag, while the py3.6 tag would continue tracking the f28 branch.

If a Fedora release goes EOL before a module inclusion tag goes EOL, then the tag could be upgraded to be a new dist-git maintenance branch in the affected packages instead.

The current docs only talk about referencing by branches: https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/#_a_typical_modulemd_example

So I guess we can close this.