Gitea: Discusión de la hoja de ruta de Gitea

Una solución de complemento (incluido el tema) para extender gitea.

¿Sería posible agregar paquetes de sistema operativo adecuados al proceso de compilación? He estado tratando de armar algo para Fedora, pero parece un desastre empaquetarlo. # 31 habla sobre esto, pero todavía parece estar abierto.

Estamos usando ansible para implementar el tarball en el sistema Debian, esto no es muy útil pero funciona. Los repositorios para las distribuciones más comunes estarían bien, pero es necesario instalarlos y mantenerlos.

Algunas sugerencias:

• Opción para integrar automáticamente Drone CI / CD en Gitea durante el proceso de construcción.
• Más configurabilidad de la administración del sitio desde la interfaz de usuario de Gitea, después de la instalación. Por ejemplo, me gustaría poder cambiar las cosas en _Configuración del servicio_ desde la página _Configuración_.
• Opción para ocultar un usuario de la página Explorar.

Solicitudes de extracción / problemas / bifurcaciones federadas

Solicitudes de extracción / problemas / bifurcaciones federadas

Tal vez no federado en el sentido de la palabra Fediverse (ActivityPub, OStatus, diaspora *, etc.) pero me gustaría tener la capacidad de interactuar con instancias remotas de la propia implementada de la manera que mejor se adapte al proyecto.

También puede ser interesante tener equipos y organizaciones formados por usuarios de varias instancias, aunque probablemente sería increíblemente difícil de implementar.

Dos sugerencias del punto de vista de un usuario final con habilidades mínimas de codificación que intenta ayudar a los proyectos de código abierto que utilizo informando errores y dando retroalimentación de UX:
1) ¡Ayude a estandarizar ForgeFed! Me encantaría que la UX de archivar errores en la instancia de Gitea (y otras falsificaciones de código alojadas en la comunidad) sea como un GH enorme y descentralizado.
2) Convierta cada parte de un proyecto en un repositorio de Git, de modo que los problemas, wiki, etc. puedan extraerse, ramificarse, insertarse o bifurcarse fácilmente. GL y sr.ht hacen esto con al menos algunos de sus componentes. Además de ser útil, esto podría ayudar potencialmente con el punto 1)

La capacidad de responder a los tickets por correo electrónico sería un gran paso adelante para la usabilidad.

Permita la edición de toda la configuración desde la interfaz de usuario (y tal vez cambie el formato del archivo de configuración durante el proceso)

Tal vez almacene la mayoría de la configuración dentro de la base de datos y proporcione la cli y la api adecuadas para ello

@sapk @tboerger Yo diría que deberíamos cambiar a viper para la configuración, de esa manera podríamos deshacernos de ini (y algunos de los errores que teníamos con él) y obtener cosas como recargar la configuración mientras Gitea se está ejecutando y las variables env adecuadas .

Estaría dispuesto a abordar esto, pero no estoy seguro de encontrar el tiempo en un futuro más cercano.

Yo también estoy a favor de Viper. Intenté hacerlo hace 2 años, pero no tuve tiempo de terminarlo ... pero puedo intentarlo de nuevo :)

Estoy a favor de obtener un archivo de configuración más mínimo ... Muchas de estas configuraciones no necesitan establecerse a través de un archivo de configuración estático y podrían agregarse fácilmente a la base de datos y almacenarse en caché por razones de rendimiento.

Creo que al principio podríamos agregar una tabla de configuración de la base de datos y mover la mayoría de los elementos de configuración cambiables allí desde el archivo ini y solo dejar los elementos que necesitan recargarse.

@lunny y todo: acepte mover muchas configuraciones a la base de datos y permitir que se configuren en la interfaz web (ya sea en todo el sitio o en el repositorio) se siente como un buen paso adelante. También sería fácil tener una herramienta como tea o gitea para cambiar esos valores desde la línea de comandos, de modo que aún podría escribir una configuración predeterminada.

El sistema de módulos suena genial. Creo que hay muchas personas dispuestas a agregar nuevas funciones a gitea.

@belliash @sapk Los complementos / módulos IMO no se pueden implementar de manera eficiente sin refactorizar el paquete de modelos por completo y agregar más abstracción. Probé varias tecnologías, como la compatibilidad con complementos nativos de Go.

El resultado fueron binarios gigantes que dependen en gran medida del binario de Gitea.

Creo que mejorar la compatibilidad con webhooks y agregar páginas personalizadas mediante webhooks es más realista de implementar, ya que ya tenemos una API madura y silenciosa que se puede usar para operaciones de bases de datos.

@jonasfranz Yo estaría muy a favor de refactorizar modelos para eliminar muchas de sus dependencias.

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

