Gitea: Gitea 로드맵 논의

gitea 확장을 위한 플러그인(테마 포함) 솔루션.

빌드 프로세스에 적절한 OS 패키지를 추가할 수 있습니까? 나는 fedora를 위해 뭔가를 조합하려고 노력했지만 go는 포장하기가 엉망인 것 같습니다. 이것에 대해 #31 종류의 이야기가 있지만 여전히 열려있는 것 같습니다.

우리는 Debian 시스템에 tarball을 배포하기 위해 가능한 것을 사용하고 있습니다. 이것은 매우 편리하지는 않지만 작동합니다. 가장 일반적인 배포판을 위한 저장소가 있으면 좋겠지만 제자리에 배치하고 유지 관리해야 합니다.

몇 가지 제안:

• 빌드 프로세스 중에 Drone CI/CD를 Gitea에 자동으로 통합하는 옵션입니다.
• 설치 후 Gitea UI에서 더 많은 사이트 관리 구성 가능성. 예를 들어, _Configuration_ 페이지에서 _Service Configuration_의 항목을 변경할 수 있기를 원합니다.
• 탐색 페이지에서 사용자를 숨길 수 있는 옵션입니다.

연합 풀 리퀘스트/이슈/포크

연합 풀 리퀘스트/이슈/포크

Fediverse라는 단어(ActivityPub, OStatus, diaspora* 등)의 의미에서 연합되지 않을 수도 있지만 프로젝트에 가장 적합한 방식으로 구현된 자신의 원격 인스턴스와 상호 작용할 수 있는 기능을 원합니다.

구현하기가 엄청나게 어려울 수 있지만 여러 인스턴스에 걸쳐 사용자로 구성된 팀과 조직을 갖는 것도 멋질 수 있습니다.

버그를 보고하고 UX 피드백을 제공하여 내가 사용하는 오픈 소스 프로젝트를 도우려는 최소한의 코딩 기술을 가진 최종 사용자의 POV에서 두 가지 제안:
1) ForgeFed 표준화를 도와주세요! 저는 Gitea(및 기타 커뮤니티 호스팅 코드 위조) 인스턴스에서 버그를 신고하는 UX가 하나의 거대하고 분산된 GH와 같기를 바랍니다.
2) 프로젝트의 각 부분을 Git 저장소로 만들어 이슈, 위키 등을 쉽게 가져오거나, 분기하거나, 푸시하거나, 분기할 수 있습니다. GL과 sr.h는 적어도 일부 구성 요소로 이 작업을 수행합니다. 유용할 뿐만 아니라 잠재적으로 포인트 1)에 도움이 될 것입니다.

이메일로 티켓에 회신하는 기능은 사용성을 위한 큰 진전이 될 것입니다.

UI에서 모든 구성의 편집을 허용합니다(프로세스 중에 구성 파일 형식을 변경할 수 있음).

대부분의 구성을 데이터베이스에 저장하고 적절한 cli 및 api를 제공할 수 있습니다.

@sapk @tboerger 구성을 위해 viper 로 전환해야 한다고 말하고 싶습니다. 그렇게 하면 ini(및 일부 버그)를 제거하고 Gitea가 실행 중이고 적절한 환경 변수를 실행하는 동안 구성을 다시 로드하는 것과 같은 항목을 얻을 수 있습니다. .

기꺼이 이 문제를 해결하고 싶지만 가까운 장래에 시간을 찾을 수 있을지 확신이 서지 않습니다.

저도 바이퍼를 지지합니다. 2년전에 하려고 했는데 시간이 없어서 끝내지 못했는데.. 다시 해볼 수 있어요 :)

나는 더 최소한의 구성 파일을 얻기 위해 ... 이러한 설정의 대부분은 정적 구성 파일을 통해 설정할 필요가 없으며 db에 쉽게 추가하고 성능상의 이유로 캐시에 저장할 수 있습니다.

처음에는 데이터베이스 구성 테이블을 추가하고 ini 파일에서 대부분의 변경 가능한 구성 항목을 이동하고 다시 로드해야 하는 항목만 남길 수 있다고 생각합니다.

@lunny 및 모두: 많은 설정을 데이터베이스로 이동하고 웹 인터페이스(사이트 전체 또는 리포지토리 전체)에서 구성할 수 있도록 하는 데 동의합니다. 그런 다음 차 또는 gitea와 같은 도구 자체가 명령줄에서 해당 값을 변경할 수 있도록 하는 것도 쉬울 것이므로 여전히 기본 설정을 스크립팅할 수 있습니다.

모듈 시스템은 훌륭합니다. 나는 gitea에 새로운 기능을 기꺼이 추가하려는 사람들이 많다고 생각합니다.

@belliash @sapk IMO 플러그인/모듈은 모델 패키지를 완전히 리팩토링하고 추상화를 추가하지 않고는 효율적으로 구현할 수 없습니다. Go의 기본 플러그인 지원과 같은 여러 기술을 테스트했습니다.

결과는 Gitea 바이너리에 크게 의존하는 거대한 바이너리였습니다.

웹훅 지원을 개선하고 웹훅으로 사용자 정의 페이지를 추가하는 것이 데이터베이스 작업에 사용할 수 있는 조용하고 성숙한 API를 이미 가지고 있기 때문에 구현하는 것이 더 현실적이라고 생각합니다.

@jonasfranz 많은 종속성을 제거하기 위해 모델을 리팩토링하는 것을 매우 선호합니다.

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

