도커파일, 도커 컴포즈를 이용해 로컬 실행시간을 최소화

[javapark]

PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요. PR을 보내기 전에 모든 항목을 확인해야 합니다.

• 동일한 업데이트/변경에 대한 다른 Pull Requests가 열려있는지 확인했습니다.
• 테스트가 성공적으로 수행되었는지 확인했습니다.

PR 유형

어떤 유형의 PR인가요? (해당 항목에 모두 체크해주세요)

• 버그 수정
• 새로운 기능
• 문서내용 수정
• 코드 의미에 영향을 주지 않는 변경사항 (오타, 서식 지정, 변수명 변경 등)
• 코드 리팩토링 (버그 수정이나 기능 변경 없는 코드 변경)
• 빌드 관련 변경
• 테스트 코드 추가
• 기타 (이유를 설명해주세요.)

변경 사항

도커파일과 도커컴포즈파일을 이용하여 간단하게 로컬에서 실행해보고 실행해보았습니다.
도커환경만 있다면 얼마든지 기여할 수 있을 것 같아 PR 을 올려봅니다.
실행 : docker-compose up -d --build

관련 이슈

기타 정보

[mirusu400]

혹시 이거 왜 Closed됐나요?

[javapark]

다시 리오픈 해봅니다.

[NavyStack]

Due to uncertainties, especially regarding aspects such as WORKDIR, volume handling, and the future direction of the project, we chose not to proceed with the Pull Request.

However, personally, you can find the Dockerfile-related builds at https://github.com/NavyStack/gnuboard-g6.git.

[NavyStack]

While the ARM architecture was built natively, we cannot guarantee its functionality until it is tested for execution.
Additionally, the image has already been pushed to Dockerhub.

Presently, available manual pushes are undertaken, and automated nightly builds are in progress at 00:00 KST.

You can check it out at https://hub.docker.com/r/navystack/gnuboard-g6
and https://hub.docker.com/r/navystack/gnuboard-g6/tags

[NavyStack]

If the Gnuboard team @gnuboard desires and is open to considering future project considerations, we are willing to proceed with relevant pull requests. Please provide us with preferences and guidance on the future direction of the project.

Gnuboard 팀이 원하고 향후 프로젝트 고려 사항을 고려할 수 있다면, 관련 PR을 진행할 의향이 있습니다.
선호 사항과 향후 프로젝트 방향에 대한 지침을 제공해 주세요.

[mirusu400]

@NavyStack 개인으로 있어서 설정 파일이 마음에 안들면 리뷰를 통해 수정 제안을 하거나 만들어진 fork branch에 PR을 하면 되지 왜 we do not chose to proceed with the PR 이란 표현을 쓰셨는지 잘 모르겠네요.

여러명이서 쓰시는 계정이신가요?

이미 비슷한 목적의 PR이 있고, 메인테이너가 닫지 않았다면 무의미하게 새로운 PR을 제시할 필요 없이 여기에 Co-Author 해도 된다고 생각합니다.

[NavyStack]

@mirusu400,
네 여러명입니다. 개별적으로 작성하고 통합해서 PR합니다.
그게 GIthub의 바탕이 되는 GIt의 정신입니다.
또한 git remote와 git fetch, git pull이 있는 이유이기도 하구요.

Co-Author할 예정입니다.
닫기를 요청한다는 문장은 없었습니다.

code reveiw를 한 이유는 이러한 부분에 대한 의견을 묻고, 의사소통을 보다 명확하게 하기 위함이었습니다.
아직 PR이 종료가 되지 않았습니다. 또한 앞서 언급한 바와 같이, 개인적으로 사용하려고 만든 이미지 역시 이미 있습니다.
왜 날카롭게 반응하시는지는 잘 모르겠네요.

[mirusu400]

영어로 말씀하셔서 서로 의사소통에 문제가 있었나 봅니다

1. we 라고 적으신 부분 때문에, 마치 메인테이너를 대변해서 해당 PR을 진행하지 않는다고 얘기하는 듯 했습니다
2. 그러는 와중에, 본인의 Dockerfile 포크 버전(+Dockerhub)을 홍보하였기에, 이 PR을 여론을 이용하여 닫고 본인의 PR을 올릴려고 요청한다고 생각하였습니다

반응이 날카로웠던 점은 사과드립니다

[NavyStack]

@mirusu400님, 아니에요. 괜찮습니다. 😊

도커 허브와 관련된 레포를 언급한 이유는 이미 작성한 파일이 있어서, 그누보드 팀이 이미지를 확인하고 결정하는 데 도움이 되기를 바랬기 때문입니다.
마지막에 방향성에 대한 확신이 없어서, 원하시면 작업에 착수한다고 그누보드 팀에게 알렸습니다.

---

아시겠지만, PR을 진행한다는 것은 조금 큰 부담이 있습니다.
고려해야 할 사항이 많고, 가끔은 마치 숙제 검사 받는 아이 같다는 느낌이 들기도 합니다.
가장 낙심하게하는 것은 열심히 기여했음에도 불구하고 아무런 반응이 없거나, 코드에 대한 명확한 리뷰 없이 닫히는 경우입니다.

