Liberar projeto em software livre

[FelipeGdM]

Olá amantes do mundo da bola

Por meio dessa PR, estou retomando as discussões para a gente liberar o nosso projeto como software livre. O pontapé inicial é substituir o modelo do robô do ThunderVolt por um modelo de robô de VSS genérico, o que acabei de fazer antes de abrir o rascunho dessa PR. Vou deixar listado aqui o que ainda precisa ser feito para que a gente libere o nosso projeto em definitivo

• [x] Substituir modelo dos robôs
• [x] Escrever documentação do modelo utilizado
• [x] Revisar instruções de uso
• [x] Adicionar licença (MIT, CC ou GPLv3)
• [x] Traduzir documentação para o inglês
• [x] Fechar a PR #8
• [x] Traduzir docs da PR #8

No mais, é isso que tenho por enquanto. Bora tornar esse projeto software livre! :tada:

[lucastrschneider]

Faz sentido colocar a descrição do nosso time de vdd no pacote do Thundervolt? Se n me engano o turtlebot3 que usamos no PS tinha um pacote só pra descrição dos robôs, que ficava no mesmo metapacote da simulação, mas como queremos manter privado, seria melhor que ficasse lá, ou em um outro repo privado, né? E como nós faríamos para usar as descrições dos nossos robôs de verdade em vez do time genérico (que ficou muito fofo, btw)? Tem como a gnt fazer isso sem referenciar diretamente o repo do Thundervolt? Fiquei bastante tempo pensando nisso e não cheguei a lugar nenhum kkkkkkk ~Digo, sem ter que mudar o parâmetro model toda vez q for rodar~

[lucastrschneider]

E como a gnt faria para abrir o repo? Pq teoricamente os modelos dos nossos robôs ainda estão aqui né, então qualquer um poderia acessar se a gnt só deixasse público.

Se bem que essa é a versão antiga tbm, teoricamente vai ter um robô novo até a próxima competição, ai n sei se importa muito deixar desse jeito.

[FelipeGdM]

Faz sentido colocar a descrição do nosso time de vdd no pacote do Thundervolt? Se n me engano o turtlebot3 que usamos no PS tinha um pacote só pra descrição dos robôs, que ficava no mesmo metapacote da simulação, mas como queremos manter privado, seria melhor que ficasse lá, ou em um outro repo privado, né?

Não encontrei nenhuma referência oficial que determine as melhores práticas nesse caso, mas todos os projetos que eu vi seguem a estrutura do turtlebot, que é ter um pacote {NOME_ROBÔ}_robot_description. Acredito que essa seria a melhor alternativa

E como nós faríamos para usar as descrições dos nossos robôs de verdade em vez do time genérico (que ficou muito fofo, btw)? Tem como a gnt fazer isso sem referenciar diretamente o repo do Thundervolt? Fiquei bastante tempo pensando nisso e não cheguei a lugar nenhum kkkkkkk

O que eu pensei foi criar um launchfile dentro do thundervolt_robot_description que chame o launchfile da simulação com os parâmetros específicos para o nosso caso. A simulação tem que ficar 100% desacoplada do nosso projeto, então o jeito de resolver isso seria nas coisas do thundervolt msm

E como a gnt faria para abrir o repo? Pq teoricamente os modelos dos nossos robôs ainda estão aqui né, então qualquer um poderia acessar se a gnt só deixasse público.

É, não tem muito como escapar disso. Mesmo removendo os nossos robôs, os arquivos .stl ficam pra sempre no histórico de commits. Como se trata de uma versão que será atualizada, eu não vejo muito problema com isso, além do que a pessoa vai ter que se esforçar muito pra fazer alguma coisa a partir desses arquivos. Acho que nem jogar na impressora 3D não dá, pq a base tá fundida com tudo que não se mexe em relação a ela.

[lucastrschneider]

A licença vai ser MIT msm que nem os outros projetos? É a mais aberta, certo?

[FelipeGdM]

A licença vai ser MIT msm que nem os outros projetos? É a mais aberta, certo?

@lucastrschneider Esse guia aqui é bem daora pra explicar a diferença entre cada uma das licensas

[d-nery]

Se for fazer as mudanças pra colocar os .md na pasta docs aí teria que mexer numas coisas, mas por agora acho que tá tudo check.

README sempre fica na raiz mesmo, não sei se é desse que você está falando CHANGELOG e CODE_OF_CONDUCT podem ficar (e normalmente ficam) numa pasta .github que é meio convenção pra coisas relacionadas ao repositório em si mais que o projeto, o que pode ir nessa pasta também é uma pasta ISSUE_TEMPLATE com templates para issues e um arquivo PULL_REQUEST_TEMPLATE.md que é um template para PRs, o GitHub vê esses arquivos e auto preenche a issue, pode ser uma boa ideia também (mesmo que só copie o que tem lá no contributing)

Mais informações sobre os templates aqui Um exemplo aqui

[LucasHaug]

Se for fazer as mudanças pra colocar os .md na pasta docs aí teria que mexer numas coisas, mas por agora acho que tá tudo check.

README sempre fica na raiz mesmo, não sei se é desse que você está falando CHANGELOG e CODE_OF_CONDUCT podem ficar (e normalmente ficam) numa pasta .github que é meio convenção pra coisas relacionadas ao repositório em si mais que o projeto, o que pode ir nessa pasta também é uma pasta ISSUE_TEMPLATE com templates para issues e um arquivo PULL_REQUEST_TEMPLATE.md que é um template para PRs, o GitHub vê esses arquivos e auto preenche a issue, pode ser uma boa ideia também (mesmo que só copie o que tem lá no contributing)

Mais informações sobre os templates aqui Um exemplo aqui

Ah tava falando dos outros .md sem ser o README hsuahsuahsuahs porque tem muitos. Não sabia dessa pasta .github, mas faz sentido. Mas oh, no exemplo que você deu aí do tensorflow, todos os que a gente colocou tão na raiz mesmo do repositório, só o ISSUE_TEMPLATE que tá no .github aí não sei shauhuashuahsua. Mas eh, vi lugares que colocam, aí não sei.

[Berbardo]

MEU DEUS DO CÉU KKKKKKKKKKKKKKKKKKKKK