search

OCA / l10n-italy

Odoo Italian localization
https://www.odoo-italia.org
GNU Affero General Public License v3.0
149 stars 303 forks source link

Sincronizzazione PR 14 <-> 16 #4391

Open TheMule71 opened 2 days ago

TheMule71 commented 2 days ago

Todo list per l'allineamento delle PR da 14 a 16 e viceversa.

Porting da 14 a 16:

Back porting da 16 a 14:

(prove di formato lista alternativo più compatto)

14.0 16.0
#4296 #4290
#4345 TODO
TODO #4365
TODO https://github.com/OCA/l10n-italy/pull/4383
TODO #4250
TheMule71 commented 2 days ago

Stiamo ancora decidendo il formato delle lista, ho messo un paio di esempi.

Inoltre da valutare se fare una sola issue come questa oppure separare 14 --> 16 e 16 --> 14 in due issue.

francesco-ooops commented 2 days ago

Indicativamente si può verificare quali issue sono aperte solo per una delle due versioni (nella grande maggioranza dei casi si tratta di PR non portate) con questi url:

sergiocorato commented 2 days ago

A me sembra più chiaro se sono evidenziate direttamente, questi filtri si basano molto sulla fiducia che qualcuno abbia inserito le etichette giuste e rischiamo di perderci qualcosa.

Però potremmo fare un filtro per ricercare le PR direttamente, mettendo nelle PR una label del tipo "verificare su 14.0" oppure una "non verificare su 14.0" ed escludere solo queste? Cosa che riportebbe completamente l'informazione della issue a questo punto, riducendo il lavoro.

Secondo me è fondamentale ridurre il lavoro, visto che siamo sempre indietro, e creare nmila issue è un lavoro non indifferente.

TheMule71 commented 2 days ago

Già che ci sono propongo una lista di priorità (sempre indicative, poi caso per caso si valuta):

Spiegazione... se la 16 deve essere la base di partenza per l'integrazione con la 18, ha senso non portarsi dietro bachi. Specialmente fastidioso se esiste già una soluzione testata e mergiata per la 14 e magari la PR per la 16 da fare review.

Bugfixing a parte, anche avere features testate e mergiate in 14, mancanti nella 16, non è bello, specie se c'è già la PR da approvare.

Va da sè che la lista non è vincolante e le priorità personali possono essere diverse. Ci sono ancora persone/aziente focalizzate su 14, per cui nella loro lista "bugfixing da mergiare su 14" è sicuramente più in alto rispetto alle PR con target 16.

In sostanza, se saltasse fuori un bug in 18 in un codice basato sulla 16, con bug, di cui esisteva PR (per 16) derivata da PR già mergiata in 14 (quindi revisionata e approvata), sarebbe un po' imbarazzante, a meno che effettivamente non siano emersi problemi con la PR 16 in fase di review. E vale in generale, considerato che la 16 è quella ufficiale (e lo sarà per un pezzo) avere un bug aperto sostanzialmente risolto non è il massimo (e al contrario anche per la 14, se la soluzione del bug, testata e approvata per la 16, esiste già).

In pratica la lista è ordinata in base a lavoro che rimane da fare per chiudere oltre che all'importanza. Chiaro che una feature (non bug) della quale esiste solo una PR non revisionata per 14 è la situazione che richiede il maggior sforzo prima di arrivare ad un merge sulla 16 (porting, bugfixing, review funzionale e tecnica di tutto). Una feature già mergiata in 14 e già portata in 16 richiede solo review del porting (nel senso che le logiche funzionali sono già state approvate, il grosso del codice revisionato, di fatto si guarda se il porting è corretto).

TheMule71 commented 2 days ago

Aggiungo che per github è un problema avere una tabella coi link e i titoli delle PR (funziona solo con le tasklist). Troppo complicato. Nel frattempo però:

$$- \frac{{\hbar ^2 }}{{2m}}\frac{{\partial ^2 \psi (x,t)}}{{\partial x^2 }} + U(x)\psi (x,t) = i\hbar \frac{{\partial \psi (x,t)}}{{\partial t}}$$

mica è un problema... :)

sergiocorato commented 2 days ago

Per me è meglio la prima versione di lista alternativa compatta.

Concordo sulle priorità, l'importante è evitare che bug già risolti o con PR aperta su una versione inferiore siano ignorati nelle versioni superiori in prima istanza, e viceversa in seconda istanza.

tafaRU commented 2 days ago

Per un controllo più accurato si potrebbe utilizzare https://github.com/OCA/oca-port Qui ho riportato un esempio di utilizzo sul modulo l10n_it_fatturapa_out.

Anche se da un test a campione non mi sembra proprio così infallibile. Esempio: https://gist.github.com/tafaRU/7f319a9e688af1e6ed9201387da89282#file-oca_port-L78 Quando invece https://github.com/OCA/l10n-italy/pull/4086 risulta già portata alla 16.0 con https://github.com/OCA/l10n-italy/pull/4085

Di certo può essere utilizzato ad integrazione di quanto già conosciamo tramite le attuali issue di tracciamento.

SirAionTech commented 2 days ago

@TheMule71 @sergiocorato potreste scrivere in una pagina tipo https://github.com/OCA/l10n-italy/wiki/Team-di-sviluppo come dovrebbe essere il flusso quando ci sarà questa issue di sincronizzazione? Credo di essermi perso qualche pezzo.

sergiocorato commented 2 days ago

Per un controllo più accurato si potrebbe utilizzare https://github.com/OCA/oca-port Qui ho riportato un esempio di utilizzo sul modulo l10n_it_fatturapa_out.

Anche se da un test a campione non mi sembra proprio così infallibile. Esempio: https://gist.github.com/tafaRU/7f319a9e688af1e6ed9201387da89282#file-oca_port-L78 Quando invece #4086 risulta già portata alla 16.0 con #4085

Di certo può essere utilizzato ad integrazione di quanto già conosciamo tramite le attuali issue di tracciamento.

In genere uso oca-port come prima scelta per migrare moduli, quando ci sono refactoring però fa fatica. È comunque uno strumento utile agli sviluppatori, qui si tenta di dare un'idea più chiara della situazione in maniera meno prolissa se possibile.