On Tue, Jul 13, 2021 at 6:52 PM Aurelien Bompard <abompard@xxxxxxxxxxxxxxxxx> wrote: > > Hey folks! > >> I think most of the repos just went with GitHub default, which recently changed from master to main. >> In Anitya and the-new-hotness I have: >> - master >> - staging >> - production >> The staging and production corresponds to deployment in OpenShift. This is why I named them like this. > > > I think a branch is a good opportunity to convey information about the branch's purpose. For example, "dev", "devel", "develop", "staging", "stable" and "production" are good names in my opinion, much better than "master" or "main" which are too generic. Do I get the production code if I clone "master" or "main", or do I get the development code? No idea. > So I'm in favor of having the following branches: > - either "dev", "devel", or "develop" Had a quick look, and there are over 50 already at "develop" as the main branch. -- most of the others are 'main' or 'master' -- so it looks like 'develop' is a bit of a standard already. --ryan > - either "stable" or "production" > For the apps that are deployed in Openshift, I also think it makes sense to have a "staging" branch that Openshift would trigger builds on. > > I've briefly looked at a few apps that we have in the Github org, and there's quite a few that have either "dev" or "develop" branches. The popularity winner between the two is not clear and I didn't want to write an actual script to check them all and exclude those who are obsolete, but feel free to do it if you have the itch ;-) (remember to check pagure too ;-) ) > > I think it would be easier for the infra & releng team to be able to expect some unified naming guidelines when maintaining the host of apps that we have, but maybe it's my projection. > If we decide on something, we can then let the project maintainers adjust when they feel the time is right, and it would be useful for new projects. > _______________________________________________ > infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
