@sledgehammer999 deberías leer esto => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Afortunadamente no tener el virus (y espero seguir así).

Me alegro por ti personalmente.

Pero estoy muy triste por el estado actual del proyecto (y no soy el único que siente lo mismo). El momento del cambio es crítico. Por lo tanto, debe reestructurar la gestión/mantenimiento del proyecto o declarar explícitamente que es solo su juguete personal, para que nadie más tenga falsas esperanzas.

¿Hay compromisos que deban ser exentos?

No creo que tenga sentido omitir ningún cambio ahora.

En cualquier caso, una nueva versión está muy atrasada.

Demasiado.

¿Debo, como de costumbre, respaldar todas las confirmaciones maestras nuevas en la rama v4_2_x?

¿Por qué v4.2.x? ¡Hay más que suficientes cambios para v4.3!
Además, simplemente puede crear la rama v4_3_x encima del maestro actual, en lugar de hacer este trabajo innecesario "seleccionando" las confirmaciones una por una.

Acabo de terminar de ver las confirmaciones desde la versión anterior hasta el último maestro. (títulos de compromiso y descripciones de relaciones públicas en su mayoría)

¿Por qué v4.2.x? ¡Hay más que suficientes cambios para v4.3!

Si. Hay un montón de confirmaciones. Y dado que se eliminó libtorrent 1.1.x, seguramente garantiza v4.3.x. (Y v4.4.x para libtorrent 2.0.x y c++17!!!)
Crearé un nuevo PR para el próximo registro de cambios, tan pronto como sea posible.

Acerca de la gestión de proyectos: hablaremos de esto después del fin de semana/próximo lanzamiento.

@sledgehammer999

Me alegro de que estés de vuelta y de que todo esté bien.

¿Debo, como de costumbre, respaldar todas las confirmaciones maestras nuevas en la rama v4_2_x? ¿Hay compromisos que deban ser exentos?

Soy indiferente a la propuesta de etiquetar la nueva versión 4.3.x. Depende de ti y de los demás decidir.

Todos los compromisos son buenos AFAIK. Sin embargo, muchas correcciones muy importantes también se han fusionado con libtorrent, por lo que es importante usar el último RC_1_2 posible para esta nueva versión.

Ya ha habido un par de compromisos relacionados con el soporte de BitTorrent V2. Sin embargo, esperaría que esta versión se construya con el último libtorrent RC_1_2 como se mencionó anteriormente, por lo que la mayoría de los usuarios no verán nada de esto en la práctica. Por lo tanto, pondría una nota en el registro de cambios explicando esto, para que los usuarios no tengan falsas esperanzas cuando lean las entradas relacionadas con BitTorrent V2.

He actualizado mi cadena de herramientas local. El backporting/changelog/minimal testing tomará algún tiempo. Pero creo que este fin de semana es un objetivo factible dependiendo del tamaño de los cambios.

¿Puede proporcionar detalles sobre esto? Supongo que tiene el último MSVC 2019 y _espero_ que esté usando vcpkg o similar para las dependencias: menos posibilidades de errores extraños debido a ligeras discrepancias en la forma en que todo está construido y más reproducibilidad. Puede consultar el nuevo CI de GitHub Actions para inspirarse. Además, recuerde usar CMake para compilar esta vez, se ha convertido en el nuevo sistema de compilación predeterminado.

Acerca de la gestión de proyectos: hablaremos de esto después del fin de semana/próximo lanzamiento.

Está bien, pero más temprano que tarde, por favor. Y debemos continuar la discusión sobre la automatización del proceso de lanzamiento, para que incluso el empaquetado se pueda hacer automáticamente.

@sledgehammer999

Además, limpie el PPA en el proceso. Las versiones de Ubuntu que no sean 18.04 , 20.04 y 20.10 son EOL, por lo que los archivos para compilaciones dirigidas a esas versiones deben eliminarse lo antes posible.

por lo que es importante utilizar el RC_1_2 más reciente posible para esta nueva versión.

Esto es evidente.
Qt 15.1, abre SSL 1.1.1 h, impulso 1.74

RC_2_0 no se utilizará todavía. No sin un par de versiones beta oficiales.

Supongo que tiene el último MSVC 2019 y espero que esté usando vcpkg

No, todavía me quedo con msvc2017 para esta versión. La última vez que revisé msvc2019 produjo un archivo .pdb muy grande para qbt. Lo comprobaré de nuevo más tarde, pero no para esta versión.
El resto de las dependencias se construyen de la forma en que siempre he hecho las cosas. Más o menos descrito aquí: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Además, recuerde usar CMake para compilar esta vez, se ha convertido en el nuevo sistema de compilación predeterminado .

Aparentemente me perdí esto en el registro de git. Estoy un poco desanimado, pero realmente no puedo objetarlo, ya que todos los demás se sienten más cómodos usando cmake que autotools/qmake.
Sin embargo, por el momento continuaré usando autotools/qmake para el lanzamiento. No tengo tiempo para familiarizarme con cmake para el lanzamiento.

Veré qué hacer con los PPA, aunque no hacen daño a nadie.

@sledgehammer999 Sé que no quiere que los usuarios normales comenten aquí, así que disculpas... He estado creando compilaciones de Windows aquí con el propósito de solucionar problemas/errores, etc.

Compilo con MSVC 2019 y los ejecutables qBittorrent suelen tener alrededor de 27 MB y .pdb son 180 MB

¿Has pensado en usar /pdbstripped ?

Compilo con MSVC 2019 y los ejecutables qBittorrent suelen tener alrededor de 27 MB y .pdb son 180 MB

Compare con msvc2017 y el maestro actual: 24,4 MB exe y 98,1 MB pdb. Como dije, el pdb es muy grande en comparación con msvc2017.

Además, no creo que queramos /pdbstripped. Probablemente dará backtraces menos útiles cuando el programa falle.

Además, no creo que queramos /pdbstripped. Probablemente dará backtraces menos útiles cuando el programa falle.

/PDBCompress ?

@sledgehammer999

Las compilaciones de CI automatizadas, que usan CMake + el último MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) tienen 57 MiB (ejecutables) + 122 MiB (pdb).

No, todavía me quedo con msvc2017 para esta versión. La última vez que revisé msvc2019 produjo un archivo .pdb muy grande para qbt. Lo comprobaré de nuevo más tarde, pero no para esta versión.

