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


26

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

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

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

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


7
나 같은 것을 모르는 사람들을 위해 MOTU를 wiki.ubuntu.com/MOTU 로 연결하십시오.
Steve Armstrong

1
링크가 도움이 될 것에 동의합니다. 그러나이 질문은 사람들이 왜 특정 일의 일부가 아닌지에 관한 것이므로 실제로 문제의 전문 용어를 설명하는 것이 좋습니다.
moberley

@moberley : MOTU는 우분투 아카이브의 유니버스 (및 멀티 버스) 섹션에 패키지를 업로드 할 수있는 개발자입니다.
txwikinger

내 ubuntu-dev 및 ubuntu-coredev 멤버쉽을 갱신하지 않고 프로세스를 다시 진행할 시간을 없애지 않기 때문에 MOTU / coredev가 더 이상 아닙니다. ;-)
ℝaphink

1
질문 스타일로 인해 커뮤니티 위키로 변환되었습니다.
Marco Ceppi

답변:


11

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

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

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


2
위키 페이지가 그다지 도움이되지 않는다는 데 동의합니다. YouTube에서 Daniel Holbach의 동영상이 처음 시작할 때 가장 도움이된다는 것을 알았습니다. IRC 세션의 로그가 위키에 게시됩니까?
maco

14

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

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


11

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

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

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


3
쉘 스크립팅은 패키징의 중요한 부분이기 때문에 쉘 유지 패키지를 사용할 수없는 사람들의 아이디어를 좋아하는지 모르겠습니다. 즉, 많은 패키지를 만들기 위해 작성 / 수정 해야하는 쉘 스크립트가 있습니다. 작업).
maco

@maco : 새로운 기고자를 원하십니까? 그렇다면 프로세스에 관련된 사람들 만이 아니라 프로세스를 변경해야 할 수도 있음을 인정해야합니다. 엘리트 주의적 사고는 잠재적 인 공동체의 상당 부분을 배제 할 것이다. 그리고 시작하기 위해 분산 된 노력을 기울이고 싶다면 명령 행은 일반적으로이를 지원하기에 매우 나쁜 도구입니다.
Bananeweizen

1
"커널 패치를 작성하려면 C를 알아야한다"는 말은 엘리트 주의자입니다. 패키지에 들어가는 스크립트를 작성하기 위해 명령 행이 어떻게 작동하는지 알아야합니다. 패키지를 만들기위한 GUI가 있어도 "postinst 쉘 스크립트를 여기에 입력하십시오"텍스트 상자가 나타납니다.
maco

1
제 의견은 기술적 인 필요성에 관한 것이 아닙니다. 나는 다시 말하려고 노력할 것이다 (나는 영어를 모국어로 사용하는 사람이 아니다) : 먼저 추가 기고자를 요청한다. 나중에 나는 당신의 의견을 읽었습니다 : 만약 당신이 쉘 스크립트를 작성할 수 없다면, 패키징에 참여하는 것을 바보로 만들어야합니다. 저를 화나게합니다. 나는 여전히 당신의 가정이 잘못되었다고 생각합니다. 지상 통제까지 모든 사람들은 LP에서 일부 프로젝트를 패치 할 수있는 버전 관리 시스템을 알아야했습니다. GC는 버전 제어를보다 쉽게하는 대신 패치의 단일 사용 사례에 집중하여 버전 제어 시스템에 대해 알아야 할 필요성을 제거했습니다.
Bananeweizen

1
나는 아무데도 "멍청한"말을하지 않았다. 나는 그것이 필요한 기술이라고 말했다. 어떤 다소 복잡한 패키지의 경우 것입니다 쉘 스크립트를 작성해야합니다. 무지 ( 아직 특정 기술을 배우지 않은 )와 지능은 결코 같지 않습니다.
maco

9

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

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

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


2
예, 런치 패드 디자인에 문제가 있습니다. LP에 대해서는 명확하지 않습니다. 쉽지만 많이 찾아야합니다. 새로운 사용자는 빨리 길을 잃습니다. GitHub와 같이보다 명확하고 간단하게하려면 재 설계가 필요합니다.
Owais Lone

