Sincronizzazione PR 14 <-> 16

[TheMule71]

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

Porting da 14 a 16:

• TODO <-- [IMP] l10n_it_fatturapa_in: add self invoice type TD22 #4476
• [FIX] l10n_it_fatturapa_in: allow use of our account in payment info #4223 <-- [FIX] Importazione da ZIP di fatture attive con inversione contabile #4218
• [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 <-- [assets_management] creazione e configurazione cespiti con utente multicompany #3651 (più PR)
• TODO <-- [14.0][l10n_it_withholding_tax] riconciliazione non coerente in caso di pagamento piu' grande #3712 (più PR)
• [16.0][FIX] account_vat_period_end_statement multicompany non stampa le imposte #3765 <-- [14.0][FIX] account_vat_period_end_statement multicompany non stampa le imposte #3762
• TODO <-- [FIX] l10n_it_withholding_tax: pagando più fatture il rimane un amount_residual pari al valore delle ritenute #4418
• TODO <-- [14.0] FIX l10n_it_financial_statements_report: use landscape format for PDF #3601
• [16.0][FIX] accounting menu not translatable #4298 <-- [14.0][FIX] accounting menu not translatable #2881
• TODO <-- [14.0][MIG] Migration to 14.0 l10n_it_fatturapa_out_fd #4386
• TODO <-- [IMP][14.0] l10n_it_intrastat show weight total #4440
• TODO <-- [14.0] [FIX] l10n_it_delivery_note: fix select exist #3853
• [16.0] [FIX] l10n_it_fatturapa_in_rc: flag RC in importazione e-fattura con raggruppamento per Aliquota #4434 <-- [14.0] [FIX] l10n_it_fatturapa_in_rc: flag RC in importazione e-fattura con raggruppamento per Aliquota #3769

Back porting da 16 a 14:

• TODO <-- [FIX] l10n_it_fatturapa_in: errore importo fattura con arrotondamento #3826
• TODO <-- [16.0] [IMP] l10n_it_asset_management: refactoring for compatibility with Odoo Enterprise #4212
• TODO <-- [16.0][FIX] l10n_it_riba: remove account and journal domain #3928
• TODO <-- [16.0] [FIX] l10n_it_fatturapa_import_zip correctly imports all XML files in zip #3959
• TODO <-- [FIX] l10n_it_fatturapa_pec - user without permission to access settings can't send PEC #3933
• TODO <-- [16.0] l10n_it_riba: fix state update on riba lines #3885
• [14.0][FIX]assets_management: Company and page number out of page #4265 <-- [MIG] assets_management -> l10n_it_asset_management: Migration to 16.0 #3776
• [IMP] l10n_it_account_stamp usability #4414 <-- [IMP] l10n_it_account_stamp: Usabilità per il bollo in fattura #3802
• 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 <-- Poter aprire una distinta RiBa quando la fattura collegata è stata eliminata #3814
• TODO <-- [IMP] Calcolare il valore del fondo ammortamento durante la dismissione parziale #4365
• TODO <-- [MIG] assets_management -> l10n_it_asset_management: Migration to 16.0 #3776
• TODO <-- [FIX] l10n_it_fatturapa_in: errore importo fattura con arrotondamento #3826
• 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
• TODO <-- [16.0] l10n_it_fatturapa_in: forward port of #3475 #3716
• TODO <-- Autofatture in valuta con differenza cambio evidenziato che non le chiude totalmente #3863 (più PR)

[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.

[SirAionTech]

Come proposto in chiamata, io e @francesco-ooops abbiamo creato delle etichette ( is porting This pull request is porting a change from another version e needs porting This issue has already been resolved for some version ) e le stiamo applicando a issues e PRs.

Ho riportato il tutto, sotto forma di proposta, in https://github.com/OCA/l10n-italy/wiki/Gestione-issues#proposta-di-gestione-tramite-issues-dedicate.

[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.

Ho visto https://github.com/OCA/l10n-italy/wiki/Team-di-Sviluppo-(proposta), grazie @TheMule71, quindi in pratica mi sembra rimanga tutto uguale ma in più ci sarebbe da mantenere questa issue di sincronizzazione.
Come detto anche in chiamata poco fa, penso sia più mantenibile aggiungere le due etichette proposte in #4391 (comment).

Riguardo al

< si può aprire una issue
---
> aprire una issue

credo sia meglio definire in quali casi la issue vada aperta e quali no (e mettere no issue needed ).
Ad esempio: se qualcuno ha verificato che il problema esiste solo nella versione che si sta correggendo, allora non serve aprire una issue.
In tutti gli altri casi secondo me la issue ci vuole.

[francesco-ooops]

Issues taggate con "needs porting", sono 87 al momento; nota che indicano semplicemente che una delle due versioni è fixata (a volte fixata per 12 ma non portata a quelle successive), ma non se è già aperta una PR di migrazione o a quale versione va portata.

Per ricercare le issues per versione, usare le label "needs porting" + "label versione", es: needs porting + 16

userei quest'ultimo link per debuggare quanto più possibile la versione 16 prima della migrazione alla 18

[TheMule71]

Ottimo, grazie Simone. Per fare il confronto, e anche riassumere quando detto in call per chi non c'era, ho aggiunto queste voci alla task list (letteralmente digitando questo):

- [ ] #4434 <-- #3769
- [ ] #4323 <-- #4280

e sotto

- [ ] #4414 <-- #3802

Quello che si ottiene è:

Mentre il risultato delle query sulle label è:

Nel primo caso ho immediata visibilità delle stato delle PR (specie se quella di origine è mergiata o no) e diretto accesso ad entrambe - e il loro stato si aggiorna da solo (se fossero state verde <- verde e poi una fosse stata mergiata, sarebbe diventata verde <- viola da sola).

Nel secondo caso ottengo un elenco di PR che sono porting di altre, ma, a meno di non mettere due label 'is porting' di colori diversi (viola e verde) a seconda se la PR originale è stata mergiata o no e gestire a mano l'aggiornamento delle stesse ogni volta che viene mergiata una PR - non ho visibilità delle stato della PR originale. Inoltre, per arrivarci, devo, clickare sulla PR:

non c'è il link alla PR orginale, per cui devo cliccare sulla issue (per fortuna il link c'è nel commento iniziale, altrimenti lo devo cercare o tra i commenti sotto o nella sezione a lato)

da qui vedo lo stato e posso accedere alla PR originale per confrontarla.

Notare che la seconda PR dello stesso elenco, si presenta diversamente:

ho il link alla PR originale, ma - non essendo una tasklist - non ho visibilità del suo stato e devo cliccarci sopra.

da qui, vedo che è stata mergiata. Ad entrambe manca il link alla issue in testata, ma vabbè ci arrivo dal riquadro a lato

e non è un problema (e comunque dalla issue di sincronizzazione non ci arriverei diretto comunque).

[SirAionTech]

Nel secondo caso ottengo un elenco di PR che sono porting di altre, ma, a meno di non mettere due label 'is porting' di colori diversi (viola e verde) a seconda se la PR originale è stata mergiata o no e gestire a mano l'aggiornamento delle stesse ogni volta che viene mergiata una PR - non ho visibilità delle stato della PR originale.

Normalmente il porting andrebbe fatto quando la PR originale è mergiata, quindi in generale assumerei che è mergiata.
I casi in cui ci sono due PR aperte per le due versioni sono eccezioni, non mi baserei su quelli per definire le linee guida.

Inoltre, per arrivarci, devo, clickare sulla PR:
non c'è il link alla PR orginale, per cui devo cliccare sulla issue (per fortuna il link c'è nel commento iniziale, altrimenti lo devo cercare o tra i commenti sotto o nella sezione a lato)

Notare che la seconda PR dello stesso elenco, si presenta diversamente:
ho il link alla PR originale, ma - non essendo una tasklist - non ho visibilità del suo stato e devo cliccarci sopra.
image
da qui, vedo che è stata mergiata.

Nella descrizione della PR infatti secondo me andrebbe indicato quale issue si sta risolvendo ed eventualmente quale PR si sta portando, proprio per facilitare la navigazione tra issue e PR collegate.

[TheMule71]

Per dire, da qui io vedo a colpo d'occhio:

ho due PR già mergiate per 14, già fatte per 16, solo da validare
una PR già mergiata ma da portare
una PR già portata ma verde su entrambe le versioni
una PR verde su 14 da portare

non so quanto sia semplice ottenere lo stesso risultato via query con label e poi tenerle pure aggiornate ogni volta che succede qualcosa (PR create, PR mergiate).

Non che sia miracoloso l'aggiornamento della lista, ma le operazioni manuali da fare sono la creazione di una riga, che potrebbe avere una o due link a PR (in caso di uno, c'è scritto "TODO"), e la sostituzione di TODO con il link alla PR portata. Da lì poi si aggiorna da solo, eventualmente quando si arriva a viola <- viola la riga marcata come fatta o meglio ancora rimossa.

