MOTU / 개발자 경로를 걷는 데 가장 큰 장벽은 무엇입니까? [닫은]

MOTU 가 아닌 사용자 (유니버스 및 다중 우주 소프트웨어 리포지토리 를 유지 관리하는 사람 )의 경우 "나는 $ date까지 MOTU에 지원할 것"에 대한 계획이 없습니다.

당신과 당신 같은 다른 사람들이 MOTU가 되려고하지 않는 이유는 무엇입니까? 왜 당신이 하나가 될 수 없다고 생각합니까?

저는 사회적, 기술적 장벽을 모두 언급하고 있습니다.

편집 : MOTU는 꽤 일반적인 그룹이기 때문에 MOTU라고 말하고 있지만 "패키징 / 패치 및 궁극적으로 업로드 권한을 시도하지 않으려는 이유는 무엇입니까?" 더 일반적인 버전입니다.

더 나은 문서를 제공하십시오.

나는 패키징 및 MOTU와 관련된 IRC 세션의 개발자 주간 (이미 두 번)에 참여했으며 이러한 세션 동안 일반적으로 프로세스에 대한 모호한 이해가 있음을 발견했습니다. 그러나 2 주 후에 우분투 위키 페이지를 보면 더 이상 모든 조각을 모을 수 없습니다. 이러한 페이지는 종종 프로세스를 자세히 이해하는 사람들의 일종의 글 머리 기호 목록입니다. 그러나 초보자에게는 콘텐츠를 이해하기에 충분하지 않습니다.

따라서 문서 위키 페이지에서 프로세스, 도구 및 관련자에 대해 자세히 설명하도록해야합니다. 또는 완전한 예를 들더라도. IRC 세션 중에는 반복 가능한 예제가 항상있을 수 있습니다. 어쩌면 위키 페이지와 차이가있을 수 있습니다.

가장 큰 기술적 장벽은 데비안 패키지를 만드는 방법을 아는 것입니다. 작업 패키지를 만드는 것은 상대적으로 간단하지만 데비안과 우분투 표준까지 패키지를 만드는 것은 훨씬 어렵습니다. 또한 패키지를 만드는 방법에 대한 가이드는 일반적으로 컴파일이 필요한 소스 코드가있는 상황을 처리합니다. 해석 된 언어로 작성된 응용 프로그램에는 혼동 될 수 있습니다.

가장 큰 사회적 장벽은 아마도 패키지를 우주 / 다중 저장소에 업로드하는 방법을 아는 것입니다. 자신만의 ppa를 만들고 패키지를 업로드하는 것이 훨씬 간단합니다.

요즘 사람들은 드라이브 바이 기부를 좋아 합니다.

20 년 전에는 애완 동물 프로젝트가있는 경우 일반적으로 많은 에너지를 애완 동물 프로젝트에 집중합니다. 오늘날 여러분은 하루에 수십 개의 인터넷 페이지를 방문하며 위키, 포럼 및 기타 자료에 기여할 수있는 많은 소셜 네트워크 또는 기타 커뮤니티가 있습니다. 이로 인해 더 많은 사람들이 기여하게되었지만 장벽이 낮은 항목을 기대하는 사람들로 이어졌습니다 ( "웹 사이트를 클릭하여 편집하기 만하면됩니다").

따라서 MOTU 프로세스에서 장벽을 찾아야합니다. 런치 패드 호스팅 프로젝트의 패치 기여 장벽을 낮추는 GroundControl 프로젝트를 기억합니다. 비슷한 새로운 도구가 필요할 수도 있으므로 새로운 MOTU 후보는 많은 명령 줄 도구를 사용하지 않아도됩니다. 이러한 도구는 강력 할 수 있지만 도구를 올바르게 사용하는 방법을 배우려면 많은 에너지가 필요합니다.

내가 찾은 가장 큰 장벽은 Ubuntu 개발자 페이지입니다. http://www.ubuntu.com/community/get-involved/developers

여러 번, 나는 우분투에 최소한 1 개의 패치를 제공하기로 열성적으로 결심했습니다 ... 그래서 나는 웹 사이트의 자연적인 장소로 가서 ... 몇 시간이 지난 후에도 여전히 패치를 작성해야할지 모르겠습니다. 우분투 버그를 살펴보면 자주 사용되지 않는 패치가 많이 있습니다.

패키지가 진행되는 한, 나는 그것을 만드는 방법을 알아 내려고 노력했지만 실제로 혼란 스럽다. 또한 Launch Pad에 참여하려고 시도했지만 인터페이스가 Source Forge보다 훨씬 복잡하므로 LP에서 자체 코드를 얻을 수 없었습니다. 새로운 사용자에게는 매우 어렵습니다.

MOTU가되는 것은 책임 입니다.

글쎄, 분명히 # 1 이유는 기술적으로 충분히 지식이 없으며, # 2 이유는 당신이하고 싶은 행동이 많기 때문입니다. 그러나 대상 독자 중 가장 큰 이유는 그것이 책임이라고 생각합니다.

내가 직접 패키지를 컴파일하면 아무도 기술 및 법률 정책을 따랐는지 신경 쓰지 않습니다. 더 새로운 버전의 패키지를 기대하는 사람은 아무도 없습니다. 아무도 나에게 버그를 고치라고 요구하지 않을 것이다.

패키지를 ppa에 업로드하면 일부 사람들이 관심을 가질 수 있습니다. 그러나 기대치가 높지 않습니다. 난 그냥 사라져 사람들이 자신의 블로그에 natty narwhal에 해당 패키지를 사용할 수 없다는 것이 얼마나 슬픈 지 불평 할 수 있습니다.

MOTU가되면 갑자기 큰 책임이 있습니다. 사용자가 버그 보고서를 내게 와서 어제 해결하지 않으면 불평합니다. 사용자는 업스트림에서 제공되는 즉시 새 버전의 패키지를 업로드 할 것으로 기대합니다. 비 기술적 인 사용자에게 무엇이 잘못되었는지 알아내는 방법을 설명해야합니다. 포럼에 게시하는 것과 달리, 나는 대답하고 싶지 않은 질문을 무시해서는 안됩니다. 그리고 무언가를 엉망으로해서 다른 개발자들이 나를 따라갈 수도 있습니다.

그리고 나는 무엇을 얻습니까?

• 내가 사람들을 도운 퍼지 느낌. 그것은 중요 할 수 있습니다. 그러나 그것이 나의 주된 동기라면, 패키징 소프트웨어는 수프 키친에서의 도움 또는 직장 외 이민자 이웃의 아이들을 가르치는 것과 어떻게 비교할 수 있습니까?

• 이력서의 요점은? Meh, 프로그래머로서 FOSS에 참여하는 것이 훨씬 더 높이 평가 될 것입니다. (이것은 대학 과정에서 가르치기 어려운 프로젝트 관리 및 장기 근절과 같은 경험을 제공합니다.) 실제로 DD / MOTU가되는 것은 정치적으로 관여하는 직원들에게 눈을 뜬 많은 고용주들에게 의심스러워 보입니다. FOSS에 정치적지지를 공개적으로 제공).

• 만족감? 내 프로그램을 처음부터 작성하는 것보다 훨씬 적습니다. 프로그래밍은 패키징보다 훨씬 창의적입니다. 큰 성취감이 있습니다. 자랑 할 권리가 있습니다. 그러나 포장에서? 집안일입니다. 화려하지 않습니다.

(이것은 위의 3 인칭 "I"입니다. 제가 제공하는 이유는 대부분의 사람들에게 적용되지만 다양한 범위에 적용됩니다. 개인적으로는 주로 내가하고 싶은 행동이 있고, 창의적 성취감이 부족한 포장입니다.)

(호기심으로 우분투에는 인력이 부족합니까?)

Language , 내 주요 문제는 여전히 영어에 대해 확신이 없기 때문에 다른 개발자가 나에게 말하려는 것을 쉽게 이해할 수 없다는 것입니다.

MOTU가 되려면 어떻게해야합니까?

Eventhough Ubuntu는 매우 훌륭한 커뮤니티입니다 (아직도 n00bie 질문에 화를 내지 않았습니다) 포장 프로세스에 대한 문서가 거의 / 불완전하다고 생각합니다 (데비안의 새로운 관리자 안내서도 "이 주제는 범위를 벗어났습니다. 이 문서의 "행). 만약 당신이 그 사실을 이해하고 모국어가 영어가 아닌 사람들에 대해 생각한다면, 그 과정은 훨씬 더 어렵고 성가시다.

간단히 말해서, 모든 것을 문서화하는 것이 우리 모두에게 더 쉬울 것이지만, 기술 문서를 작성하는 사람들은 그 문서를 작성하기에는 너무 바쁩니다.

몇 가지 이유가 있다고 생각합니다. 또한 그 이유는 종종 개인이라고 생각합니다.

현재 문제 중 하나는 전체 MOTU 시스템의 변경입니다. 나는 변화가 혼란 스러울 수 있고 기술적 인 측면에서 더 많이 구현되었으며 불행히도 커뮤니티가 완전히 혼란에 빠지지는 않았다고 생각한다.