Esta no es una buena razón, en mi opinión. MSVC 2019 contiene muchas correcciones. Es (finales de) 2020. A nadie le importa un tamaño de instalación adicional de \~50 MiB (y si lo hacen, qué mal jajaja). Podemos averiguar más tarde si algo está inflando el pdb/ejecutable, pero por ahora todo funciona y \~50 MiB extra es una compensación que haría cualquier día de la semana por una cadena de herramientas mucho más reciente.

Además, no creo que queramos /pdbstripped. Probablemente dará backtraces menos útiles cuando el programa falle.

:+1:, pero esto puede investigarse adecuadamente en el futuro.

El resto de las dependencias se construyen de la forma en que siempre he hecho las cosas. Más o menos descrito aquí: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Aparentemente me perdí esto en el registro de git. Estoy un poco desanimado, pero realmente no puedo objetarlo, ya que todos los demás se sienten más cómodos usando cmake que autotools/qmake.
Sin embargo, por el momento continuaré usando autotools/qmake para el lanzamiento. No tengo tiempo para familiarizarme con cmake para el lanzamiento.

:-1:, esta no es la forma en que la mayoría de la gente ha estado probando qBittorrent durante los últimos meses en Windows. Mucha gente estaba usando compilaciones de mi rama de CI (CMake + vcpkg), y ahora la propia sección Acciones del repositorio. Diría que es muy probable que observemos regresiones inexplicables derivadas de las diferencias en el proceso de construcción si hace esto.

@sledgehammer999 No quiero agregar más "bloqueadores" antes del lanzamiento, pero al menos esperaría a que llegue, ya que básicamente está listo: https://github.com/qbittorrent/qBittorrent/pull/13499

El cambio en el valor predeterminado para subprocesos de E/S asíncrona será beneficioso para muchos usuarios.

No quiero criticar msvc2019, pero creo que estás un poco exagerado al considerar que todo lo nuevo es mejor. No siempre es el caso. Y sí, 50 MB extra para un cliente bt es un gran problema. Es un exceso innecesario sin ningún beneficio medible (por ejemplo, el programa no se vuelve 1,5 veces más rápido).

Por último, sobre los sistemas de compilación: si vemos regresiones solo por el cambio del sistema de compilación, entonces hay algo gravemente mal con el código. Las cosas no deberían ser tan frágiles.

13499 está fuera del alcance ya que se trata de una opción libtorrent 2.0.x que aún no es la predeterminada. Por último el corte se realizará el fin de semana.

@sledgehammer999

No quiero criticar msvc2019, pero creo que estás un poco exagerado al considerar que todo lo nuevo es mejor. No siempre es el caso.
Y sí, 50 MB extra para un cliente bt es un gran problema. Es un exceso innecesario sin ningún beneficio medible (por ejemplo, el programa no se vuelve 1,5 veces más rápido).

Por favor, no deseche mis argumentos como "nuevo = mejor". Y creo que está un poco "exagerado" al apegarse a una cadena de herramientas peor para 50 MiB. Por supuesto, nunca (o muy raramente) verá un aumento de velocidad de "1.5x" al actualizar su cadena de herramientas. Pero esa es una barra poco realista para establecer. Con una cadena de herramientas más reciente, es posible que no haya una velocidad "1.5x", pero siempre hay pequeñas mejoras de rendimiento, mejor soporte de lenguaje, mejor generación de código (que a veces conduce a menos errores), ... Hay muchos recursos en línea que documentan el mejoras en MSVC 2019.

Una vez más, estoy de acuerdo en que deberíamos eliminar esos 50 MiB adicionales si es posible, pero mi punto es que si no podemos hacerlo a tiempo para el próximo lanzamiento (¡o nunca!), _está bien_. Además, no hay ninguna implicación de que esto seguirá sucediendo con cada lanzamiento una vez más (también me molestaría en ese caso). Este es claramente un problema aislado. Como usuario, no me gustaría escuchar "aquí está tu binario de peor calidad, pero al menos te ahorramos 50 MiB, hermano". 50 MiB es un error de redondeo hoy en día (para los programas de escritorio, de todos modos; por supuesto, en el mundo integrado y ese no es el caso). Lo siento, pero te equivocas si piensas lo contrario.

Por último, sobre los sistemas de compilación: si vemos regresiones solo por el cambio del sistema de compilación, entonces hay algo gravemente mal con el código. Las cosas no deberían ser tan frágiles.

No necesariamente. Algo puede estar seriamente mal con el propio sistema de compilación. Vea el estado anterior del sistema de compilación CMake, antes de mi revisión PR. Antes de eso, compilar con CMake generaba bastantes errores. Algunos problemas (¡a veces graves!) realmente se derivan de sistemas de compilación incorrectos/malos y recetas de compilación. No importa cuán robusto sea su código, si lo construye mal, se romperá, a veces de manera muy espectacular pero difícil de diagnosticar.

13499 está fuera del alcance ya que se trata de una opción libtorrent 2.0.x que aún no es la predeterminada. Por último el corte se realizará el fin de semana.

Por favor vea el resto de la discusión. Ese PR también cambia el número predeterminado de subprocesos de E/S asíncronos, de modo que, de manera predeterminada, también se usan al menos 2 subprocesos hash al compilar contra libtorrent 1.2.x. Esto da como resultado un aumento de rendimiento muy significativo para los usuarios de SSD (más de 1.5x, en realidad, je) al mismo tiempo que proporciona una ganancia muy marginal para los usuarios de HDD también.

@sledgehammer999

Aquí hay algo de ayuda para empezar:

• el nuevo tutorial para compilar con CMake estáticamente en Windows: https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• lista de opciones + breve tutorial/introducción de CMake: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake:-common-information

En caso de que no esté usando vcpkg, o si está usando vcpkg para algunos paquetes pero no para otros, solo necesita pasar adicionalmente las sugerencias apropiadas que le indican a CMake dónde encontrar los archivos de configuración para los paquetes, como -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . En caso de duda, simplemente puede ejecutar la configuración hasta que tenga éxito, corrigiendo cada mensaje de error sobre cada paquete uno a la vez a medida que aparecen, ya que los mensajes de error son lo suficientemente útiles como para que siempre pueda entender y averiguar qué necesita agregar. próximo.

No voy a discutir más acerca de los compiladores. No estoy de acuerdo contigo específicamente para qbt. msvc2019 será mucho más relevante para nosotros una vez que cambiemos a c++17. Por último, para un usuario de cliente bt, lo único que le importa es si el cliente puede alcanzar la velocidad máxima hacia abajo/arriba. Esa es la métrica para el binario de calidad "mejor" o "peor". msvc2017 logra eso sin sobrecarga adicional. --Mantengo mi juicio hasta que rehago mis compilaciones con msvc2019--

