Open source 참여의 난관

김정균의 이미지

요즘 들어 몇몇 패치((kernel sysctl tcp_timewait patch, openssh skip hostkey check patch, apache max client error page patch 등등)를 만들었는데, 이를 main stream 에 반영을 하려고 하니 막막하군요.

현재 제가 패치를 main stream 에 반영을 하려고 투고를 한 것은 php 와 snmp 입니다. 이 중에서 php 는 거절을 당했고, snmp (http://sourceforge.net/tracker/index.php?func=detail&aid=1657741&group_id=12694&atid=312694) 는 다음 major release 에 반영을 하겠다는 답변을 받았습니다.

이 외에도 S.E 의 입장에서 필요한 패치들을 꽤 한편인데, 문제는 이를 투고하는 것이 난관이라는 것입니다. 일단 SF.net 에 있는 project 의 경우에는 그나마 투고하는 것이 쉽습니다만, 이곳이 아닌 다른 큰 프로젝트들은 어디다 투고를 해야 하는지 찾는 것도 힘이 들더군요.

더군다나.. 영어로 투고를 해야 하는데, (제 개인적인 견해로 php 의 safe_mode_execdir 패치가 거절당한 이유는 php 개발자들이 배타적인 부분도 상당하겠지만, 제 영어가 너무 엉터리였기 때문일 수도 있다는 생각이 듭니다. 아니면 코드가 너무 구렸거나 --) 이 부분도 만만치가 않더군요.

안녕 리눅스를 관리하면서 한 패치들도 꽤 되는데, 이를 main stream 에 반영하지 못하다 보니 안녕 2.0 작업시에 안녕 1.0 에 들어가 있던 패치들이 승계가 잘 되리라는 보장도 못할 정도로 관리가 안되는 점도 문제입니다.

또한, 해당 패치들은 정말 별거 아니지만 관리의 입장에서는 필요할 만한 것들인데, 개발자들이 이런 입장을 생각해볼 만한 상황이 안되어서 인지 구현이 안되어 있거나, 또는 구현한 것을 찾기가 쉽지 않은 패치들이죠.

어떻게 보면 정말 별거 아닌 패치를 main stream 에 반영시키기 위해서는 명분을 잘 적어야 하는데, 결국에는 제가 main stream 에 반영을 제대로 하지 못하는 이유는 결국 언어가 문제가 아닌가 생각이 듭니다.

여러분 .. 영어 공부 열심히 하시기 바랍니다. :-)

댓글

ioriy2k의 이미지

안녕 리눅스로 유명한 김정균님의 patch도 잘 받아들여지지 않는 걸 보면, 영어를 통한 의사소통이 patch를 만드는 것보다 힘든 것 같습니다;;

저도 역시 외국의 open source project를 참여하고 싶어도 언어의 장벽이 만만치 않아서..
(어쩌면 게으른 자의 핑계일지도 모르겠네요.. )

요새 계속 영어에 대한 압박이 밀려오고 있는데 이 글을 보니 하루빨리 영어공부를 다시 시작해야 겠다는 생각이 듭니다.

이전에 웹서핑하다가 찾은 영어공부에 괜찮은 사이트 링크 걸어둡니다.
모두들 같이 열심히 공부합시다. (무슨 광고 같네..;;)
ESL Potcast : http://www.eslpod.com

-- Homepage : http://ioriy2k.pe.kr
-- God Bless..

-- God Bless..

perky의 이미지

저도 몇몇 프로젝트에서 패치를 보내기도 하고, 리뷰해서 커밋해 주기도 하고 있는데요,
받아서 리뷰를 몇번 해 보면, 패치를 보낼 때 도움이 많이 되기 때문에, 패치를 받는
입장에서의 느낌을 몇 자 적어봅니다. 아무래도 패치를 쭉 보다 보면, 영어권에서
오는 패치보다 비영어권에서 오는 패치가 다루기가 훨씬 까다로운 것이 사실입니다.
물론 설명이 부족한 것이 가장 난감하긴 한데, 그 외에 문화적인 요소나 설명에 대한
공포감(?)또는 노력이 너무 많이 들어서 하다가 만 부분이 많은 것이 가장 치명적인 것
같습니다.

그래서, 몇가지 패치 보내기에 있어서의 체크포인트를 적어봅니다.

1. 패치 설명에는 동기가 꼭 포함되어야 한다.

주로 일본이나 러시아에서 오는 패치들을 보면, 코드만 많고 설명은 1~2줄로 짧게
끝나는 경우가 많습니다. 게다가 그 설명이 그냥 뭐 하게 고쳤다는 내용만 있고,
안 고치면 뭐가 문제가 되는지 상황에 대한 설명이 없는 경우가 많습니다.
패치를 보낼 때는, 이 패치가 없을 때 생기는 구체적인 일을 설명해야합니다.
대형 프로젝트일 수록, 프로젝트 전체를 아는 사람이 줄어들고 리뷰 과정이 까다로워집니다.
많은 사용자들이 이게 없어서 굉장히 고통받고 있다거나, 전혀 표준에 맞지 않다는 등
패치가 들어가야만 하는 이유가 정확히 설명되어 있어야 합니다.

사실 한 프로젝트에 소속돼서 오랫동안 활동한 개발자들은 목적만 설명이 된다면,
외부에서 처음 패치한 사람보다 훨씬 간단하고 효율적인 방법을 만들 수 있습니다.
그렇기 때문에, 동기나 목적을 제시해 주는 것이 더 나은 해결책을 만들 수 있다는
점에서 아주 중요합니다.

2. 맨 첫 패치 메일의 스타일이 패치의 운명을 좌우한다.

한 패치를 올리면 그 다음에 답장을 주고 받는 과정이 길게 일어납니다. 물론, 최종적으로
커밋되는 패치가 깔끔하면 되긴 하지만, 맨 처음 개발자에게 보내는 패치의 스타일이
패치가 얼마나 빨리 답장이 오느냐를 결정합니다. 사람의 첫인상이 중요하듯, 스타일이
좋은 패치(코드)들은 리뷰어의 시간과 스트레스를 줄여주고, 이 패치를 적용해 보고 싶다는
생각이 들게 합니다. 구현이 잘 되어있더라도, 그 프로젝트의 기존 코드들과 어울리지
않는 스타일이 작성되었거나 스타일이 일관되지 않은 패치들은 리뷰어가 미뤄뒀다가 맨 마지막에
정말 할 일 없을 때나 리뷰하는 패치가 되게 합니다.

3. 문제를 재현할 수 있는 스크립트, 패치가 적용된 후에 제대로 돌아가는지 테스트하는 스크립트를
꼭 포함한다.

재현할 수 있는 문제와 재현하려면 많은 노력이 드는 문제와는 처음 개발자가 진입할 때
드는 노력이 확실히 다릅니다. 그냥 실행만 하면 바로 명백한 에러가 떨어지는 스크립트가
완벽하게 동봉되어 있다면 대부분의 시간이 있는 개발자들이 한번 실행해 보고 싶어
합니다. 일단 개발자가 실행해서 에러 메시지를 보게 되면, 그 때 많은 수의 개발자들은
에러에 푹 빠져서 이제 패치에 답장을 쓰지 않고서는 배기지 못합니다.

4. 영어를 완벽하게 쓸 필요는 없지만 꼭 필요한 설명을 빼지는 않는다.

영어 문장을 쓰기 힘들 때는 대충이라도 꼭 필요한 설명들은 빼먹으면 안 됩니다. 간단하게
패치가 돌아가는 과정이나, 패치가 대상으로 하고 있는 것, 패치로 인해 발생할 수 있는 문제점
등 같이 없으면 이해할 수 없다고 생각되는 사항들은 빼면 안 됩니다. 특히 패치로 인해
발생할 수 있는 문제점들을 자기가 언급하면 같이 고민해 볼 사항이 되지만, 그걸 빼먹고
나중에 리뷰하는 사람이 발견하게 되면 패치의 심각한 결함이 돼서 거부되는 구실이 됩니다.

5. 꿋꿋이 참고 기다린다. (그리고 뒤에서 물밑작업을 한다.)

패치가 간다고 바로 답장이 오는 경우는 거의 없습니다. 1달 걸리는 경우도 많고 심지어
1년 넘어서 답장이 오기도 합니다. 따라서, 너무 조바심을 내고 매일 답장 오나 확인하면
에너지에 심각한 손실이 옵니다. 그렇다면, 손놓고 마냥 기다리느냐.. 그렇게 하면 또
오래 걸리니까 안 되겠죠. 그래서 결국은 패치를 보내놓고 물밑작업을 해야하는데,
주로 물밑작업은 이런 게 있겠습니다. 1) 종종 패치를 업데이트한다: 기존의 패치에서 사소한
것들을 고쳐서 업데이트하되, 너무 치명적인 문제를 패치하면 신뢰가 떨어질 수 있기 때문에
적당한 간격으로 패치를 업데이트해 주면 됩니다. 가장 좋은 구실은 소스트리가 업데이트되는
바람에 컨플릭트가 나서 패치를 업데이트했다가 있겠죠. 2) 의존성 있는 패치를 올린다:
다른 패치를 올리면서 전에 올렸던 패치를 언급하거나, 아예 그걸 적용하지 않으면
고치기 힘들게 만듭니다. 서로 관련 없는 것끼리는 그렇게 하기가 물론 힘들겠죠.
그러니까, 일부러 관련된 문제를 찾아나서야합니다. 꼭 자기가 발견한 것 아니더라도
다른 사람이 올린 관련 패치에 답글을 달면 효과적입니다. 3) 다른 사람 패치를 리뷰한다:
다른 사람들이 올린 패치들에 리뷰를 가볍게 하고 답글을 달아봅니다. 그러면, 트래커를 지키는
개발자들 (보통 3~4명 정도가 굉장히 열심히 봅니다.)의 눈에 이름이 어느정도 익숙하게
됩니다. 이런 일들이 좀 지나면 자기가 올린 메일이나 패치들의 발언력이 많이 강해집니다.
이제부터는 패치를 업데이트하거나, 메일을 올리고 그래도 반응이 상당히 잘 올라옵니다.