revela 98 (!) importaciones directas. 50 de los cuales son núcleo non-go.

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

revela 437 (!!) dependencias transitivas. (304 de los cuales son núcleo non-go)

Mire la fuente del dron, allí tenemos muchas cosas conectables basadas en webhooks.

Además de eso, un modelo de complementos como el empaquetador tiene sentido, un sistema de complementos basado en grpc.

@tboerger ¿Puede proporcionar un ejemplo de las cosas conectables de los drones? ¿Te refieres al sistema de complementos basado en imágenes de Docker?

Estoy hablando de las extensiones para configuraciones, secretos, etc., las interfaces deben definirse en https://github.com/drone/drone/tree/master/plugin

Estoy de acuerdo contigo, el próximo gran paso de Gitea debería ser el sistema de complementos. También estoy pensando en esto estos días. Probaré el sistema de complementos.

Creo que debería ser similar con el sistema de complementos de drone, pero tiene más. Tenemos que permitir que un complemento tenga una interfaz de usuario y debería iniciar sesión con OAuth2 de Gitea automáticamente. Y deberíamos tener alguna política de seguridad sobre los complementos. y etc.

Quiero compartir una tabla de comparación que hicimos alrededor de 2016 para _decidir_ qué plataforma de alojamiento elegir para la Fundación Geoespacial de Código Abierto. En esa tabla enumeramos las características que eran importantes para nosotros. Gitea está en una de las columnas:

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

Verá que una característica importante que faltaba en 2016 todavía falta hoy: respuesta por correo electrónico (comentario / respuesta) --- algunas otras se han implementado a partir de hoy.

La herramienta migrate from github y Comments on diff lines están listos.

Necesita personalización de la plantilla de correo
Ver # 6037

Así que ya es posible un poco de personalización de la plantilla: la línea de asunto es lo único que no creo que tengamos.

Sin embargo, lo que realmente deberíamos estar haciendo es habilitar i18n para el correo electrónico y los mensajes de git serv hook.

Es necesario revertir una solicitud de extracción.
Ver # 6375

Soporte completo de etiquetas en la interfaz de usuario. Crear, asignar, cambiar, eliminar, etc. Realmente extraño esta función.

Soy partidario de config en base de datos (con cli o api para configurarlo, como crear usuario y autenticación ldap, etc.) y sistema de plugins.
Esos dos deberían impulsar a gitea un gran paso adelante.

LFS

• [x] Necesitamos alguna forma de administrar los archivos LFS en un repositorio - en la actualidad son totalmente opacos # 7199 es un intento de proporcionar esto - pero para ser eficientes, es probable que se necesite ...
  
  
  
  • [] Filtro Bloom para búsqueda de blobs: sería muy bueno tener una forma ligeramente eficiente de encontrar la confirmación y en qué ruta de árbol introdujo un blob
  
  
• [] En la actualidad, no existe una forma confiable de reiniciar una carga en LFS, por lo que las cargas muy grandes pueden fallar repetidamente. Implementar tus.io según # 1723
• [] Deberíamos proporcionar una opción para usar .gitattributes para determinar si un archivo es un puntero LFS en lugar de simplemente asumir que cualquier archivo que parezca un puntero es un puntero. Aunque es probable que la funcionalidad en # 7199 sea muy difícil ...
• [] Los archivos LFS deben poder verse en la vista de diferencias.

Endurecimiento

Cierre y el comienzo de hacer de Gitea realmente agrupable

• [] Necesitamos endurecer la respuesta de Gitea al cierre.
  
  
  
  • [x] Esto significa un cierre elegante de las conexiones de escucha, en particular el SSH incorporado, que actualmente podría provocar la corrupción de los repositorios de git a través de un cierre abrupto. # 7274 es el comienzo de un intento de solucionar este problema.
  
  
  • [] pero también significa que los trabajos de notificación deben ser serializables, por ejemplo, las colas de indexación deben pasar por colas en disco o db, de manera similar colas de correo, etc. Ya tenemos algo de esto, pero estas colas no se cierran correctamente.
  
  
• [] Como corolario de lo anterior, debemos separar la acción de indexar de la búsqueda. El cierre elegante requiere esto en cualquier caso, pero es parte del paso hacia la agrupación en clústeres. No estoy seguro de qué arquitectura deberíamos tomar, pero hay varias opciones: separar el indexador en un proceso separado y hacer que Gitea solo lea el índice, o exportar todo el indexado.

Diff y lectura de datos de longitud arbitraria en la memoria

