Descubra o que faz
Veja o código e descubra o que ele deve fazer. Se você não precisa, por que está lá? Há algo mais fazendo seu trabalho agora? Se é algo que ainda está em demanda, por que não está funcionando para você?
Você verá frequentemente software específico de hardware escrito para casos extremos como uma única variedade de laptops (por exemplo, existem dezenas de vários drivers de hardware do Thinkpad).
De acordo com o leia-me , o driver cobre sem fio, LEDs, bluetooth, 3G e luz de fundo. Para mim, parece algo que você (ou outras pessoas) pode querer, então, despejar ou colocar na lista negra por padrão pode não ser desejável.
Descubra como foi instalado no seu computador
De onde veio? É puxado para dentro do kernel? É uma atração do Ubuntu? Em última análise, isso decidirá onde você precisa fazer sua reclamação.
Com problemas no nível do kernel, realmente ajuda a testar o kernel vanilla estável mais recente. Você pode pegar uma cópia do repositório da linha principal, embora provavelmente descubra que há incompatibilidades de versão do GCC com certos drivers apenas binários (eu tenho, com a nvidia), portanto não é algo que você queira executar o tempo todo na IMO.
Se o problema persistir com um kernel vanilla, adicione um bug a montante e vincule-o ao bug da Barra de Ativação e rastreie-o também para trás. Um bom bug com link duplo ajudará todos a permanecer na mesma página.
Nesse caso, parece que é um driver do kernel na árvore (ou seja, sua fonte é inserida no repositório do kernel e incorporada).
Encontre a pessoa ou pessoas responsáveis por ela
Não é razoável apenas despejar um bug no Launchpad e esperar que ele encontre a pessoa certa. Eu diria que apenas uma pequena parte dos desenvolvedores rastreia seus bugs através deles, então você precisa encontrar os mantenedores do software e entrar em contato.
Pode parecer rude começar a enviar emails para as pessoas, mas o software é o bebê delas. Se não estiver funcionando, acho que eles gostariam de saber. Nove vezes em dez, eles também o ajudarão a identificar o problema.
Se ainda for mantido, obtenha instruções de depuração. Verifique se o seu hardware é compatível.
Se não for mantido, e você pode confirmar que, com o antigo mantenedor, registre um bug no kernel alertando as pessoas de que há uma parte do código rotando e que está causando problemas.
Sugira ação para as pessoas certas
Quando você souber qual é o problema, não guarde para si. Certifique-se de agir sobre seus erros.
Se é algo que pode ser corrigido no driver, persiga as pessoas no kernel para obter a nova versão no lançamento do desenvolvimento. Pergunte sobre o backport para 2.6.35 para usuários existentes do Ubuntu. Converse com a equipe do Kernel sobre como realizar as alterações no kernel do Maverick (embora você possa não ter sorte lá).
Se estiver apodrecendo, empurre os desenvolvedores principais do kernel para retirá-lo de seus repositórios. Peça aos desenvolvedores da equipe do kernel do Ubuntu para removê-lo de seus repositórios. No mínimo, solicite a inclusão na lista negra (como alguns módulos foram removidos à força pelo Ubuntu no passado).
Se você obtiver uma boa resposta quanto à fixação / destruição do driver, deve ser possível corrigi-lo no kernel Natty final (que ainda está em -nextestágio no repositório de kernel adequado).
O ponto que estou tentando entender é que quando você faz sua própria triagem e conversa com as pessoas certas, as coisas recebem muito mais atenção e têm uma chance maior de um bom resultado final.
E de modo algum pare se você vir outra pessoa com o mesmo problema. Assine, comente o bug deles, pergunte o que eles encontraram, pergunte o que eles fizeram sobre isso ... E então continue. Não confie neles para resolver o seu problema.
É assim que o código aberto deve funcionar. Colaboração através de uma comunicação boa e aberta. Comunique bem o seu problema, ajude onde puder e terá uma boa chance de obter um software de melhor qualidade.