포럼
커미터 활동을 해보고서 써보는 오픈소스로써의 XE 의 이후 개선점
2012.02.01 13:02
커미터 활동을 며칠 해보니,
중요한 이후의 건의사항이 있어서 적어봅니다.
현재 커미터로써 활동하기가 상당히 애매한 부분은,
개선 패치를 내기도 힘들고,
패치를 다른분들이 제출하셔도 규모가 있는 경우에는 반영이 애매한것이 사실입니다.
당장 언제 그것이 검토없이 버전에 투입될지 모르니
함부로 커밋하기가 상당히 부담되더군요.
이후에, 다른 커미터들이 늘어나서 커밋양이 급증하면 할수록 그러한 것의 관리 부분에 문제가 된다고 봅니다.
그래서 제안합니다.
현재 1.5 버전이 Stable 이니,
1.6 버전을 배포할때는
1.7 버전이 배포될떄까지는
1.5 를 Stable 로
1.6 을 Develop 로 배포하는거지요.
그리고 1.6이 배포되면 1.6은 그동안 배포된 기능을 다듬고 버그를 수정하고, (새로운 기능을 추가하지 않습니다.)
1.7에 새로운 기능을 자유롭게 커밋하는겁니다.
물론, 커밋된 내용을 개발팀이 정리하고, 불필요한 커밋을 제거하는 작업도 해야겠지요.
현재 상태로는 개발팀의 계획을 커미터들이 공유할수도 없고,
그덕에 사용할수 있는 자원을 효율적으로 사용하지 못하는것 같습니다.
간단히 정리해보면
1. 커미터들의 패치를 자유롭게 할수 있도록 오픈해달라 (현재는 결점 부분의 패치만 권장되고, 개선사항부분은 개발팀과 논의후 커밋하라고 되어있지만, 이것이 상당히 힘들죠. 논의라는게. 개별적인 연락라인이 있는것도 아니구요.)
2. 그덕에 산만해 질수 있는 코드를, 버전단위를 안정 - 개발 버전의 이중 유지로 관리하자.
입니다.
오픈소스 프로젝트로써 많은 사람의 참여를 확대하기 위해서는 이것이 필수적이라고 봅니다.
댓글 28
-
misol
2012.02.01 13:15
-
Treasurej
2012.02.01 14:13
좋은 대안입니다.^^
-
銀童
2012.02.01 23:45
개발팀이 꼭 보시고 피드백을 주셨으면 좋겠습니다.
-
misol
2012.02.02 11:00
이 글에는 피드백이 있었으면 합니다..
-
비나무
2012.02.02 20:24
과연 피드백이 있을지... 있다면 얼마후일지... ^^ -
misol
2012.02.02 20:25
이 글에 피드백 안해주면.. 협업을 하자는 자세가 아닌거 같아서요 ㅠ -
비나무
2012.02.02 21:20
저도 미솔님의 글 어떤 의미인지 압니다...
다만, 제 개인적으로 언제부터인가 개발팀의 자세에 신뢰감이 줄어서 말입니다... ^^* -
정찬명
2012.02.03 03:15
이 글에 개발팀이 직접 피드백 하는것이 소통이고 개발팀의 의무라고 생각하시는지요? -
XE-SPAM
2012.02.03 03:33
결론적으로 보면 서로 소통을 "이미" 하고는 있으나, 다른 한쪽이 "미처" 느끼지 못할 수도 있는 부분이고
그로 인해 노력하고 있는 다른 한쪽은 서운 할 수도 있는 상황인 것 같습니다.
서로의 입장을 자극할만한 어투나 글들은 서로 간에 절제하는 편이 좋을 것 같아요.
-
delphiXE2
2012.02.03 03:52
개발에 관한 직접적인 의견제안에 대한 토론은 소통의 범주에 넣을 수 있겠지만 의무는 아닙니다.
-
카르마
2012.02.03 08:33
" 의무라고 생각하시는지요?"
이런 반어법은 부정의 의미가 너무 강해서 상대방을 공격적으로 만든다는 생각은 안해보셨는지요.
말꼬리물기는 별로 즐기는 취미가 아닙니다만...
개발팀의 고충을 이해 못해서 드리는 말씀이 아닙니다.
개발팀이 바쁘고. 또 바쁘지 않다하더라도 조직의 특성상... 피드백과 소통이 쉽지 않을 수도 있습니다.
하지만 대부분의 사용자들이 원하는 소통은 구체적으로 소스차원의 세세한 것을 원하지는 않습니다.
배우는 무대와 관객이 있을때 춤을 춥니다.
무대는 XE이고 관객은 사용자입니다. 그 관객들을 위해서 빈말 한마디 하는 것이 그리 어려운 일인지 모르겠습니다.
그저 사용자들이 원하는 것은 최소한의 리액션입니다.
이렇듯이 정찬명님이 댓글을 다는 것이 리액션의 하나입니다. 고맙습니다.
하지만 반어법을 이용한 강한 부정은 여러사람을 불편하게 할 수도 있습니다.
노력하고 있지만 잘 안되네요...
아님 그럴만한 여유가 없습니다.
조직 여건상 그렇게 하기 어렵습니다. 등등등등....
아쉽네요.
-
delphiXE2
2012.02.03 03:47
사실 버전관리에 관해서 제 의견을 말한 적이 몇번 있습니다.
1.4는 Legacy stable, 1.5는 stable, 1.6은 development. 그 이전은 모두 Legacy.
1.4, 1.5는 버그수정 및 보안패치. 기능 개선. 매우 제한적인 기능 추가.
엔진엑스가 성공적인 예입니다.
-
정찬명
2012.02.03 07:55
개선사항은 개발팀 내부에서도 회의를 통해 반영 여부를 결정한 다음 진행합니다. 커미터 분들이 독자적으로 판단하는 경우 내부 정책과 다른 판단을 내릴 수 있기 때문에 혼선을 줄이기 위해 협의해 달라는 부탁을 했던 것이구요. XE 배포 버전을 2개 이상 두는것은 형상관리가 복잡해지기 때문에 아직 고려하지 않고 있습니다. -
서비여
2012.02.03 09:55
XE 배포 버전을 2개 이상 두는것은 형상관리가 복잡하다??
바로 그점이 사태를 이지경으로 만든다고 생각은 안하십니까?
칭찬과 격려를 받을 일을... 원성과 질책으로.....
결국 차후에도 그나마 안정된 버전이 하나도 없다는 것인데요.
-
銀童
2012.02.03 09:27
왜 이글이 이런 분쟁의 소지가 되는지 잘 모르겠습니다. 그냥 피드백을 해주셨으면 좋겠다 라는 의견을 피력한건데 이렇게 되는군요.
어찌됬든 정찬명님의 답변 고맙게 잘 받았습니다.
저는 개인적으로 커밋자체는 자유롭게 하고, 그 커밋된 내역의 실제 배포시의 반영 여부를 개발팀이 결정하시면 된다고 생각합니다.
왜냐하면 개발팀에서도 방향을 정하는데 회의가 필요하시다면
.. 커미터와 개발팀간의 협의는 더욱 힘들기 마련 아니겠습니까.
예를들어서 특정 인터페이스 개선을 한다고 할때,
해당 인터페이스 개선안을 커밋하고, 해당 개선안이 개발팀이 추구하는 방향과 맞지 않으면 rollback 하는 방식이 더 효율적이지 않을까 하는 생각입니다.
어찌되었든, 더욱 참여가 늘어서 이러한 진행 방법에 대한 토론이 더욱 많이 있었으면 좋겠네요.
-
정찬명
2012.02.03 09:58
롤백을 하는 것보다는 사전에 공유해서 가부를 결정하는 것이 더 효과적이라고 생각해요.
-
銀童
2012.02.03 10:02
그렇다면 메일이 아닌 공식적인 공유 채널을 공식 사이트에 만드는건 어떨까요?
개선사항을 커밋하기 전에 이야기 할수있는 공간을 말이죠.
-
정찬명
2012.02.03 11:02
XE 개발팀은 안팍으로 현재도 상당히 많은 의사소통 채널이 있고 너무 많아서 효과적으로 소통이 잘 되지 않습니다. 따라서 기존에 존재하고 있는 채널을 이용하는것이 좋을것 같습니다. 현재로써는 contact앳xpressengine.com 메일이 가장 효과적입니다.
-
銀童
2012.02.03 11:07
메일은
개발팀 <-> 커미터 한명과는 소통이 편리하지만
커미터가 여럿이 되면 메일로 해결하기에는 무리가 있다고 생각합니다.
어찌되었든, XE 가 외부 커미터들의 많은 참여를 통해 이끌어나가지길 원하신다면 게시판 생성은 필요한 부분이 아닐까 싶어요.
-
misol
2012.02.03 10:03
저도 정찬명님의 이 댓글에 매우 공감을 하기 때문에 위와 같은 댓글을 달았습니다. 혹시라도 마음 상하셨다면 죄송합니다.. -
고수군
2012.02.03 10:36
아마 XE팀에서는 소통이 불편한 것 일텐데요. resolved 될 가능성보다 close 될 가능성이 많아 보이네요. 오픈소스라고 말을 하기엔 NHN 산출물에 가깝다고 생각합니다. NHN 산출물에 여러사람들이 손대는게 불편할 수도 있습니다. 아니라고 말씀 하실 수 있겠으나.. 지금까지 처리결과를 보면 말이죠. 지극히 개인적 생각입니다.
http://wordpress.org/support/forum/alphabeta
-
코뿔소2020
2012.02.04 20:06
아니, 정확히 꽤뚫어 보시네요. 저도 전적으로 동감합니다.!
-
宋芭江
2012.02.03 12:00
http://www.xpressengine.com/userForum/20487803
위 글을 보니 오픈소스라는 의미가 쉽게 이해되는데 요새는 오픈소스니,협업이니 하는게
무슨 의미인지 잘 와닿지 않습니다.
-
misol
2012.02.03 12:22
-
銀童
2012.02.03 12:41
과도하게 개발팀의 태도 문제가 지적되는거 같아서 남겨봅니다.
개발팀의 태도니 오픈소스의 정책이니 그런문제가 아니라 어떤방식을 취하느냐는 취사선택의 차이일 뿐이라고 생각합니다.
개발팀에 날을 세우신 분들이 많은데,
주제에 맞지않는 리플로 날을 세우시는것도 영 보기 좋아보이진 않네요.
-
銀童
2012.02.03 12:51
커미터들에게 자유가 보장되야 오픈소스 프로젝트로써의 가치가 증대된다는 생각에는 변함이 없습니다만,
BNU 님의 의견이나 정찬명님의 의견도 개인적으로는 동감하는 부분도 있습니다.
제 의견이 받아들여지는 것과는 별도로 어떻게 이렇게 생각한거냐면,
예를들어서 개선사항과 버그 패치의 경우 다른데
현재 외부 커미터들은 버그 패치의 경우는 크게 망설임 없이 할수있지만 개선사항의 경우는 XE 개발팀과의 소통을 하도록 되어있습니다.
그런데 이 버그패치와 개선사항의 범주가 애매한것이,
예를들어서 코어의 내부 함수의 비효율적인 부분을 개선하는 패치는, 분명 버그패치는 아닙니다,
근데 부작용이 있는 개선사항또한 아니지요.
그러나, 현재의 범주 상태에서는 그러한것을 커밋하기가 상당히 애매한 상황인게 사실입니다.
예를들어서 http://code.google.com/p/xe-core/issues/detail?id=1153&q=meta&sort=-id (SMaker 님의 meta 개선 패치)
등을 적용함에 있어서 외부 커미터가 반영하기 힘들고,
결국 개발팀의 패치를 기다려야하는게 실정입니다.
그런데, XE 팀의 방향이 외부 개발자들의 참여를 늘리고자 하는것이라면
이러한 애매모호한 구분은 좋지 않다고 봅니다.
솔직히 저도 어떤 방향이 최적의 방향인지 잘 모르겠지만,
XE 가 XE 팀이 주도는 하되,
XE 팀만 개발하는 프로젝트가 되진 않았으면 하는 바램에서 굳이 이렇게 글을 남기게 되었습니다.
-
cherryfilter
2012.02.03 15:15
이 또한 개인적인 의견입니다.
팀 내부에서도 팀원간에 의견이 달라서 많은 논의를 하고 해당 개선사항이나 버그를 수정할지
아니면 won't fix로 갈지, 아니면 invalid 처리할지 이야기를 많이 합니다.
그런데 그런 것 없이 커밋터라는 이유 하나로 마음대로 커밋을 하게 된다면, 그 이후의 뒷감당(?)은 어떻게 해야 할까요?
은동님께서도 일전에 포인트 모듈을 core에 넣어야 할지 빼야 할지에 대해서 논의 해 주실 때도
의견이 매우 갈려서 다양한 이야기들이 나왔습니다.
그럼 그건 어떻게 처리하는게 옳을까요?
혼자 개발해서 혼자 배포하는 거면 이런거 저런거 생각 안해도 좋겠지만...
그런게 아니다 보니 이슈 하나에도 조금 더 신중을 기할 수 밖에 없는 모습입니다.
복잡하게 말씀 드릴께 아니라 간단히 말씀 드리자면...
XE 팀만 개발하고자 하는게 아니라,
어떤 기능을 넣는 것이 더욱 더 많은 사람들에게 좋은 결과를 줄지에 대한 고민이 필요하다는 것입니다.
제가 드리는 말씀이 지면을 통한 글이다 보니 오해의 여지가 있을 수도 있지만, 그리고 제가 말 주변이 없어서 뜻 전달이 모호할 수 있지만, 그 내면에 있는 뜻은 알아 주시면 감사하겠습니다. ^^
덧. 평소 은동님의 논리 정연한 사고방식을 예의 주시하면서 기분좋게 보고 있었습니다. ^^ XE 커뮤니티 내에서 전 은동님 팬이에요 ㅎㅎ
-
Garon
2012.02.03 22:39
댓글 후반부가 너무 훈훈하네요 ㅋㅋㅋ
커미터는 아니지만, 이 부분 저도 동감합니다.
연락할 방법이 없지요.. 개발팀이야 옆자리에 가서 이야기하면 되겠지만.. 외부개발자가 순간이동해서 갈 수도 없는 노릇이고요..