We use cookies to ensure you get the best experience on our website
Home Explore Help News
Register Sign In
NeuralEnsemble
/
ephy_testing_data
9
6
Fork 15
Files Issues 10 Pull Requests 4 Wiki
Labels Milestones
New Pull Request

#37 Replacement of #28: Add contribution guideline

Merged
samuelgarcia merged 1 commits from NeuralEnsemble/contribution_guide into NeuralEnsemble/master 3 years ago
Conversation 3 Commits 1 Files changed 1
sprenger commented 3 years ago

This PR is an updated version of #28, which was corrupted during the implementation of #29. This PR solves #27.

In the proposed contribution guide contributors need to be added as collaborators to the repository to be able to create branches in the repository itself instead of a fork. This is necessary since git-annex content is not copied between a fork and the main repository when a PR is merged. Adding contributors as collaborators has further implications since the permission scheme in gin is very coarse:

  • Collaborators can merge PRs -> We should make it clear that is is not advised.
  • Collaborators can push to existing branches -> We should make all base branches (master, git-annex, synced/master, synced/git-annex protected from pushes and force-pushes (allowing changes only via PRs)

Furthermore after merging a PR, admins should remove the source branches <my feature> and synced/<my feature>, e.g. via gin git push <remote> --delete <branch>.

Also note, that gin get fetches all git objects existing in all branches in the repo. This implies, that one non-annex branch with large files can cause the whole repository to take a long time for downloading, since also the content of that branch is downloaded. Deleting the respective branch resolves the issue as the data is deleted from the repository. -> We need to monitor existing branches for redundant files.

This PR is an updated version of #28, which was corrupted during the implementation of #29. This PR solves #27. In the proposed contribution guide contributors need to be added as collaborators to the repository to be able to create branches in the repository itself instead of a fork. This is necessary since git-annex content is not copied between a fork and the main repository when a PR is merged. Adding contributors as collaborators has further implications since the permission scheme in gin is very coarse: - Collaborators can merge PRs -> We should make it clear that is is not advised. - Collaborators can push to existing branches -> We should make all base branches (`master`, `git-annex`, `synced/master`, `synced/git-annex` protected from pushes and force-pushes (allowing changes only via PRs) Furthermore after merging a PR, admins should remove the source branches `<my feature>` and `synced/<my feature>`, e.g. via `gin git push <remote> --delete <branch>`. Also note, that `gin get` fetches all git objects existing in all branches in the repo. This implies, that one non-annex branch with large files can cause the whole repository to take a long time for downloading, since also the content of that branch is downloaded. Deleting the respective branch resolves the issue as the data is deleted from the repository. -> We need to monitor existing branches for redundant files.
sprenger commented 3 years ago
Owner

@apdavison & @samuelgarcia: Can you please have a quick look at this and decide if in principle this way of handling contributions is acceptable for you (making contributors collaborators) or if you see any other way on how to implement this more nicely? I think this is a rather urgent discussion as we want people to contribute to this repo.

@apdavison & @samuelgarcia: Can you please have a quick look at this and decide if in principle this way of handling contributions is acceptable for you (making contributors collaborators) or if you see any other way on how to implement this more nicely? I think this is a rather urgent discussion as we want people to contribute to this repo.
Samuel Garcia commented 3 years ago
Owner

I am totally OK with this new way. I am trying it now with openephysbinray. Tell if it is ok.

I am totally OK with this new way. I am trying it now with openephysbinray. Tell if it is ok.
sprenger commented 3 years ago
Owner

@samuelgarcia I think this worked well for the openephys example. Do you want to add a paragraph that if people only want to contribute once it is also ok to provide the files outside of gin and we take care of the integration?

@samuelgarcia I think this worked well for the openephys example. Do you want to add a paragraph that if people only want to contribute once it is also ok to provide the files outside of gin and we take care of the integration?
samuelgarcia closed 3 years ago
This pull request has been merged successfully!
Sign in to join this conversation.
Labels
Clear labels
No Label
Milestone
Clear milestone
No Milestone
Assignee
Clear assignee
No assignee
2 Participants
Write Preview
Loading...
Cancel
Save
There is no content yet.