6. 패치는 반드시 최신 소스트리 HEAD에 대해 올려야한다. (물론 옛날 브랜치에 대한 거라면 옛날 것)

소스를 릴리스된 것을 기반으로 올리는 분들이 많이 있는데, 이런 경우에 개발자들이 또 일일이
그걸 받아서 풀어다가 확인해봐야하기 때문에 귀찮아서 나중으로 미룰 확률이 높아집니다.
소스는 꼭 cvs, svn, git 등 개발자들이 쓰는 저장고에서 최신판을 받아서 패치를 만들어야합니다.
물론 conflict가 나면 안 되죠~

7. 패치는 멋있거나 빠르거나 기타등등.. 열심히 하는 것보다 무조건 짧고 간단한 게 좋다.

패치가 굉장히 멋있고 영리한 디자인으로 되어있는데, 건드리는 파일이 수십개인 것보다,
간단하게 파일 한 두개 건드려서 해결되는 것이 패치로서는 훨씬 매력적입니다.
물론 hack 만들듯이 이상한 방법이면 안 되고, 그래도 정상적인 방법 중에서 가장 간단한
것을 택해야 하겠죠. 이제 그러면 거기서부터 걸려든 리뷰어가 제대로 된 방법으로 발전해
가는데, 각 요소들의 메인테이너들도 리뷰어들이 친하기 때문에 훨씬 더 일이 많은 사람들이
붙어서 빨리 진행되거나 혼자 멋있는 것 만드는 것 보다 더 정확한 패치가 나올 확률이 높습니다.