98(!)개의 직수입을 공개합니다. 그 중 50개는 non-go 핵심입니다.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

437(!!)개의 전이 종속성을 나타냅니다. (이 중 304개가 논고 코어임)

드론 소스를 보면 웹훅을 기반으로 하는 플러그인 가능한 것들이 많이 있습니다.

그 외에도 grpc 기반 플러그인 시스템인 packer와 같은 플러그인 모델이 적합합니다.

@tboerger 무인 항공기의 플러그 가능한 물건에서 예를 제공 할 수 있습니까? 도커 이미지 기반 플러그인 시스템을 말씀하시는 건가요?

구성, 비밀 등에 대한 확장에 대해 이야기하고 있습니다. 인터페이스는 https://github.com/drone/drone/tree/master/plugin 에서 정의해야 합니다.

동의합니다. Gitea의 다음 큰 단계는 플러그인 시스템이어야 합니다. 저도 요즘 이런 생각을 합니다. 플러그인 시스템을 사용해 보겠습니다.

드론의 플러그인 시스템과 비슷해야 하지만 더 많이 있어야 한다고 생각합니다. 플러그인에 UI가 있어야 하고 Gitea의 OAuth2로 자동 로그인해야 합니다. 그리고 플러그인에 대한 보안 정책이 있어야 합니다. 등

Open Source Geospatial Foundation을 위해 선택할 호스팅 플랫폼을 _결정_하기 위해 2016년경에 만든 비교 표를 공유하고 싶습니다. 이 표에는 우리에게 중요한 기능이 나열되어 있습니다. Gitea는 다음 열 중 하나에 있습니다.

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

2016년에 누락된 중요한 기능이 오늘날에도 여전히 누락되었음을 알 수 있습니다. 메일로 회신(댓글/회신) --- 일부 다른 기능은 오늘 현재 구현되었습니다.

migrate from github 및 Comments on diff lines 대한 @strk 도구가 완료되었습니다.

메일 템플릿 사용자 정의 필요
#6037 참조

따라서 이미 가능한 템플릿 사용자 정의가 상당히 많이 있습니다. 제목 줄은 우리가 가지고 있지 않다고 생각하는 유일한 것입니다.

그러나 우리가 정말로 해야 할 일은 이메일과 git serv hook 메시지에 대해 i18n을 활성화하는 것입니다.

pull 요청을 되돌리는 것이 필요합니다.
#6375 참조

UI에서 태그를 완벽하게 지원합니다. 생성, 할당, 변경, 삭제 등 이 기능이 정말 그립습니다.

나는 데이터베이스 구성(사용자 생성 및 인증 ldap 등을 구성하는 cli 또는 api 사용) 및 플러그인 시스템에 찬성합니다.
그 두 가지가 기테아를 한 걸음 더 나아가게 할 것입니다.

LFS

• [x] 리포지토리에서 LFS 파일을 관리하는 방법이 필요합니다. 현재는 완전히 불투명합니다. #7199는 이것을 제공하려는 시도입니다.
  
  
  
  • [ ] 블롭 조회를 위한 블룸 필터 - 커밋을 찾는 약간 효율적인 방법과 블롭을 도입한 트리 경로가 있으면 매우 좋습니다.
  
  
• [ ] 현재 LFS에 업로드를 다시 시작할 수 있는 안정적인 방법이 없으므로 매우 큰 업로드는 반복적으로 실패할 수 있습니다. #1723에 따라 tus.io를 구현합니다.
• [ ] 포인터처럼 보이는 파일이 포인터라고 가정하기 보다는 파일이 LFS 포인터인지 판별하기 위해 .gitattributes를 사용하는 옵션을 제공해야 합니다. #7199의 기능을 매우 어렵게 만들 가능성이 있지만...
• [ ] LFS 파일은 diff 보기에서 볼 수 있어야 합니다.

경화

종료 및 Gitea를 실제로 클러스터링 가능하게 만들기 시작

• [ ] 종료에 대한 Gitea의 대응을 강화해야 합니다.
  
  
  
  • [x] 이는 수신 연결, 특히 내장된 SSH의 정상적인 종료를 의미합니다. 현재 갑작스러운 종료를 통해 git 리포지토리가 손상될 수 있습니다. #7274는 이 문제를 해결하려는 시도의 시작입니다.
  
  
  • [ ] 뿐만 아니라 작업과 같은 알림은 직렬화할 수 있어야 함을 의미합니다. 예를 들어 인덱싱 대기열은 디스크나 DB 대기열, 유사하게 메일 대기열 등을 통과해야 합니다. 이미 일부가 있지만 이러한 대기열은 정상적으로 종료되지 않습니다.
  
  
• [ ] 위와 같은 결과로 인덱싱과 검색을 분리해야 합니다. 정상적인 종료는 어떤 경우에도 이를 필요로 하지만 클러스터링을 향한 단계의 일부입니다. 어떤 아키텍처를 선택해야 하는지 확실하지 않지만 여러 옵션이 있습니다. 인덱서를 별도의 프로세스로 분리하고 Gitea에서 읽기 전용 인덱스를 사용하거나 전체 인덱싱을 내보내도록 합니다.

메모리에 임의의 길이의 데이터 비교 및 ​​읽기

