Sincronizzazione PR 14 <-> 16 #4391

TheMule71 · 2024-10-04T08:22:22Z

TheMule71 · 2024-10-04T08:50:07Z

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 · 2024-10-04T09:07:50Z

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 · 2024-10-04T10:00:59Z

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 · 2024-10-04T10:35:11Z

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 · 2024-10-04T11:18:33Z

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 · 2024-10-04T13:27:43Z

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 · 2024-10-04T14:07:30Z

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 · 2024-10-04T14:29:43Z

@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 · 2024-10-04T15:11:43Z

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 · 2024-10-14T08:55:23Z

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 · 2024-10-14T09:11:32Z

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 · 2024-10-28T10:14:07Z

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 · 2024-11-08T10:47:09Z

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.

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 in un'altra versione: serve prioritizzarle perché ci interessa mantenere le versioni allineate.

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 mergiata, nella issue c'è da:

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

Quando verrà aperta la PR per 16.0 (o se esiste già), deve 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.

SirAionTech · 2024-11-08T11:29:40Z

@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 · 2024-11-08T11:31:04Z

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 · 2024-11-08T11:49:59Z

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 · 2024-11-08T12:03:48Z

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 · 2024-11-08T12:04:28Z

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 · 2024-11-08T12:24:44Z

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 · 2024-11-08T14:39:47Z

@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 · 2024-11-08T14:51:06Z

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:

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)
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 · 2024-11-08T15:46:43Z

@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 · 2024-11-08T17:41:21Z

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 · 2024-11-13T07:54:35Z

@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 · 2024-11-13T11:32:06Z

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

SirAionTech · 2024-11-13T13:27:26Z

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 · 2024-11-13T15:15:17Z

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:

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)

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.

TheMule71 added the enhancement label Oct 4, 2024

TheMule71 added the help wanted label Oct 11, 2024

francesco-ooops added no PR yet 🫤 and removed no PR yet 🫤 labels Nov 8, 2024

SirAionTech mentioned this issue Nov 12, 2024

[IMP][14.0] l10n_it_intrastat show weight total #4440

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sincronizzazione PR 14 <-> 16 #4391

Sincronizzazione PR 14 <-> 16 #4391

TheMule71 commented Oct 4, 2024 •

edited by SirAionTech

Loading

TheMule71 commented Oct 4, 2024 •

edited

Loading

francesco-ooops commented Oct 4, 2024 •

edited by SirAionTech

Loading

sergiocorato commented Oct 4, 2024

TheMule71 commented Oct 4, 2024 •

edited

Loading

TheMule71 commented Oct 4, 2024

sergiocorato commented Oct 4, 2024

tafaRU commented Oct 4, 2024

SirAionTech commented Oct 4, 2024

sergiocorato commented Oct 4, 2024

SirAionTech commented Oct 14, 2024

francesco-ooops commented Oct 14, 2024

TheMule71 commented Oct 28, 2024

SirAionTech commented Nov 8, 2024 •

edited

Loading

SirAionTech commented Nov 8, 2024

francesco-ooops commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

SirAionTech commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

TheMule71 commented Nov 8, 2024 •

edited

Loading

francesco-ooops commented Nov 8, 2024

sergiocorato commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

sergiocorato commented Nov 13, 2024

SirAionTech commented Nov 13, 2024

SirAionTech commented Nov 13, 2024 •

edited

Loading

SirAionTech commented Nov 13, 2024

Sincronizzazione PR 14 <-> 16 #4391

Sincronizzazione PR 14 <-> 16 #4391

Comments

TheMule71 commented Oct 4, 2024 • edited by SirAionTech Loading

TheMule71 commented Oct 4, 2024 • edited Loading

francesco-ooops commented Oct 4, 2024 • edited by SirAionTech Loading

sergiocorato commented Oct 4, 2024

TheMule71 commented Oct 4, 2024 • edited Loading

TheMule71 commented Oct 4, 2024

sergiocorato commented Oct 4, 2024

tafaRU commented Oct 4, 2024

SirAionTech commented Oct 4, 2024

sergiocorato commented Oct 4, 2024

SirAionTech commented Oct 14, 2024

francesco-ooops commented Oct 14, 2024

TheMule71 commented Oct 28, 2024

SirAionTech commented Nov 8, 2024 • edited Loading

SirAionTech commented Nov 8, 2024

francesco-ooops commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

SirAionTech commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

TheMule71 commented Nov 8, 2024 • edited Loading

francesco-ooops commented Nov 8, 2024

sergiocorato commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

TheMule71 commented Nov 8, 2024

sergiocorato commented Nov 13, 2024

SirAionTech commented Nov 13, 2024

SirAionTech commented Nov 13, 2024 • edited Loading

SirAionTech commented Nov 13, 2024

TheMule71 commented Oct 4, 2024 •

edited by SirAionTech

Loading

TheMule71 commented Oct 4, 2024 •

edited

Loading

francesco-ooops commented Oct 4, 2024 •

edited by SirAionTech

Loading

TheMule71 commented Oct 4, 2024 •

edited

Loading

SirAionTech commented Nov 8, 2024 •

edited

Loading

TheMule71 commented Nov 8, 2024 •

edited

Loading

SirAionTech commented Nov 13, 2024 •

edited

Loading