• [] El código de diferencia necesita refactorización - es frágil, lee la diferencia completa en la memoria y requiere que el navegador analice diferencias enormes antes de que el usuario pueda responder. Esto requiere cambios tanto en la interfaz de usuario como en el servidor; presumiblemente, un desplazamiento infinito respaldado con Ajax es la técnica correcta para esto. En la actualidad, una diferencia suficientemente grande podría acabar con el servidor y el navegador.
• [] Nuestra arquitectura de diferencias actualmente contamina el repositorio base con ramas y objetos combinados previamente.
• [] En general, DEBEMOS dejar de leer datos de longitud arbitraria en la memoria. Si hay un lugar donde el navegador podría querer esto, deberíamos limitar lo que leemos y luego usar una técnica de desplazamiento infinito o un enlace completo con la representación del navegador o renderizado en una canalización para asegurarnos de que no se almacena completamente en la memoria. Incluso el código relativamente nuevo todavía sufre este problema.
• [] (Si estamos ejecutando un proceso git que puede devolver datos arbitrariamente largos, deberíamos tratar de evitar leerlos todos directamente en un búfer de salida estándar por completo, pero hacer más canalizaciones de rutina).

Unir

• [] Debemos refactorizar la combinación para usar el índice de git por completo, ya que actualmente hacemos un pago escaso para la combinación, básicamente porque git merge se desplegará en https://git-scm.com/docs/git-merge-one-file para manejar fusiones que no sean de avance rápido. Esto fuerza la creación de rutas semi-arbitrarias en el servidor, que son innecesarias y dependen de los factores del sistema de archivos / juego de caracteres. No es necesario hacer esto, podemos hacer estas fusiones con archivos temporales, hash y agregando al índice directamente.

Ubicaciones de escapes y repositorios

• [] Debemos comprobar en todas partes para ver si hay escape. En general, el código heredado de Gogs se escapó mal y ha sido responsable de múltiples problemas de seguridad.
• [] La suposición de que el nombre de usuario y los nombres del repositorio no necesitan escapar nos obliga a tomar una decisión de arquitectura que no necesitamos. Ni siquiera nos protegió adecuadamente para las firmas de git, por lo tanto, # 5774.
• [] Aunque es agradable para los usuarios que la ubicación del repositorio subyacente coincida con la ubicación del sistema de archivos, por ejemplo, $GITEA_ROOT/owner/reponame es una mala decisión arquitectónica en mi humilde opinión y lleva a los usuarios a suponer que nuestros repositorios aún pueden ser usados ​​por git en el servidor sin pensamiento adicional - NO DEBEN. Deberíamos movernos a $GITEA_ROOT/repository-$ID , posiblemente fragmentado. (Hacer esto permitiría eliminar muchas llamadas a repo.MustOwner() o repo.GetOwner() )
  
  
  
  • [] Una vez que pasemos a lo anterior y estemos escapando de todo correctamente, podemos relajar las restricciones en los nombres de usuario y los nombres de los repositorios, aunque esto debería pensarse cuidadosamente para asegurarnos de que lo hacemos de una manera que no permita Fingiendo problemas similares al # 5774.
  
  
• [x] Deberíamos hacer cumplir los procesos git del servidor para que se ejecuten con un entorno de Gitea suficiente; hay usuarios repetidos que intentan usar los repositorios de Gitea en el servidor sin pasar por Gitea, por lo que luego se quejan de que Gitea no está actualizado, etc. paso necesario para esto y después de la fusión de esto, simplemente cambiamos https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 para hacer cumplir la configuración de SSH_ORIGINAL_COMMAND o hacer cumplir el resto del entorno estándar.
• [] Deberíamos poder hacer frente a repositorios montados NO_EXEC y, de hecho, probablemente deberíamos recomendar esto. Probablemente no sea realmente difícil de hacer, simplemente cambie la variable .git/config o la variable central .gitconfig core.hooksPath y piense dónde vamos a colocar los ganchos de otra manera.
• [] Básicamente, estamos almacenando líneas de código directamente en la base de datos para comentarios, lo que no funciona si los datos que se almacenan no están en UTF-8. Esto significa que simplemente no puede comentar sobre un código que no sea UTF8.

API / SDK

• [] Es una locura la cantidad de trabajo que tenemos que hacer para construir una API cuando hacemos todo el esfuerzo para tener arrogancia. Deberíamos autogenerar esto a partir de swagger, o autogenerar tanto como sea posible.
• [] No tenemos forma de probar una versión de API fija en nuestro desarrollo Gitea, por lo que no podemos saber cuándo estamos haciendo cambios importantes.
• [] Deberíamos poder utilizar una API / SDK generada automáticamente para crear arneses de prueba simples

Pruebas

