page27
Mundo Libre
artigo
Contanto que você possa testar as alterações, você pode adiar a necessidade de entender plenamente o funcionamento do código no Windows.
Olhei ao longo do código, mas não o entendi direito e, honestamente, nem queria. Por outro lado, foi fácil ver que a alteração era razoável e útil para muitos casos. Então, eu submeti no Gerrit, para ver se a minha alteração poderia se revista e aprovada. Se posso esgueirar-me em um build diário, então talvez pudesse convencer alguém a experimentar meu patch. Eu o apresentei e esperei por algum comentário. Três dias depois, Caolan McNamara da Red Hat revisou e aceitou o patch. Eu pessoalmente acho que o Arch Linux é uma distro melhor do que o Fedora, mas sou muito grato pelos investimentos úteis que a Red Hat tem feito para o projeto do LibreOffice.
Uma vez que meu patch entrou nas builds diárias, enviei um e-mail ao tester, perguntando se ele poderia avaliá-lo, mas ele respondeu que não tinha tempo.
Estava novamente preso e frustrado. Não podia saber se a mudança havia corrigido o bug, o que me deixou desconfortável para pedir um patch para ser revisado 3 vezes. Correções às cegas para versões estáveis geralmente não são uma boa maneira de trabalhar.
Também não sabia como apresentar alterações a qualquer coisa que não fosse o branch master. A wiki do LibreOffice é ótima para novos desenvolvedores, mas não cobrem esse tópico específico. Então decidi pedir ao Caolan se ele poderia submetê-los ao Gerrit para tê-los antes do lançamento da release 4.2.3. Caolan fez isso e ainda me enviou os “feitiços” para uso do Git, para que eu mesmo possa fazê-lo no futuro.
Com alguns comentários do Norbert e do Miklos Vajna, o patch entrou no release 4.2.3. Fiquei muito feliz, mas não por muito tempo, pois logo percebi que a versão final do 4.2.3 RC já havia sido lançada. Você ainda pode distribuir as mudanças para o Git, mas isso não faz diferença, pois ele é o equivalente digital do air guitar.