como -DLibtorrentRasterbar_DIR=C:\ruta\a\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar

¿Hace alguna diferencia cómo se construye/instala un paquete? Actualmente no tengo la carpeta cmake debajo lib para cualquiera de boost, libtorrent, openssl. Solo por qt.
PD: boost y libtorrent se construyen usando b2. Openssl usando su script de configuración.

@sledgehammer999

El único requisito es que construyas libtorrent con CMake, IIRC. Todos los demás paquetes generan los archivos de configuración necesarios de forma predeterminada o son compatibles con CMake de alguna manera:

• libtorrent tiene que construirse con CMake para que se generen los archivos apropiados. Esto se cubre específicamente en el tutorial Wiki.
• CMake es compatible de forma nativa con OpenSSL a través de un módulo de búsqueda incluido: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. Solo necesita configurar OPENSSL_ROOT_DIR . Ejemplo: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost genera los archivos requeridos por defecto. Solo tienes que configurar Boost_DIR Ejemplo: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• Para zlib tienes que pasar algunos caminos. Ejemplo: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt genera los archivos requeridos, supongo que ya descubrió el indicador de tiempo de configuración requerido para señalarlos.

Nuevamente, si le falta alguno de estos, CMake se lo informará en el paso de configuración y le sugerirá exactamente lo que quiere que agregue.

Estoy de acuerdo con sledgehammer999.
El binario más pequeño siempre es mejor. Especialmente dado el historial de lanzamientos anteriores.
Muchos todavía tienen un Internet lento... también el sitio web que sirve los binarios podría ser lento para algunos usuarios según la ubicación.
En tales casos, un binario pequeño permite una descarga más rápida. Las personas pueden desanimarse a actualizar si sospechan de bloatware innecesario.

se ha convertido en el nuevo sistema de compilación predeterminado.

sistema de compilación predeterminado de qué?

se ha convertido en el nuevo sistema de compilación predeterminado.

sistema de compilación predeterminado de qué?

incluso declaró obsoleto qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

incluso declaró obsoleto qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

¡Esta arbitrariedad está empezando a enfurecer de verdad!

se ha convertido en el nuevo sistema de compilación predeterminado.
sistema de compilación predeterminado de qué?

¡Esta arbitrariedad está empezando a enfurecer de verdad!

¡Oh wow! ¡Así que no es una decisión real! No me siento desanimado después de todo.

@FranciscoPombal
No distraiga a @sledgehammer999 con conversaciones inútiles sobre diferentes herramientas de compilación, sistemas de compilación, etc. Deje que el próximo lanzamiento se realice de la manera habitual: será más rápido y más confiable. Necesitamos tener tiempo para resolver cuestiones de organización para que podamos mantener el proyecto a flote, independientemente de que uno de sus miembros desaparezca durante mucho tiempo.
Tampoco tiene sentido hablar de libtorrent-2.0 en el contexto del próximo lanzamiento (y toda la próxima rama), ya que no tenemos soporte para él y ni siquiera podemos predecir cuándo se implementará por completo.

Es (finales de) 2020. A nadie le importa un tamaño de instalación adicional de ~ 50 MiB (y si lo hacen, qué mal jajaja).

Mis dos ordenadores principales tienen 9 y 12 años (aunque recientemente los he mejorado instalando SSD como discos del sistema). Muchos usan hardware incluso más antiguo. No es porque nos guste. Simplemente no tenemos la capacidad financiera o de otro tipo para actualizarlo cada 2 o 3 años. Si no puede entendernos, todavía no le da derecho a burlarse de nosotros.

PS Sin embargo, incluso hace 10 años no me habría preocupado tanto por estos 50 megas.

@an0n666 @ sledgehammer999 @glassez

Estoy de acuerdo con sledgehammer999.
El binario más pequeño siempre es mejor. Especialmente dado el historial de lanzamientos anteriores.
Muchos todavía tienen un Internet lento... también el sitio web que sirve los binarios podría ser lento para algunos usuarios según la ubicación.
En tales casos, un binario pequeño permite una descarga más rápida. Las personas pueden desanimarse a actualizar si sospechan de bloatware innecesario.

Vamos, la descarga de la aplicación tiene un costo único. Incluso a 10 Mb/s, 50 MiB adicionales son solo 50 segundos adicionales. Si estas personas están tan molestas por eso, mejor que vengan aquí y ayuden a solucionar el problema ellos mismos. No se deje llevar por personas obsesivas compulsivas que se quejan de los 50 MiB. ¿Quieren volver a uT 2.2.1 por eso? Multa. Incluso en Somalia puedes obtener 10 Mb/s en promedio: https://www.speedtest.net/global-index , y dudo que un cliente de BitTorrent sea la principal preocupación de la mayoría de los somalíes nativos. Las compilaciones se sirven tanto de Fosshub como de Sourceforge, que es poco probable que se conviertan en un cuello de botella a menos que Kim Kardashian les diga a todos sus fanáticos que descarguen qBittorrent o algo así.

También,

El binario más pequeño siempre es mejor. Especialmente dado el historial de lanzamientos anteriores.

Cita necesaria. ¿Dónde está la correlación entre "mejor historial" y "menor tamaño binario"? ¿Mejor historial de qué? ¿Rendimiento? ¿Fiabilidad?

sistema de compilación predeterminado de qué?

incluso declaró obsoleto qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

¡Esta arbitrariedad está empezando a enfurecer de verdad!

¡Oh wow! ¡Así que no es una decisión real! No me siento desanimado después de todo.

Estuvimos de acuerdo en que el sistema de compilación CMake era el futuro. Es un error seguir manteniendo dos sistemas de construcción, como he dicho muchas veces antes. Esto incluso se menciona en contribuciones recientes: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

Hablando de bloatware: mire el esfuerzo duplicado que tenemos debido al mantenimiento de 2 sistemas de compilación. Mire los varios archivos de autotools bloat que tenemos en el repositorio.

No distraiga a @sledgehammer999 con conversaciones inútiles sobre diferentes herramientas de compilación, sistemas de compilación, etc. Deje que el próximo lanzamiento se realice de la manera habitual: será más rápido y más confiable.