• [] Actualmente ejecutamos nuestras pruebas unitarias a nivel de TRACE; esto limita nuestra capacidad para agregar un seguimiento adecuado a las cosas. Desde https://gitea.com/gitea/log/pulls/3 y si hacemos backport a Gitea, podemos cambiar esto desde nuestro makefile.
• [] Necesita más pruebas unitarias y considere si algunas de las pruebas de integración son realmente unitarias y viceversa. por ejemplo, https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [] Necesitamos más pruebas de integración que intenten ejecutar a través de historias de usuarios. Es decir: un usuario inicia sesión, hace X, luego sucede Y y Z. Está bien probar cosas de forma aislada, por ejemplo. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go pero eso no está realmente integrado y no prueba lo que experimenta el usuario. Sigo diciendo esto, pero más pruebas deberían verse así: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go y https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go que realmente prueba si una función se integra correctamente.
• [x] Nuestro régimen de pruebas lleva demasiado tiempo: ¡CI está tardando entre 30 y 40 minutos en ejecutarse en la actualidad! Deberíamos ejecutarlos en paralelo.
• [] No existe una forma sencilla de crear pruebas de migración.

Ir a la arquitectura del paquete

Modelos

• [] code.gitea.io/gitea/models depende de demasiadas cosas que esto tiene que terminar.
• [] models.x debe ser destruido. Es una terrible decisión arquitectónica.
• [] Para muchos de los modelos es demasiado fácil causar una desreferenciación nula del puntero porque no sabes en qué estado se encuentra. ¿Podemos usar el sistema de escritura de go un poco mejor aquí?
• [x] Deberíamos pegar OwnerName en la tabla del repositorio, ya que cada vez que obtenemos un repositorio tenemos que ir a buscar el propietario. Es una tontería y una pérdida de tiempo. Los repositorios no cambian de propietario con mucha frecuencia, por lo que el costo de tener que manejar eso no es importante.
• [] Todavía se hacen demasiadas cosas en los modelos y se deberían eliminar más.
• [] Puede tener sentido dividir los modelos en básicos y no básicos.

Módulos

• [x] Existen esencialmente dos tipos de módulos: los que dependen de los modelos y los que dependen de los modelos. Separemos estos, uno podría llamarse servicios.

Macaron

• [] Creo que deberíamos tomarnos en serio el cambio a la ginebra propuesto por @lunny
• [] Nuestro código base está salpicado de dependencias en macaron, este no debería ser el caso

Configuración

• [] Depende del macaron también (!)
• [] Está estrechamente vinculado a go-ini, otra dependencia de la que deberíamos considerar desconectarnos.

Internacionalización

• [] Correo electrónico no internacionalizado
• [] Mensajes de Git no internacionalizados
• [] Mensajes de error no internacionalizados
• [] Deberíamos automatizar la eliminación de la documentación de nuestro sitio web de hugo para que pueda internacionalizarse con CrowdIn.
• [] Es extraño que tengamos los idiomas que usan formas en minúsculas, por ejemplo, français, español en las listas de selección de idiomas; esto representa el comienzo de una oración en cada uno de esos idiomas, por lo que AFAICS deben estar en mayúscula. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • inglés
  
  
  • Français
  
  
  • Español
  
  

Volcado y restauración de Gitea

• [] El volcado de Gitea está roto para convertir entre variantes de SQL
• [] No tenemos comando de restauración

En la parte de la interfaz de usuario, sugeriría entregar dos interfaces de usuario:

• un HTML simple (similar al actual uno sin js)
• un JS completo que se basa solo en la llamada a la API. Esto obligaría a repensar algunas API, pero también permitirá una mayor interacción de otras aplicaciones externas.

• creo que deberíamos tomarnos en serio el cambio a la ginebra propuesto por @lunny

Sugeriría go-chi en lugar de ginebra.

• Debemos automatizar la eliminación de la documentación de nuestro sitio web de hugo para que pueda internacionalizarse con CrowdIn

En mi humilde opinión, el sitio web / documentos no deben traducirse en absoluto, de todos modos siempre está desactualizado ...

En mi humilde opinión, el sitio web / documentos no deben traducirse en absoluto, de todos modos siempre está desactualizado ...

Pero con el crowdin, estar desactualizado notificaría a las personas e invalidaría las traducciones actuales.

¿Sería posible agregar paquetes de sistema operativo adecuados al proceso de compilación? I

Quizás los paquetes de estilo PPA controlados y versionados por los desarrolladores de GItea serían una buena idea, pero no soy fanático de la forma de versionar "parches de seguridad de congelación y backport" estilo Debian para proyectos de rápido movimiento (como GItea)

Todavía me gustaría tener https://github.com/go-gitea/gitea/issues/3840.
Creo que se puede implementar con compatibilidad con versiones anteriores.
Pero esto quedará claro solo después de que se establezca la migración de la nueva biblioteca de enrutamiento.
Una limpieza / refactorización fundamental como requisito previo también lo haría más fácil.