[TheMule71]

Nel secondo caso ottengo un elenco di PR che sono porting di altre, ma, a meno di non mettere due label 'is porting' di colori diversi (viola e verde) a seconda se la PR originale è stata mergiata o no e gestire a mano l'aggiornamento delle stesse ogni volta che viene mergiata una PR - non ho visibilità delle stato della PR originale.

Normalmente il porting andrebbe fatto quando la PR originale è mergiata, quindi in generale assumerei che è mergiata. I casi in cui ci sono due PR aperte per le due versioni sono eccezioni, non mi baserei su quelli per definire le linee guida.

Non saprei quanto normale sia, io spesso ho aperto issue e fatto le due PR (anzi la considero la prassi, e mi secca quando magari non riesco a farlo), oppure ho preso una issue esistente (senza PR) e ho fatto le due PR in parallelo.

In effetti è qualcosa che dovremmo incoraggiare, e farlo ogni volta che è possibile, visto che la persona migliore per fare il porting della PR è comunque l'autore dell'originale. Il caso in cui venga fatta la PR su una versione e ignorata l'altra (lasciando a qualcun altro il compito di fare il porting) sicuramente capita spesso, ma rimane il caso meno ideale, sicuramente non lo vogliamo incoraggiare o dichiararlo come la norma. Può succedere, è inevitabile, non c'è nulla di male, ma non andrebbe bloccato il porting di una PR solo perché l'orginale non è mergiata, soprattutto dall'autore originale. In effetti è capitato spesso che venisse mergiata prima quella portata (specie se l'originale verde era sulla 14 e il porting sulla 16). E se le fai insieme, non è chiaro qual è l'originale e qual è il porting...

È anche vero che avere due PR aperte (parlo per esperienza) può essere frustante, a volte ricevi due review diverse che ti dicono di fare due cose diverse, la discussione andrebbe fatta su una sola PR, e poi traslato il risultato sull'altra. In effetti la prassi potrebbe essere quella di fare sì due PR (ripeto due PR dallo stesso autore sono l'ottimo per me) ma una metterla in draft per incoraggiare la discussione solo sull'altra. Ma anche qui, per esperienza, dopo un po' cominciano a fioccare richieste 'merge?' anche se la PR è in draft, per cui lascia il tempo che trova.

