<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Software Release Practice HOWTO: Buone regole di comunicazione</TITLE> <LINK HREF="Software-Release-Practice-HOWTO-4.html" REL=previous> <LINK HREF="Software-Release-Practice-HOWTO.html#toc5" REL=contents> </HEAD> <BODY> Avanti <A HREF="Software-Release-Practice-HOWTO-4.html">Indietro</A> <A HREF="Software-Release-Practice-HOWTO.html#toc5">Indice</A> <HR> <H2><A NAME="s5">5. Buone regole di comunicazione</A></H2> <P>Il proprio software non renderà il mondo migliore se nessuno sa che esiste. Inoltre, con una presenza visibile del progetto su Internet sarà più semplice trovare utenti e co-sviluppatori. Ecco i modi standard per farlo. <P> <H2><A NAME="ss5.1">5.1 Riferire a c.o.l.a</A> </H2> <P>Annunciare la nuova release a <A HREF="news:comp.os.linux.announce">comp.os.linux.announce</A>. Oltre a essere letto da moltissime persone, questo gruppo è una dei più grossi contenitori di siti web riguardanti le novità del settore, come <A HREF="http://www.freshmeat.net">Freshmeat</A>. <P> <H2><A NAME="ss5.2">5.2 Riferire ad un newsgroup attinente al tema</A> </H2> <P>Si trovi un gruppo USENET attinente alla propria applicazione, e si annunci lì la sua uscita. Si posti solo dove la <EM>funzione</EM> del codice è attinente, e si restringa il campo d'azione. Se (per esempio) si sta rilasciando un programma scritto in Perl che consulti un server IMAP, si dovrebbe sicuramente postare a comp.mail.imap. Ma non si dovrebbe probabilmente postare a comp.lang.perl a meno che il programma non sia anche un esempio istruttivo delle tecniche Perl all'avanguardia. <P>L'annuncio dovrebbe includere l'URL di un sito web del progetto. <P> <H2><A NAME="ss5.3">5.3 Fornire un sito Web</A> </H2> <P>È importante avere un sito web se si vogliono raccogliere utenti o un gruppo di sviluppatori del progetto. Caratteristiche standard di un sito sono: <UL> <LI>Lo statuto del progetto (perché esiste, a chi si rivolge, ecc.).</LI> <LI>Collegamenti per scaricare i sorgenti.</LI> <LI>Istruzioni per iscriversi alla/alle mailing list del progetto.</LI> <LI>Un elenco di FAQ (Frequently Asked Questions).</LI> <LI>Documentazione in HTML sul progetto.</LI> <LI>Link a progetti correlati e/o in competizione con il proprio.</LI> </UL> <P>Alcuni siti di progetti forniscono anche degli URL per l'accesso anonimo al master source tree. <P> <H2><A NAME="ss5.4">5.4 Creare delle mailing list attinenti al progetto</A> </H2> <P>È una pratica comune creare una lista privata di sviluppo attraverso cui i collaboratori del progetto possano comunicare e scambiarsi delle patch. Si potrebbe anche creare una lista di annunci e notizie per le persone che vogliano essere tenute informate sullo stato del progetto. <P> <H2><A NAME="ss5.5">5.5 Distribuzione attraverso i più importanti archivi</A> </H2> <P>Negli anni scorsi, l'archivio di <A HREF="http://www.sunsite/unc.edu/pub/Linux/">Sunsite</A> è stato il più importante luogo di scambio per i programmi Linux. <P>Altri siti importanti sono: <P> <UL> <LI>Il sito del <A HREF="http://www.python.org">Python Software Activity</A> (per programmi scritti in Python).</LI> <LI>Il <A HREF="http://language.perl.com/CPAN">CPAN</A>, Comprehensive Perl Archive Network, (per programmi scritti in Perl).</LI> </UL> <P> <H2><A NAME="ss5.6">5.6 Fornire archivi RPM</A> </H2> <P>La configurazione standard de-facto per i pacchetti di binari installabili è quella usata dal Red Hat Package Manager, RPM. È presente nella maggior parte delle più conosciute distribuzioni Linux, e supportato efficacemente da praticamente tutte le altre (eccettute Debian e Slackware). <P>Di conseguenza, è una buona idea per il sito del proprio progetto fornire tanto pacchetti RPM installabili quanto archivi tar. <HR> Avanti <A HREF="Software-Release-Practice-HOWTO-4.html">Indietro</A> <A HREF="Software-Release-Practice-HOWTO.html#toc5">Indice</A> </BODY> </HTML>
