Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
infra:nextgen [2017/10/08 23:34] – [Proof of Concept] ochosiinfra:nextgen [2017/11/07 21:26] – [Hardware] add needed hardware skunnyk
Line 32: Line 32:
 On the DNS side, maybe outsource this to a provider. On the DNS side, maybe outsource this to a provider.
  
 +
 +**What do we need** : 
 +2 instances (VM are ok), at least: 
 +  * 2/4CPUs 
 +  * 6GB Ram 
 +  * At least 50GB Disk 
 ===== Software ===== ===== Software =====
  
Line 58: Line 64:
 Projects and users Projects and users
  
-  - Each Xfce project should be placed under specific category — "organization" in terms of gitea. The following organizations should be created: Xfce Core, Xfce Applications, Panel Plugins, Thunar Plugins, Bindings, WWW, Archive. +  - Each Xfce project should be placed under specific category — "organization" in terms of gitea. The following organizations should be created: Xfce Core, Xfce Applications, Panel Plugins, Thunar Plugins, Bindings, WWW, Archive. ✔  
-  - Allow to register for everybody in order to create issues and pull requests +  - Allow to register for everybody in order to create issues and pull requests ✔  
-  - Users with higher level of privileges can create their own user repositories (is it possible to do with gitea?) +  - Users with higher level of privileges can create their own user repositories (is it possible to do with gitea?) => Everybody can create a "fork" or a repository by default. We can set MAX_CREATION_LIMIT = 0 to only allow Forks (note: need to handle the "user repo" thing) ✔ 
-  - Users can be added as project collaborators in order to commit to the repo directly (multiple project maintainers) +  - Users can be added as project collaborators in order to commit to the repo directly (multiple project maintainers): One "owner" team per organization (full admin, by default), one "core" dev team per organization (with write access) + individual dev write access to individual projects (for example panel plugins). ✔ 
-  - Some git hooks/configs are required: deny force push to git master, deny deleting master repo, deny deleting projects from organizations (official categories, see above), (what else?)+  - Some git hooks/configs are required: deny force push to git master, deny deleting master repo, deny deleting projects from organizations (official categories, see above), (what else?) : Only on "official" repo (not forks), enable "branch protection" + Add denyNonFastforwards = true with a script (not possible via gitea itself) ✔ 
 +  - git post-receive hook : use a "hack" by using git template (in ~/.gitconfig ) + symbolic links based on https://discuss.gogs.io/t/global-git-hook-support/777 : ✔ 
 +  - Enable github oauth ?
  
 Migration from Cgit Migration from Cgit
Line 68: Line 76:
   - All git repos, project descriptions and hooks should be migrated to gitea   - All git repos, project descriptions and hooks should be migrated to gitea
   - Cgit could remain in order to provide old GUI. It should work with gitea repos (gitolite will be dropped) so it requires some patches to display user repos properly   - Cgit could remain in order to provide old GUI. It should work with gitea repos (gitolite will be dropped) so it requires some patches to display user repos properly
 +  - Keep a git-daemon for the git:/ protocol
 +
 +
  
 Style and GUI Style and GUI
Line 77: Line 88:
 Migration from Bugzilla Migration from Bugzilla
  
-  - Issues link should redirect to bugzilla initially+  - Issues link should redirect to bugzilla initially: Done with "External Tracker" option ✔
  
 ==== Phase 2 ===== ==== Phase 2 =====
 +Gitea hacking
 +
 +  - Transifex translation commits can be (optionally) hidden from gitea web gui
 +
 Migration from Bugzilla Migration from Bugzilla
  
Line 88: Line 103:
   - Bug statuses such as open/closed bugs should be migrated as open/closed issue statuses   - Bug statuses such as open/closed bugs should be migrated as open/closed issue statuses
   - All attachments (even patches) should be migrated as attachments   - All attachments (even patches) should be migrated as attachments
 +  - Write a simple web server which will redirect from old bugzilla pages to new gitea issue pages (there should be a small db with ("bugzilla bug id" <> "repo name", "repo bug id") association)