Sincronizzazione PR 14 <-> 16

[TheMule71]

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

Porting da 14 a 16:

• [16.0][FIX] l10n_it_delivery_note,l10n_it_delivery_note_order_link: delivery note count in sale order #4323 <-- [14.0] [FIX] l10n_it_delivery_note,l10n_it_delivery_note_order_link: delivery note count in sale order #4280
• TODO <-- [14.0][FIX]assets_management: properly open wizard #4345
• TODO <-- [14.0][MIG] Migration to 14.0 l10n_it_fatturapa_out_fd #4386

Back porting da 16 a 14:

• TODO <-- [16.0][FIX]l10n_it_intrastat_statement: adapt report format to correct version #4417
• [14.0][FIX] l10n_it_central_journal_reportlab: Support lines without account #4296 <-- [FIX] Errore stampa libro giornale raggruppato per righe senza conto #4290
• TODO <-- [IMP] Calcolare il valore del fondo ammortamento durante la dismissione parziale #4365
• TODO <-- [IMP] l10n_it_riba: modificare data pagamento distinte #4383
• TODO <-- [FIX] l10n_it_fatturapa: link fatturapa.attachments #4250
• TODO <-- [16.0][FIX] l10n_it_central_journal_reportlab: escape Paragraph content #4400

[TheMule71]

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]

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:

• 14.0 https://github.com/OCA/l10n-italy/issues?q=is%3Aissue+is%3Aopen+label%3A14.0+-label%3A16.0+-label%3A%22no+PR+yet+%F0%9F%AB%A4%22
• 16.0 https://github.com/OCA/l10n-italy/issues?q=is%3Aissue+is%3Aopen+label%3A16.0+-label%3A14.0+-label%3A%22no+PR+yet+%F0%9F%AB%A4%22

[sergiocorato]

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]

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

• bugfixing mergiato su 14 con PR per la 16 (fare review e chiudere)
• bugfixing da mergiare su 16 (fare review e mergiare)
• bugfixing mergiato su 16 con PR per la 14 (fare review e chiudere)
• bugfixing mergiato su 14 bug verificato su 16 (da portare la PR)
• bugfixing mergiato su 16 bug verificato su 14 (da backportare la PR)
• feature mergiata su 14 con PR per la 16 (fare review e chiudere)
• bugfixing mergiato su 14 da testare su 16 (per funzionali, in genere)
• bugfixing mergiato su 16 da testare su 14 (per funzionali, in genere)
• bugfixing da mergiare su 14
• feature mergiata su 16 con PR per la 14 (fare review e chiudere)
• feature da mergiare su 16
• feature da mergiare su 14

---

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]

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]

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]

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.

[SirAionTech]

@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]

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.

[SirAionTech]

L'idea di evidenziare in qualche modo che per alcune cose manca solo un porting ci sta.

Non mi convince avere questa issue di tracciamento perché penso sia difficilmente mantenibile: in pratica è una copia di informazioni che già ci sono nelle issues/PRs e in quanto tale va tenuta sincronizzata.

Magari si potrebbe anche solo aggiungere un'etichetta needs porting alla issue quando manca solo il porting da una versione all'altra per chiudere la issue?
E/O un'etichetta porting alla PR quando è un porting?

Anche mettere le etichette non è semplice da mantenere, però lo vedo più fattibile; 🤷 sarà che io e @francesco-ooops ormai ci abbiamo fatto il callo.

[francesco-ooops]

Aggiungo che il tag "Hotfix" è stato anche usato per indicare funzionalità presenti in una versione precedente (12, 14) non presenti in una successiva (14, 16)

L'approccio più semplice mi sembra quello di puntare a ridurre quanto più possibile tempo tra il merge di una PR e quello del rispettivo porting, con l'obiettivo di chiudere a stretto giro PR / porting PR / issue

Chiaramente mi riferisco a moduli che non hanno subito grossi refactoring tra versioni (abbiamo una lista di quali sono? Magari potremmo elencarli nella issue di migrazione)

[TheMule71]

Aggiungo che il tag "Hotfix" è stato anche usato per indicare funzionalità presenti in una versione precedente (12, 14) non presenti in una successiva (14, 16)

L'idea di hotfix è quella di marcare le issue relative a bug ad alto impatto - lo stato del bug in altre versioni (per es. viene segnalato su 16 ma esiste anche su 14) o l'esistenza o meno di PR non dovrebbe condizionarne l'uso: si tratta di un tag usato nel triage, quindi relativo alla classificazione delle nuove issue.

Il triage serve principalmente per non "perdersi" delle issue (specie se importanti). Non riguarda le PR.

Al contrario, questa issue riguarda la gestione delle PR. A mio modesto parare, una tasklist è lo strumento più adatto per gestire un elenco di cose da fare, piuttosto che aggiungere altre label. Le label servono per classificare.