사실 위에서 설명한 것 중에 많은 것들이 영어하고는 별로 관련이 없는 것처럼 느껴질 수가
있습니다. 그런데, 사실 대부분이 비영어권에서 오는 패치들에서 빈도가 상당히 높은 문제들입니다.
그 이유는 아무래도 비영어권 사용자들이 메일링 리스트를 검색해서 관례를 파악하는데 드는
노력도 많이 들고, 말로 해서 금방 확인할 수 있는 내용도 언어상의 소통이 힘들어서 혼자
많은 일을 하다보니까 생기는 문제이기도 합니다.

정말로 김정균님의 말씀대로 영어공부하는게 무척 중요하긴 하지만, 대충 영어가 기초만
되더라도, 눈치와 코치, 경험으로 어느 정도는 극복할 수 있으니 실제로 부딪혀 보는
것이 가장 중요할 것 같네요. ^_^

You need Python

김정균의 이미지

Quote:
정말로 김정균님의 말씀대로 영어공부하는게 무척 중요하긴 하지만, 대충 영어가 기초만
되더라도, 눈치와 코치, 경험으로 어느 정도는 극복할 수 있으니 실제로 부딪혀 보는
것이 가장 중요할 것 같네요. ^_^

KLDP 10 주년 컨퍼런스에스 다 들었던 내용이죠. 제가 윗 글에서 쓴 요지는 이런 저런 방법 보다는 perky님이 말씀 하셨던.. 패치와 함께 올라가야 할 상황 설명을 제대로 적지를 못해서 입니다. 결국에는 언어의 벽에 부딫히고 있다는 거죠. "대충 영어가 기초만 되더라도"라고 말을 할 수 있는 것은 영어로 소통이 가능하기 때문에 나올수 있습니다. 영어를 못하는 사람은 정말 못하죠 ^^;