Otro ataque más contra probablemente el miembro más activo de este repositorio durante los últimos meses, y que ha hecho contribuciones cruciales, especialmente en el campo de los sistemas de compilación, herramientas, etc. Las nuevas compilaciones y modificaciones al sistema de compilación _son_ más confiables. Si mal no recuerdo, incluso ha habido casos de problemas que desaparecieron simplemente al construir con el nuevo método. Gracias a mis esfuerzos, ahora podemos obtener compilaciones más confiables mucho más rápido para los usuarios. Ciertamente NO es inútil. Tengo un plan para mejorar aún más esto, hasta el punto del lanzamiento oficial, pero no cuentes conmigo si sigues menospreciando mi participación de esa manera.

No lo estoy distrayendo, lo estoy poniendo al día con los desarrollos importantes de los últimos meses. La responsabilidad está en él para ponerse al día.
Ahora que el trineo ha regresado, quiero sacar la construcción por la puerta tanto como cualquiera, pero quiero hacerlo _bien_. El regreso de Sledge no debería significar que tenemos que volver a nuestras viejas costumbres (incluso para este lanzamiento se siente como un compromiso), debería significar que podemos evolucionar _más rápido_ para llegar al lugar en el que queremos estar.

Necesitamos tener tiempo para resolver cuestiones de organización para que podamos mantener el proyecto a flote, independientemente de que uno de sus miembros desaparezca durante mucho tiempo.

Parte del problema es depender de una sola persona para producir compilaciones manualmente con un sistema de compilación obsoleto y menos fácil de mantener, saltando a través de aros solo por 50 MiB (que se puede resolver más adelante), etc. Considere el hecho de que nos estamos desviando del cadena de herramientas que usamos en nuestro CI solo para esto. Incluso si en realidad no es un gran problema ahora, es un mal principio y un precedente.

Tampoco tiene sentido hablar de libtorrent-2.0 en el contexto del próximo lanzamiento (y toda la próxima rama), ya que no tenemos soporte para él y ni siquiera podemos predecir cuándo se implementará por completo.

No necesitamos hablar de libtorrent 2.0 en absoluto. Solo una pequeña nota que explica que la compatibilidad con V2 aún no está presente a pesar de que aparecerán algunas menciones de compatibilidad con V2 en los mensajes de confirmación en el registro de cambios. Por ejemplo, 19d77b0881dc777b7930106869854067e5b2faba. (a menos, por supuesto, que no elija esas confirmaciones para la versión 4.3.0, pero eso complica las cosas en mi opinión).

Mis dos ordenadores principales tienen 9 y 12 años (aunque recientemente los he mejorado instalando SSD como discos del sistema). Muchos usan hardware incluso más antiguo. No es porque nos guste. Simplemente no tenemos la capacidad financiera o de otro tipo para actualizarlo cada 2 o 3 años. Si no puede entendernos, todavía no le da derecho a burlarse de nosotros.

PS Sin embargo, incluso hace 10 años no me habría preocupado tanto por estos 50 megas.

Señale dónde me "burlé" de los usuarios de baja especificación. Yo también tengo una computadora portátil C2D de 12 años en la que instalé un SSD (¡aunque la conexión es solo SATA II!) Que todavía uso con frecuencia. Tampoco tengo ninguna máquina con un procesador fabricado en los últimos 3 años, y desearía poder obtener un AMD Ryzen en el futuro. Ciertamente no "actualizo cada 2-3 años". Te entiendo y estoy de acuerdo contigo. Me burlé de las personas que se quejan de los 50 MiB en una computadora de escritorio/portátil hoy en día (léase: últimos 15 años), porque esas personas merecen que se burlen de ellas.

Otro ataque más contra probablemente el miembro más activo de este repositorio durante los últimos meses.

Por favor, deja de buscar algún subtexto oculto en mis comentarios. Solo dije lo que dije. Espero que tu reacción no confunda a nadie.

No lo estoy distrayendo, lo estoy poniendo al día con los desarrollos importantes de los últimos meses. La responsabilidad está en él para ponerse al día.

Todo tiene su tiempo y lugar.
¿Por qué presionar @sledgehammer999 aquí y ahora, si solo puede llevar al hecho de que no tendrá tiempo ni para hacer el próximo lanzamiento, ni para reestructurar la gestión/mantenimiento del proyecto antes de que desaparezca nuevamente, para que no seamos capaz de continuar el trabajo de pleno derecho en su ausencia.

No necesitamos hablar de libtorrent 2.0 en absoluto. Solo una pequeña nota que explica que la compatibilidad con V2 aún no está presente a pesar de que aparecerán algunas menciones de compatibilidad con V2 en los mensajes de confirmación en el registro de cambios.

He mencionado repetidamente que el registro de cambios no debe copiar ciegamente el historial de git. Debes tener en cuenta que:

1. algunas confirmaciones son parte de una sola corrección/mejora/característica, por lo que tiene sentido mencionarlas en su totalidad;
2. algunas confirmaciones corrigen errores intermedios que no estaban presentes en la versión anterior, por lo que no tiene sentido mencionarlos;
3. algunos compromisos son parte de un trabajo inacabado, por lo que no tiene sentido mencionarlos.

@sledgehammer999
Se le notificará sobre el problema n.º 13519.

EDITAR: falsa alarma: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDITAR (FranciscoPombal) no es una falsa alarma: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@ sledgehammer999 @Chocobo1 @glassez

Perdón por el ping masivo, pero este también parece bastante crítico y, lamentablemente, un poco complicado en este momento (también estoy confundido en este punto sobre cuál es realmente el problema): https://github.com/ qbittorrent/qBittorrent/problemas/13389. ¿Quizás uno de ustedes pueda arrojar algo de luz sobre esto?

Una cosa es segura; No me gustaría arriesgarme a romper las configuraciones de *arr todos con la primera versión 4.3.x.

este también parece bastante crítico, y desafortunadamente un poco desordenado en este momento (también estoy confundido en este punto sobre cuál es realmente el problema): # 13389. ¿Quizás uno de ustedes pueda arrojar algo de luz sobre esto?

Una cosa es segura; No me gustaría arriesgarme a romper las configuraciones de *arr todos con la primera versión 4.3.x.

Por favor, no empieces a enloquecer al final. ¿Cuál es el problema? (Además de los problemas para comprender la lógica de la aplicación). No cambiamos el código relacionado, ¿verdad? Ciertamente no leí todo el hilo. Si hay evidencia clara de un error en la aplicación, indíqueme un comentario específico.

@glassez

Por favor, no empieces a enloquecer al final. ¿Cuál es el problema? (Además de los problemas para comprender la lógica de la aplicación). No cambiamos el código relacionado, ¿verdad? Ciertamente no leí todo el hilo. Si hay evidencia clara de un error en la aplicación, indíqueme un comentario específico.

