search

NOAA-EMC / RDASApp

Regional DAS
GNU Lesser General Public License v2.1
1 stars 7 forks source link

Limit branches on the authoritative RDASApp repo #59

Open guoqing-noaa opened 3 weeks ago

guoqing-noaa commented 3 weeks ago

When we move forward, we will have many, many feature/bugfix/etc branches. If we put all those short-lived branches in the authoritative repo, it will get crowded.

I would suggest each developer make changes in the individual's fork instead of a branch in the authoritative RDASApp repo and then make a PR to commit back to the authoritative RDASApp repo.

ShunLiu-NOAA commented 3 weeks ago

Good suggestion. Let's discuss this in the next RRFS DA developer meeting.

guoqing-noaa commented 1 week ago

One risk for allowing users creating branches on the authoritative repo without a review process is that if someone accidently commit large binary data to his/her own branches on this repo, although the develop branch is not affected, it increases the repo's disk size and it is not trivial to remove those large binary files and hence the repo will normally always carry those binary data under-the-hood even no longer in use.

delippi commented 2 days ago

One risk for allowing users creating branches on the authoritative repo without a review process is that if someone accidently commit large binary data to his/her own branches on this repo, although the develop branch is not affected, it increases the repo's disk size and it is not trivial to remove those large binary files and hence the repo will normally always carry those binary data under-the-hood even no longer in use.

Hi @guoqing-noaa, I think this is a really great point. @ShunLiu-NOAA, this suggestion aligns with the code management policies that I copied from GSI. I think we should start enforcing that devs should work from their own forks. Is there a way to restrict the ability to create new branches on the main repo?

guoqing-noaa commented 2 days ago

@delippi Thanks for your input! We can NOT limit developers who have write access to this repo.

But we can move the majority of developers to triage access to avoid accidental commits while those having write access need to be careful not to push unexpected things to this authoritative repo.