Skip to content
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

Archival and branch protection #18

Open
mwakok opened this issue Jan 31, 2024 · 2 comments
Open

Archival and branch protection #18

mwakok opened this issue Jan 31, 2024 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@mwakok
Copy link
Collaborator

mwakok commented Jan 31, 2024

Hi @wmotion,

I see in the branch rules that all branches are by default protected and only accept new commits through pull requests. Was this setup chosen to ensure the branches remain available in the future? If not, what is the reason for this protection?

If so, I would like to propose a different setup as the current one introduces issues with using gitautopush. Currently, only members with admin rights would be able to push directly to a branch. Although almost everyone is currently an admin (not a smart setup), this setup would defeat its purpose in my opinion.

Instead of relying on branch protection, couldn't we make use of tags(/releases) for archival purposes? By adding a tag to the branch after the workshop (or even creating a release to create an easy-to-download zip-file) we can avoid the use of generic branch protection and in fact delete branches of previous workshops altogether. With a tag in place, you would always be able to restore a branch.

Let me know what you think

@mwakok mwakok added the question Further information is requested label Jan 31, 2024
@wmotion
Copy link
Collaborator

wmotion commented Jan 31, 2024

@mwakok Fine with this suggestion. The old setting had not much thinking behind it, and I am very glad to be led there. I cannot think of any objection to a leaner setting, so long as the people changing this repo are recognised members of the 4TU.R*D* organisation. Anything that is in keeping with the general usage principles of the organization looks fine to me.

@bbartholdy
Copy link
Collaborator

I agree with @mwakok, it might be a better way to do things, especially since Data Carpentry workshops have started using this repo, too, it could get unruly pretty quickly. Maybe something for @halfordd to implement (if we choose to continue using this option for notes)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants