On Sun, 12 Nov 2006 10:56:19 +0100
Maurizio Lemmo - Tannoiser <tannoiser@xxxxxxxxxxx> wrote:
> * domenica 12 novembre 2006, alle 09:47, Ivan Sergio Borgonovo
> scrive:
> > http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html
> >
> > Allora vedo di ri-interpretare:
> > testing per sua natura ha ancora un sacco di cazzi "nascosti"
> > però se ci accorgiamo di un problema lo metteremo a posto in tempi
> > comparabili a quelli di stable.
> >
> > ???
>
> Dovresti imparare anche a *leggere* oltre che a incollare.
Ma non mi sembra di aver contraddetto ne te ne il primo comunicato.
> L'obbiettivo di fare i security per testing viene proposto *ogni
> volta*, ma per X motivi, non si riesce mai a fare.
[snip]
> Hai letto il readme del repository che hai copiaincollato?
No. Avevo letto la notizia. E la notizia l'avevo interpretata come ti
ho detto.
E` vero che il comunicato non è "crystal clear" e davanti a qualche
cosa non "crystal clear" uno non fa progetti... e infatti non ne ho
fatti. Però il comunicato "invoglia" a fare progetti e il fatto che
questi tentativi siano stati già fatti in passato con identici
risultati non è bello.
Stò criticando solo quella comunicazione e non gli sforzi di chi ci
sta dietro. Ovviamente se in base a questo tipo di info basi
decisioni lavorative dovresti andare oltre a quel comunicato prima di
prendere decisioni in merito... ma questo è un altro paio di maniche.
> L'archivio e` fermo da giugno, il sito e` vuoto, e per la sua
> natura, e` un progetto che difficilmente riuscira` mai a essere
> completato - penso.
E` un caso di botte piena moglie ubriaca. Dipende da quanto vuoi la
moglie ubriaca o la botte piena.
Epperò così mi sembra tu stia dando dei cretini a chi ci ha provato
più volte di fronte a un sicuro fallimento se la cosa è così ovvia.
> Debian ha stable per queste cose. full stop.
Ma non c'è dubbio.
Quello che dico è che in testing è lecito che un pacchetto cambi di
versione e eg. il software che ci hai sviluppato sopra o la tua cfg
custom si sminchino, in stable no.
E` un bel constrain non avendo il quale ad esempio una delle
situazioni da te descritte può avere come soluzione più economica
l'upgrade a una nuova versione che non ha vulnerabilità anzichè lo
studio di un patch custom che verrà superato "domani".
Se togliere questo constrain sia o meno sufficiente per rendere il
problema affrontabile è altra cosa visto che te e chi si è proposto di
farlo, persone indubbiamente più qualificate di me in questo ambito
avete pareri diversi, quindi non esprimo giudizio.
Nel campo dell'ipotetico, scenari possibili:
- testing con sicurezza e ovviamente "non stabile"
Sviluppo soft con una release pianificata in prossimità della data di
switch di testing in stable.
Lo sviluppo è su tempi "lunghi": 6 mesi.
In questi 6 mesi avrò l'extra burden di stare attento a potenziali
sminchi per cambiamento di versione... ma avrò comunque un occhio sui
vari pacchetti e le nuove versioni che sono "mission critical" anche
nell'eventualità che salti fuori qualche cosa di nuovo che possa
sfruttare e che verrà integrato nella prossima stable.
Ad ogni modo non sono in produzione...
La release tarda di 2 mesi... starò attento per 2 mesi... non per 8,
12 o 15, quanto è l'intervallo tra la release di una stable e l'altra.
La cosa diventa tanto più intrigante quanto il tempo di release del
tuo soft si avvicina al tempo di release della nuova stable.
- testing senza sicurezza e ovviamente "non stabile"
... le conseguenze di avere del soft pronto che gira solo con
pacchetti nuovi e senza copertura di sicurezza da mandare in
produzione sono ovvie...
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
|