8

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

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

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

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

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

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

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

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

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

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

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


1
그렇습니다. 우리의 버그 추적기를 보셨습니까?
maco

@maco : MOTU 페이지 에서 MOTU가 무엇이며 어떻게 될 수 있는지 쉽게 알 수 있습니다. "우분투 삼촌이 당신을 필요로합니다!" 버그 트래커가 일반 사용자에게 많은 것을 알려주지 않는다고 생각합니다. 예를 들어, 닫히지 않은 많은 버그는 버그를 재현하기에 충분한 정보를 게시하지 않은 많은 보고서 및 실행 사용자를 의미 할 수 있습니다.
Gilles 'SO- 악마 그만'

나는 Gilles에 전적으로 동의해야합니다. 오픈 소스에 더 많은 시간을 할애한다면 프로그래밍하고 싶은 몇 가지 프로젝트가 있습니다.
Javier Rivera

그런 버그가 많이 있지만 결국에는 비 활동으로 인해 닫힙니다. 런치 패드에 패치가 첨부 된 ~ 2000 개의 버그가 있습니다. Cleansweep 작업은 패치를 검토하고 검토하여 양호하면 업스트림으로 전송하고 불량이면 거부합니다. 이들이 양호하고 업스트림 릴리스를 통과하기 위해 전체 릴리스주기를 기다리지 않아야하는 경우 패키지화해야합니다. 많은 사람들이 나이가 들었지만. 우리는 그들이 제출 한 요금을 따라 가지 않았습니다.
maco

4

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


3

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

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

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


3

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

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

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

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

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


스폰서 해야한다 "헤이, 어쩌면 당신은 지금 적용해야"누구의 패키지 그들은, 준비가 생각할 때 그들이 후원하는 사람들을 이야기 할 수 있지만, 나는 그런 일이 얼마나 자주 모른다. 나는 멘토링을하고있는 한 사람에게 지원할 것을 제안했지만, 그는 다른 개발 분야로 초점을 바꾸었다.
maco

스폰서가 누군가에게 신청을 요청하거나이 사람이 스폰서에 의해 지명 될 때 여전히 차이가 있습니다.
txwikinger

어? 스폰서는 사람을 추천하지 않으며 스폰서는 자체 추천을 옹호합니다.
lfaraone

lfaraone : txwikinger는 스폰서가 사람들을 추천 할 수 있어야한다고 제안합니다. 한 번 일어났다. 일부 사람들은 사라 홉스 (Sara Hobbs)를위한 위키 페이지를 만들어 TB에 이메일을 보내어 평가를 보냈으며, 그 시점까지 분명한 지원이 쏟아 질 때 까지 IRC 회의에 참석하여 마지막 단계를 밟았습니다.
maco

2
@Ifaraone : 좋은 사람들이 스스로 추천하지 않기 때문에 잃어 버리 겠다는 제안입니다. 결국 MOTU가되는 좋은 사람은 우분투의 승리입니다. 어쩌면 우리는 이것에 대해 생각해야합니다.
txwikinger

2

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

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


2

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

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

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

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


종속성의 소스가 필요하지 않고 일반 뎁만 필요합니다. 개발 릴리스의 VM이 작동하도록 설정하지 않는 이유는 무엇입니까? 그런 다음 설정에 신경 쓰지 않아도됩니다 (2007 년 2 월 이후 거의 지속적으로 개발 릴리스를 실행했습니다 ... 우분투 버그 패키징 / 수정과 관련된 작업을 시작하기 1 년 이상 전에). 환경을 설정 한 후에는 일주일에 2 시간 동안 버그를 수정하는 것이 가능합니다. 패키징 할 것들의 목록과 관련하여 Launchpad에는 패키징 태그가 있습니다. 기존 패치를 패키징하는 것도 매우 유용합니다!
maco

1

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

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.