3. Fork e varianti¶
Come già accennato precedentemente, il fork di un progetto software può essere inteso in modo diverso a seconda dello scopo finale di tale diramazione. Per questioni di chiarezza, qui di seguito distinguiamo le due possibilità: fork tecnici e varianti software.
3.1. Fork tecnici (i.e. pubblicare patch)¶
Un fork tecnico è un fork eseguito da uno sviluppatore con lo scopo di lavorare sulla code base originale o per inviare miglioramenti agli autori del software originale, senza la finalità esplicita di creare e mantenere una variante alternativa del software originale.
Nel contesto di un sistema di controllo distribuito e piattaforme di hosting di codice collaborative quali GitHub, lo strumento del fork è quasi sempre usato dagli sviluppatori come il primo passo per lavorare ad un contributo su una code base già esistente inviando pull request.
Visto il modo in cui il sistema di forking funziona su GitHub ed altre
piattaforme simili, gli sviluppatori pubblicano i propri fork sotto
forma di copie perfette del software originale, quindi includendo anche
il file publiccode.yml originale. I parser devono essere in grado di
distinguere questi fork tecnici dalla code base originale.
3.1.1. Parser¶
I parser DOVREBBERO identificare un fork tecnico notando che la
chiave top-level url non punta al repository dove si trova il file
publiccode.yml.
I parser POTREBBERO identificare un fork tecnico anche attraverso i metadati che potrebbero essere esposti dalla piattaforma di code hosting (e.g., GitHub contrassegna i fork esplicitamente come fork).
3.1.2. Autori¶
Gli autori di un fork tecnico NON DOVREBBERO modificare il file
publiccode.yml in alcun modo. Più nello specifico, NON DEVONO
modificare la chiave top-level url in quanto questa DEVE
continuare a puntare al repository originale.
Non c’è una chiave specifica per contrassegnare un fork come tecnico.
Questa è una scelta consapevole di design perché non vogliamo che gli
autori di un fork tecnico debbano necessariamente essere consapevoli del
file publiccode.yml e di come doverlo modificare. Il design corrente
non richiede che questi autori facciano alcunché.
3.2. Varianti software¶
Una variante software è un fork che rappresenta una valida alternativa al software originale upstream.
Questa contiene modifiche che non sono ancora parte della versione upstream, come ad esempio più funzionalità, dipendenze diverse, ottimizzazioni, etc.
Contrassegnando un fork come una variante, l’autore indica che questa variante include una serie di modifiche complete e funzionanti che potrebbero giovare ad altre persone.
Contrassegnare un fork come una variante non pregiudica la volontà di contribuire upstream; l’autore potrebbe comunque voler contribuire upstream o essere in attesa di farlo. Perciò, anche se il fork alla fine verrà inclusa (merge) upstream, potrebbe aver senso contrassegnarla come una variante durante queste fasi di lavoro intermedie, in modo tale che anche altri possano trovarla e beneficiarne.
3.2.1. Parser¶
I parser DOVREBBERO identificare una variante notando che la chiave
top-level url è uguale al repository nel quale il file
publiccode.yml risiede, E una chiave top-level isBasedOn
esiste e punta ad un altro repository.
I parser dovrebbero aspettarsi e analizzare altre differenze nelle due
varianti dei file publiccode.yml. In particolare, la chiave
description/features è pensata per essere comparata tra diverse
varianti in modo da identificare e visualizzare le differenze lato
utente.
3.2.2. Autori¶
Gli autori che vogliano pubblicare un fork come una variante DEVONO almeno:
- Aggiungere una chiave
isBasedOnche punti a uno o più repository upstream dai quali questa variante deriva. - Cambiare il valore di
urlper farla puntare al repository che ospita la variante. - Cambiare il valore di
legal/repoOwnerper identificarsi come autori della variante. - Rivisitare la sezione denominata
maintenanceper aggiornare lo stato di manutenzione della variante.
Inoltre, gli autori DOVREBBERO valutare di apportare anche i seguenti cambiamenti:
- Aggiungere le funzionalità che differenziano le varianti alla chiave
description/features. Le funzionalità esistenti NON DOVREBBERO essere modificate o rimosse da questa lista a meno che esse siano state rimosse dalla variante, per permettere ai parser di comparare facilmente la lista delle funzionalità.