저도 영어권에 자주 놀러가봐서.. 대충 대화는 하겠지만, 영어로 글을 쓴다는 것은 아주 쉽지 않은 일입니다. 그러다 보니 패치가 받아들여지지 않고.. 그런 상황을 올린 것이죠.. 솔직히 무안한 일이지만 쩝.. 뭐, 독해야 하도 해서 대충 하지만.. ^^;

확실히 언어의 장벽이 상당히 크다는 것을 요즘 뼈저리게 느낍니다.

익명 사용자의 이미지

영문과 (맞죠?) 나오신 분이 이럴진대, 일반인(?)은 얼마나 더하겠습니다.

저는 패치 보낼 때 최대한 간결하게, 문제 일으키는 방법, 해결방법을 보냅니다(문제 일으키기 어려운 경우도 있죠. 그럴 때는 원래 코드랑 비교 설명 해봅니다).

그렇게 해서 안받아들여지면, 그냥 제 로컬만 수정해서 씁니다. 설명하기도 귀찮고 괜히 무시당한 느낌이라 '그래 너 내 패치없이 쓰다가 한번 x먹어 봐라'하는 심정도 전혀 없다고는 할수없겠죠.

김정균의 이미지

음.. 제가 영문과 나와서 영어가 좀 되었다면.. 아마 어디 변두리 학원 영어 강사를 하고 있었을 겁니다. (학벌이 별로 좋지 않은 관계로..) 영어를 못해서 영어로 밥먹고 살기 힘든 관계로 IT 쪽으로 흘러 들어오게 된 것입니다. :-)

뭐 덕분에 입에 풀칠하기 위해서 죽으라고 해야 했던 입장이 되어, 26살이라는 늦은 나이에 본격적으로 컴퓨터라는 것을 접한 이후에 이렇게 밥 먹고 살 정도는 된 것 같습니다. :-) 26살에 제대해서 Windows 95 라는 것을 처음 접해 봤는데.. Dos 에서 한메타자교실 하다가 입대한 이후로 엄청난 공황이었습니다. 컴퓨터라는 것이 이렇게 어려워 졌다니 하고 말이죠 ^^;

권순선의 이미지

경험에서 우러나온 좋은 정보이네요. 메모해 두어야겠습니다. :-)

krisna의 이미지

perky님께서 좋은 말을 해주셨는데요.

저는 이 부분이 일반 사용자들이 오픈소스에 기여할 수 있는 틈새라고 생각을 합니다.
패치를 만드는 작업은 개발자들이 하겠지만 그것을 적용하게 하는 정치 작업은 사용자들이 할 수 있다는 생각입니다.

프로젝트 관리자들이 중요하지 않다고 느끼는 문제점들에 대해서는 딱히 고치려고 노력하지 않을 가능성이 높습니다. 그러니까 perkey님께서 지적하신 대로 손쉽게 패치를 적용할 수 있고 패치가 중요한 버그를 고쳐준다는 이미지를 줄수 있어야 합니다.

그러나 프로젝트 관리자는 그 메일만 가지고는 해당 사안의 중요성을 느끼지 못할 가능성이 높습니다. 단지 한사람의 버그 리포팅이기 때문에 크게 신경쓰지 않을 가능성이 높지요. 그러나 두세명이 더 같은 문제로 버그 리포팅하거나, 메일링에 메일을 보낸다면, 조금이라도 신경쓰지 않을 수 없을 것입니다.
여기에 더 많은 사람들이 이 문제를 고쳐달라고 버그리포팅이나 의견을 보내온다면 더더욱 개발자는 고치려고 할 가능성이 높아지리라고 생각합니다.

이런 류의 작업은 굳이 개발자가 아니더라도 할수 있고, 또 오히려 개발자가 아니라 사용자가 사용자 관점에서 줄기차게 주장을 해주는 것이 좋을 것입니다.

