젊은 개발자의 유입을 막는 장벽으로 메일링 리스트를 통한 관리

Microsoft Linux Foundation 이사회 회원인 Sarah Novotny는 다음과 같이 말했습니다. 높은 문제 Linux 커널 개발 프로세스의 구식 특성에 대해 설명합니다. Sarah에 따르면 커널 개발을 조정하고 패치를 제출하기 위해 메일링 리스트(LKML, Linux Kernel Mailing List)를 사용하는 것은 젊은 개발자의 의욕을 꺾고 새로운 유지관리자가 합류하는 데 장벽이 됩니다. 커널의 크기와 개발 속도가 증가함에 따라 다음과 같은 문제가 발생합니다. 부족 커널 하위 시스템을 감독할 수 있는 관리자.

Git에서 직접 패치를 채택하여 GitHub의 "문제" 시스템 및 풀 요청과 유사한 관리자와 개발자 간의 상호 작용을 위한 보다 현대적인 메커니즘을 만들면 젊은 관리자를 프로젝트에 끌어들이는 것이 가능해집니다. 현재의 이메일 기반 개발 관리 프로세스는 많은 젊은 개발자들에게 구식이고 불필요하게 시간이 많이 걸리는 것으로 인식됩니다. 현재 커널 개발자의 주요 작업 도구는 이메일 클라이언트이며, 5~10년 전에 업계에 들어와 현대 협업 개발 시스템에 익숙한 신규 이민자가 이러한 작업 조직에 적응하는 것은 매우 어렵습니다.

불편함은 문자 형식에 대한 엄격한 요구 사항으로 인해 더욱 악화되며, 그 중 일부는 25년 전에 채택되었습니다. 예를 들어, 메일링 리스트에서는 대부분의 이메일 클라이언트가 기본적으로 HTML 마크업을 사용함에도 불구하고 HTML 마크업 사용을 금지합니다. 이로 인해 발생하는 어려움의 예로 HTML 메일을 허용하지 않는 OpenBSD 메일링 리스트에 패치를 보내기 위해 별도의 이메일 클라이언트를 설치해야 하는 동료가 언급되었습니다. 왜냐하면 그의 기본 이메일 클라이언트(Outlook) 때문입니다. HTML 메일을 보냅니다.

확립된 기반을 무너뜨리지 않고 기존 개발자의 습관을 위반하지 않기 위해 풀 리퀘스트나 "이슈"와 유사한 시스템을 통해 메인테이너에게 직접 패치를 제출하고 자동으로 브로드캐스트할 수 있는 신규 개발자용 모드를 만드는 것이 제안됩니다. LKML 메일링 리스트에 올리세요.

또 다른 아이디어는 토론과 발표를 위해 패치에서 LKML을 오프로드하는 것입니다. 현재 형태에서는 수천 개의 문자가 LKML을 통과하며, 그 중 대부분은 커널에 포함되도록 직접 제안된 코드이며, 일부만이 패치 및 토론의 본질을 설명하는 공지입니다. 게시된 패치는 여전히 Git에 반영되며 일반적으로 Git에서 풀 요청을 사용하여 승인되며 LKML은 프로세스만 문서화합니다.

출처 : opennet.ru