이러한 마음을 잘 이해하기에, Code review를 꼼꼼히 하고 의사소통을 원활하게 하기 위해 노력했습니다. 고려하지 못한 부분이 있다면, 다른 개발자의 리뷰에서 더 나은 방향을 찾길 바라고 있습니다.

---

관련된 이미지는 실제로 sir.kr에도 올렸습니다. 댓글에서도 메인스트림에 반영되었으면 하는 의견이 있었습니다.
하지만 도커 이미지를 관리하는 것은 부담스럽습니다.
이미 다른 과제들에 신경을 쓰고 있을 그누보드 팀에게 더 큰 부담을 주고 싶지 않았습니다.

또한, 위와 관련된 모든 링크에 수익을 목적으로 하지 않았습니다.
본 PR 첨부된 링크에 그누보드와 관련된 권리도 주장하지 않습니다.

(링크 참조: https://github.com/NavyStack/gnuboard-g6/blob/8ddeec06207075d99cf47b1128202f4f612b317e/README.md?plain=1#L66)

또한 MIT 라이선스는 상업적인 이용을 허용하는 오픈 소스 라이선스 중 하나입니다.
따라서 MIT 라이선스로 배포된 소프트웨어를 상업적으로 이용하는 것은 허용되므로 상업성을 띄었다고 해도 문제가 없지요.
MIT 라이선스는 소프트웨어를 수정하고 재배포할 수 있도록 허용하며, 이는 비상업적이든 상업적이든 상관없이 적용됩니다.

---

영어로 주석을 작성한 이유는 그누보드가 더 커지길 바라는 마음이었습니다.
스레드 형식이 더 많아지고 있지만, 세계 어딘가에서는 이 형식을 원하는 사용자가 있을 것이기 때문입니다.

판이 더 커지면 재미있을 것 같지 않으세요? 😊

[NavyStack]

@mirusu400님,
또한 아직 semver 태그가 붙지 않아서 조금 더 조심스러운 마음도 있었습니다.

1. we 라고 적으신 부분 때문에, 마치 메인테이너를 대변해서 해당 PR을 진행하지 않는다고 얘기하는 듯 했습니다.

이와 관련하여, 같은 맥락에서, 권리 주장을 더 명확히 하기 위해,

커뮤니티가 계속 성장하면서 새로운 기여자들을 끌어들이고 있는 만큼, 기여자 라이선스 동의서 (CLA)를 도입하여 프로젝트와 기여자 모두의 이익을 보호했으면 좋겠습니다.
CLA는 기여자가 프로젝트에 어떤 조건으로 기여할지에 대한 법적 문서로, 기여자가 자신의 작업을 기여할 권리가 있으며 필요한 라이선스를 부여하며 프로젝트가 그들의 기여를 사용하고 배포할 수 있도록 하는 내용을 포함합니다.

CLA를 도입함으로써, 모든 이해 당사자에게 명확하고 필수적인 법적 보호를 제공하며 지적 재산에 관한 갈등을 효과적으로 회피하며, 프로젝트가 의도한 대로 오픈 소스 라이선스 하에 원활하게 배포될 수 있도록 보장할 수 있습니다.

[NavyStack]

이것도 결국 메인테이너의 의견이 중요한 부분이겠네요.
만약 메인테이너가 원하신다면, 자동으로 CLA 동의를 체크하는 기능을 PR에 추가하는 것은 좋은 아이디어일 것입니다.

또한, GitHub Actions를 활용하여 기계적으로 문법 검사(Unit Testing) 등을 추가하는 것도 좋은 방법입니다.
이러한 자동 검사가 코드 품질을 향상시키고, 미리 에러를 방지할 수 있습니다.

더 나아가, demo를 띄워서 gnuboard를 실행하고 확인하는 방법도 있습니다.
이를 통해 실제로 어떻게 동작하는지 미리 확인할 수 있어서 개발자들에게 더 안정적인 경험을 제공할 수 있을 것입니다.

사실 Code review에 기록했던 것 들은 저희도 Dockerfile을 작성하면서 많이 고민했던 것들이었습니다.
https://github.com/NavyStack/gnuboard-g6/blob/8ddeec06207075d99cf47b1128202f4f612b317e/README.md?plain=1#L21
여기도 그렇구요 😊

[NavyStack]

PR(Pull Request)이 merge되기까지 걸리는 시간은 많은 요소에 따라 다르며, 프로젝트의 특성, 규모, 관리 정책, 참여자의 활동 수준 등에 따라 달라집니다. 일반적으로 PR이 즉시 머지되는 경우도 있지만, 때로는 몇 주 또는 몇 달 걸리기도 합니다. 1년 이상 걸리는 경우도 특별한 상황에서 나타날 수 있습니다.

또한 @mirusu400님, 제가 권한이 main에 Push할수 있는 권한이 없을 수 있어서, 따로 Fork해서 PR해야하지 않을까 싶네요.

[NavyStack]

@mirusu400님, 권한 부족으로 #343 PR에 대해 수정하지 못했습니다.
따라서 별도로 PR합니다.

[NavyStack]

가감없는 의견 전개 부탁드립니다.

gnuboard5 (gnuboard/gnuboard5#302) 도 진행중입니다.