antz의 이미지

저도 언어의 장벽이 높다고 느낍니다.
그래도 꿋꿋이 보낼 필요가 있으면 메일링에 보내고 하는데요. ^^;

패치를 하신 분이 있으면, 도움을 드릴 수 있는 경로가 있었으면 좋겠다는 생각이
글을 읽으며 드는군요.

음... 예를들어서 패치에 대한 한글 설명을 영어로 변환해 주는겁니다.
변환해 준걸로 메일을 보내고 하면 어떨까? 생각이 드는군요.

KLDP Wiki와 더블어서 Open Source 기어에 도움이 되지 않을까? 생각이 듭니다.

---


Jabber: lum0320@jabber.org

purluno의 이미지

더 나아가 패치나 버그 보고 등록 대행 서비스같은 것을 하면 어떨까 싶네요.

예를 들어 KLDP OSS 통합 버그 보고 시스템이란 것을 만들었다고 가정하면...

사용자는 자신의 오픈소스 프로그램에서 발생한 문제를 여기에 보고하면 등록 대행 봉사자가 그 프로그램의 실제 보고 시스템에 등록하고 알려주는 것이죠. 필요하면 번역도 동반해서요.

부가적인 효과로 KLDP 사이트에서 각종 오픈소스 프로그램들의 방대한 버그 목록을 확보할 수 있을겁니다. 국내의 오픈소스 참여도에 비례하겠지만 말이죠. :)

권순선의 이미지

이 모델은 등록 대행 봉사자(?)가 많아야 제대로 동작할텐데 과연 얼마나 될까요? 개인적으로는 잘 되기가 어려운 방안이라고 생각해 왔는데 지금 시점에서 다시한번 생각해 봐야겠네요. 다른 분들의 의견은 어떨지....

antz의 이미지

글 쓰면서... 봉사자 에대한 걱정을 안 한것은 아니나...
오픈소스에 기여라는 측면에서 언어가 높은 장벽이 된다면,
좋은 방법을 고민해 보는게 좋겠다는 생각입니다.

가장 좋은 것은 개발자가 영어 공부를 해서 직접하는것이겠지만,
그게 쉽지 않으니... 우회적인 방법이라도 생각해 보자는 거지요.

음... 그냥 생각되는것이...

1. 포트딩자의 익명성이 필요하면 그렇게 할 수 있도록 했으면 좋겠고,
2. 포럼이나 게시판 담당자 처럼 이쪽 담당자를 몇명 지정해서 처리가 되도록 하는것도 생각이 되구요. ( 말은 쉽게 하지요 ^^;;; )
3. KLDP의 중앙에 포스팅을 해주거나 참여를 유도할 수 있는 방안을 마련하는겁니다.

이 글을 쓰면서 또 생각되는 것이 번역에 대한 수요가 얼마나 많을까? 하는 생각이 듭니다만,
다시 생각하면 하나라도 더 오픈소스에 참여를 유도 하는것이 좋지 않을까? 하는 생각이 듭니다.

항상 드는 생각이 미국, 유럽과 비교해서 아시아의 오픈소스 커미터들이 너무 적은것 같습니다.
특히 한국은 더 적은것 같습니다.
활성화 차원에서도 사용은 많이 해도 기여가 적으니, 이유를 찾아서 장애를 없애주는것도
KLDP에서 할 일이라고 생각합니다. :-)

---


Jabber: lum0320@jabber.org

keizie의 이미지

몇몇 버그는 등록되고 나름대로 활발한 논의가 있었지만 그 논의라는 게 위키나 게시판이나 포럼 등 다른 수단에서 이미 나왔던 얘기가 대부분이었습니다. 분야도 주로 한글화에 국한되었죠. 버그질라가 쓰기 어려워 보여서 그랬다고 치고, 게시판 같은 걸로 자유롭게 쓰는 걸 모니터링해서 정리한다고 하면 일단 중복 투고를 어떻게 조절 및 관리할 것이며 (메인에 보고하기도 수고로운데) 중간 단계가 늘어나는 수고까지 감당할 수 있을까 싶습니다.

제 단견으로는 대행을 할만큼 의지가 있다면 (버그 보고 체계를 이해하고 따라올 수 있는 사용자라면 이미 숙련되었다고 봐야 합니다) 그 시간에 메인스트림에 보고하고 설득하는 쪽을 선호하리라 생각합니다. 저는 그렇습니다.