• [ ] Diff 코드는 리팩토링이 필요합니다. 취약하고 전체 diff를 메모리로 읽고 사용자가 응답할 수 있기 전에 브라우저에서 엄청난 diff를 구문 분석해야 합니다. 이를 위해서는 UI와 서버 변경이 모두 필요합니다. 아마도 Ajax로 뒷받침되는 무한 스크롤이 이에 대한 올바른 기술일 것입니다. 현재 충분히 사악한 큰 diff는 서버와 브라우저를 모두 중단시킬 수 있습니다.
• [ ] 우리의 diff 아키텍처는 현재 미리 병합된 분기와 개체로 기본 저장소를 오염시킵니다.
• [ ] 일반적으로 임의의 길이의 데이터를 메모리로 읽는 것을 중단해야 합니다. 브라우저가 이것을 원할 수 있는 곳이 있다면 우리는 읽는 것을 제한해야 하고 무한 스크롤 기술이나 브라우저 렌더링 또는 파이프라인에서 렌더링되는 전체 링크를 사용하여 메모리에 완전히 버퍼링되지 않도록 해야 합니다. 비교적 새로운 코드라도 여전히 이 문제를 겪고 있습니다.
• [ ] (만약 우리가 임의의 긴 데이터를 반환할 수 있는 git 프로세스를 실행하고 있다면 모든 데이터를 stdout 버퍼로 직접 읽는 것을 피하려고 노력해야 하지만 더 많은 go-routine 파이프라인을 수행해야 합니다.)

병합

• [ ] 현재 병합을 위한 스파스 체크아웃을 수행하므로 병합을 완전히 리팩터링해야 git 인덱스를 사용할 수 있습니다. 기본적으로 git merge가 https://git-scm.com/docs/git-merge-one-file 로 드롭다운되기 때문입니다. 빨리 감기가 아닌 병합을 처리합니다. 이것은 불필요하고 charset/filesystem 요소에 의존하는 반임의 경로를 서버에 강제로 생성합니다. 이 작업을 수행할 필요는 없습니다. 임시 파일을 사용하여 이러한 병합을 수행하고 해싱하고 인덱스에 직접 추가할 수 있습니다.

탈출 및 저장소 위치

• [ ] 우리는 탈출을 위해 모든 곳을 확인해야 합니다. 레거시 Gogs 코드는 일반적으로 제대로 이스케이프되지 않았으며 여러 보안 문제를 담당했습니다.
• [ ] 사용자 이름과 저장소 이름에 이스케이프가 필요하지 않다는 가정은 필요하지 않은 아키텍처 결정을 강요합니다. git 서명에 대해 제대로 보호하지도 않았으므로 #5774입니다.
• [ ] 사용자가 기본 저장소 위치가 파일 시스템 위치와 일치하도록 하는 것이 좋지만 - 예를 들어 $GITEA_ROOT/owner/reponame 이는 잘못된 아키텍처 결정이며 사용자가 우리 저장소를 서버의 git에서 사용할 수 있다고 가정합니다. 추가 생각 - 해서는 안 됩니다. $GITEA_ROOT/repository-$ID 로 이동해야 합니다. 아마도 샤딩되었을 것입니다. (이렇게 하면 repo.MustOwner() 또는 repo.GetOwner() 에 대한 많은 호출을 제거할 수 있습니다)
  
  
  
  • [ ] 일단 위의 단계로 이동하고 모든 것을 적절하게 이스케이프하면 사용자 이름과 저장소 이름에 대한 제약을 완화할 수 있습니다. #5774와 유사한 문제를 통해 가짜.
  
  
• [x] 서버 git 프로세스가 충분한 Gitea 환경에서 실행되도록 해야 합니다. Gitea를 거치지 않고 서버에서 Gitea의 저장소를 사용하려고 시도하는 반복적인 사용자가 있으므로 Gitea가 업데이트되지 않았다고 불평합니다. #6961 is a a 이에 필요한 단계를 수행하고 이를 병합한 후 https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 를 변경하여 SSH_ORIGINAL_COMMAN의 설정을 적용하거나 그렇지 않으면 해당 설정을 적용합니다. 의 표준 환경이 설정됩니다.
• [ ] 우리는 NO_EXEC 마운트된 리포지토리에 대처할 수 있어야 하며 실제로 이것을 권장해야 합니다. 실제로 하는 것은 어렵지 않을 것입니다. .git/config 또는 중앙 .gitconfig core.hooksPath 변수를 변경하고 그렇지 않으면 후크를 배치할 위치를 생각하면 됩니다.
• [ ] 기본적으로 주석을 위해 데이터베이스에 코드 줄을 직접 저장합니다. 저장되는 데이터가 UTF-8이 아닌 경우 작동하지 않습니다. 이것은 단순히 비 UTF8 코드에 대해 주석을 달 수 없다는 것을 의미합니다.

API / SDK

• [ ] Swagger를 갖기 위해 모든 노력을 기울일 때 API를 구축하기 위해 해야 하는 작업의 양은 정말 어마어마합니다. 우리는 이것을 swagger에서 자동 생성하거나 가능한 한 많이 자동 생성해야 합니다.
• [ ] 개발 중인 Gitea에 대해 고정 API 버전을 테스트할 방법이 없으므로 주요 변경 사항을 언제 적용할지 알 수 없습니다.
• [ ] 자동 생성된 API/SDK를 사용하여 간단한 테스트 하네스를 만들 수 있어야 합니다.

테스트

