Ti si fredda l'insalata?
Ecchecavolo! Già aperto il repository?
Scherzi a parte, però mi pare di aver discusso su una forma di pianificazione su carta prima di mettere su già i mattoni...
Ad ogni modo:
1) glib è il nome che avevo dato inizialmente alla libreria, in quanto "g" per Gambas, e "lib"... tralasciamo le spiegazioni
2) come da documentazione ufficiale, le librerie gambas hanno il suffisso "gb.", e quindi la libreria penso si giusto suffissarla con "gb.glib."
3) tutti i sotto progetti, in base alle loro caratteristiche, verrano inseriti in apposite classificazioni, tipo: "gb.glib.audio" per i progetti che hanno a che fare con l'audio, "gb.glib.net" per quelli di utilità verso la rete, e via dicendo. La classificazione si decide al momento che si inizializza un progetto. La classificazione verrà definita in fase iniziale, o al primo progetto cui si decide di associarlo ad una certa classe di librerie.
4) dato che ha creato il repository, simo97 fungerà da Project Manager, con appunto il compito di classificare, ovvero creare i sotto repository su cui andranno le librerie. Avrà anche il compito di congelare il progetto per la pubblicazione di una nuova versione (ciò non toglie che la decidione può coinvolgere i vari sotto responsabili delle varie librerie).
5) Si può già creare una struttura di classi (classificazione) sul repository, basandosi appunto sulla struttura delle libreria di gambas.
6) Per ogni classe, si nomina un Class Manager (o anche Library Manager), che ha il compito di gestire il subrepository e validare il codice inserito. Come il PM (Project Manager), può congelare la libreria per renderla disponibile con il rilascio della successiva versione del progetto.
7) Tutti gli sviluppatori e contributori (es. per la documentazione), registrati, potranno contribuire allo sviluppo di tutte le librerie, facendo sempre capo al CM (Class Manager).
Il CM (Class Manager) può decidere anche di rigettare, nel caso riscontri anomalie, i pezzi di codice inseriti dagli sviluppatori. Questo vuol dire che il CM ha il compito di validare la libreria, le classi e i moduli inseriti.
9) Ogni classe, modulo o funzione, deve essere corredata da documentazione ed esempi sull'utilizzo.
10) il codice deve avere una testata, con la data di creazione, l'elenco delle date delle modifiche effettuate, ivi compresi lo/gli sviluppatori che hanno introdotto le variazioni, quindi anche una descrizione sommaria delle modifiche apportate.
11) il nome delle librerie, delle classi, dei moduli ecc. devono essere univoche, e concordate con il CM. Per questo motivo credo sia il caso di pubblicare una tabella con la lista delle librerie, e delle classi e moduli che contiene, in modo che chiunque può verificarne l'esistenza e quindi dove è utilizzata e qundo è stata creata.
Quanto sopra, a mio avviso, è un primo accenno di pianificazione e di istituzione di una serie di regole, che credo sia il caso di pianificare prima di procedere alle attività vere e proprie.
Quello che ho buttato giù è un primo elenco di cose che io considero basilari per poter iniziare. E' sottinteso che sono da discutere e implementare con altre idee, per cui, visto il fuoco che arde sotto la sedia di simo97, è aperto a tutti, anche se non vuole o può contribuire, anche in futuro, magari aggiungendo la propria esperienza.
Di codice e librerie già in piedi e funzionanti già ci sono (vedi la Grid di Milio, o la libreria matematica che già da un pò gira nel forum...
). Quindi, volendo, di elementi già pronti ci sono, ma credo sia opportuno prima decidere bene il da farsi.
Dal mio canto, appena possibile e dopo aver istituito un piano concreto di progetto, posso contribuire a fornire il codice che già compone la vecchia libreria glib, alla quale però creado sera un restiling e alcuni adattamenti a Gambas3.
Bye
