Lines Matching refs:una
35 Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
47 Sebbene si attenga allo standard ISO C89, esso utilizza una serie di
81 I sorgenti del kernel Linux hanno una vasta base di documenti che vi
86 con lo spazio utente, è raccomandabile che inviate una notifica o una
91 Di seguito una lista di file che sono presenti nei sorgente del kernel e che
95 Questo file da una piccola anteprima del kernel Linux e descrive il
101 Questo file fornisce una lista dei pacchetti software necessari
115 Questo file descrive dettagliatamente come creare ed inviare una patch
163 kernel, e spiega cosa fare se si vuole che una modifica venga inserita
172 Una buona introduzione che descrivere esattamente cos'è una patch e come
177 ReStructuredText (ReST), come questo. Esso include una completa
213 la compilazione del kernel e l'applicazione di una modifica.
221 È un buon posto da cui iniziare. Esso presenta una lista di problematiche
228 Prima di apportare una qualsiasi modifica al codice del kernel Linux,
257 - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
271 accettato dopo la -rc1 poiché non esistono rischi di una possibile
276 una lista di discussione pubblica per un'ulteriore revisione.
280 L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.
289 legato allo stato dei bachi e non ad una cronologia preventiva."*
327 in uso, o file di patch pubblicate come una serie quilt.
331 Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad
332 una revisione che inizialmente avviene tramite liste di discussione (vedere la
379 al corrente della vostra presenza. Riparare bachi è una delle migliori vie per
401 É caldamente consigliata una ricerca in questi archivi sul tema che volete
405 Molti dei sottosistemi del kernel hanno anche una loro lista di discussione
406 dedicata. Guardate nel file MAINTAINERS per avere una lista delle liste di
424 ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
439 caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e
450 Quando inviate una modifica che volete integrare, sarà valutata esclusivamente
475 In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili,
476 ci saranno sempre opinioni differenti sull'utilità di una modifica.
480 una soluzione che è corretta.
483 semplicemente una lista con dozzine di cose che dovreste correggere.
493 sviluppo aziendali. Qui di seguito una lista di cose che potete provare a
500 - "Qui una modifica che spiega cosa sto cercando di fare."
502 - "Qui una serie di piccole modifiche che.."
515 - "Ecco una patch da 5000 righe che.."
517 - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"
526 basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna
528 Linux e che hanno espresso una personale opinione hanno avuto esperienze
542 buttati lì tutti in una volta. Le modifiche necessitano di essere
550 stesso momento in una lista di discussione, il più delle volte la vostra serie
558 manutentore con a mala pena una seconda occhiata. Invece, una modifica da
564 non va. È molto più facile annullare le modifiche una per una che
565 dissezionare una patch molto grande dopo la sua sottomissione (e rompere
582 problema che uno sta risolvendo. Vogliono vedere una soluzione
585 Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione
586 elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere