@asamalik @nphilipp please review

Is there an open issue against dist-git and/or fm-orchestrator to support branch aliases? If we had that, then we could just add the relevant Fedora releases as branch aliases, and the traditional releases would automatically track the right branches.

Is there a specific rationale for dropping the leading f from these branch names?

Mostly looks good to me, just a couple of questions inline.

LGTM. I don't have any questions other than the two above.

I like the idea of branch aliases, but I don't think we need to have that figured out before merging this.

I would also prefer to have 'f27' and 'f28' instead of just '27' and '28' so it's consistent with what we already have.

I'm +1 for merging when at least the second question is answered/fixed.

Concur, having the "f" prefix makes it easier to tell if a stream/branch name is tied to the distro release or not.

Just a side thought, not relevant to the review: This requires an implicit or explicit knowledge about "branch Y is or isn't a progression from branch X". We can hardcode tools to assume that for f27, f28, … but I'm hesitant to put in heuristics for arbitrary versions. Let maintainers at some point define that e.g. "5.8" follows "5.7" for their module or component (and "strawberry" follows "tomato")?

I'm curious if we want to add all kinds of auxiliary files and directories that some random program may drop here. IMO these files/directories belong into the users' own gitignore files, see gitignore(5):

     ·   Patterns which a user wants Git to ignore in all situations (e.g.,
         backup or temporary files generated by the user’s editor of choice)
         generally go into a file specified by core.excludesFile in the
         user’s ~/.gitconfig. Its default value is       
         $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set
         or empty, $HOME/.config/git/ignore is used instead.

I think they should be in both places:

• in a repo they mean "Never commit these, regardless of which user does the commit" (helpful for beginners submitting PRs)
• in a user's config they mean "Never commit these, regardless of the repo I'm working on" (helpful for personal projects and collaborative projects that choose not to block commits of common editor and build tool artifacts)

so, i can't comment on the comments, which is annoying.

• re:aliasing) definitely should file something about aliasing. I would love that but didn't think was something git supported and wasn't sure if it was something any one would want to add
• re:27 vs f27) so, technically, the "branch" is the "27" branch, which is why I didn't have the "f" but, in retrospect is confusing, so I will modify it to use "f" even though it isn't quite "right"
• re: upgrade path) this is a known issue with modularity. I think we had proposed a way in the modulemd to specify "antecedents" to provide for this but currently we are cheating and relying on rpm monotonic version increase to solve this.

@langdon I'm sure you didn't mean to close this, right?

He did - replacement PR was https://pagure.io/modularity/pull-request/95