• [ ] 우리는 현재 TRACE 레벨에서 단위 테스트를 실행합니다. 이것은 사물에 적절한 추적을 추가하는 능력을 제한합니다. https://gitea.com/gitea/log/pulls/3 이후로 Gitea로 백포트하면 makefile에서 이를 변경할 수 있습니다.
• [ ] 더 많은 단위 테스트가 필요하고 일부 통합 테스트가 실제로 단위인지 또는 그 반대인지 고려하십시오. 예: https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [ ] 사용자 스토리를 통해 실행하려는 더 많은 통합 테스트가 필요합니다. 즉 - 사용자가 로그인하고 X를 수행한 다음 Y와 Z가 발생합니다. 예를 들어 개별적으로 테스트하는 것이 좋습니다. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go 그러나 실제로 통합되지 않았으며 사용자 경험을 테스트하지 못했습니다. 계속 말하지만 더 많은 테스트는 https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go 및 https://github.com/go-gitea/gitea/blob 기능이 올바르게 통합되는지 실제로 테스트하는
• [x] 테스트 기간이 너무 오래 걸립니다. 현재 CI를 실행하는 데 30-40분이 걸립니다! 이것을 병렬로 실행해야 합니다.
• [ ] 마이그레이션 테스트를 생성하는 쉬운 방법은 없습니다.

Go 패키지 아키텍처

모델

• [ ] code.gitea.io/gitea/models 은(는) 중지해야 하는 항목이 너무 많습니다.
• [ ] models.x 는 파괴되어야 합니다. 그것은 끔찍한 아키텍처 결정입니다.
• [ ] 너무 많은 모델의 경우 어떤 상태인지 모르기 때문에 nil 포인터 역참조를 유발하기가 너무 쉽습니다. 여기서 go의 타이핑 시스템을 조금 더 잘 사용할 수 있습니까?
• [x] 리포지토리를 얻을 때마다 소유자를 가져와야 하므로 리포지토리 테이블에 OwnerName을 고정해야 합니다. 어리석고 시간 낭비입니다. 리포지토리는 소유자를 자주 변경하지 않으므로 이를 처리하는 데 드는 비용은 그다지 중요하지 않습니다.
• [ ] 아직 모델에서 수행되는 작업이 너무 많으며 더 많이 제거해야 합니다.
• [ ] 모델을 코어와 비코어로 나누는 것이 합리적일 수 있습니다.

모듈

• [x] 기본적으로 두 가지 유형의 모듈이 있습니다. 즉, 모델에 의존하는 모듈과 모델이 의존하는 모듈입니다. 이들을 분리해 봅시다. 하나는 서비스라고 할 수 있습니다.

마카롱

• [ ] @lunny가 제안한 진으로의 전환을 진지하게 받아들여야 한다고 생각합니다.
• [ ] 우리의 코드베이스는 마카롱에 대한 의존성으로 가득 차 있습니다.

환경

• [ ] 마카롱에 따라서도(!)
• [ ] 연결 해제를 고려해야 하는 또 다른 종속성인 go-ini와 밀접하게 연결되어 있습니다.

국제화

• [ ] 이메일이 국제화되지 않음
• [ ] Git 메시지가 국제화되지 않음
• [ ] 국제화되지 않은 오류 메시지
• [ ] CrowdIn을 사용하여 국제화할 수 있도록 당사의 휴고 웹사이트 문서를 자동으로 제거해야 합니다.
• [ ] 언어 선택기 목록에 français, español과 같은 소문자 형식을 사용하는 언어가 있다는 것은 이상한 일입니다. 이는 각 언어에서 문장의 시작을 나타내므로 AFAICS는 대문자로 표시해야 합니다. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • 영어
  
  
  • 프랑세즈
  
  
  • 스페인어
  
  

Gitea 덤프 및 복원

• [ ] SQL 변형 간 변환을 위해 Gitea 덤프가 손상되었습니다.
• [ ] 복원 명령이 없습니다.

UI 부분에서는 두 가지 UI를 제공하는 것이 좋습니다.

• 하나의 일반 HTML(js가 없는 현재 HTML과 유사)
• API 호출에만 의존하는 완전한 JS. 이렇게 하면 API를 거의 재고하지 않을 수 있지만 다른 외부 앱과의 상호 작용도 더 많이 허용됩니다.

• @lunny가 제안한 진으로의 전환을 진지하게 고려해야 한다고 생각합니다.

진 대신 고찌를 추천합니다.

• CrowdIn으로 국제화할 수 있도록 당사의 휴고 웹사이트 문서를 자동으로 제거해야 합니다.

IMHO 웹사이트/문서는 전혀 번역되어서는 안 됩니다. 어쨌든 항상 구식입니다...

IMHO 웹사이트/문서는 전혀 번역되어서는 안 됩니다. 어쨌든 항상 구식입니다...

그러나 crowdin을 사용하면 구식으로 사람들에게 알리고 현재 번역을 무효화합니다.

빌드 프로세스에 적절한 OS 패키지를 추가할 수 있습니까? NS

아마도 GItea 개발자가 제어하고 버전을 관리하는 PPA 스타일 패키지는 좋은 생각일 것입니다. 하지만 저는 빠르게 움직이는 프로젝트(예: GItea)를 위한 데비안 스타일의 "보안 패치 고정 및 백포트" 버전 관리 방식을 좋아하지 않습니다.

