Procedimentos para submeter colaboração

[Waldir Paim]

Para que possamos colaborar de forma mais efetiva, abrangente e assertiva, surge a necessidade de padronizamos a colaboração, dessa forma o colaborador teria parâmetros e rotinas a serem executadas para submeter um código para avaliação e possível incorporação ao código oficial.

Preciso saber, como diria a Luna;

1- Qual o procedimento correto?

2- Se o código do trunk1 não será mais atualizado preciso dizer que o código submetido não será mais para ele?

3- Devo fazer um test case?

4- Posso submeter de outra forma, usando o próprio SVN?

5- O SVN será sempre o repositório oficial, não tem  nem se que de longe a possibilidade de usar o Github (maravilha de commit local)?  "até o google sugere migrar para ele".

Waldir

[Daniel Simoes]

1 - O ideal é você discutir as necessidades da modificação aqui no fórum... antes mesmo de implementá-las... Isso evita situações como: Já enviaram correção semelhante, a equipe de commiter discordas da maneira como foi implementado

2 - Se algum commiter quiser, pode enviar correções para o Trunk1... mas acredito que no momento, todos já optaram por não o fazerem, pois já estão usando o Trunk2 em produção

3 - Dependendo da Unit isso seria ótimo... veja a pasta "Testes"

4 - Apenas usuários convidados a serem commiter podem submeter ao SVN...  Eles atingem esse privilégio através da meritocracia e reconhecimento da equipe atual

5 - Se depender de mim... o ACBr nunca usará Git... tive péssimas experiencias de uso com ele: cada comando simples no SVN é traduzido em 3 comandos do Git (ou mais)... Seria um inferno lidar com os inúmeros Pull Requests..

 

[Isaque Pinheiro]

Complementando 
6 - Mandou vários postes cada um com uma unit e uma contribuição, melhor se fosse um único post, nele explicando o motivo da colaboração juntamente com a unit da mesma, toda contribuição é bem vinda, mas nem sempre podemos adivinhar a necessidade da mesma se não nos for explanada e justificada, assim podemos avalia-la para ser disponibilizada no repositório, essa é a finalidade do fórum de discussão.

[Waldir Paim]

Daniel,

Sobre a discussão é um pouco antiprodutivo para colaborar com o desenvolvimento pois hoje o tempo de cada vez mais escasso, pois sem o código produto nem posso se quer defende-lo.

Acredito que cada um tem seu ponto de vista e vai defende-lo da melhor forma possivel.

Não tenho pretenções nem ambições de ser um commiter, minhas atribuições já são mais do que suficiente, mas tambem assim que posso e sinto falta de alguma rotina eu gosto de colaborar, mas se  o caminho para tal for organizado podemos receber colaboração e o trabalho dos commiter ser muito mais simplicado.

Sobre o GIT, use o SmartGit e com ele de ide e vai ver é extremamente simples e vantajoso a migração, pois com commit local você tem uma revisão do seu código antes mesmo de submeter ao repositório remoto, essa é uma "das" vantagens, tem outras como multiplataforma e alta disponibilidade do repositório.

 

Isaque,

Foi intencional, pois cada uma das alterações eram de assuntos e possível commiter diferente, dessa forma não ocupa não gera um desconforto no commiter que fez a avaliação sem conhecer o código da unit.

Mas os códigos estão ai e se servir fiquem a vontade para aceitar ou rejeitar.

 

Irei continuar mandando as melhorias e correções, mas se conseguirmos padronizar seria muito melhor.

 

Waldir 

[Daniel Simoes]

Waldir,

Pela mesma falta de tempo... fica muito complicado para nós acatarmos uma Unit sem nenhum "change-log.txt" ou descrição do que foi modificado e porque...  Lembre-se que se você estivesse efetuando um Pull-Request (GIT), precisaria descrever as modificações enviadas

Trabalhei com o GIT com a equipe do Fortes Report... minha impressão foi: "ódio a primeira vista"... Demasiadamente burocrático, e confuso... achei muito improdutivo...

[AlexandreADC]

Sinto orgulho desta comunidade, pois são raras as comunidades de Delphi com códigos-fonte open-source, e o Projeto ACBr sem dúvida nenhuma é um sucesso! Parabéns aos fundadores e a todos colaboradores deste grande projeto!

Mas hoje minha equipe enfrenta várias dificuldades em entender o que está sendo alterado nos fontes comitados, apesar de ter o changelog e log do svn muitas informações estão espalhadas, inclusive no fórum, deixando assim a conferência de códigos-fonte quase impossível, inclusive o feedback para o desenvolvedor que criou a alteração.

Lembro antigamente que não era obrigatório o comentários nos logs do SVN, e era um inferno naquela época (desculpe o palavrão), melhorou muito desde aquela época, mas até hoje sou obrigado a manter uma cópia homologada dos fontes do ACBr para garantir que bugs não cheguem ao cliente.

Sou a favor do Git, pois apesar de aumentar um pouco a burocracia, melhora muito a questão de controle de alterações, tanto local quanto global, a ferramenta TortoiseGit é muito parecida com a TortoiseSVN, pois usaria o Git muito parecido com o SVN, aumentando a curva de aprendizagem, e com ele minha equipe poderia colaborar mais ainda.

Gostaria que mais pessoas inclusive contribuíssem com este post, sugerindo outras ferramentas que conheçam, ou alguma outra sugestão de melhoria.

Obrigado

[Daniel Simoes]

Como eu já disse, GIT está fora de cogitação... Mas nada impede que você faça o seu mirror..