I seem to recall there be some discussion around doing this for the entire dist-git, which makes me wonder if we should wait on this and to it all at once or start with flatpaks now and use this namespace as a test bed.

Thoughts?

I seem to recall there be some discussion around doing this for the entire dist-git, which makes me wonder if we should wait on this and to it all at once or start with flatpaks now and use this namespace as a test bed.
Thoughts?

I would always be in favour of a single testbed rather than big bang approach just in case there are any unforeseen issues

There's definitely been discussion of master => rawhide for dist-git in general, but rawhide really doesn't work at all for the branch name for the rolling-stable approach we take for Flatpaks.

(E.g., at the moment we are building a F32 Inkscape against an F32 runtime on the master branch.)

So, I think this is going to be separate anyways - but could definitely be a testbed for a bigger branch rename.

I seem to recall there be some discussion around doing this for the entire dist-git, which makes me wonder if we should wait on this and to it all at once or start with flatpaks now and use this namespace as a test bed.
Thoughts?

I like using flatpaks as a test bed but I prefer using the same branch name for all the namespaces in dist-git rather than having each namespace their own default branch.

So, we are doing other src.fedoraproject.org repos tomorrow with rawhide/main as the new name.

I wonder if we couldn't just add 'stable' as another symref for flatpaks? or replace rawhide with 'stable' for them?

@pingou / @mohanboddu thoughts?

Is there some description of the behavior you are getting with symrefs? If I try adding a symbolic ref to a local repository and cloning that repository, I don't see the symbolic ref at all.

In general, I think it's important:
* That there's only one branch visible in pagure
* That 'git clone <repo>' lands you on branch called stable

We need 'fedpkg module-build' to reliably end up with a stream called stable with no possibility of mistake.

I basically think that anything other than a single default branch called stable is unnecessarily confusing, but could be convinced :-)

So, a symref just shows exactly the same as any branch, but the symref stays exactly the same as the branch it's associated with.
pagure has a setting for 'default branch', which is that you get if you clone and don't specify any branch.
Thats also what it shows by default in the web interface, etc.

https://src.fedoraproject.org/rpms/python-mechanize has been converted in prod. It has: no master branch, a rawhide branch (which is default) and a 'main' branch symref.

If you check out nothing, you get rawhide, if you specify rawhide you get rawhide, if you specify main you get main (but it's really rawhide).

a 'fedpkg module-build' in any of those checkouts would build the same thing.

Well, the only objection I have to just changing all flatpak's to use stable instead of master is that they would be different than all the rest of the repos.
But perhaps thats not a great big deal. @pingou and @mohanboddu have been doing all the work here, so I will let them chime in.

I'm pretty sure that without rpkg changes, building on rawhide will produce
a module build with the stream "rawhide" and building on main a module with
the stream "main", different versioning though the module contents would be
identical.

The stable branch of flatpaks does not follow the Fedora rahwide content
and doesn't have rawhide-like stability priorities. It's not rawhide.

So if we need to be the same as everything else, we'd need to move the
current "master" to stable and have a new rawhide/master branch with a "do
not use this" README.md.

I'd, however, prefer to just move master to stable.

We moved all the flatpak's to 'stable'