slacky.eu

Salve a tutti.
Mi sono sempre chiesto quali siano i meccanismi per mantenere un progetto opensource.Ad esempio lo sviluppo di un software.
Come si gestisce la cosa?Ad esempio visto che molte persone accedono al sorgente per modificarlo,come si fa a stabilire se una modifica è buona o cattiva,come si fa ad aggiornare il progetto e a stabilire la versione?
Come si tiene traccia dei bug?

Insomma faccio prima a dire come si gestisce lo sviluppo software?

http://it.wikipedia.org/wiki/Processo_software
http://it.wikipedia.org/wiki/Ciclo_di_vita_del_software

Non mi riferivo alla progettazione software,ma al mantenimento.

il ciclo vita di un sw non comprende solo analisi e progettazione, ma anche mantenimento e eliminazione.. insomma "ciclo vita"
Il resto viene con l'esperienza!

Secondo me si riferiva all'utilizzo di CVS (o git o subversion o svn o chipiùnehapiùnemetta).

Creedo si essermi spiegato male,anzi malissimo.Allora faccio un esempio.
Prendiamo un software come emesene.IL sito è http://www.emesene.org/.
Qui infatti ci sta una sezione per il bug report.
Ciò che voglio sapere,è come si "decide" di mantenere un software.Se un programmatore fa una modifica,come faccio a sapere se è affidabile?Chi decide se va accettata?Chi ufficializza che quella versione svn è quella?C'è qualcuno che controlla il processo?

Si mi riferivo anche all'utilizzo di cvs,anzi proprio a quello.Però vorrei capire chi e come e in base a quali principi viene gestita la cosa.

mordecai ha scritto: Ciò che voglio sapere,è come si "decide" di mantenere un software.Se un programmatore fa una modifica,come faccio a sapere se è affidabile?Chi decide se va accettata?Chi ufficializza che quella versione svn è quella?C'è qualcuno che controlla il processo?

Si mi riferivo anche all'utilizzo di cvs,anzi proprio a quello.Però vorrei capire chi e come e in base a quali principi viene gestita la cosa.

Questione interessante, credo che la base sia chi si prende la responsabilità. Chi dà il via allo sviluppo di un software solitamente si prende la responsabilità di decidere tutte quelle cose che dici tu, amministra i contributi e gestisce le modifiche. E' il vero e proprio amministratore del progetto.
Dopotutto non è che OpenSource significhi democrazia assoluta (che poi significherebbe sostanzialmente anarchia), OpenSource significa maggiore facilità nel collaborare, ma collaborare spesso significa anche riconoscere chi coordina le attività.
In fondo non è che un rilascio OpenSource rappresenti la perdita di controllo da parte di chi il software l'ha sviluppato, possono anche esistere software amministrati secondo vere e proprie "dittature" che permettono sono un contributo infinitesimo rispetto a quanto viene sviluppato dai detentori del progetto. Un buon esempio sono quei software OpenSource che sono in mano ad aziende. E' naturale che, a prescindere da quali siano le richieste della comunità, sarà la politica dell'azienda stessa a guidare le decisioni.
Se si considera che un progetto sia gestito in modo troppo rigido o nella maniera sbagliata l'arma che è in mano alla comunità è quella del fork... quindi la creazione di una nuova linea di sviluppo del software, di una nuova direzione del cambiamento, ma, inevitabilmente, anche di un nuovo manutentore che coordini e prenda le decisioni.

semplificando c'è un tizio (il mantainer, meglio noto come DaBoss) che decide tutto (e eventualmente delega) e gestisce i permessi per il repo. in ambito opensource se non ti sta bene come la pensa (DaBoss ti ha mandato a schifo quando gli hai inviato le tue modifiche) ti fai un fork.

edit: ops! arrivato tardi e comunque non avevo scritto "a schifo"

Esempio Slackware:
PJV decide, i fork di chi non e` d'accordo:
Zenwalk ecc.

hahahahah....

Straquoto neongen in pieno.
Mi raccomando un sistema di tracking dei bug.
Fai sempre chiarezza nei changelog e fai una precisa roadmap.
Tira fuori le palle. Ci serve gente così!

DanBadJar ha scritto:Straquoto neongen in pieno.
Mi raccomando un sistema di tracking dei bug.
Fai sempre chiarezza nei changelog e fai una precisa roadmap.
Tira fuori le palle. Ci serve gente così!

Se il problema è avere una buona infrastruttura Sourceforge è sempre un ottimo punto di partenza. Anche se quando provai ad usarlo lo trovai un po' complesso, credo che metta a disposizione strumenti dalla vasta potenzialità.

Poi ovviamente valgono le leggi del buon informatico: codice pulito, commenta tutto, commenta in inglese, modularizza come si deve, pigrizia, arroganza e impazienza.

Si, è il mantainer a decidere quali modifiche apportare al codice. Il mantainer è l'amministratore del progetto, colui che lo ha creato, quindi mi sembra giusto che abbia
l'ultima parola sulle linee guida da seguire. SourceForge offre tutto quello che serve per lo sviluppo del software open, anche se la home del progetto pone molte
limitazioni sul numero di caratteri. La loro politica distingue la home del progetto dallo spazio web inteso come vetrina del progetto stesso. Tutto ciò può essere un po fastidioso per quelle persone che non hanno voglia o tempo di imparare l' HTML.
Infine voglio rassicurare il nostro amico che, fino a quando un progetto non diventa maturo e di largo interesse, difficilmente riceverà proposte di modifica.
Saluti!

Ah ecco un'altra cosa che non mi è MAI stata chiara,è come numerare la versione di un software.
Un qualsiasi software ha un numero diversione.
Ad esempio vari cms sono alla versione 1.0.1 poi alla 1.0.2 e poi alla 1.1.0.
Poi altri 3.5 poi 3.6 e poi alla 4.0
Posso fare infiniti esempi,ma non ho mai trovato una logica che lega univocamente il modo con cui numerare lo sviluppo.

Quindi ognuno fa come gli pare?

mordecai ha scritto: Quindi ognuno fa come gli pare?

Certo che si! La logica te la fai tu.