From: Marcello Magaldi <magowiz@gmail.com>
To: gentoo-docs-it@lists.gentoo.org
Subject: Re: [gentoo-docs-it] richiesta assegnazione http://www.gentoo.org/proj/en/overlays/policy.xml
Date: Sun, 08 Jun 2008 20:11:47 +0200 [thread overview]
Message-ID: <484C20E3.8070607@gmail.com> (raw)
In-Reply-To: <200806081623.27443.scen@gentoo.org>
[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]
Davide Cendron ha scritto:
> Il Thursday 05 June 2008 15:43:42 Marcello Magaldi ha scritto:
>
>> Ciao,
>> richiedo che mi venga assegnato questo documento.
>>
>> Saluti
>>
>> Marcello
>>
>
> /proj/en/overlays/policy.xml tuo, grazie!
>
> Ciao,
>
>
Ciao,
ho tradotto il documento, tuttavia non ne sono convinto al 100%, allora
ve lo allego per una revisione, in particolare non sono riuscito a
capire, ne quindi a tradurre , la frase : (coming in Phase 2) .
Altra cosa , ho visto che come versione del documento è riportata :
Draft 1 , quando aprirò il bug dovrò mettere questa come dicitura
"document version" ?
Ciao
Marcello
PS vi ho allegato entrambe le versioni, sia quella origninale
(policy-en.xml) che la mia traduzione (policy.xml)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: policy.xml --]
[-- Type: text/xml; name="policy.xml", Size: 12090 bytes --]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/overlays/policy.xml,v 1.3 2006/12/16 13:37:17 genstef Exp $ -->
<guide link="/proj/it/overlays/policy.xml" lang="it">
<title>Politiche dei Gentoo Overlay</title>
<author title="Autore">
<mail link="stuart@gentoo.org">Stuart Herbert</mail>
</author>
<author title="Traduzione">
<mail link="magowiz@gmail.com">Marcello Magaldi</mail>
</author>
<abstract>
Questo è il documento delle politiche che regola il servizio degli Overlay Gentoo.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>Draft 1</version>
<date>2006-05-01</date>
<chapter>
<title>Introduzione</title>
<section>
<body>
<p>
Qui vi sono le policy del servizio overlays.g.o. Se si ospita un overlay su
overlays.g.o, o se si partecipa all'amministrazione di overlays.g.o, bisogna
seguire queste policy.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Che cos'è il servizio Overlays.g.o?</title>
<section>
<body>
<p>
Il servizio overlays.g.o fornisce un workspace sociale, per progetti Gentoo e
sviluppatori per permettergli di pubblicare i propri overlay di pacchetti
Gentoo in un posto, dove è facile per sviluppatori e non sviluppatori di
collaborare.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Tipi di Overlay</title>
<section>
<body>
<p>
overlays.g.o ospita due tipi di overlay:
</p>
<ul>
<li>overlay per team di progetti Gentoo</li>
<li>overlay per sviluppatori Gentoo individuali</li>
</ul>
<p>
overlays.g.o in questo momento *non* ospita overlay posseduti da altri individui.
</p>
</body>
</section>
<section>
<title>Overlay di Progetto</title>
<body>
<p>
Gli "overlay di Progetto" sono overlay posseduti da team di progetto Gentoo
riconosciuti.
E' necessario che questi team corrispondano alla definizione di progetto che si
può trovare nel nostro documento di metastruttura.
</p>
<p>
Gli "overlay di Progetto" avranno lo stesso nome del team di progetto Gentoo.
A ogni progetto è concesso un singolo overlay.
</p>
<p>
Per quanto concerne queste politiche, gli overlay di progetto sono di proprietà
del(degli) capo(i) eletto(i) del progetto.
</p>
</body>
</section>
<section>
<title>Overlay dello Sviluppatore</title>
<body>
<p>
Gli "overlay dello sviluppatore" sono overlay di proprietà di singoli
sviluppatori Gentoo.
Questi sono gli sviluppatori che hanno passato i quiz degli sviluppatori Gentoo,
e a cui è stato data la possibilità di effettuare commit al package tree
principale di Gentoo.
</p>
<p>
Ogni "overlay dello sviluppatore" avrà lo stesso nome dello sviluppatore che lo
possiede. Ad ogni sviluppatore è concesso un singolo overlay.
</p>
<p>
Per quanto concerne queste politiche, gli overlay degli sviluppatori sono di
proprietà dei singoli sviluppatori che ne hanno fatto richiesta.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Responsabilità</title>
<section>
<body>
<ol>
<li>I membri del team infrastruttura sono responsabili della piattaforma
(hardware + SO) su cui è ospitato overlays.g.o.</li>
<li>Il team del progetto overlay è responsabile dell'amministrazione del
servizio overlays.g.o, inclusa la responsabilità del software utilizzato per
fornire il servizio (es. svn, trac)</li>
<li>I possessori di overlay sono responsabili dei contenuti dei propri
overlay, e della condotta di chiunque abbia l'accesso al commit ai propri
overlay.
</li>
<li>Ogni singola persona che effettui commit a un overlay è responsabile per
le proprie azioni.</li>
</ol>
</body>
</section>
</chapter>
<chapter>
<title>Creazione di Overlay</title>
<section>
<body>
<p>
Gli overlay sono creati in base alla richiesta di chiunque sarà il possessore
dell'overlay.
</p>
<p>Gli overlay sono opzionali; a nessuno sviluppatore Gentoo è richiesto di
predisporre un overlay.
</p>
<p>
Gli sviluppatori Gentoo sono liberi di ospitare i propri overlay altrove.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Accesso Commit agli Overlay</title>
<section>
<body>
<p>
Per essere chiari:
</p>
<ul>
<li>Uno "sviluppatore" è qualcuno che ha l'accesso commit al package tree
principale di Gentoo.</li>
<li>Un "non-sviluppatore" è chiunque non abbia l'accesso commit al package
tree principale di Gentoo. Ciò include altri membri dello staff di Gentoo.</li>
</ul>
<p>
Overlay di Progetto:
</p>
<ul>
<li>Ogni sviluppatore elencato nella pagina del team del progetto può avere
l'accesso commit all'(agli) overlay di quel team. Chiedere al team di
amministratori dell'overlay per ottenere l'accesso.</li>
<li>Ogni sviluppatore non elencato nella pagina del team del progetto può
avere l'accesso commit, se ha il consenso di uno dei membri del team del
progetto.</li>
<li>Ogni "non sviluppatore" può avere l'accesso commit all'overlay di un team.
La richiesta dell'accesso deve pervenire dal proprietario dell'overlay.</li>
</ul>
<p>
Overlay dello Sviluppatore:
</p>
<ul>
<li>Ogni sviluppatore Gentoo può richiedere l'accesso commit, se ha il
consenso del proprietario dell'overlay.</li>
<li>Ogni "non sviluppatore" può avere l'accesso commit a un overlay di uno
sviluppatore. La richiesta di accesso deve pervenire dal proprietario
dell'overlay.</li>
</ul>
<p>Prerequisiti comuni per i "Non-Sviluppatori"</p>
<ul>
<li>Al "non-sviluppatore" è richiesto di aver registrato il proprio nickname
su Freenode IRC, e deve fornire un indirizzo email valido per la nostra banca
dati.</li>
<li>Se si è un non-sviluppatore, si prega di non richiedere direttamente
l'accesso al team dell'overlay, poichè un rifiuto spesso offende.</li>
</ul>
<note>
Con trac e svn, è possibile garantire l'accesso commit separatamente a trac
(es : il wiki), e a svn.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Regole Generali per gli Overlay</title>
<section>
<body>
<p>
Stiamo cercando deliberatamente di mantenere ridotte al minimo le regole sugli
overlay. Si prega di non abusare del servizio e di non costringerci ad
aggiungere più regole :(
</p>
</body>
</section>
<section>
<title>Cosa si può e cosa non si può salvare su overlays.g.o</title>
<body>
<p>
overlays.g.o è fatto per ospitare package tree, le loro patch, qualsiasi
documento, e ogni tarball scaricabile che non sono (e non possono essere)
ospitati altrove.
</p>
<p>
Non deve essere l' $UPSTREAM per un pacchetto ( a meno che sia una piccola
utility come un modulo per eselect o equivalente, necessario per supportare il
pacchetto nell'overlay). Se si ha bisogno dell'hosting di $UPSTREAM ,
rivolgersi a servizi come SourceForge, Berlios.de, o Gentoo Experimental.
</p>
</body>
</section>
<section>
<title>Gli Overlay sono Pubblici</title>
<body>
<p>
Non ci sono overlay "segreti".
</p>
<p>
Tutti gli overlay sono elencati nella pagina principale di overlays.g.o, e
chiunque è libero di scaricare i contenuti di un overlay.
</p>
<p>
Se si ha bisogno di un overlay segreto, noi non siamo il servizio adatto.
</p>
</body>
</section>
<section>
<title>Bug Tracking</title>
<body>
<p>
bugs.g.o è il OneTrueBugTrackingSystem(tm) (ndt : l'unico vero bug tracking
system), perfino per gli overlay.
</p>
</body>
</section>
<section>
<title>Spostare i Contributi dagli Overlay al Portage Tree</title>
<body>
<p>
Non impostare nulla che effettui automaticamente il commit dei contenuti di un
overlay al package tree principale di Gentoo. Mai.
</p>
<p>
Tutto il codice che viene preso da un overlay e che poi ne venga fatto il
commit al package tree principale di Gentoo è necessario che venga prima
completamente revisionato. Come persona che effettua il commit al main tree,
è <e>propria</e> responsabilità assicurarsi che il codice sia conforme agli
standard richiesti.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Amministrazione degli Overlay</title>
<section>
<body>
<p>
Solo il team di amministrazione di overlays.g.o (elencato nella pagina del
progetto overlay) ha l'accesso shell alla macchina overlays.g.o. Attualmente,
la gestione degli account (inclusa la reimpostazione delle password) deve
essere fatta attraverso il team di amministrazione degli overlay.
</p>
<p>
Se si ha bisogno di fare qualsiasi cosa al proprio overlay
(aggiungere/rimuovere un utente per esempio), si prega di chiedere su
#gentoo-overlays, e qualcuno vi aiuterà appena possibile.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Rimozione degli Overlay</title>
<section>
<body>
<p>
Gli Overlay possono essere rimossi a discrezione del team di amministrazione
degli overlay. Tranne circostanze eccezionali, rimuoveremo gli overlay
unicamente per le seguenti ragioni:
</p>
<ul>
<li>Gli overlay dei Progetti saranno rimossi se il progetto chiude.</li>
<li>Gli overlay degli sviluppatori saranno rimossi quando il proprietario si
ritira.</li>
</ul>
<p>
Le Circostanze Eccezionali possono includere:
</p>
<ul>
<li>Denuncie da altri sviluppatori circa i contenuti di un overlay che causino
problemi a pacchetti nel main tree.</li>
<li>Denuncie da altri sviluppatori circa i conteunti di un overlay che creino
rischi di sicurezza ai nostri utenti.</li>
</ul>
<p>
Tutte le circostanze eccezionali saranno discusse su gentoo-dev prima che
qualsiasi azione sia intrapresa.
</p>
<impo>
Gli overlay sono posti dove cambiamenti sperimentali possono essere fatti e
testati. Si prega di assicurarsi di aver compreso perchè le cose sono come sono
in un overlay prima di lamentarsi su ciò che sta succedendo!
</impo>
</body>
</section>
</chapter>
<chapter>
<title>Restrizioni su Nuovo Software</title>
<section>
<body>
<p>
Noi vogliamo sempre ascoltare le richieste di molti software che potremmo
offrire come parte del servizio. Si prega di tenere a mente che abbiamo bisogno
di mantenere il numero di software offerto al minimo, per ridurre il carico di
lavoro del team di amministrazione degli overlay.
</p>
<p>
Ogni nuovo software aggiunto al servizio dovrà *come minimo* essere conforme ai
seguenti requisiti. Si prega di non chiedere un software finchè non si è
controllato e assicurati che sia conforme ai requisiti.
</p>
<ul>
<li>Deve esserci un pacchetto funzionante per il software nel Portage.</li>
<li>Il pacchetto deve avere un maintainer attivo.</li>
<li>Il pacchetto deve avere una "credibile" storia di sicurezza alle spalle. In
particolare, pacchetti che hanno bisogno di aggiornamenti regolari per tappare
buchi di sicurezza saranno probabilmente respinti.</li>
<li>Se il pacchetto fornisce un sistema di bug-tracking, deve essere possibile
disabilitare il sistema di bug-tracking.</li>
</ul>
<p>
L'unico accesso consentito a overlays.g.o è mediante questi due meccanismi:
</p>
<ol>
<li>HTTP/HTTPS e Apache, e</li>
<li>rsync da dev.gentoo.org (coming in Phase 2)</li>
</ol>
<p>
Il meccanismo di sicurezza per overlays.g.o è mediante l'autenticazione base di
HTTP, su SSL. Noi usiamo sia il file htpasswd che htgroup per gestire chi può
fare il commit e dove.
</p>
<p>Un pacchetto può avere un controllo più accurato mediante i propri
meccanismi di sicurezza (es. lista di permessi di trac), ma il pacchetto deve
essere compatibile con questi accessi e queste restrizioni di sicurezza.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Errori e Omissioni</title>
<section>
<body>
<p>
Se si trova un errore in queste politiche, si prega di aprire un bug su
bugs.g.o, e assegnarlo a overlays@gentoo.org.
</p>
<p>
Tutti i cambiamenti nelle politiche saranno prima postati su gentoo-dev per
essere discussi.
</p>
</body>
</section>
</chapter>
</guide>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: policy-en.xml --]
[-- Type: text/xml; name="policy-en.xml", Size: 10658 bytes --]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/overlays/policy.xml,v 1.3 2006/12/16 13:37:17 genstef Exp $ -->
<guide link="/proj/en/overlays/policy.xml" lang="en">
<title>Gentoo Overlays Policy</title>
<author title="Author">
<mail link="stuart@gentoo.org">Stuart Herbert</mail>
</author>
<abstract>
This is the policy document governing the Gentoo Overlays service.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>Draft 1</version>
<date>2006-05-01</date>
<chapter>
<title>Introduction</title>
<section>
<body>
<p>
Here are the policies for the overlays.g.o service. If you host an overlay on
overlays.g.o, or if you participate in the administration of overlays.g.o, you
must follow these policies.
</p>
</body>
</section>
</chapter>
<chapter>
<title>What Is The Overlays.g.o Service?</title>
<section>
<body>
<p>
overlays.g.o provides a social workspace, for Gentoo projects and developers
to publish their Gentoo package overlays in one location, where it's easy for
devs and non-devs alike to collaborate.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Types Of Overlay</title>
<section>
<body>
<p>
overlays.g.o hosts two types of overlay:
</p>
<ul>
<li>overlays for Gentoo project teams</li>
<li>overlays for individual Gentoo developers</li>
</ul>
<p>
overlays.g.o does *not* host overlays owned by any other individuals at this
time.
</p>
</body>
</section>
<section>
<title>Project Overlays</title>
<body>
<p>
"Project overlays" are overlays owned by recognised Gentoo project teams.
Such teams are required to meet the definition of a project that you can find
in our metastructure document.
</p>
<p>
"Project overlays" will have the same name as the Gentoo project team. Each
project is only allowed a single overlay.
</p>
<p>
As far as this policy is concerned, project overlays are owned by the elected
lead(s) of the project.
</p>
</body>
</section>
<section>
<title>Developer Overlays</title>
<body>
<p>
"Developer overlays" are overlays owned by individual Gentoo developers.
These are the developers who have successfully taken the Gentoo developer
quizzes, and who have been given commit access to the main Gentoo package
tree.
</p>
<p>
Each "developer overlay" will have the same name as the developer who owns
the overlay. Each developer is only allowed a single overlay.
</p>
<p>
As far as this policy is concerned, developer overlays are owned by the
individual Gentoo developer who asked for the overlay to be hosted.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Responsibilities</title>
<section>
<body>
<ol>
<li>Infra are responsible for the platform (hardware + o/s) that overlays.g.o is hosted on.</li>
<li>The overlays project team is responsible for administering the overlays.g.o service, including responsibility for the software used to deliver the service (e.g. svn, trac).</li>
<li>Overlay owners are responsible for the contents of their overlays, and for the conduct of anyone who has commit access to their overlays.</li>
<li>Any individual committing to an overlay is responsible for his/her own actions.</li>
</ol>
</body>
</section>
</chapter>
<chapter>
<title>Creating Overlays</title>
<section>
<body>
<p>
Overlays are created at the request of whoever will be the owner of the
overlay.
</p>
<p>Overlays are optional; no Gentoo developer or project team is required to setup an overlay.
</p>
<p>
Gentoo developers are free to host their overlays somewhere else.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Commit Access To Overlays</title>
<section>
<body>
<p>
To be clear:
</p>
<ul>
<li>A "developer" is someone who has commit access to the main Gentoo package tree.</li>
<li>A non-developer is anyone who doesn't have commit access to the main Gentoo package tree. That includes other members of Gentoo staff.</li>
</ul>
<p>
Project overlays:
</p>
<ul>
<li>Any developer listed on a team's project page can have commit access to that team's overlay(s). Just ask the overlays admin team to sort you out with access.</li>
<li>Any dev not listed on a team's project page can have commit access, with the agreement of a member of the project team.</li>
<li>Any non-dev can have commit access to a team's overlay(s). The request for access has to come from the owner of the overlay.</li>
</ul>
<p>
Developer overlays:
</p>
<ul>
<li>Any Gentoo dev can ask for commit access, with the agreement of the overlay's owner.</li>
<li>Any non-dev can have commit access to a developer's overlay. The request for access has to come from the owner of the overlay.</li>
</ul>
<p>Common Requirements For Non-Devs</p>
<ul>
<li>The non-dev is required to have registered their nick on Freenode IRC first, and must provide a valid email address for our records.</li>
<li>If you're a non-dev, please don't ask the overlays team directly for access, as refusal often offends.</li>
</ul>
<note>
With trac + svn, it's possible to give commit access separately to trac (ie, the wiki), and svn.
</note>
</body>
</section>
</chapter>
<chapter>
<title>General Rules For Overlays</title>
<section>
<body>
<p>
We're deliberately trying to keep the rules on overlays to a minimum. Please,
don't abuse the service, and force us to add more rules :(
</p>
</body>
</section>
<section>
<title>What You Can And Cannot Store On overlays.g.o</title>
<body>
<p>
overlays.g.o is for hosting package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted.
</p>
<p>
It's not to be $UPSTREAM for a package (unless it's a small utility like an eselect module or equivalent, required to support the packages in the overlay). If you need $UPSTREAM hosting, look at somewhere like SourceForge, Berlios.de, or Gentoo Experimental.
</p>
</body>
</section>
<section>
<title>Overlays Are Public</title>
<body>
<p>
There are no "secret" overlays.
</p>
<p>
All overlays are listed on the frontpage of overlays.g.o, and anyone is free to download the contents of an overlay.
</p>
<p>
If you need a secret overlay, we're not the service for you.
</p>
</body>
</section>
<section>
<title>Bug Tracking</title>
<body>
<p>
bugs.g.o is the OneTrueBugTrackingSystem(tm), even for overlays.
</p>
</body>
</section>
<section>
<title>Moving Contributions From Overlays To The Portage Tree</title>
<body>
<p>
Don't set up anything to automatically commit the contents of an overlay to the main Gentoo package tree. Ever.
</p>
<p>
Any code you take from an overlay and commit to the main Gentoo package tree needs to be thoroughly reviewed first. As the person committing the code to the main tree, it's <e>your</e> responsibility to ensure that the code meets the required standards.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Administration Of Overlays</title>
<section>
<body>
<p>
Only the overlays.g.o administration team (listed on the overlays project
page) have shell access into the overlays.g.o box. At the moment, account
management (including resetting passwords) has to be done through the overlays
administration team.
</p>
<p>
If you need anything doing to your overlay (adding/removing a user f.ex),
please ask in #gentoo-overlays, and someone will help you as soon as possible.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Removal Of Overlays</title>
<section>
<body>
<p>
Overlays can be removed at the discretion of the overlays administration team.
Except for exceptional circumstances, we'll only remove overlays for the
following reasons:
</p>
<ul>
<li>Project overlays will be removed if the project closes down.</li>
<li>Developer overlays will be removed when its owner retires.</li>
</ul>
<p>
Exceptional circumstances may include:
</p>
<ul>
<li>Complaints from other developers about the contents of an overlay causing problems for packages in the main tree.</li>
<li>Complaints from other developers about the contents of an overlay creating a security risk to our users.</li>
</ul>
<p>
All exceptional circumstances will be discussed on gentoo-dev before action is
taken.
</p>
<impo>
Overlays are places where experimental changes can be made and tested. Please make sure you understand why things are the way they are in an overlay before you make a complaint about what's going on!
</impo>
</body>
</section>
</chapter>
<chapter>
<title>Restrictions On New Software</title>
<section>
<body>
<p>
We're always willing to listen to requests for different software we could
offer as part of the service. Please bear in mind that we need to keep the
amount of software offered to a minimum, to reduce the workload on the overlays
administration team.
</p>
<p>
Any new software added to the service will have to meet the following
requirements *as a minimum*. Please don't ask for a piece of software unless
you've checked and made sure it meets these requirements.
</p>
<ul>
<li>There must be a working package for the software in Portage.</li>
<li>The package must have an active maintainer.</li>
<li>The package must have a "credible" security history. In particular, packages that need regular updating to fix security holes are likely to be rejected.</li>
<li>If the package provides a bug-tracking system, it must be possible to disable the bug-tracking system.</li>
</ul>
<p>
The only access to overlays.g.o is via these two mechanisms:
</p>
<ol>
<li>HTTP/HTTPS and Apache, and</li>
<li>rsync from dev.gentoo.org (coming in Phase 2)</li>
</ol>
<p>
The security mechanism for overlays.g.o is via HTTP basic auth, over SSL. We use both htpasswd and htgroup files to manage who can commit where.
</p>
<p>A package can have finer-grained control via its own security mechanisms (e.g. trac's permissions list), but the package must be compatible with these access and security restrictions.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Errors And Omissions</title>
<section>
<body>
<p>
If you find a fault with this policy, please file a bug on bugs.g.o, and
assign it to overlays@gentoo.org.
</p>
<p>
All policy changes will first be posted to gentoo-dev for discussion.
</p>
</body>
</section>
</chapter>
</guide>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
next prev parent reply other threads:[~2008-06-08 18:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 13:43 [gentoo-docs-it] richiesta assegnazione http://www.gentoo.org/proj/en/overlays/policy.xml Marcello Magaldi
2008-06-08 14:23 ` Davide Cendron
2008-06-08 18:11 ` Marcello Magaldi [this message]
2008-06-17 18:15 ` Davide Cendron
2008-06-25 21:39 ` Marcello Magaldi
2008-06-29 16:23 ` Marcello Magaldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484C20E3.8070607@gmail.com \
--to=magowiz@gmail.com \
--cc=gentoo-docs-it@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox