Come coinvolgere più persone nel miglioramento di X.org per Ubuntu? [chiuso]

In Ubuntu, X è uno dei pezzi più critici nello stack. In quanto tale, riceviamo una TONTA di domande e segnalazioni di bug al riguardo, probabilmente circa 100 volte quante ne abbiamo di manodopera.

Canonical sta assumendo altri ingegneri per lavorare su X, il che aiuterà, ma ci sono ancora molte cose che esulano dallo scopo di ciò che Canonical può fare, quindi penso che sia davvero importante avere una forte comunità coinvolta nel miglioramento di X in Ubuntu, in particolare ottenere risposte, verifiche e (si spera) risolte tutte queste enormi quantità di segnalazioni di bug.

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

Bene, come tutto ciò che lo rende molto facile e accessibile per le persone a scoprirlo. Quindi, da quanto ricordo inizialmente con il triage di bug, non c'era molto aiuto dalla comunità. Poi, quando alcune pagine wiki che spiegano i processi regolari nel triaging dei bug e alcuni giorni di bug hanno coinvolto molti più membri della community. Inoltre, se puoi avviare un'attività regolare per la comunità e offrire aiuto a coloro che la provano, otterrai un certo interesse.

Se hai bisogno di aiuto con l'attività, puoi inviarmi un'e-mail e ricevere aiuto nell'organizzazione.

Quindi la mia risposta è creare una pagina wiki con domande e comandi per ottenere informazioni utili sul triage dei bug e coinvolgere le persone.

Per lo sviluppo è un grosso problema. Le cose di Xorg e Kernel richiedono competenze di programmazione di basso livello per la maggior parte delle funzionalità di correzione e implementazione dei bug. Quindi devi indirizzare un gruppo specifico di programmatori e farli interessare. Non ho alcun suggerimento qui se non chiedere un po 'in giro e vedere chi esce in # ubuntu-x e chiedere loro se possono aiutare.

Il motivo per cui X non ottiene molto lavoro è che richiede un'enorme quantità di conoscenze su come funzionano le GPU, la memoria, ecc., Nonché la familiarità con la base di codice X.org e in una certa misura la programmazione del kernel. Non è cosa da poco entrare e dal punto di vista della comunità coloro che sono interessati a lavorare su driver X o X probabilmente lo stanno già facendo. Al momento non esiste alcuna motivazione per uno sviluppatore affinché lo sviluppatore lavori su Xorg a parte l'interesse personale.

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

Attualmente esiste un repository di Xorg Edgers che utilizzo per testare i driver sul mio sistema stabile. È abbastanza facile ripristinare un singolo pacchetto dopo aver terminato i test. Tuttavia, l'unico altro modo che possiamo testare è o costruire X tu stesso o installare il repository di edger che costruisce da monte. Questo fa una sostituzione X all'ingrosso, per quanto posso dire. Ciò significa che è un approccio tutto o niente al test di X.

Avere un modo per avere 2 versioni di X (e scegliere abbastanza facilmente) quale si desidera utilizzare consentirebbe ai tester di testare non solo X, ma di tornare a un Xorg funzionante in modo che possano inviare la segnalazione di bug.

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

1. Ho accesso solo a una manciata di schede grafiche e sospetto che la maggior parte delle persone abbia accesso solo a una. 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 riesco facilmente ad aggiornare all'ultimo driver, testarlo, quindi ripristinare. Questo scoraggia la sperimentazione (perché se qualcosa va storto potrei anche essere murata); ostacola anche i test di regressione.

4. L'ultima volta che ho guardato, applicare con successo una patch, compilare ed eseguire X era difficile da fare, ho fatto un passo in tutto il gestore dei pacchetti, ho richiesto anche la patch dei moduli del kernel ed è stato praticamente un passo irreversibile.

5. Al giorno d'oggi, i driver X dividono il loro codice tra kernel, Mesa, udev (per impostazioni e impostazioni predefinite) e driver per l'utente. Ciò significa che anche le patch vengono divise ...

Quindi suppongo che la risposta sia rendere l'applicazione e il ripristino delle modifiche qualcosa che è gestito dal gestore dei pacchetti e facile da recuperare da quando si rompe il sistema.

Inoltre, un sistema come DKMS dovrebbe essere considerato per i driver X; se potessi facilmente patchare / compilare / testare / disinstallare, per 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 motiverai a esaminare i bug di triaging e testare le patch relative a quel bit di hardware.

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

È difficile migliorare X.org quando molti utenti utilizzano driver proprietari che sostituiscono parti dello stack grafico e guardano quindi al team X.org quando un aggiornamento del kernel / aggiornamento X.org interrompe l'installazione dei driver.

Sono valide anche molte discussioni su "Non ho tutte le carte disponibili".

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