Skip to content

Tidy up non-active branches #3321

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nickrandolph opened this issue Jun 4, 2020 · 15 comments
Closed

Tidy up non-active branches #3321

nickrandolph opened this issue Jun 4, 2020 · 15 comments
Assignees
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior improvements ✨ maintenance ⚙️ open discussion ☎️
Milestone

Comments

@nickrandolph
Copy link

There are currently 118 branches with no coherent branching strategy.

To make it easier for contributors, please:

  • purge non-active branches
  • adopt a model where contributors (all) work in private forks and push all changes via a PR to the main WCT repo
  • if some contributors continue to work on main repo, please propose a branching strategy that makes sense
@nickrandolph nickrandolph added the bug 🐛 An unexpected issue that highlights incorrect behavior label Jun 4, 2020
@ghost ghost added the needs triage 🔍 label Jun 4, 2020
@ghost
Copy link

ghost commented Jun 4, 2020

Hello nickrandolph, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

@Kyaa-dost
Copy link
Contributor

@nickrandolph Thanks for highlighting the issue. We will discuss these options and explore ways we can improvise the process 🙌

@michael-hawker michael-hawker added this to the 7.0 milestone Jun 23, 2020
@michael-hawker
Copy link
Member

As a note to my future self, we should also document how we work with branches and what our current active branches are.

@michael-hawker michael-hawker self-assigned this Jul 28, 2020
@nickrandolph
Copy link
Author

nickrandolph commented Sep 15, 2020

cc @nmetulev @hermitdave @cbarkerms @clairernovotny @VisualByteStudios @deltakosh @jwilcox1701 @normesta @rjmurillo @TGoodhew @JustinXinLiu
Can you please review any branches that you have and delete them if they're no longer relevant. If relevant, can you rebase them so we know they're still active
I know this is a road map item but the admin responsibility shouldn't just fall on @michael-hawker

@michael-hawker
Copy link
Member

Thanks @nickrandolph, @Kyaa-dost @RosarioPulella and I went quickly over them this morning as well, there are a lot I know from some folks which are just stale and we can get rid of from past projects too. 🙂

@Kyaa-dost I think you have the right permissions to get rid of ones from tgoodhew, rjmurillo, and jwilcox1701 that we know are all from past projects?

@TGoodhew
Copy link
Contributor

If you need me to I'm happy to delete those old dead decaying and, frankly, somewhat smelly branches with tgoodhew on them.

@Kyaa-dost
Copy link
Contributor

Thanks, @michael-hawker will clean it up. @TGoodhew if you have any stale branches that are closed or non-active please feel free to delete them, thanks 😄

@TGoodhew
Copy link
Contributor

Just tried - Looks like I don't have permissions - Sorry

@nickrandolph
Copy link
Author

@Kyaa-dost / @azchohfi are you able to assist @TGoodhew with tidying up branches?

@Kyaa-dost
Copy link
Contributor

@nickrandolph Yes, all clear!

@michael-hawker
Copy link
Member

Things are looking a lot better now, appreciate everyone's help on this project!

Wondering if we want to close down write access to the repo to force people to have to submit from forks? Thoughts?

@Kyaa-dost
Copy link
Contributor

Kyaa-dost commented Jan 11, 2021

Wondering if we want to close down write access to the repo to force people to have to submit from forks? Thoughts?

I think that's a great idea as there is still a possibility of mishaps. This will be one way to stop and we can always provide Write access to individuals based on requests or severity of the work.

@Nirmal4G
Copy link
Contributor

I propose that we use git flow for branching strategy and Fork-PR model for contributing.

  • Only have master, develop, release branches in the main repo.
  • Then have specific hotfix and feature branches according to severity of the work so that the other contributors know what's happening.
  • Experiments and regular contributions can still happen via Fork-PR model.

Also, with explosion of the UWP Controls projects, the naming of folders is becoming long with Microsoft.Toolkit prefixing everywhere. May be a subfolder organization might do some good.

@michael-hawker
Copy link
Member

@Nirmal4G yeah. I'm thinking of locking down write access on the main repo, as we can just fork and do PRs for the things we need, and only admins do the release work anyway currently.

There's a couple of branches we can't delete (one of them is odd and like a zombie (https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/DwayneUWPCTKSandbox - can't get rid of it).

Going to close this issue for now. @Kyaa-dost we should probably open up an issue around this topic and better guidance in our Wiki repo from the governance side.

At least from an action of the original intent of the issue, I think we're good. Thanks for the help @nickrandolph!

@DLamb-MagicLeap
Copy link
Contributor

DLamb-MagicLeap commented Mar 9, 2021 via email

@ghost ghost locked as resolved and limited conversation to collaborators May 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior improvements ✨ maintenance ⚙️ open discussion ☎️
Projects
None yet
Development

No branches or pull requests

6 participants