Come aumentare il numero di persone coinvolte nel miglioramento di X.org per Ubuntu? [chiuso]

18

In Ubuntu, X è uno dei pezzi più critici nello stack. Di conseguenza, riceviamo un numero di domande e segnalazioni di bug a riguardo, probabilmente circa 100 volte di quante ne abbiamo manodopera.

Canonical sta assumendo ingegneri addizionali per lavorare su X, il che aiuterà, ma ci sono ancora molte cose che non rientrano nell'ambito di ciò che Canonical può fare, quindi ritengo che sia davvero importante coinvolgere una comunità forte nel miglioramento di X in Ubuntu, in particolare per ottenere risposte a tutte queste enormi quantità di segnalazioni di bug, triaging e (si spera) risolti.

Tuttavia, è difficile trovare persone che lavorino su X o convincere le persone che per loro è utile investire il loro tempo. Come suggeriresti di incoraggiare le persone a partecipare, chi potrebbe altrimenti non pensare di lavorare su X?

    
posta Bryce 10.08.2010 - 01:42

5 risposte

7

Beh, molto di tutto questo lo rende facile e accessibile alla gente per scoprirlo. Quindi da quello che ricordo con bug triage in origine non c'era molto aiuto proveniente dalla comunità. Poi, quando alcune pagine wiki che spiegavano i processi regolari nei bug triaging e alcuni giorni di bug, coinvolgevano molti più membri della comunità. Inoltre, se puoi iniziare un'attività regolare da fare per la comunità e offrire aiuto a coloro che la provano, ti interesserà.

Se hai bisogno di aiuto con l'attività, puoi inviarmi un'e-mail e aiutarti a organizzarla.

Quindi la mia risposta è creare una pagina wiki con domande e comandi per ottenere buone informazioni sul triage di bug per coinvolgere le persone in questo.

Per lo sviluppo è un grosso problema. Le risorse di Xorg e Kernel richiedono competenze di programmazione di basso livello per la maggior parte delle funzioni di bug fixing e implementazione. Quindi devi indirizzare un gruppo specifico di programmatori e farli interessare. Non ho suggerimenti qui tranne chiedere un po 'e vedere chi si blocca in # ubuntu-x e chiedere loro se possono aiutare.

    
risposta data Shane Fagan 23.08.2010 - 00:22
12

Il motivo per cui X non ha molto lavoro è che richiede un'enorme quantità di conoscenza su come GPU, memoria ecc. funzionano così come la familiarità con la base di codice X.org e in parte la programmazione del kernel. Non è una cosa banale entrare e dal punto di vista della comunità, chi è interessato a lavorare con i driver X o X probabilmente lo sta già facendo. Attualmente non vi è alcuna motivazione per uno sviluppatore che lo sviluppatore possa lavorare su Xorg oltre all'interesse personale.

La cosa che la community ha che gli sviluppatori di X.org non necessariamente hanno, è l'accesso a un'ampia varietà di hardware. Avere persone che sono disposte a dedicare il tempo a scrivere "buone" segnalazioni di bug e testare driver e parti dello stack prima di una release probabilmente aiuteranno gli ingegneri più di ogni altra cosa.

Attualmente esiste un repository Xorg che utilizzo per testare i driver sul mio sistema stabile. È abbastanza facile ripristinare un singolo pacchetto dopo aver finito i test. Tuttavia, l'unico altro modo che possiamo testare è quello di creare X da soli o installare il repository di edgers che costruisce da upstream. Questo fa una sostituzione X all'ingrosso per quanto ne so. Questo significa che è un approccio tutto o niente al test di X.

Avere un modo per avere 2 versioni di X (e abbastanza facilmente scegliere) quale si vuole usare consentirebbe ai tester non solo di testare X, ma successivamente di tornare a un Xorg funzionante in modo che possano inviare il bug report.

    
risposta data user543 10.08.2010 - 04:24
12

Parlando come uno sviluppatore che è casualmente interessato a X, ecco i miei problemi:

  1. Ho solo accesso a una manciata di schede grafiche e sospetto che la maggior parte delle persone abbia accesso a una sola. Quindi non posso fare molto per la stragrande maggioranza dei bug, che sarà sempre su "qualche altra carta".

  2. A differenza della maggior parte dei pacchetti, non riesco a creare banalmente un ambiente di test per una nuova versione del driver; le macchine virtuali hanno i loro driver X.

  3. Non posso aggiornare facilmente al driver più recente, provarlo e poi ripristinarlo. Ciò scoraggia la sperimentazione (perché se qualcosa va storto potrei anche essere ammuffito); ostacola anche i test di regressione.

  4. L'ultima volta che ho guardato, con successo l'applicazione di una patch, la compilazione e l'esecuzione di X è stata difficile da fare, ho fatto un passo in tutto il gestore dei pacchetti, richiesto i moduli del kernel e anche un passaggio irreversibile.

  5. Oggigiorno, i driver X dividono il loro codice tra kernel, Mesa, udev (per impostazioni e valori predefiniti) e driver userland. Il che significa che anche le patch vengono divise ...

Quindi immagino che la risposta sia rendere l'applicazione e il ripristino delle modifiche qualcosa che viene gestito dal gestore dei pacchetti e facile da ripristinare quando interrompe il sistema.

Inoltre, un sistema come DKMS dovrebbe essere visto per i driver X; se potessi facilmente correggere / compilare / testare / disinstallare, ad esempio, il driver di input per il mio touchscreen senza dover ricostruire l'intero aggeggio monolitico (con la sua minaccia di rendere X completamente inutilizzabile), otterresti un contributo più casuale e mi motiverei a guarda i bug triaging e test patch relativi a quel bit di hardware.

    
risposta data jbowtie 10.08.2010 - 06:05
4

Per completare ciò che ha detto jbowtie, aggiungo che, come triager di bug, trovo gli X bug molto difficili da affrontare, semplicemente perché X è una bestia molto complessa. Ciò si riflette nella complessità della pagina wiki di risoluzione dei problemi . Ciò che sicuramente aiuterebbe è una sorta di programma di mentorship per i membri di BugSquad per imparare come gestire meglio i bug di X. Forse fare un abbraccio bug intorno ad esso? O una sessione di formazione pratica in # ubuntu-classroom?

    
risposta data Bruno Girin 21.08.2010 - 14:31
1

È difficile migliorare X.org quando molti utenti usano driver proprietari che sostituiscono porzioni dello stack grafico e poi guardano al team X.org quando un aggiornamento del kernel / l'aggiornamento di X.org interrompe l'installazione del driver.

Anche molti dei discorsi su "Non ho tutte le carte disponibili" sono validi.

La programmazione grafica è piuttosto difficile se non sei un buon programmatore. Il debug può essere un vero problema, soprattutto se non riesci a vedere cosa sta succedendo.

    
risposta data Broam 23.08.2010 - 20:13

Leggi altre domande sui tag