Nadie se está volviendo loco, solo debemos ser conscientes de las posibles consecuencias. El punto es que alguien más lea el hilo con cuidado y con la cabeza clara. Antes, cuando traté de abordarlo, no podía estar seguro de si se trataba de una regresión legítima o una tergiversación del usuario de un cambio reciente, o si el cambio de redacción reciente expuso un defecto inesperado o qué. Esto se ve agravado por el hecho de que nunca he usado ningún software *arr , pero sé que muchas personas lo hacen. Independientemente, aquí están los informes originales en los repositorios de *arr : https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , si quiero echar un vistazo.

Hola chicos,

Me acabo de dar cuenta de que alguien mencionó FOSSHUB en un comentario anterior. He leído el hilo y quiero decir esto. Asumiendo que qBittorrent tendrá alrededor de 50 MB, eso no hace ninguna diferencia para nosotros. Lo mismo con cualquier pico de tráfico, alguien mencionó a Kim Kardashian. Por favor, pídale que recomiende qBittorrent; Estoy seguro de que no bajaremos. Podemos absorber ese tráfico. Por ejemplo, cada vez que se lanza un nuevo qBittorrent, hemos visto miles de solicitudes de actualización por segundo.

Lo que estoy tratando de decir es que no deberías preocuparte por esto.

¡Gracias!

mis 1.5 centavos se compilan y funcionan mejor en msvc2019 por cualquier motivo
50 MB de espacio en disco no es absolutamente nada en 2020, si su sistema está TAN limitado, entonces está ejecutando un cliente más ligero o qbt-cli de todos modos

Nunca deje de poner su proyecto en lo último y lo mejor cuando se puede hacer sin causar errores.

Creo que Sledge se refería a problemas como estos que se abren incluso después de un aumento de solo 12 MiB en el tamaño del instalador.
https://github.com/qbittorrent/qBittorrent/issues/12247

Por lo tanto, ni siquiera son 50 MiB, sino solo 12 MiB, que las personas van al extremo de crear un ticket de emisión.

@sledgehammer999 "SI" va a utilizar Qt 5.15.0/5.15.1 en la próxima versión, tome nota (el menú contextual se cierra después de elegir una etiqueta) #13492

En pocas palabras, creo que si se va a etiquetar como 4.3, nadie se va a quejar de que el instalador sea más grande, ¡seguramente se esperaría! Honestamente, mantener cadenas de herramientas anticuadas se siente como una representación adecuada del proceso de lanzamiento de qBittorrent.

Emocionado de ver que esto finalmente sucediera, casi había perdido la esperanza de ver algo este año.

Creo que Sledge se refería a problemas como estos que se abren incluso después de un aumento de solo 12 MiB en el tamaño del instalador.

12247

>

Por lo tanto, ni siquiera son 50 MiB, sino solo 12 MiB, que las personas van al extremo de crear un ticket de emisión.

¿Entonces? La única respuesta apropiada para tales boletos es "lo que sea, hombre". No entiendo la obsesión de hacer lo imposible por esta gente. Como dije en https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739, por supuesto, siempre haremos todo lo posible para evitar tales aumentos de tamaño, pero no debemos sacrificar nada más solo por 50 MiB, y si a algunas personas les molesta eso, pueden venir aquí y arreglarlo ellos mismos.

no debemos sacrificar nada más

Lo siento, pero realmente no veo lo que sacrificamos al no ir al compilador más reciente y mejor (duda). No hay nada tangible de ir al último compilador. No es que msvc2017 sea un compilador antiguo.

@sledgehammer999

Lo siento, pero realmente no veo lo que sacrificamos al no ir al compilador más reciente y mejor (duda). No hay nada tangible de ir al último compilador. No es que msvc2017 sea un compilador antiguo.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-711123971

mis 1.5 centavos se compilan y funcionan mejor en msvc2019 por cualquier motivo

Como mencioné antes, recuerdo otras cuentas similares de esto en el rastreador de problemas u otros canales de comunicación. No estoy inventando esto.

De todos modos, siempre se debe intentar usar la cadena de herramientas más reciente (dentro de lo razonable, pero MSVC 2019 está maduro en este punto), a menos que haya una muy buena razón para no hacerlo. Además, las compilaciones de MSVC 2019 han sido ampliamente probadas en batalla durante los últimos meses, proporcionadas por mí, xavier2k6 u otros, o ahora, más recientemente, con el flujo de trabajo oficial de GitHub Actions. 50 MiB no es una buena razón, como muchas personas intentan decirte. ¡¡No te dejes acosar por aquellos que se obsesionan con más de 50 MiB!! Yo personalmente me encargaré de esos informes, ni siquiera tendrás que verlos.

¿Actualizar a MSVC2019 es algo que requiere mucho tiempo? Es solo un caso de cuando no si no es así? Entonces, si no es este lanzamiento, seguramente el próximo, los lanzamientos dados generalmente tienen casi meses de diferencia.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 es solo un informe subjetivo que probablemente se ve afectado por el uso de las últimas bibliotecas y el código qbt. No por el compilador.

¿Actualizar a MSVC2019 es algo que requiere mucho tiempo? Es solo un caso de cuando no si no lo es? Entonces, si no es este lanzamiento, seguramente el próximo, los lanzamientos dados generalmente tienen casi meses de diferencia.

la razón se da aquí https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

¡¡No te dejes acosar por aquellos que se obsesionan con más de 50 MiB!!

Tampoco me dejaré intimidar por aquellos que se obsesionan con lo "último y lo mejor". Y la diferencia es en realidad 68 MB de almacenamiento adicional (hice compilaciones estáticas locales). ¡msvc2017 simplemente funciona! y no requiere espacio adicional.

13505 (comentario) es solo un informe subjetivo que probablemente se ve afectado por el uso de los últimos códigos libs y qbt. No por el compilador.

Y sus comentarios acerca de que MSVC 2019 no proporciona ningún beneficio en absoluto también son afirmaciones sin fundamento.

Tampoco me dejaré intimidar por aquellos que se obsesionan con lo "último y lo mejor". Y la diferencia es en realidad 68 MB de almacenamiento adicional (hice compilaciones estáticas locales). ¡msvc2017 simplemente funciona! y no requiere espacio adicional.