나는 여전히 https://github.com/go-gitea/gitea/issues/3840 을 갖고 싶습니다
하위 호환성으로 구현할 수 있다고 생각합니다.
그러나 이것은 새로운 라우팅 라이브러리의 마이그레이션이 해결된 후에야 명확해질 것입니다.
전제 조건인 기본 정리/리팩터를 사용하면 더 쉽게 만들 수 있습니다.

나는 여전히 #3840을 갖고 싶다.
하위 호환성으로 구현할 수 있다고 생각합니다.
그러나 이것은 새로운 라우팅 라이브러리의 마이그레이션이 해결된 후에야 명확해질 것입니다.
전제 조건인 기본 정리/리팩터를 사용하면 더 쉽게 만들 수 있습니다.

이 경우 현재 Gitlab에 대해 구현되지 않았기 때문에 Drone 지원을 느슨하게 할 수 있습니다.

나는 여전히 #3840을 갖고 싶다.
하위 호환성으로 구현할 수 있다고 생각합니다.
그러나 이것은 새로운 라우팅 라이브러리의 마이그레이션이 해결된 후에야 명확해질 것입니다.
전제 조건인 기본 정리/리팩터를 사용하면 더 쉽게 만들 수 있습니다.

리포지토리 URL에 영향을 주기 위해 이 그룹 기능이 필요하지 않을 수 있습니다. 리포지토리를 표시할 수 있는 폴더를 만들 수 있지만 리포지토리 URL은 현재와 동일하게 유지할 수 있습니다.

@tboerger
내 생각은 repo가 ​​그룹/디렉토리에 중첩되지 않으면 URL이 동일하게 유지될 수 있다는 것입니다.
리포지토리가 그룹/디렉토리 기능을 사용하는 경우에만 URL을 "업그레이드"해야 합니다.
그러나 예, 새 URL이 있는 리포지토리는 기본적으로 Drone을 지원하지 않을 수 있습니다.

@lafriks
그거 좋은 아이디어군요. 이 기능의 사용 시나리오는 Git 모듈 또는 Repo 프로젝트의 하위 프로젝트를 호스팅하는 것입니다. 그래서, 나는 그것이 그 경우를 커버하는지 확신하지 못합니다.

걱정 마. 나는 그러한 광범위하고 아마도 파괴적인 변화를 일으키기를 꺼립니다.

이 문제는 많은 좋은 아이디어를 가지고 있으며 우리는 그것들을 유지하고 해결해야 합니다.
그러나 언제, 어떻게 선택해야 합니까? 이 토론은 영원히 계속될 수 있습니다.

나는 소유자가 주제를 선택하거나 그들과 회원 사이의 투표를 제안할 것입니다.
어떻게 생각하나요?

@DblK 맞습니다. 하지만 gitea.com으로 마이그레이션한 후에는 그렇게 할 수 있다고 생각합니다. 현재 사용자로부터 더 많은 피드백이 필요합니다.

• 수은 지원
• PR 및 문제에 대한 더 나은 정렬 및 필터링

• 수은 지원

아니요 괜찮아요. 이유가 있어 "git"ea라고 합니다.
더 넓은 범위를 갖고 싶은 마음은 이해하지만
부풀어 오르는 것이 모퉁이에 있습니다 ...

수은 수입이 대안이 될 것입니다.

2019년 7월 26일 UTC 오후 1시 52분 50초에 Sandro Santilli [email protected] 은 다음과 같이 썼습니다.

• 수은 지원

아니요 괜찮아요. 이유가 있어 "git"ea라고 합니다.
더 넓은 범위를 갖고 싶은 마음은 이해하지만
부풀어 오르는 것이 모퉁이에 있습니다 ...

--
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

연합 풀 리퀘스트/이슈/포크

Fediverse라는 단어(ActivityPub, OStatus, diaspora* 등)의 의미에서 연합되지 않을 수도 있지만 프로젝트에 가장 적합한 방식으로 구현된 자신의 원격 인스턴스와 상호 작용할 수 있는 기능을 원합니다.

이미 #1612에서 이에 대한 논의가 있습니다. ForgeFed는 Gitea와 같은 코드 위조에 연합하기 위한 몇 가지 흥미로운 아이디어를 수집합니다. 이것이 Gitea의 다음 큰 기능이라면 굉장할 것입니다!

Github이 제공 하는 것과 유사한 그래픽 파일(JPEG, PNG 및 PDF)을 위한 시각적 diff 도구를 원합니다.

우리는 이미 이미지를 구별하기 위한 PR을 가지고 있습니다.

우리는 이미 이미지를 구별하기 위한 PR을 가지고 있습니다.

사실이지만 스와이프 또는 어니언 스킨 미리보기는 포함되지 않고 나란히만 포함됩니다. 또한 PDF 파일을 다루지 않는다고 생각합니다. 우리는 그래픽 자료(매뉴얼 및 브로셔 포함) 개발을 위해 여기에서 Gitea를 사용하고 있으며 PDF에 대한 훌륭한 시각적 차이는 인생을 바꿀 것입니다.

버리고 싶은 몇 가지 아이디어가 있습니다.smile_cat:

1. Cloud KSM을 사용하여 모든 비밀을 투명하게 암호화/복호화합니다. 이렇게 하면 DB가 해킹되어 노출되는 것을 방지할 수 있습니다. 아이디어는 DB에 쓰기 전에 비밀 데이터를 암호화하기 위해 XORM 인코딩/디코딩 방법과 함께 사용자 정의 유형을 사용할 수 있다는 것입니다. 여기에서 데모 예제를 만들었습니다: https://github.com/gomodules/ksm-xorm