Todavía me gustaría tener el # 3840.
Creo que se puede implementar con compatibilidad con versiones anteriores.
Pero esto quedará claro solo después de que se establezca la migración de la nueva biblioteca de enrutamiento.
Una limpieza / refactorización fundamental como requisito previo también lo haría más fácil.

En ese caso, es posible que pierda el soporte de Drone, ya que actualmente tampoco está implementado para Gitlab.

Todavía me gustaría tener el # 3840.
Creo que se puede implementar con compatibilidad con versiones anteriores.
Pero esto quedará claro solo después de que se establezca la migración de la nueva biblioteca de enrutamiento.
Una limpieza / refactorización fundamental como requisito previo también lo haría más fácil.

Probablemente no necesitemos esta función de grupo para afectar las URL del repositorio, simplemente podríamos crear carpetas en las que el repositorio podría colocarse en la pantalla, pero mantener las URL del repositorio igual que ahora.

@tboerger
Mi pensamiento fue que la URL puede permanecer igual si un repositorio no está anidado en un grupo / directorio.
Las URL deben "actualizarse" solo si el repositorio utiliza la función de grupo / directorio.
Pero sí, los repositorios con las nuevas URL probablemente no podrían tener compatibilidad con Drone de fábrica.

@lafriks
Eso suena como una buena idea. Mi escenario de uso de la función es alojar módulos Git o los subproyectos de proyectos Repo. Entonces, no estoy seguro de que cubra ese caso.

No hay problema. Soy reacio a hacer un cambio tan extenso, y posiblemente rompedor, también.

Este problema tiene una buena idea y deberíamos mantenerlos y abordarlos.
Sin embargo, ¿cuándo y cómo deberíamos elegir? Esta discusión puede durar para siempre.

Sugeriría que el propietario elija los temas o una votación entre ellos y los miembros.
¿Qué piensas?

@DblK Eso es correcto. Pero creo que podríamos hacer eso después de migrar a gitea.com. Actualmente necesitamos más comentarios de los usuarios.

• Soporte mercurial
• mejor clasificación y filtrado de relaciones públicas y problemas

• Soporte mercurial

No por favor. Se llama "git" ea por una razón.
Entiendo el deseo de tener un alcance más amplio pero
la hinchazón está a la vuelta de la esquina ...

la importación mercurial sería una alternativa

El 26 de julio de 2019 1:52:50 PM UTC, Sandro Santilli [email protected] escribió:

• Soporte mercurial

No por favor. Se llama "git" ea por una razón.
Entiendo el deseo de tener un alcance más amplio pero
la hinchazón está a la vuelta de la esquina ...

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Solicitudes de extracción / problemas / bifurcaciones federadas

Tal vez no federado en el sentido de la palabra Fediverse (ActivityPub, OStatus, diaspora *, etc.) pero me gustaría tener la capacidad de interactuar con instancias remotas de la propia implementada de la manera que mejor se adapte al proyecto.

Ya hay una discusión sobre esto en el n. ° 1612. ForgeFed recopila algunas ideas interesantes para que la federación forme códigos como Gitea. ¡Sería increíble si esta fuera la próxima gran característica de Gitea!

Me encantaría una herramienta de diferenciación visual para archivos gráficos (JPEG, PNG, pero también PDF), similar a la que ofrece Github .

Ya tenemos un PR para diferenciar imágenes

Ya tenemos un PR para diferenciar imágenes

Es cierto, pero eso no cubre la vista previa de deslizamiento o piel de cebolla, solo una al lado de la otra. Además, no creo que cubra los archivos PDF. Estamos usando Gitea aquí para el desarrollo de material gráfico (incluidos manuales y folletos), y una buena diferencia visual para archivos PDF cambiaría la vida.

Tengo algunas ideas que solo quiero lanzar: smile_cat:

1. Utilice Cloud KSM para cifrar / descifrar de forma transparente cualquier secreto. Esto protegerá contra DB hackeado y expuesto. La idea es que podamos usar un tipo personalizado con métodos de codificación / decodificación XORM para cifrar los datos secretos antes de escribir en la base de datos. Hicimos un ejemplo de demostración aquí: https://github.com/gomodules/ksm-xorm

2. Soporte OIDC: Devuelve id_token además del token oauth2 cuando inicias sesión a través de Gitea

3. El perfil de usuario de Gitea puede mostrar el perfil del usuario en cualquier repositorio de Git verificado. Ejemplo: el usuario puede anclar repositorios de Github / Gitlab / BitBuket / Gitea. La idea es que los usuarios tampoco puedan ignorar a los demás. Entonces, ¿puede gitea ser el único perfil de usuario global?