Mal regreso. Nadie que abogue por la última cadena de herramientas lo está "intimidando". Apegarse a la última cadena de herramientas (nuevamente, dentro de lo razonable) es objetivamente la mejor política, especialmente cuando el único argumento en contra es que produce archivos binarios un poco más grandes (no estamos desarrollando para alguna plataforma integrada). Además, no es una buena política hacer un lanzamiento con una cadena de herramientas diferente a la que CI y la mayoría de los usuarios y colaboradores han estado usando durante los últimos _meses_. Y para colmo, es probable que haya una solución relativamente simple para la hinchazón binaria: pídales a sus amigos de 50 MiB que inviertan su energía en encontrar el problema en lugar de simplemente quejarse de 50 MiB si les molesta tanto.

(msvc2017 =>msvc2019) se puede discutir/discutir/debatir, etc. en otro problema _CUANDO_ sea necesario

msvc2019 será mucho más relevante para nosotros una vez que cambiemos a c++17.

También se volverá más relevante en el cambio a Qt 6.0/6.1/6.2 cuando Qt requiera msvc2019 & drop (soporte de Windows 7/8/8.1 y 32 bits) (que aún está muy lejos de ser implementado, lo sé)

Hosts y objetivos de desarrollo en Qt 6.0

Hosts de desarrollo Qt 6.0

Objetivos de desarrollo de Qt 6.0

Hosts de desarrollo Qt 6.1

Objetivos de desarrollo de Qt 6.1

No voy a discutir más acerca de los compiladores. No estoy de acuerdo contigo específicamente para qbt. msvc2019 será mucho más relevante para nosotros una vez que cambiemos a c++17.

referencia: https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708094578

¡POR AHORA!, ¿PODEMOS TODOS DE UNA VEZ APARCAR ESTO AQUÍ PARA OTRA VEZ?

¡Saquemos 4.2.x/4.3.x por la puerta!

(msvc2017 =>msvc2019) se puede discutir/discutir/debatir, etc. en otro problema CUANDO sea necesario

¡POR AHORA!, ¿PODEMOS TODOS DE UNA VEZ APARCAR ESTO AQUÍ PARA OTRA VEZ?

¡Saquemos 4.2.x/4.3.x por la puerta!

Mire, quiero que esto termine tanto como cualquier otra persona, pero al menos es francamente irresponsable cambiar la cadena de herramientas en el último minuto para el lanzamiento cuando todos los demás, incluido usted, han estado usando y probando con MSVC 2019 para el últimos meses_. Cuando se ve desde esta lente, creo que es muy "necesario" usar MSVC 2019 para esta versión.

Personalmente, tengo mucha experiencia en este juego: si algo sale mal, seré yo quien se ocupe de la mayoría de los informes de errores del tipo "la compilación nocturna/CI funcionó bien, pero la versión no", etc., etc. Y sí, sé que no "tengo" que lidiar con eso. Pero no quiero que el proyecto se vea inundado con nuevos problemas después de un lanzamiento por una razón que pueda evitarse. Ya es bastante malo que el lanzamiento no se realice con bibliotecas compiladas de la misma manera o similar que el CI.

Me desconcierta cómo todo esto, incluido el tiempo y el esfuerzo que invertí en el proyecto y la gestión del rastreador de problemas, no es más importante que alguien obsesionado con más de 50 MiB. ¿Quiénes son estas personas, incluso? ¿Qué han hecho por el proyecto?

@FranciscoPombal No tendré más discusiones sobre el compilador aquí. Mi palabra es definitiva. Los lanzamientos se realizarán con msvc2017.

si mal no recuerdo, solo Qt 5.15 "oficialmente" es compatible con msvc2019. no comenzaron a ejecutarse allí ci en msvc2019 hasta Qt 5.15
y no puede lanzar con qt 5.15 de todos modos debido a los errores mencionados anteriormente.

Mire, quiero que esto termine tanto como cualquier otra persona, pero al menos, es francamente irresponsable cambiar la cadena de herramientas en el último minuto para el lanzamiento cuando todos los demás, incluido usted, han estado usando y probando con MSVC 2019 para el últimos meses. Cuando se ve desde esta lente, creo que es muy "necesario" usar MSVC 2019 para esta versión.

Las compilaciones de MSVC 2017 están probadas en batalla con todo el ciclo de lanzamiento 4.2.x y no hay muchas novedades en msvc 2019 de todos modos y msvc 2017 todavía tiene un ciclo de lanzamiento principal, no puedo entender por qué estás tan obsesionado con "lo último y lo mejor" .

@xavier2k6

Además, supongamos que no solucionamos el "problema" adicional de 50 MiB antes del próximo lanzamiento "grande". ¿Todos vamos a tener esta misma discusión entonces? ¿Vamos a posponer la actualización a Qt 6 por eso? ¿Qué es o no es más importante que 50 MiB? Simplemente estamos barriendo el problema debajo de la alfombra, es un mal precedente.

Sugerencia: casi puedo garantizar que, según las opiniones que he visto de otros a lo largo del tiempo, la actualización a Qt6 se pospondrá por mucho más tiempo de lo razonable, por estas 3 razones, y posiblemente más, sin ningún orden en particular: extra Tamaño del instalador de 50 MiBs, manteniendo vivo el soporte para Windows 7, manteniendo vivo el soporte para compilaciones de 32 bits.

@jagannatharjun Qt 5.15.1 funciona bien con msvc2017. Los únicos problemas vinculados son sobre el cierre del menú contextual al seleccionar etiquetas. En mi opinión, eso no es un bloqueador. Sin embargo, Qt 5.15 ofrece un soporte HiDPI mucho mejor.

@FranciscoPombal ¡Puedo entender de dónde vienes y tu trabajo aquí es muy apreciado!

Los puntos que menciona tienen relevancia pero, desafortunadamente, no creo que el marco de tiempo actual para sacar el "nuevo lanzamiento" permita esta discusión... (en este momento)

No puedo entender por qué estás tan obsesionado con "lo último y lo mejor".

Las políticas objetivamente superiores no son "obsesiones". Supongo que se podría decir que estoy obsesionado con no satisfacer otras estúpidas obsesiones. Pero hazme un favor y deja de proyectar esto en mí, ¿sí? No fortalece su punto.

Ustedes están considerando seriamente mantener un ritmo razonable de actualizaciones/modernizaciones como una "obsesión" y no ser más importante que 50 MiB en el instalador. Joder Jesús.

@jagannatharjun Qt 5.15.1 funciona bien con msvc2017. Los únicos problemas vinculados son sobre el cierre del menú contextual al seleccionar etiquetas. En mi opinión, eso no es un bloqueador. Sin embargo, Qt 5.15 ofrece un soporte HiDPI mucho mejor.

Estoy de acuerdo, el error de las etiquetas del menú contextual es desafortunado, pero los errores de HiDPI son mucho más graves y producen muchos más informes con el tiempo.

