|
1 | | -Placeholder per [forks.md](../en/forks.md) |
| 1 | +# `publiccode.yml` - Fork e varianti |
2 | 2 |
|
| 3 | +Questo documento descrive come gestire l'aggiornamento di `publiccode.yml` nel |
| 4 | +contesto di un software fork. Per questioni di chiarezza, qui di seguito |
| 5 | +distinguiamo le due possibilità: fork tecnici e varianti software. |
3 | 6 |
|
| 7 | +## Fork tecnici (i.e. pubblicare patch) |
| 8 | + |
| 9 | +Un fork tecnico è un fork eseguito da uno sviluppatore con lo scopo di lavorare |
| 10 | +sulla *code base* originale o per inviare miglioramenti agli autori del |
| 11 | +software originale, senza la finalità esplicita di creare e mantenere una |
| 12 | +variante alternativa del software originale. |
| 13 | + |
| 14 | +Nel contesto di un sistema di controllo distribuito e piattaforme di hosting di |
| 15 | +codice collaborative quali GitHub, lo strumento del *fork* è quasi sempre usato |
| 16 | +dagli sviluppatori come il primo passo per lavorare ad un contributo su un |
| 17 | + |
| 18 | +Visto il modo in cui il sistema di *forking* funziona su GitHub ed altre |
| 19 | +piattaforme simili, gli sviluppatori pubblicano i propri fork sotto forma di |
| 20 | +copie perfette del software originale, quindi includendo anche il file |
| 21 | +`publiccode.yml` originale. I parser devono essere in grado di distinguere |
| 22 | +questi fork tecnici dalla *code base* originale. |
| 23 | + |
| 24 | +### Parser |
| 25 | + |
| 26 | +I *parser* **DOVREBBERO** identificare un fork tecnico notando che la chiave |
| 27 | +top-level `url` non punta al repository dove si trova il file `publiccode.yml`. |
| 28 | + |
| 29 | +I *parser* **POTREBBERO** identificare un fork tecnico anche attraverso |
| 30 | +i metadati che potrebbero essere esposti dalla piattaforma di code hosting |
| 31 | +(e.g., GitHub contrassegna i fork esplicitamente come fork). |
| 32 | + |
| 33 | +### Autori |
| 34 | + |
| 35 | +Gli autori di un fork tecnico **NON DOVREBBERO** modificare il file |
| 36 | +`publiccode.yml` in alcun modo. Più nello specifico, **NON DEVONO** modificare |
| 37 | +la chiave top-level `url` in quanto questa **DEVE** continuare a puntare al |
| 38 | +repository originale. |
| 39 | + |
| 40 | + |
| 41 | +Non c'è una chiave specifica per contrassegnare un fork come tecnico. Questa |
| 42 | +è una scelta consapevole di design perché non vogliamo che gli autori di un |
| 43 | +fork tecnico debbano necessariamente essere consapevoli del file `publiccode.yml` e |
| 44 | +di come doverlo modificare. Il design corrente non richiede che |
| 45 | +questi autori facciano alcunché. |
| 46 | + |
| 47 | +## Varianti software |
| 48 | + |
| 49 | +Una variante software è un fork che rappresenta una valida alternativa al |
| 50 | +software originale upstream. |
| 51 | + |
| 52 | +Questa contiene modifiche che non sono ancora parte della versione upstream, |
| 53 | +come ad esempio più funzionalità, dipendenze diverse, ottimizzazioni, etc. |
| 54 | + |
| 55 | +Contrassegnando un fork come una variante, l'autore indica che questa variante |
| 56 | +include una serie di modifiche complete e funzionanti che potrebbero giovare ad |
| 57 | +altre persone. |
| 58 | + |
| 59 | +Contrassegnare un fork come una variante **non** pregiudica la volontà di |
| 60 | +contribuire upstream; l'autore potrebbe comunque voler contribuire upstream |
| 61 | +o essere in attesa di farlo. Perciò, anche se il fork alla fine verrà inclusa |
| 62 | +(merge) upstream, potrebbe aver senso contrassegnarla come una variante durante |
| 63 | +queste fasi di lavoro intermedie, in modo tale che anche altri possano trovarla |
| 64 | +e beneficiarne. |
| 65 | + |
| 66 | +### Parser |
| 67 | + |
| 68 | +I parser **DOVREBBERO** identificare una variante notando che la chiave |
| 69 | +top-level `url` è uguale al repository nel quale il file `publiccode.yml` |
| 70 | +risiede, **E** una chiave top-level `isBasedOn` esiste e punta ad un altro |
| 71 | +repository. |
| 72 | + |
| 73 | +I parser dovrebbero aspettarsi e analizzare altre differenze nelle due varianti |
| 74 | +dei file `publiccode.yml`. In particolare, la chiave `description/features` |
| 75 | +è pensata per essere comparata tra diverse varianti in modo da identificare |
| 76 | +e visualizzare le differenze lato utente. |
| 77 | + |
| 78 | + |
| 79 | +### Autori |
| 80 | + |
| 81 | +Gli autori che vorrebbero pubblicare un fork come una variante **DEVONO** |
| 82 | +almeno: |
| 83 | + |
| 84 | +* Aggiungere una chiave `isBasedOn` che punti a uno o più repository upstream |
| 85 | + dai quali questa variante deriva. |
| 86 | +* Cambiare il valore di `url` per farla puntare al repository che ospita la |
| 87 | + variante. |
| 88 | +* Cambiare il valore di `legal/repoOwner` per identificarsi come autori della |
| 89 | + variante. |
| 90 | +* Rivisitare la sezione denominata `maintenance` per aggiornare lo stato di |
| 91 | + manutenzione della variante. |
| 92 | + |
| 93 | +Inoltre, gli autore **DOVREBBERO** valutare di fare anche i seguenti cambiamenti: |
| 94 | + |
| 95 | +* Aggiungere le funzionalità che differenziano le varianti alla chiave |
| 96 | + `description/features`. Le funzionalità esistenti **NON DOVREBBERO** essere |
| 97 | + modificate o rimosse da questa lista a meno che esse siano state rimosse |
| 98 | + dalla variante, per permettere ai parser di comparare facilmente la lista |
| 99 | + delle funzionalità. |
0 commit comments