4. Soporte de dominio personalizado para repositorios (ir)

5. Compatibilidad total con Github (he visto algunos trabajos en este frente, no sé cuánto ya se ha hecho).

6. Integración de servidor de idiomas opcional. Algo como Sourcegraph, como la navegación integrada en la interfaz de usuario.

Me gustaría contribuir a 1 & 2 en poco tiempo.

Tal vez podamos mostrar diff en una forma de árbol de carpetas y archivos que han cambiado, como en BitBucket, en lugar de una página enorme con todos los cambios. Sería mucho más legible.

Quizás una opción para agregar notificaciones en todos los repositorios por día o por semana.
Algo así como un resumen de las actividades de las últimas semanas.

Agregue la posibilidad de definir webhooks personalizados a través de plantillas personalizadas y un grupo de variables estándar.

No es una evolución de Gitea, sino un proyecto paralelo que sería útil: # 7853

¡Paridad de características con github!

O, al menos, una lista actualizada en la wiki, que muestra todas las características que aún necesitamos antes de lograr la paridad. Esta sería una buena forma de estructurar los esfuerzos de desarrollo futuros.

@ lonix1 echa un vistazo a https://docs.gitea.io/en-us/comparison/ para ver esa lista

¡@kolaente parece que tenemos casi todas las marcas! ¡sí!

Soy muy nuevo aquí, pero también un codificador dispuesto; Me encantaría que gitea apoyara las esencias. Ese es uno de los mayores agujeros para mi uso. Se solucionó con bastante facilidad, pero prefiero tener un sistema esencial en su lugar.

Creo que el problema de los gists sería https://github.com/go-gitea/gitea/issues/693 (enlazando, ya que todavía no parece que se haga referencia a él desde aquí).

Agregue también la documentación Help , a la que se puede acceder mediante el enlace Help . La fuente inicial de esta documentación puede ser de la Ayuda de GitHub , con modificaciones específicas de Gitea.

La ayuda de

1. Creación de problemas a través de correo electrónico (consulte la mesa de servicio de GitLab).

Si más personas comienzan a adoptar el autohospedaje para compartir sus proyectos de código abierto, es necesario que los usuarios no registrados envíen problemas sin tener que crear una cuenta en cada instancia (es muy poco probable que la mayoría de las personas se registren para detectar un error). reporte).

1. Algo parecido a AutoDevOps de GitLab. Esto significa la capacidad de definir un trabajo de CI predeterminado cuando no hay ningún archivo yaml de CI en el repositorio.

2a. Pestaña de interfaz de usuario de registro de contenedor y autenticación.

1. Bots
2. GPG para confirmaciones web
3. Capacidad para bloquear fusiones según las condiciones
4. Capacidad para crear archivos en la interfaz de usuario web (incluso en un repositorio vacío en blanco)
5. Administre los fragmentos adjuntos al repositorio a través de la interfaz de usuario (consulte GitLab)
6. Compatibilidad con el protocolo Git v2
7. Opción de IDE web mejorada
8. Integración de Kubernetes (a través del complemento de interfaz de usuario a la GitLab)
9. Agregue un retraso de 400 ms antes de que se muestre una información sobre herramientas al pasar el mouse
10. Mejor integración de CI (show pipelines, soporte de Concourse, etc.)
11. Refinar la interfaz de usuario
12. Hacer cumplir 2FA
13. Bloqueo de archivos
14. Cerrar automáticamente los problemas vinculados con la combinación de relaciones públicas.

Algún tipo de sistema de extensión / complemento.

La mayoría de las sugerencias son buenas, pero crearán problemas en el código base.

Sería mejor tener complementos oficiales (y no oficiales). Esto también significaría que los autores de complementos podrían publicar con más frecuencia.

@ lonix1 Bueno, los ganchos de git, los webhooks y la API Swagger pueden considerarse puntos de conexión de complementos. Estoy a favor de más compatibilidad con complementos, pero indicar una lista con detalles específicos podría ayudar. Por ejemplo, me gustaría tener soporte para un equivalente de línea de comandos de webhooks.

@ guillep2k Por ejemplo, todas las funciones de gestión de proyectos discutidas anteriormente. Serían muy útiles, pero probablemente toquen tantas partes del código base que 1) podrían causar problemas incluso para aquellos que no usan esas funciones, y 2) debido a eso, dicho desarrollo es muy lento porque los responsables de La fusión de nuevas funciones saben que este escenario es posible, por lo que son cautelosos.

Si estas nuevas funciones pudieran lanzarse por separado, los usuarios que lo deseen podrían probarlas antes de fusionarlas en la rama principal.