Nella descrizione della PR infatti secondo me andrebbe indicato quale issue si sta risolvendo ed eventualmente quale PR si sta portando, proprio per facilitare la navigazione tra issue e PR collegate.

Infatti, ma torniamo alla limitazione che ho evidenziato nei primi commenti, github non consente la visualizzazione dello stato di un PR in un normale link. Il link non riporta nemmeno il titolo (che in questo caso serve relativamente).

Il link deve essere in una tasklisk per vedere se la PR è verde o viola. Devi comunque cliccarci sopra.

Se github consentisse uno short link e un full link (tipo #NNNN:long) nel testo normale, con lo stesso stile di quello che succede in una tasklist, sarebbe già diverso.

[francesco-ooops]

@TheMule71 ma la lista nel primo commento è da espandere, giusto?

Teoricamente dovrebbe contenere tutte le 141 PR aperte al momento, ad esclusione di migrazioni e PR che non riguardano le altre versioni, o sbaglio?

[sergiocorato]

Come proposto in chiamata, io e @francesco-ooops abbiamo creato delle etichette ( is porting This pull request is porting a change from another version e needs porting This issue has already been resolved for some version ) e le stiamo applicando a issues e PRs.

Con queste etichette sarà possibile capire cosa c'è da portare e cosa è stato portato, ad esempio:

* PRs sulla `16.0` che sono porting da un'altra versione: https://github.com/OCA/l10n-italy/pulls?q=is%3Apr+is%3Aopen+base%3A16.0+label%3A%22is+porting%22.

* PRs sulla `14.0` che sono porting da un'altra versione: https://github.com/OCA/l10n-italy/pulls?q=is%3Apr+is%3Aopen+base%3A14.0+label%3A%22is+porting%22.

* Issues risolte per una versione, da portare a `16.0`: https://github.com/OCA/l10n-italy/issues?q=is%3Aopen+label%3A%22needs+porting%22+label%3A16.0.

* Issues risolte per una versione, da portare a `14.0`: https://github.com/OCA/l10n-italy/issues?q=is%3Aopen+label%3A%22needs+porting%22+label%3A14.0.

Come usare le nuove etichette Supponendo che esista la issue di tracciamento, quando la PR per 14.0 viene chiusa, nella issue c'è da:

* rimuovere https://github.com/OCA/l10n-italy/labels/14.0

* aggiungere 
  [
    needs porting](https://github.com/OCA/l10n-italy/labels/needs%20porting)
    This issue has already been resolved for some version
   e 
  [
    no stale](https://github.com/OCA/l10n-italy/labels/no%20stale)
    Use this label to prevent the automated stale action from closing this PR/Issue.

Quando viene aperta la PR per 16.0, dovrà avere is porting This pull request is porting a change from another version .

Se ci piace, aggiornerò https://github.com/OCA/l10n-italy/wiki/Team-di-sviluppo.

Le etichette sono un buon metodo per filtrare le PR/Issue, però sono impostabili solo dal PSC, quindi comportano un appesantimento del lavoro non irrilevante.

In ogni caso, il lavoro di marcare la PR come da portare va fatto:

1. nel caso ci sia una issue riassuntiva lo sviluppatore che l'ha creata potrebbe semplicemente taggarla e poi, senza fretta, il PSC aggiorna la issue riassuntiva comodamente (c'è la lista di chi l'ha taggata)
2. nel caso lo sviluppatore crei la issue, c'è la necessità che il PSC veda la PR e poi la taggi

Con n issue quindi il PSC deve andare a taggare/staggare tutte le PR collegate per capire in che stato sono, mentre con una issue riassuntiva lo stato si vede direttamente dalla singola riga in cui sono riportate le PR. La differenza è tra il taggare/staggare 141 PR (+ quelle chiuse/stale/mergiate) e l'aggiornare il testo di tipo 6 issue riassuntive.

In ogni caso, le issue di migrazione funzionano da sempre nel modo della issue riassuntiva, non è nulla di nuovo, si tratta solo di prendere quel funzionamento e migliorarlo.

[TheMule71]

@TheMule71 ma la lista nel primo commento è da espandere, giusto?

Teoricamente dovrebbe contenere tutte le 141 PR aperte al momento, ad esclusione di migrazioni e PR che non riguardano le altre versioni, o sbaglio?

Si, escluse anche quelle per la 12. Probabilmente sono circa 100 in tutto. Al momento sarebbero divise in due gruppi (avanti e indietro,16 <-- 14 e 14 <-- 16).

Ovviamente la lista attuale non è completa, ho preso solo esempi delle varie tipologie... anche per discutere la formattazione. Per dire adesso è #PR1 <-- #PR2 (per mettere in rilievo le cose da fare) potrebbe essere #PR1 --> #PR2 se ci fosse una buona ragione.

L'unica cosa che non possiamo evitare è la tasklist perché solo quella mette il link espanso con lo stato della PR.

[TheMule71]

Aggiungo che non è fondamentale avere un'unica issue. Si era esplorata la possibilità di avere una issue 16 <-- 14 e una 14 <-- 16 se aiuta avere due elenchi separati.

[sergiocorato]

@TheMule71 sulla lista sopra credo ci sia un refuso nella proposta porting da 14.0 a 16.0, forse intendevi così?

• [14.0] --> [16.0]

[SirAionTech]

Ho mergiato #4434 quindi ho checkato il suo task, oppure va tolto?

[SirAionTech]

Nel secondo caso ottengo un elenco di PR che sono porting di altre, ma, a meno di non mettere due label 'is porting' di colori diversi (viola e verde) a seconda se la PR originale è stata mergiata o no e gestire a mano l'aggiornamento delle stesse ogni volta che viene mergiata una PR - non ho visibilità delle stato della PR originale.

Normalmente il porting andrebbe fatto quando la PR originale è mergiata, quindi in generale assumerei che è mergiata. I casi in cui ci sono due PR aperte per le due versioni sono eccezioni, non mi baserei su quelli per definire le linee guida.

Non saprei quanto normale sia, io spesso ho aperto issue e fatto le due PR (anzi la considero la prassi, e mi secca quando magari non riesco a farlo), oppure ho preso una issue esistente (senza PR) e ho fatto le due PR in parallelo.

In effetti è qualcosa che dovremmo incoraggiare, e farlo ogni volta che è possibile, visto che la persona migliore per fare il porting della PR è comunque l'autore dell'originale. Il caso in cui venga fatta la PR su una versione e ignorata l'altra (lasciando a qualcun altro il compito di fare il porting) sicuramente capita spesso, ma rimane il caso meno ideale, sicuramente non lo vogliamo incoraggiare o dichiararlo come la norma. Può succedere, è inevitabile, non c'è nulla di male, ma non andrebbe bloccato il porting di una PR solo perché l'orginale non è mergiata, soprattutto dall'autore originale. In effetti è capitato spesso che venisse mergiata prima quella portata (specie se l'originale verde era sulla 14 e il porting sulla 16). E se le fai insieme, non è chiaro qual è l'originale e qual è il porting...

È anche vero che avere due PR aperte (parlo per esperienza) può essere frustante, a volte ricevi due review diverse che ti dicono di fare due cose diverse, la discussione andrebbe fatta su una sola PR, e poi traslato il risultato sull'altra. In effetti la prassi potrebbe essere quella di fare sì due PR (ripeto due PR dallo stesso autore sono l'ottimo per me) ma una metterla in draft per incoraggiare la discussione solo sull'altra. Ma anche qui, per esperienza, dopo un po' cominciano a fioccare richieste 'merge?' anche se la PR è in draft, per cui lascia il tempo che trova.

Ho scritto che è normale perché il caso d'uso tipico è che uno ha un problema nell'istanza di un cliente, lo corregge e propone qui la correzione: ovviamente lo fa solo per la versione che gli serve.
Se siamo fortunati seguirà anche la PR e arriverà al merge, ma raramente capita che qualcuno veda quella PR e la porti all'altra versione.
Poi tenere sincronizzate due PR che fanno la stessa modifica è oneroso e, come hai scritto, frustrante per l'autore quindi non è una pratica che incoraggerei.
Ma questi sono altri discorsi.

Tornando alla gestione di issues/PRs, l'etichetta is porting This pull request is porting a change from another version serve a prioritizzare le PR che hanno una correzione già mergiata nell'altra versione: serve prioritizzarle perché ci interessa mantenere le versioni allineate.
Quindi finché nessuna delle due è mergiata, nessuna è is porting This pull request is porting a change from another version ; appena una delle due viene mergiata, l'altra diventa is porting This pull request is porting a change from another version .

P.S.: l'ho chiarito in #4391 (comment).

[SirAionTech]

Le etichette sono un buon metodo per filtrare le PR/Issue, però sono impostabili solo dal PSC, quindi comportano un appesantimento del lavoro non irrilevante.

In ogni caso, il lavoro di marcare la PR come da portare va fatto:

1. nel caso ci sia una issue riassuntiva lo sviluppatore che l'ha creata potrebbe semplicemente taggarla e poi, senza fretta, il PSC aggiorna la issue riassuntiva comodamente (c'è la lista di chi l'ha taggata)
2. nel caso lo sviluppatore crei la issue, c'è la necessità che il PSC veda la PR e poi la taggi

Con n issue quindi il PSC deve andare a taggare/staggare tutte le PR collegate per capire in che stato sono, mentre con una issue riassuntiva lo stato si vede direttamente dalla singola riga in cui sono riportate le PR. La differenza è tra il taggare/staggare 141 PR (+ quelle chiuse/stale/mergiate) e l'aggiornare il testo di tipo 6 issue riassuntive.

Anche l'aggiornamento di questa issue va fatto dal PSC.

Secondo me elencare solo qui dentro i 100 problemi aperti che ci sono fa perdere di vista il fatto che ci sono ancora 100 problemi aperti e la corrispondenza 1 issue <-> 1 problema.
Questa issue in pratica nasconderebbe il fatto che ci sono ancora 100 problemi che qualcuno ha risolto in una versione, ma che esistono ancora per l'altra versione.

In ogni caso, le issue di migrazione funzionano da sempre nel modo della issue riassuntiva, non è nulla di nuovo, si tratta solo di prendere quel funzionamento e migliorarlo.

La issue di migrazione è fatta in modo simile ma molto meno impegnativa da gestire perché va modificata solo in periodi specifici (quando esce una nuova versione).
Pur essendo meno impegnativa, esistono dei tool in ocabot fatti apposta per aggiornarla, ma quando era da aggiornare manualmente si rischiava di mettere ad esempio lo stesso modulo più volte.
E lì almeno è una sola lista dove l'ordine può essere stabilito oggettivamente per nome modulo o per numero di PR.
In questa issue di sincronizzazione invece c'è una lista con probabilmente più task per ogni modulo, 1 o 2 PR per modulo, da ordinare in base a non pochi criteri:

• 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

Secondo me è ben più complicato della issue di migrazione.

[SirAionTech]

In descrizione, la PR di migrazione #3776 è riportata più volte:

• [14.0][FIX]assets_management: Company and page number out of page #4265 <-- [MIG] assets_management -> l10n_it_asset_management: Migration to 16.0 #3776
• ...
• TODO <-- [MIG] assets_management -> l10n_it_asset_management: Migration to 16.0 #3776

pensavo fosse un errore, ma forse invece è perché la PR #3776 risolveva diverse issues

Il commit successivo alla migrazione risolve #3775 per 16.0.
Risolve #3009 per 16.0.
Risolve #3318 per 16.0.
Risolve #3851 per 16.0.
Risolve #3874 per 16.0.
Risolve #3170 per 16.0.

e ad esempio #4265 è il backporting della soluzione per una di quelle issues (la #3874).

Come facciamo a tracciare quali checkbox corrispondono a quale issue?