2. OIDC 지원: Gitea를 통해 로그인할 때 oauth2 토큰과 함께 id_token을 반환합니다.

3. Gitea 사용자 프로필은 확인된 모든 Git 저장소에서 사용자 프로필을 표시할 수 있습니다. 예: 사용자는 Github/Gitlab/BitBuket/Gitea 저장소를 고정할 수 있습니다. 아이디어는 사용자가 다른 것도 무시할 수 없다는 것입니다. 그렇다면 gitea가 하나의 글로벌 사용자 프로필이 될 수 있습니까?

4. 리포지토리에 대한 사용자 지정 도메인 지원(go)

5. Github과 완벽하게 호환됩니다(이 부분에서 일부 작업을 보았지만 이미 얼마나 많은 작업이 완료되었는지 모르겠습니다.)

6. 선택적 언어 서버 통합. UI에 내장된 탐색과 같은 Sourcegraph와 같은 것.

1,2편에 짧게나마 기여하고 싶습니다.

모든 변경 사항이 포함된 하나의 거대한 페이지 대신 BitBucket과 같이 변경된 폴더 및 파일의 트리 형태로 diff를 표시할 수 있습니다. 훨씬 더 읽기 쉽습니다.

하루 또는 매주 모든 리포지토리에 대한 알림을 집계하는 옵션일 수 있습니다.
지난 주 활동의 요약과 같습니다.

사용자 지정 템플릿과 표준 변수 풀을 통해 사용자 지정 웹훅을 정의할 수 있는 가능성을 추가합니다.

Gitea 진화가 아니라 유용할 사이드 프로젝트 : #7853

github와 기능 패리티!

또는 최소한 동등성을 달성하기 전에 필요한 모든 기능을 보여주는 Wiki의 최신 목록입니다. 이것은 미래의 개발 노력을 구성하는 좋은 방법이 될 것입니다.

@lonix1 해당 목록은 https://docs.gitea.io/en-us/comparison/ 을

@kolaente 거의 모든 눈금이 있는 것 같습니다! 응!

나는 여기에서 매우 새롭지만 기꺼이 코더이기도 합니다. 나는 gitea가 요점을 지원한다면 그것을 좋아할 것입니다. 그것은 내 사용에 대한 가장 큰 구멍 중 하나입니다. 충분히 쉽게 해결할 수 있지만 요점 시스템을 제자리에 두는 것이 좋습니다.

요점에 대한 문제는 https://github.com/go-gitea/gitea/issues/693 (여기에서 아직 참조되지 않은 것 같아서 연결)이 될 것이라고 생각합니다.

Help 링크로 액세스할 수 있는 Help 문서도 추가합니다. 이 문서의 초기 소스는 GitHub 도움말 에서 가져올 수 있으며 Gitea 관련 수정 사항이 있습니다.

@bagasme 도움말은 github에서

1. 이메일을 통한 문제 생성(GitLab 서비스 데스크 참조).

더 많은 사람들이 오픈 소스 프로젝트를 공유하기 위해 자체 호스팅을 채택하기 시작하면 등록되지 않은 사용자가 각 인스턴스에 대해 계정을 만들지 않고도 문제를 제출할 수 있는 방법이 필요합니다(대부분의 사람들은 버그에 등록할 가능성이 매우 낮습니다. 보고서).

1. GitLab의 AutoDevOps와 유사한 것. 이는 리포지토리에 CI yaml 파일이 없을 때 기본 CI 작업을 정의하는 기능을 의미합니다.

2a. 컨테이너 레지스트리 UI 탭 및 인증.

1. 봇
2. 웹 커밋을 위한 GPG
3. 조건에 따라 병합을 차단하는 기능
4. 웹 UI에서 파일 생성 기능(빈 베어 리포지토리 포함)
5. UI를 통해 repo에 첨부된 스니펫 관리(GitLab 참조)
6. Git 프로토콜 v2 지원
7. 향상된 웹 IDE 옵션
8. Kubernetes 통합(GitLab의 UI 플러그인을 통해)
9. 마우스 오버 시 툴팁이 표시되기 전에 400ms 지연 추가
10. 더 나은 CI 통합(파이프라인 표시, Concourse 지원 등)
11. UI 수정
12. 2FA 시행
13. 파일 잠금
14. PR 병합으로 연결된 문제를 자동으로 닫습니다.

일종의 플러그인/확장 시스템.

대부분의 제안은 훌륭하지만 핵심 코드베이스에 문제를 일으킬 것입니다.

공식(및 비공식) 플러그인을 사용하는 것이 가장 좋습니다. 이것은 또한 플러그인 작성자가 더 자주 릴리스할 수 있음을 의미합니다.

@lonix1 git hooks,

@guillep2k 예를 들어 위에서 설명한 모든 프로젝트 관리 기능. 그것들은 매우 유용할 것입니다 - 그러나 아마도 코드베이스의 너무 많은 부분을 만지기 때문에 1) 해당 기능을 사용하지 않는 사람들에게도 문제를 일으킬 수 있고 2) 그로 인해 이러한 개발이 매우 느립니다. 새로운 기능을 병합하는 것은 이러한 시나리오가 가능하다는 것을 알고 있으므로 신중합니다.

이러한 새로운 기능이 별도로 출시될 수 있다면 메인 브랜치에 병합되기 전에 기꺼이 사용자가 사용해 볼 수 있습니다.