Y hay otros ejemplos de este tipo de grandes características nuevas, simplemente desplácese hacia arriba.

@brandonkal GPG La firma de confirmaciones generadas automáticamente ahora es posible con la fusión de # 7631

Supongo que la hoja de ruta debe dividirse en esas cuatro categorías (agregué algunos problemas de ejemplo; debería ser obvio que está lejos de estar completo: guiño :):

Funcionalidad básica

Todavía hay algunas _funciones básicas_ que no funcionan correctamente.
Por ejemplo:

• todavía necesita una buena solución de búsqueda como se menciona en problemas como # 5694 # 5277 # 3448, # 2967, # 2434, # 8366, # 8386 y # 7825
• el visor de PDF no funciona
• el visor de SVG está roto
• parece que se utilizan dependencias no libres

Seguridad

También existen algunos problemas de seguridad:

• [] [la imagen de Docker todavía se ejecuta como root] (https://github.com/go-gitea/gitea/issues/1190) aunque la guía de Docker es muy clara al respecto y no hay razón para usar el root usuario (puede reasignar puertos en el exterior de todos modos)
• [] [aún no es posible aplicar 2FA] (https://github.com/go-gitea/gitea/issues/880)
• [] [Habilite la configuración de encabezados CSP más estrictos eliminando estilos en línea] (https://github.com/go-gitea/gitea/issues/305)
• [] [no se comprueba si alguien puede acceder a los archivos adjuntos] (https://github.com/go-gitea/gitea/issues/7908)

Integración

Supongo que la integración con otras aplicaciones / servicios es algo bueno en general.
Porque el desarrollo de software no suele depender de una única herramienta.
Y probablemente ayudará a convencer a algunas personas de que utilicen Gitea en su lugar de trabajo.

Esos dos problemas mejorarían mucho la interoperabilidad:

• [] integra automáticamente Drone CI / CD ( como @BNolet propuesto anteriormente )
• [] [Integración de API para revisiones de relaciones públicas automatizadas] (https://github.com/go-gitea/gitea/issues/5733) a través de herramientas como Pronto
• [] [fácil integración con Container Registry] (https://github.com/go-gitea/gitea/issues/2316)
• [] una solución de webhook genérica que permite a los usuarios configurar webhooks personalizados fácilmente ( como lo propuso @bkcsoft anteriormente )

Además, los webhooks genéricos evitarían la necesidad de que otras personas conozcan los aspectos internos de gitea. @ guillep2k tuvo una idea maravillosa de que una integración de "comando externo" podría realizarse de manera similar a la integración de webhook genérico .
: advertencia: Esto probablemente resolvería la mayoría de los problemas sobre lo que la mayoría de las personas en este tema quieren como 'soporte de complementos' . Porque eso permitiría llamar a cualquier usuario que necesite llamar. Sin embargo, @lunny acaba de mencionar que esto ya es prácticamente posible a través de git hooks. Simplemente no estoy muy seguro de si esta es realmente la mejor manera de integrar otras herramientas / complementos / servicios.

Funciones superiores

Además, obviamente, hay algunas características interesantes en aplicaciones de la competencia (es decir, Git [Hub / Lab]) (la mayoría de ellas probablemente sea bastante agradable de tener):

• [] [Revertir PR] (https://github.com/go-gitea/gitea/issues/6375)
• [] [Diferenciación mejorada para cosas no textuales como lo menciona @ arthur-bauer] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [] [ediciones de mantenedores] (https://github.com/go-gitea/gitea/issues/717)
• [] [Problemas confidenciales] (https://github.com/go-gitea/gitea/issues/3217)
• [] muestra más detalles del repositorio (es decir, tamaño del repositorio , gráfico de contribuyentes , barra de idiomas )
• [] algunas mejoras en la wiki (# 823 # 574)
• [] [que tiene una diferencia como BitBucket como lo menciona @SignumPL] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (no lo sabía antes, pero parece realmente útil )
• [] [integra una funcionalidad como Octotree] (https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

¿Se puede utilizar la base de datos Oracle como opción? Si es posible técnicamente.

@DemiusAcademius Si xorm soporta mejor Oracle, creo que es posible.

Cada vez más personas están comenzando a usar Gitea, por ejemplo, también debido al reciente anuncio del rastreador de GitLab. Pero GitHub / GitLab todavía tienen el efecto de red de su lado.

La federación sería un gran impulsor para mejorar la capacidad de colaboración entre usuarios de diferentes instancias de Gitea y, por lo tanto, aumentar toda la red de Gitea: # 1612

Se informó que la capacidad de mostrar grandes diferencias en la IU es un factor limitante en la adopción de Gitea.
Tickets que lo abordan: # 7341 (función), # 7495 (error de bloqueo)

Se informó que la capacidad de mostrar grandes diferencias en la IU es un factor limitante en la adopción de Gitea.
Tickets que lo abordan: # 7341 (función), # 7495 (error de bloqueo)

Esa es una limitación enorme. En mi opinión, todo lo que @alexanderadam enumeró anteriormente palidece en comparación con esto. Si no puedo revisar diferencias grandes comentando en línea en el código, eso es un gran problema.

W / R / T la ira contra Microsoft y Github que causó la migración de muchos proyectos y provocó una gran demanda de federación, Gitlab ha propuesto recientemente prohibir a los empleados en China y Rusia, 2 de los países más grandes del mundo por masa de tierra y economía. El ejército de los EE. UU. Ha cambiado el enfoque a China y Rusia (entre otros) para debilitar las barreras que plantean a la expansión / intereses imperiales de EE. UU. La propaganda y los incentivos financieros han llevado a Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) e incluso a Gitlab a las industrias de la guerra, el espionaje, la propaganda y la vigilancia en un papel ofensivo.

Menciono esto para agradecer a quienes trabajan en repositorios remotos de código abierto de alta disponibilidad con pocas deficiencias en los servicios corporativos y vinculados al Pentágono que usamos y en los que todavía confiamos ahora, y para llamar su atención sobre las alternativas rápidas que existen. desapareciendo para aquellos que deseen utilizar Internet y la tecnología tan lejos del imperio más poderoso y hostil de la historia.

Quizás el tema sea lo suficientemente grande como para que una sección separada del sitio web oficial realice un seguimiento del progreso en esta función, junto con una campaña de recaudación de fondos separada para capturar esta demanda. Incluir a ForgeFed en la recaudación de fondos puede ser beneficioso y justo, viendo su trabajo hasta ahora. Han pasado 17 meses desde el combate de Microsoft con Github, y espero que en otros 17 meses podamos usar Gitea federado, o tener partes restantes del 'patrimonio neto en construcción'.

Por favor, no hablemos de política aquí, sigamos con el tema: mejorar Gitea para todos.

@lafriks Mejorar Gitea significa definir un nicho, algo que los productos sustitutos no satisfacen. El marketing es el proceso de encontrar oportunidades externas, siendo "político" una de las 4 categorías principales de análisis de marketing. Una marca inteligente atrae los _valores_ de las personas tanto como ofrece características, especificaciones y precio. Existe una atracción basada en valores ("política") hacia alternativas como Gitea, y no subrayarlo y mantenerlo sería una falla en comprender a su consumidor y la oportunidad del mercado.

"Político" como término se ha convertido en un cliché que acaba con el pensamiento, extinguiendo la discusión sobre el racismo, la violencia y la explotación. Simplemente vine aquí para agradecer a la gente por continuar trabajando en alternativas no asociadas con los campos de concentración estadounidenses, la vigilancia con redes de arrastre y otros intereses imperialistas en los que la mayoría de nuestra industria está ayudando activamente. Si está diciendo que estas no son cualidades que Gitea defiende, Te entendí mal y me iré.

Nota para @OKNoah

Marketing 101 para un proyecto de código abierto:

1. No menciones los campos de concentración
2. No menciones la política
3. Pierde el sombrero de papel de aluminio
4. No uses términos antiguos como imperialismo.
5. Conozca la ventaja de su producto. La ventaja de Gitea es su sencillez.

Si la transparencia de GitLab.com te ofende, puedes autohospedar GitLab-FOSS. Es un producto todo en uno extremadamente bueno. Pero si desea una instalación simple o requiere un menor uso de memoria en comparación con GitLab o GitHub Enterprise, Gitea es una buena opción para las funciones web básicas.

Este hilo trata sobre las características que pueden ayudar a cerrar esa brecha sin comprometer la simplicidad.

Mis 2 centavos: creo que este hilo se volvió demasiado largo y es hora de abrir un nuevo número que resuma las ideas que ya se han expresado aquí. Y cierra este.

Si estás diciendo que estas no son cualidades que Gitea defiende, te entendí mal y me iré.

Esto no es lo que se dice. Lo que se dice es que este hilo es el lugar para discutir qué cambios / mejoras a Gitea se pueden hacer (específicamente técnicos). Estas discusiones son más que bienvenidas, pero no en este hilo específico.

Como uno de los clientes potenciales, bloquearé este hilo, como @XVilka lo dijo correctamente, hemos solicitado muchos comentarios y ahora debería evaluarse para los próximos pasos.

Podríamos cambiar el camino hacia el cumplimiento de FHS para v2. Ya es posible con banderas, pero debería ser el predeterminado para v2.