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
infra:nextgen [2017/10/08 23:34] – [Proof of Concept] ochosiinfra:nextgen [2018/02/17 20:14] (current) – [Hardware] skunnyk
Line 28: Line 28:
 Even if we don't update our workflow, we need to get rid of our old servers. We can thank UNamur 100000x for their free hosting for the last decade, but I think we need to find a new sponsor. Maybe Gandi (with m8t) can be a solution.  Even if we don't update our workflow, we need to get rid of our old servers. We can thank UNamur 100000x for their free hosting for the last decade, but I think we need to find a new sponsor. Maybe Gandi (with m8t) can be a solution. 
  
-This can be some cloud services or dedicated servers or something else. We don't need unlimited resources, only 2 or 3 instances with enough ram / cpu / disk and good stability (8GB Ram minimum)+This can be some cloud services or dedicated servers or something else. We don't need unlimited resources, only 2 or 3 instances with enough ram / cpu / disk and good stability.
  
 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), per instances:
 +  * 2/4CPUs 
 +  * 6GB Ram 
 +  * ~ 50GB Disk 
 +
 +And a backup server. As we can keep our servers at namur, they can serve as a backup site.
 ===== Software ===== ===== Software =====
  
Line 58: Line 66:
 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 78:
   - 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 90:
 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 105:
   - 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)