또한 어떤 경우에는 MOTU가되기위한 동기가 명확하지 않다고 생각합니다. IMHO, MOTU가되는 것은 특권이 아니라 책임입니다. 제목에 관한 것이 아니라 함께 제공되는 액세스 권한으로 Ubuntu 커뮤니티를 도울 수있는 능력에 관한 것입니다. 이로 인해 전체 승인 프로세스가 수정 (또는 확장) 될 수 있습니다. MOTU는 일반적으로 자신을 지명 한 후 보드가 MOTU가 될 준비가되었는지 확인합니다. 누군가가 MOTU가 될 준비가되었다고 생각하는 동료는 그 사람을 지명 할 수있을 것입니다. 이것은 IMHO가 제목을 얻지 않고 프로세스를 돕기 위해 지명되었다는 사실을 더 많이 나타냅니다. 나는 이것을 유일한 길로 만드는 것도 문제가 있다는 것을 이해하므로 오히려 유일한 대안이 아니라 대안으로 본다.

또한 과거에 사람들이 KDE에 더 집중하는 데 문제가 있음을 알고 있습니다. 이러한 문제는 잘 해결 되었으나, 더 널리 알려지면 좋을 것입니다.

분명히, 이것들은 내가 주목 한 몇 가지 문제 일뿐입니다. 사람들은 다르며 다른 것을 보거나 같은 것에 의해 다르게 영향을받습니다. 따라서 이러한 문제로 모든 사람을 막을 수있는 것은 아니며이 문제의 유일한 원인도 아닙니다.

나는 여기에 몇 가지 아이디어를 게시했습니다 : http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

내가 실제로 제시하고 싶은 한 가지는 얼마나 많은 개발자들이 패키징 도구에 쉽게 연결되는 빌드 시스템을 사용하지 않는지 궁금합니다. 파이썬 개발을하고 있습니다. 내 세계는 setuptools를 중심으로 배포하고 있습니다. 그렇습니다. 내가 가지고있는 것을 가져 와서 내보낼 수 있지만 그 끝은 무엇입니까? 이미 배포 할 수있는 것이 있습니다. 자체 빌드 도구 / 배포 방법으로 스크립팅 언어가 등장하여 데비안 패키징 도구 및 MOTU 레벨과 함께 일할 때 경험이 부족하고 욕구가 생기는지 궁금합니다.

저에게는 아마도 시간과 관련이 있습니다. 현재 투자 할 시간이 없습니다. 그리고 버그 심사를 시작했지만 곧 좀 더 복잡하다는 것을 알게되었습니다. 그리고 실제로 치아를 가라 앉힐 필요가 있습니다.

그런 다음 내가 좋아할 버그 수정이 있습니다. 나를 도와주지 못하게하는 것은 개발 지점이나 무언가를 실행해야한다는 것입니다. 나는 한 번 시스템 모니터에서 내 종이 잘라 내기 작업을 시작했습니다. 버그 수정. 그러나 종속성으로 인해 쉽지 않은 것으로 나타났습니다. 나는 개발 버전에서만 작업하고 수정되었는지 테스트해야한다는 것을 알고 있습니다. 그러나 다른 많은 그놈 패키지의 소스를 다운로드해야했습니다. 지상 통제로는 쉽지 않습니다. 그리고 당신은 아마 작업 기계에서해야합니다. 그래서 나는 거기서 멈췄다. (다시 시작하려면 너무 많은 시간이 걸립니다)

포장에 관해, 나는 포장이 필요한 것을 전혀 모른다. 패키징에 대한 튜토리얼을 한 번 해본 결과 작은 응용 프로그램에서는 그렇게 어렵지 않습니다. 그러나 포장이 필요한 물건의 목록을 찾지 못했습니다.

그래서 기본적으로 그것은 단지 시간입니다. 도와 드리고 싶지만 이상한 주마다 약 두 시간 (2 또는 뭔가)이 있습니다. 그리고 그 작은 시간에 나는 이것을 시작할 수없는 것 같습니다.

패키지를 만들 때 다른 누군가가 패키지를 원하기 때문에 가려움증을 긁는 것이 일반적입니다. Checkinstall은 나를 위해 패키지를 만들기에 충분하며 가려움증이 긁히고 수동으로 패키지를 추가로 가져와 모든 종속성과 물건을 알아낼 개인적인 인센티브가 없습니다.

따라서 배포 용 패키징이 쉬운 경우에도 직접 패키징하는 것보다 훨씬 많은 작업이 필요합니다.