@FranciscoPombal ¡Puedo entender de dónde vienes y tu trabajo aquí es muy apreciado!

Buen chiste.

Los puntos que menciona tienen relevancia pero, desafortunadamente, no creo que el marco de tiempo actual para sacar el "nuevo lanzamiento" permita esta discusión... (en este momento)

Veo que no puedo hacer nada más. Oh bien.

@FranciscoPombal ¡Puedo entender de dónde vienes y tu trabajo aquí es muy apreciado!

Buen chiste.

@FranciscoPombal ¿En serio? - ¡¡¡Esto no era una broma y yo estaba/soy siendo personalmente sincero!!!

Los puntos que menciona tienen relevancia pero, desafortunadamente, no creo que el marco de tiempo actual para sacar el "nuevo lanzamiento" permita esta discusión... (en este momento)

Veo que no puedo hacer nada más. Oh bien.

No tome esta situación personalmente/en serio... ok
........ toma un respiro
Deje que parte de su arduo trabajo en el proyecto al menos llegue a ver al "público principal" a través del nuevo lanzamiento. (ya que actualmente solo puede ser visto por personas como yo que vienen aquí y participan/contribuyen/construyen, etc.

Acabo de empujar una rama staging_v4_3_x . Básicamente es maestro con un registro de cambios actualizado.
Eche un vistazo a Changelog y dígame si algo está mal o me perdí algo.
@glassez

1. ¿#13234 tiene algún atributo de cara al usuario? ¿Algo que debería estar en el registro de cambios? por ejemplo, "mejorar la velocidad de carga de las sesiones con cientos de torrents".
2. ¿Cuál es el propósito de #13395. ¿Qué hace? ¿Debo incluir algo en el registro de cambios?

En un momento, veré los problemas mencionados en este hilo que podrían hacer que algunas confirmaciones no se incluyan para el lanzamiento. Te mantendré informado.

@sledgehammer999

Además, limpie el PPA en el proceso. Las versiones de Ubuntu que no sean 18.04 , 20.04 y 20.10 son EOL, por lo que los archivos para compilaciones dirigidas a esas versiones deben eliminarse lo antes posible.

Ubuntu 14.04 y 16.04 no son EOL. ¿De dónde sacaste esa lista?
https://wiki.ubuntu.com/Releases

@sledgehammer999 Parece que te perdiste https://github.com/qbittorrent/qBittorrent/pull/13188 para el registro de cambios

Además, ¿puede agregar una nota en el registro de cambios que
"Los paquetes de temas anteriores no funcionarán correctamente con esta versión debido a los cambios en el formato de los archivos del paquete. Comuníquese con el proveedor del tema para obtener una solución. Puede leer más sobre el nuevo formato aquí https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " o algo así.
En realidad, esto se debe a https://github.com/qbittorrent/qBittorrent/pull/12755/files

Creo que se debe mencionar que se eliminó el soporte para RC1_1 libtorrent.

Además, si alguien quiere una tasa de anuncio de rastreador más rápida o tiene una salida de cliente más lenta (en comparación con 4.2.x) con esta versión, entonces puede intentar aumentar el límite de "Anuncio HTTP simultáneo máximo" desde la configuración avanzada.

¿#13234 tiene algún atributo de cara al usuario? ¿Algo que debería estar en el registro de cambios? por ejemplo, "mejorar la velocidad de carga de las sesiones con cientos de torrents".

Lo siento, no recuerdo todo... fue mayormente una mejora interna. Tal vez la siguiente parte de la descripción de relaciones públicas se ajuste a los "atributos de cara al usuario":

Permite guardar correctamente los datos del currículum en algunas circunstancias, por ejemplo, en el estado de "archivos faltantes" (aunque tratamos de evitar que esto se hiciera antes, el usuario podría hacerlo cuando, por ejemplo, cambia alguna propiedad de dicho torrente).

¿Cuál es el propósito de #13395. ¿Qué hace? ¿Debo incluir algo en el registro de cambios?

https://github.com/qbittorrent/qBittorrent/pull/13395#issuecomment-710787904

Creo que se debe mencionar que se eliminó el soporte para RC1_1 libtorrent

👍

CARACTERÍSTICA: agregue soporte para crear torrents v2 (requiere libtorrent 2.0.x) (Chocobo1)

¡Maldición! ¿QBittorrent ya es compatible con libtorrent-2.0? ¿Por qué mencionarlo como es? Ya hablamos de eso.

Además, ¿puede agregar una nota en el registro de cambios que
"Los paquetes de temas anteriores no funcionarán correctamente con esta versión debido a los cambios en el formato de los archivos del paquete. Comuníquese con el proveedor del tema para obtener una solución. Puede leer más sobre el nuevo formato aquí https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " o algo así.
En realidad, esto se debe a https://github.com/qbittorrent/qBittorrent/pull/12755/files

Creo que agregaré esto a la sección de "noticias" del sitio web. Fuera de los cambios, en el texto introductorio.

Creo que se debe mencionar que se eliminó el soporte para RC1_1 libtorrent.

está bien.

Además, si alguien quiere una tasa de anuncio de rastreador más rápida o tiene una salida de cliente más lenta (en comparación con 4.2.x) con esta versión, entonces puede intentar aumentar el límite de "Anuncio HTTP simultáneo máximo" desde la configuración avanzada.

¿Debería mencionarse esto en el registro de cambios como un elemento?

¡Maldición! ¿QBittorrent ya es compatible con libtorrent-2.0? ¿Por qué mencionarlo como es? Ya hablamos de eso.

Luego, moveré este elemento a la entrada de publicación v4.4.0 (no forma parte del registro de cambios de v4.3.0). A menos que se haya introducido antes el soporte oficial de libtorrent-2.0. ¿Es eso satisfactorio?

Aquí está el registro de cambios actualizado: https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

¿Debería mencionarse esto en el registro de cambios como un elemento?

Creo que mejor si se publica como noticia. Los usuarios con miles de torrents/muchos rastreadores por torrent pueden notar el lento comportamiento de anuncio.

Actualizado de nuevo: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Anuncio: se debe esperar un retraso muy pequeño. Tengo que hacer una recompilación parcial de la cadena de herramientas debido a un problema de seguridad que me informaron por correo electrónico. Los detalles estarán disponibles unos días después del lanzamiento. En mi opinión, la gravedad es probablemente menor porque el exploit requiere que alguien malintencionado tenga acceso local o que ya esté ejecutando una aplicación maliciosa en su sistema. En ambos casos ya estás jodido incluso sin el problema de seguridad de qbt.

Ubuntu 14.04 y 16.04 no son EOL. ¿De dónde sacaste esa lista?

Probablemente redacción incorrecta. Es EOL para nosotros porque su versión Qt es menor que nuestro requisito mínimo.

está bien. Creo que todo está listo ahora, y estoy preparando compilaciones. La rama v4_3_x se insertará junto con las compilaciones.

@sledgehammer999 Perdón por el comentario tardío, pero recuerde mencionar (en la sección de noticias del sitio web) que ha habido muchas correcciones de libtorrent desde la última versión que están presentes en esta, incluidas fugas de memoria conocidas, problemas de velocidad debido a lógica de configuración de caché defectuosa en Windows, etc. Puede echar un vistazo a libtorrent 1.2.6-1.2.11 (1.2.11 aún no se ha lanzado oficialmente pero ya tiene algunas entradas de registro de cambios) para inspirarse y seleccionar las entradas más relevantes.

Por curiosidad, ¿qué confirmación de libtorrent se usará?

OK, y la última confirmación de git como siempre.

@rrrevin

Ubuntu 14.04 y 16.04 no son EOL. ¿De dónde sacaste esa lista?
https://wiki.ubuntu.com/Releases

Probablemente redacción incorrecta. Es EOL para nosotros porque su versión Qt es menor que nuestro requisito mínimo.

Bueno, supongo que realmente quise decir "Fin del soporte estándar", que es realmente lo que importa de todos modos. Más allá de eso, solo las empresas que pagan obtienen apoyo. 16.04 técnicamente ni siquiera está en el "Fin del soporte estándar", pero está muy cerca. E independientemente, el soporte OOTB para él se eliminó hace aproximadamente 2 años debido a que qBittorrent elevó la versión mínima requerida de Qt a 5.9.

@sledgehammer999 Una pequeña cosa más: considere mencionar la conocida regresión menor del menú contextual de la etiqueta en las noticias: https://github.com/qbittorrent/qBittorrent/issues/13492.

@ Sledgehammer999 No acreditaste muchas de mis relaciones públicas en el registro de cambios... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal Combiné todas sus relaciones públicas de CMake en una sola entrada. Sus relaciones públicas de limpieza de código interno no se pueden mencionar en el registro de cambios. Debe contener correcciones para el usuario. Lo mismo con las muchas relaciones públicas de @Chocobo1
Si me perdí algo específico, por favor menciónelo a continuación. Esperaré unos momentos, ya que todavía hago tareas administrativas entre bastidores.

@sledgehammer999

Debe contener correcciones para el usuario.

OK entonces:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 está orientado al usuario, ya que corrige un error de anuncio en el rastreador integrado. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 y https://github.com/qbittorrent/qBittorrent/pull/13439 no son limpiezas de cara al usuario, así que supongo que está bien.

• https://github.com/qbittorrent/qBittorrent/pull/13288 está orientado al usuario, supongo. Ahora los usuarios pueden descargar compilaciones experimentales de CI, ¿eso se considera orientado al usuario?

• El resto ya está acreditado, relacionado con las mejoras de CMake (ya acreditado también) o relacionado con https://github.com/qbittorrent/qBittorrent/pull/13288.

/offtopic (para otro momento): ¿quizás las limpiezas que no enfrentan los usuarios deberían incluirse en "OTROS" o quizás una nueva sección "CÓDIGO DE SALUD"? A los usuarios les gusta ver ese tipo de cosas en el registro de cambios.

--> #13042 está orientado al usuario, ya que corrige un error de anuncio en el rastreador integrado. <--

OK lo siento. No estaba claro en el título de la confirmación. ¿Puede sugerir una entrada de registro de cambios adecuada (para los usuarios que la lean)?

Los cambios de CI suelen ser irrelevantes para los lanzamientos.

/offtopic (para otro momento): ¿quizás las limpiezas que no enfrentan los usuarios deberían incluirse en "OTROS" o quizás una nueva sección "CÓDIGO DE SALUD"? A los usuarios les gusta ver ese tipo de cosas en el registro de cambios.

Hmm, agregaré una entrada de OTHER para las limpiezas de código que te acrediten a ti y a @Chocobo1

13288 es algo orientado al usuario, supongo. Ahora los usuarios pueden descargar compilaciones experimentales de CI, ¿eso se considera orientado al usuario?

En mi opinión, tal cosa se puede mencionar en Noticias (fuera del registro de cambios).

En mi opinión, tal cosa se puede mencionar en Noticias (fuera del registro de cambios).

De alguna manera podría meter un enlace de "nightlies" en la página de descargas...

~@glassez~ @ sledgehammer999

En mi opinión, tal cosa se puede mencionar en Noticias (fuera del registro de cambios).

De alguna manera podría meter un enlace de "nightlies" en la página de descargas...

Solo mencione las cosas de CI en las noticias, dudaría en vincular la página de descargas "nocturnas" a una audiencia más amplia antes de que tengamos versiones basadas en git en los ejecutables. De lo contrario, todos los usuarios informarán todas las versiones nocturnas diferentes como "4.x.xalpha1", lo que generará confusión.

Control de versiones basado en git en los ejecutables. De lo contrario, todos los usuarios informarán todas las versiones nocturnas diferentes como "4.x.xalpha1", lo que generará confusión.

Sí, esa es una observación correcta.

@sledgehammer999

¿Puede sugerir una entrada de registro de cambios adecuada (para los usuarios que la lean)?

"Se corrigió la lógica de anuncios rotos en el rastreador integrado que causaba fallas en algunos casos".

Las compilaciones de CI también podrían usarse con fines maliciosos. Creando relaciones públicas maliciosas y luego distribuyendo enlaces.
Recomendaría no vincular tal cosa en el sitio web.

@an0n666

Las compilaciones de CI también podrían usarse con fines maliciosos. Creando relaciones públicas maliciosas y luego distribuyendo enlaces.
Recomendaría no vincular tal cosa en el sitio web.

Este también es un buen punto. Supongo que será mejor que empiece a trabajar en el flujo de trabajo específicamente para compilaciones nocturnas que solo compilan desde el maestro del que he hablado antes. Entonces podremos vincularnos a compilaciones nocturnas sin temor a que tal cosa suceda.

El lanzamiento está hecho.
PPA se limpiará mañana.
Detalles del problema de seguridad en unos días.
Plan de cambios organizativos en unos días.

Y como siempre, gracias a todos por sus contribuciones en este ciclo de lanzamiento.