Como conseguir mais pessoas envolvidas na melhoria do X.org para o Ubuntu? [fechadas]

Question

No Ubuntu, o X é uma das partes mais críticas da pilha. Como tal, recebemos uma tonelada de perguntas e relatórios de erros sobre isso, provavelmente cerca de 100 vezes mais do que temos mão-de-obra para manusear.

A Canonical está contratando engenheiros adicionais para trabalhar no X, o que ajudará, mas ainda há muitas coisas fora do escopo do que a Canonical pode fazer, então eu sinto que é realmente importante ter uma comunidade strong envolvida na melhoria do X em Ubuntu, particularmente em torno de obter todas essas quantidades massivas de relatórios de bugs respondidos, triados e (esperançosamente) resolvidos.

No entanto, é difícil encontrar pessoas para trabalhar no X ou convencer as pessoas de que vale a pena investir seu tempo nisso. Como você sugeriria incentivar as pessoas a se envolverem, que poderiam não estar pensando em trabalhar no X?

    

Answer 1

Bem como tudo, muito disso é tornar mais fácil e acessível para as pessoas descobrirem sobre isso. Então, pelo que eu me lembro com a triagem de bugs, originalmente não havia muita ajuda vindo da comunidade. Então, quando algumas páginas wiki explicando os processos regulares de triagem de bugs e alguns dias de bugs, muitos membros da comunidade se envolveram. Além disso, se você puder iniciar uma atividade regular para a comunidade e oferecer ajuda àqueles que a experimentarem, você terá algum interesse.

Se você precisar de ajuda com a atividade, envie-me um e-mail e não ajude a organizá-la.

Então minha resposta é criar uma página wiki com perguntas e comandos para obter boas informações sobre triagem de bugs para envolver as pessoas nisso.

Para o desenvolvimento, é um grande problema. As coisas do Xorg e do Kernel requerem habilidades de programação de baixo nível para a maioria dos recursos de correção e implementação de bugs. Então você tem que direcionar um grupo específico de programadores e levá-los interessados. Eu não tenho nenhuma sugestão aqui, exceto perguntar um pouco e ver quem fica no # ubuntu-x e perguntar se eles podem ajudar.

    

Answer 2

A razão pela qual o X não recebe muito trabalho é que ele requer uma enorme quantidade de conhecimento sobre como a GPU, a memória etc. funcionam, bem como a familiaridade com a base de código do X.org e até certo ponto com a programação do kernel. Não é uma coisa trivial para entrar e de uma perspectiva de comunidade aqueles que estão interessados ​​em trabalhar em drivers X ou X provavelmente já estão fazendo isso. Atualmente, não há motivação para um desenvolvedor trabalhar com o Xorg além do interesse pessoal.

O que a comunidade tem que os desenvolvedores do X.org não têm necessariamente é o acesso a uma grande variedade de hardware. Ter pessoas que estão dispostas a gastar o tempo para escrever 'bons' relatórios de bugs e testar drivers e partes da pilha Xorg antes de uma versão provavelmente vai ajudar os engenheiros mais do que qualquer coisa.

Atualmente, há um repositório de edutores do Xorg que eu uso para testar drivers no meu sistema estável. É muito fácil reverter um único pacote depois de terminar o teste. No entanto, a única outra maneira que podemos testar é construir o próprio X ou instalar o repositório de edgers que é construído a partir do upstream. Isso faz uma substituição de X por atacado, tanto quanto eu posso dizer. Isso significa que é uma abordagem de tudo ou nada para testar o X.

Ter uma maneira de ter 2 versões do X (e facilmente escolher) qual delas você deseja usar permitiria que os testadores não apenas testassem o X, mas subsequentemente voltassem a trabalhar com o Xorg para que eles pudessem enviar o relatório do bug.

    

Answer 3

Falando como um desenvolvedor que está interessado em X, aqui estão os meus problemas:

1. Eu só tenho acesso a um punhado de placas gráficas e suspeito que a maioria das pessoas só tem acesso a uma. Assim, não posso fazer muito pela grande maioria dos bugs, que sempre estarão em "algum outro cartão".

2. Diferentemente da maioria dos pacotes, não posso criar trivialmente um ambiente de teste para uma nova versão do driver; máquinas virtuais têm seus próprios drivers X.

3. Não consigo atualizar facilmente para o driver mais recente, testá-lo e depois reverter. Isso desencoraja a experimentação (porque, se algo der errado, eu poderia muito bem ser bricked); também dificulta o teste de regressão.

4. A última vez que eu olhei, aplicando com sucesso um patch, compilando e rodando o X era difícil de fazer, percorrendo todo o gerenciador de pacotes, módulos do kernel requeridos para serem corrigidos também, e foi praticamente um passo irreversível. / p>

5. Hoje em dia, os drivers X dividem seu código entre kernel, Mesa, udev (para configurações e padrões) e drivers de usuário. O que significa que os patches também são divididos ...

Então, eu acho que a resposta é fazer com que a aplicação e a reversão de alterações seja algo que é gerenciado pelo gerenciador de pacotes e fácil de recuperar quando ele quebra o sistema.

Além disso, um sistema como o DKMS deve ser analisado para drivers X; se eu pudesse facilmente corrigir / compilar / testar / desinstalar, digamos, o driver de entrada para minha touchscreen sem ter que reconstruir toda a geringonça monolítica (com sua ameaça de tornar X completamente inutilizável), você teria uma contribuição mais casual e me motivaria a olhar para triagem de bugs e testar patches relacionados a esse bit de hardware.

    

Answer 4

Para complementar o que o jbowtie disse, eu acrescentaria que, como um triager de bugs, acho muito difícil lidar com X bugs, simplesmente porque X é uma besta muito complexa. Isso se reflete na complexidade da página wiki de solução de problemas . O que definitivamente ajudaria é uma espécie de programa de orientação para os membros do BugSquad aprenderem a lidar melhor com os bugs do X. Talvez faça um dia de insetos em torno disso? Ou uma sessão de treinamento prático em # ubuntu-classroom?

    

Answer 5

É difícil melhorar o X.org quando muitos usuários usam drivers proprietários que substituem partes da pilha de gráficos e, em seguida, olham para a equipe do X.org quando uma atualização do kernel / X.org quebra a instalação do driver.

Muita conversa sobre "Eu não tenho todas as cartas disponíveis" também é válida.

A programação gráfica é bastante difícil se você não for um bom programador. A depuração pode ser uma dor real, especialmente se você não puder ver o que está acontecendo.