warpdory의 이미지

OS/2 관련해서 IBM 에 문의했더니 돌고 돌아서 한국 IBM 에서 .. 온 답장은 상상을 초월합니다.

-----------------------
안녕하십니까! 한국IBM 대표전화서비스팀입니다.

현재 IBM에서는 OS/2관련 사업을 하고 있지 않으며 제품의 구입 및 서비스가 불가능하십니다.

OS/2는 MS-DOS로 대체하여 사용가능하기 때문에 MS-DOS로 대체하여 사용해 주시면 감사하겠습니다.

문의해주신 내용에 대하여 고객님께 도움을 드리지 못해 대단히 죄송합니다.
오늘 하루도 즐겁고 평안한 하루 되십시오.
...................................................................................................
IBM Korea. 기술지원센터: 1588-5801 / 대표전화서비스: 822-3781-7114 / e-mail: ibmkspoe@kr.ibm.com

IBM의 다양한 소식을 격주로 편리하게 받아보실 수 있습니다.
지금 오른쪽 링크를 통해 e-mail 뉴스레터를 신청해보세요! http://www-903.ibm.com/kr/member
-----------------------

그나마, IBM 에 문의하면, 그게 한국 IBM 으로 돌아와서 '한국 OS/2 사용자 모임에 akpil 이라는 사람 홈페이지에 가서 문의하면 답을 얻을 수 있을 거다.' 라는 답이 아닌 게 다행이기는 합니다. -_- 제가 질문했는데, 그게 돌고 돌아서 저에게 그런 답이 오면 황당하죠.

대체 이놈의 한국 IBM 은 뭐하는 건지 알다가도 모르겠습니다.

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

danby04의 이미지

"OS/2는 MS-DOS로 대체하여 사용가능하기 때문에 MS-DOS로 대체하여 사용해 주시면 감사하겠습니다."
이거 넘 웃기네요

litdream의 이미지

울화가 많이 치미셨겠는걸요?

삽질의 대마왕...

삽질의 대마왕...

litdream의 이미지

답글을 눌러서 달았어야 했는데, 지저분한 포스팅 죄송합니다.
윗글은 OS/2 와 MsDos 관련된 글에 해단 답글입니다.
물론 김정균님의 고충과 전혀 상관없는 글은 아닙니다만,
본의아니게 잘못 포스트된점 사과드리면서.

삽질의 대마왕...

삽질의 대마왕...

ydhoney의 이미지

일단 모든 프로젝트가 같은 형태로 관리되는 것은 아니니 각 프로젝트 관리 형태에 따라서 패치나 피드백을 제공하는 방법이 다를수밖에 없다는 것이 일반 사용자들이 오픈소스에 접근하기에 상당히 장애물이 되곤 합니다. 실제로 해당 프로젝트에 관심을 가지고 큰맘을 먹고 참여하겠다는 생각을 하지 않으면 엄두가 나지 않는 것이지요.

일단 툴 자체의 버그는 약간 수고스럽겠으나 버그 자동 트래킹 시스템을 만드는것이 가장 효율적일테고 (이를테면 윈도우의 경우 뭔가가 이상하게 죽는 경우 MS 사에 해당 버그에 대한 정보를 날려주는 기능이 있지요. dumprep.exe 라는 툴이 작동하면서 말이지요.), 기타 패치 적용의 경우 좀 더 접근이 편리한 방식이 필요하지 않나 하는 생각이 듭니다.

그리고 패치나 피드백을 받는 개발자 입장에서도 위에서 퍼키님께서 말씀을 주시긴 했습니다만, 일단 사용자마다 패치내용을 보내는 형식이 일관되지 않아서 생기는 문제들이 크고 작게 나타나곤 하지요. 역시 모든 프로젝트가 동일하게 운영되는 것이 아니니, 일반적인 사용자나 프로젝트에 가벼운 관심을 가지고 있는 개발자/사용자분들이 해당 프로젝트의 방식을 항상 딱 맞춰서 따라하기는 힘들다는 것이지요. 이런 부분의 경우 주요 공동체에서 피드백이나 패치를 보내려면 어떤 형식으로 보내야 하는가에 대한 논의를 거쳐 적절한 템플릿 양식을 만들어 사용하거나 특정한 Form을 만들어 사용한다면 어느정도 해결할 수 있는 여지가 있지 않나 생각합니다.
 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.