Policy: Decide what to do with 'private accounts' and 'private repos' #33
Labels
No Label
Service
Buildbot
Service
Chat
Service
Gitea
Service
Translate
Type
Bug
Type
Config
Type
Deployment
Type
Feature
Type
Setup
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/blender-projects-platform#33
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Already there seems to have been someone who's set
User visibility
to 'private' on projects.blender.org. Next to this, they have also set up a private repo.This introduces the question, however, if we should permit 'private' user-visibility at all; and especially if we should consider private repositories to be a valid thing.
Note that the settings for the current deployment are:
We should likely consider:
1 repository limit for new users
5 repo limit set globally as 'catch all'
20+ repo limit set on organisation 'blender'
Set user-visibility to public
I think we should disallow private accounts and repositories entirely, assuming there is an option for that. If not we could considering adding that configuration option.
I don't think limiting number of repositories more is good, because a regular Blender contributor can easily need 5 forks to contribute to various things. The issue is not in the number of repositories.
We could set limit to 1 for any new user so that they can at least clone blender and create pull-requests from any branches they care to make.
If a user is a regular contributor, he/she'd likely part of the 'blender' organisation (i am assuming this is the policy?). The blender-repository would have a high (or no) limit.
But what problem would we be solving by limiting the number of repositories to less than 10?
For users I guess we can do:
For repositories I could not find an option.
The issue with allowing anyone to create as many repositories as possible is that a simply 'clone, clone, clone, clone, clone' action of for example blender/blender will fill up the disks of the machine in no time before you even realize that somebody's adding a 1GiB disk-filler with each click. This is perhaps even quicker when somebody uses the API.
In essence, you're allowing an easy way for someone to do a DDoS on projects.blender.org while only requiring a blender-id.
Though I imagine that gitea'd only let you clone a repo once; not multiple times.. making exploitation of this a little less quick. It'd still be possibly by cloning other people's clones..
I have added the
ALLOWED_USER_VISIBILITY_MODES = public,limited
setting to the current app.ini. It'll be in effect upon next restart. We'll just need to un-privatize the Orkspalter user.. Will do this , informing him about it, too.Creating a fork should use hard links and not take up much space, until someone starts modifying it and then it will gradually take up more space. So not sure this is really an issue.
Over time many people really will need ~5 repositories, we should not make that something that they have to go and ask permission for. 10 is not that much more and gives some headroom.
An upcoming PR may also be of interest for you https://github.com/go-gitea/gitea/pull/21820 instead of limiting on number of repos, you can also limit on total repo size for a user.
The user-visibility-setting's been set and gitea's been reloaded.
I think we can close this. Control over repo size and disabling private repositories entirely would be good, and when they become available in Gitea we can enable such features.
But I don't think there is anything we have to spend time on here until we encounter a problem.