그리고 이러한 종류의 큰 새 기능의 다른 예가 있습니다. 위로 스크롤하십시오.

자동 생성 커밋의 @brandonkal GPG 서명은 이제 #7631의 병합으로 가능합니다.

로드맵은 다음 네 가지 범주로 나누어져야 한다고 생각합니다.

기본 기능

아직 제대로 작동하지 않는 _기본 기능_이 있습니다.
예를 들어:

• #5694 #5277 #3448, #2967, #2434, #8366, #8386 및 #7825와 같은 문제에서 언급한 것처럼 여전히 좋은 검색 솔루션이 필요합니다.
• PDF 뷰어가 깨졌습니다
• SVG 뷰어가 고장났습니다
• 비자유 종속성이 사용된 것 같습니다.

보안

다음과 같은 몇 가지 보안 문제도 있습니다.

• [ ] [Docker 이미지는 여전히 루트로 실행](https://github.com/go-gitea/gitea/issues/1190) Docker 가이드에서 이에 대해 매우 명확 하고 root 를 사용할 이유가 없습니다.
• [ ] [아직 2FA 시행 불가](https://github.com/go-gitea/gitea/issues/880)
• [ ] [인라인 스타일을 제거하여 더 엄격한 CSP 헤더 설정 사용](https://github.com/go-gitea/gitea/issues/305)
• [ ] [누군가가 첨부 파일에 액세스할 수 있는지 여부를 확인하지 않습니다.](https://github.com/go-gitea/gitea/issues/7908)

완성

다른 애플리케이션/서비스와의 통합은 일반적으로 좋은 일이라고 생각합니다.
소프트웨어 개발은 ​​일반적으로 단일 도구에만 의존하지 않기 때문입니다.
또한 일부 사람들이 직장에서 Gitea를 사용하도록 설득하는 데 도움이 될 것입니다.

이 두 가지 문제는 상호 운용성을 크게 향상시킵니다.

• [ ] Drone CI/CD를 자동으로 통합합니다( 이전에 제안한 @BNolet 과 같은 ).
• [ ] [자동화된 PR 검토를 위한 API 통합](https://github.com/go-gitea/gitea/issues/5733) Pronto 와 같은 도구를 통한
• [ ] [Container Registry와 손쉬운 통합](https://github.com/go-gitea/gitea/issues/2316)
• [ ] 사용자가 사용자 정의 웹훅을 쉽게 설정할 수 있는 일반 웹훅 솔루션( 이전에 @bkcsoft에서 제안한 것처럼 )

또한 일반 웹훅을 사용하면 다른 사람들이 gitea의 내부를 알 필요가 없습니다. @guillep2k 는 "외부 명령" 통합이 일반 웹훅 통합과 유사하게 수행될 수 있다는 멋진 아이디어를 가지고 있었습니다 .
:경고: 이것은 아마도 이 문제의 대부분의 사람들이 '플러그인 지원'으로 원하는 문제의 대부분을 해결할 것입니다 . 그래야 사용자가 호출해야 하는 모든 것을 호출할 수 있기 때문입니다. 그러나 @lunny 는 이것이 사실상 이미 git hooks를 통해 가능하다고 언급했습니다. 이것이 다른 도구/플러그인/서비스를 통합하는 가장 좋은 방법인지 확실하지 않습니다.

최고의 기능

또한 경쟁 응용 프로그램(예: Git[Hub/Lab]) 에는 분명히 몇 가지 멋진 기능이 있습니다(대부분의 기능이 있으면 좋을 것입니다).

• [ ] [PR 되돌리기](https://github.com/go-gitea/gitea/issues/6375)
• [ ] [@arthur-bauer가 언급한 비텍스트에 대한 diff 개선](https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [ ] [관리자 편집](https://github.com/go-gitea/gitea/issues/717)
• [ ] [기밀 문제](https://github.com/go-gitea/gitea/issues/3217)
• [ ] 더 많은 리포지토리 세부 정보 표시(예: 리포지토리 크기 , 기여자 그래프 , 언어 표시줄 )
• [ ] 일부 위키 개선 사항(#823 #574)
• [ ] [@SignumPL이 언급한 BitBucket과 같은 차이점이 있음](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (이전에는 몰랐지만 실제로 유용해 보입니다. )
• [ ] [Octotree와 같은 기능 통합](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

Oracle Database를 옵션으로 사용할 수 있습니까? 기술적으로 가능하다면.

@DemiusAcademius xorm이 oracle을 더 잘 지원한다면 가능하다고 생각합니다.

최근 GitLab 트래커 발표로 인해 점점 더 많은 사람들이 Gitea를 사용하기 시작했습니다. 그러나 GitHub/GitLab에는 여전히 네트워크 효과가 있습니다.

연합은 서로 다른 Gitea 인스턴스의 사용자 간의 협업 능력을 개선하고 전체 Gitea 네트워크를 증가시키는 큰 동인이 될 것입니다: #1612

UI에서 큰 차이를 표시하는 기능은 Gitea 채택의 제한 요소로 보고되었습니다.
티켓 주소: #7341(기능), #7495(크래셔 버그)

UI에서 큰 차이를 표시하는 기능은 Gitea 채택의 제한 요소로 보고되었습니다.
티켓 주소: #7341(기능), #7495(크래셔 버그)

그것은 _거대한_ 한계입니다. IMO 위에 나열된 모든 @alexanderadam 은 이것에 비해 창백합니다. 코드에 인라인으로 주석을 달아 큰 diff를 검토할 수 없다면 큰 문제입니다.

W/R/T 많은 프로젝트를 마이그레이션하고 페더레이션에 대한 높은 수요를 일으킨 Microsoft와 Github에 대한 분노-Gitlab은 최근 토지와 경제 규모로 세계 최대 2개 국가인 중국과 러시아의 직원 금지를 제안했습니다. 미군은 미국 제국의 확장/이해에 대한 장벽을 약화시키기 위해 중국과 러시아에 초점을 옮겼습니다. 선전 및 재정적 인센티브로 인해 Microsoft(Github, Azure), Amazon, Google, Atlassian(Trello, Jira), 심지어 Gitlab까지 전쟁, 스파이 활동, 선전 및 감시 산업에 공격적인 역할을 했습니다.

우리가 현재 사용하고 여전히 의존하고 있는 기업 및 국방부 관련 서비스에 대한 단점이 거의 없는 고가용성 오픈 소스 원격 리포지토리에서 작업하는 사람들에게 감사를 표하고 빠른 대안이 있음을 알려드리기 위해 이 글을 올립니다. 역사상 가장 강력하고 적대적인 제국에서 멀리 떨어진 곳에서 인터넷과 기술을 사용하려는 사람들을 위해 사라지고 있습니다.

아마도 이 주제는 공식 웹사이트의 별도 섹션에서 이 기능에 대한 진행 상황을 추적하고 이 수요를 포착하기 위한 별도의 기금 모금 캠페인을 할 만큼 충분히 클 것입니다. ForgeFed를 모금에 포함시키는 것은 지금까지 그들의 작업을 볼 때 유익하고 공정할 수 있습니다. Microsoft가 Github을 이긴 지 17개월이 지났습니다. 또 다른 17개의 나방이 연합된 Gitea를 사용하거나 '순 가치 구축'의 나머지 부분을 가질 수 있기를 바랍니다.

여기에서 정치에 대해 논의하지 마십시오. 주제를 계속 유지합시다 - 모두를 위한 Gitea 개선

@lafriks Gitea를 개선한다는 것은 대체 제품으로 충족되지 않는 틈새 시장을 정의하는 것을 의미합니다. 마케팅은 외부 기회를 찾는 과정이며 "정치적"은 마케팅 분석의 4가지 주요 범주 중 하나입니다. 현명한 브랜드는 기능, 사양 및 가격을 제공하는 만큼 사람들의 _가치_가 동등하게 어필합니다. Gitea와 같은 대안에는 가치 기반("정치적") 끌림이 있으며, 이를 강조하고 유지하지 못하는 것은 소비자와 시장 기회를 이해하지 못하는 것입니다.

"정치적"이라는 용어는 인종차별, 폭력 및 착취에 대한 논의를 소멸시키면서 생각을 끝내는 진부한 말이 되었습니다. 나는 단순히 미국 강제 수용소, 드래그넷 감시 및 기타 제국주의자들의 이익과 관련이 없는 대안에 대한 계속 작업에 대해 사람들에게 감사하기 위해 왔습니다. 대다수의 우리 업계가 적극적으로 지원하고 있습니다. 이것이 Gitea가 지지하는 자질이 아니라고 말한다면, 내가 당신을 잘못 생각하고 떠날거야.

@OKNoah에 대한 참고 사항

오픈 소스 프로젝트를 위한 마케팅 101:

1. 강제 수용소를 불러일으키지 마십시오.
2. 정치를 언급하지 말라
3. 은박지 모자 분실
4. 제국주의와 같은 고대 용어를 사용하지 마십시오.
5. 제품의 장점을 파악하십시오. Gitea의 장점은 단순성입니다.

GitLab.com의 투명성이 기분을 상하게 하는 경우 GitLab-FOSS를 자체 호스팅할 수 있습니다. 아주 좋은 올인원 제품입니다. 그러나 간단한 설치를 원하거나 GitLab 또는 GitHub Enterprise에 비해 더 적은 메모리 사용량이 필요한 경우 Gitea는 기본 웹 기능에 대한 좋은 옵션입니다.

이 스레드는 단순성을 손상시키지 않으면서 그 격차를 줄이는 데 도움이 될 수 있는 기능에 대해 논의합니다.

내 2센트 - 이 스레드가 너무 길어져서 여기에 이미 표현된 아이디어를 요약한 새 문제를 시작할 때입니다. 그리고 이것을 닫습니다.

이것이 Gitea가 기대하는 특성이 아니라고 말씀하신다면, 제가 잘못 이해한 것이므로 저는 이만 물러가겠습니다.

이것은 말하는 것이 아닙니다. 말하고자 하는 바는 이 스레드가 Gitea에 대한 변경/개선 사항(특히 기술적인 사항)에 대해 논의하기 위한 장소라는 것입니다. 이러한 논의는 환영할 만한 것이지만 이 특정 스레드에서는 그렇지 않습니다.

리드 중 하나로서 @XVilka가 옳게 말한 대로 이 스레드를 잠글 것입니다. 우리는 많은 피드백을 요청했으며 이제 다음 단계를 위해 평가되어야 합니다.

v2에 대한 FHS 규정 준수 경로를 변경할 수 있습니다. 플래그로 이미 가능하지만 v2의 기본값이어야 합니다.