diss
1.0.0
[email protected]에 프로젝트를 게시 한 후 Foss 커뮤니티의 사람들이 Github와 같은 독점적 인 사업 시스템을 사용하는 것에 대한 우려가있을 수 있다는 주목을 받았습니다.
나는 우리의 첫 주 노력의 아카이브로서 레거시 목적으로 이것을 남겨 둘 것입니다.
향후 업데이트는 Gitlab의 새로운 프로젝트 홈과 Gitlab의 새로운 Project Wiki에 있습니다.
이 프로젝트에 관심을 가져 주셔서 감사합니다. Gitlab에서 우리를 따르도록 환영합니다. 새로운 시스템의 WebHook 알림을 지원하기 위해 개발 채널에서 IRC 봇을 업데이트 할 것입니다. 이 프로젝트 페이지를 더 업데이트하지 않을 것입니다.
모든 데비안의 지원 리소스를 상승적으로 통합하고 잘 테스트 한 진단 절차에 간단하고 직관적 인 인터페이스를 제공하는 야심 찬 목표를 가진 프로젝트.
이것은 결코 우리의 모든 기존 리소스를 대체 할 수있는 것은 아니며 실제로는 매우 달라집니다. 이론적 근거는 우리의 시스템이 기하 급수적으로 증가하고 있으며 우리는 "보편적 인 OS"이며, 우리는 지원 자원이 제한되어 있으며 모든 사람이 제한된 지원 자원이 제한되어 있다는 것입니다. 모든 것을 올바르게 사용하는 방법과 순서가 잘 알려져 있고 쉽게 관찰 가능한 많은 문제를 유발하는 방법을 아는 것은 아닙니다.
우리가 이미 해결 한 알려진 문제를 반복적으로 처리하여 팀 소진을 지원하고, 절차와 정책을 설명하고, 당면한 문제와 관련된 정보를 수집해야합니다.
시스템에 대한 이해 부족, 지지자 등과의 비생산적인 상호 작용을 통한 사용자 소외. 그것은 우리의 최고의 지지자들 사이에서 잘 문서화 된 사고 방식이었습니다. 우리는 우리가 우리의 프로젝트에 기여하지 않고 우리의 자원에 대한 추첨이 될 것이기 때문에 경험이없는 사용자를 실제로 원하지 않는다는 것을 포함합니다. 또한 개발자와 숙련 된 사용자가 종종 다른 소프트웨어를 시도하는 데 덜 모험을하는 경향이 있기 때문에 개발자와 숙련 된 사용자가 종종 버그와 문제를 찾는 마지막 사람들이라는 사실은 쉽게 관찰 할 수있는 사실입니다. 그들은 이미 좋아하는 것을 알고 사용하는 방식으로 사용하기 때문에 다른 소프트웨어를 시도하는 데 덜 모험적인 경향이 있기 때문입니다. 모든 종류의 옵션을 시도하고 모호한 오류를 발견하는 방식으로 사물을 사용하려면 경험이없는 사람이 필요합니다. 이것은 우리가 점점 커지는 소프트웨어 기반을 습득하여 우리가 놓칠 수있는 문제를 발견하는 사람들의 경험이없는 사용자를 대량으로하는 귀중한 상품입니다. 그러나 우리는이 귀중한 자원에서 얻은 피드백이 의미가 있고 앞서 언급 한 문제없이 올바른 장소에 감을 수 있도록해야하므로, 우리는 그들의 필요와 우리의 요구에 부응하는 종류의 필터가 필요합니다.
또한이 두 가지 문제에 대한 모든 노력이 활용되도록해야합니다. 즉, 우리는 사용자가 문제를 해결하는 데 대한 자기 이익을 가지고 우리에게 계속 오는 것을 계속할 수 없으며, 그 노력은 제대로 문서화되지 않았기 때문에 활용률이 낮습니다. 일부 사용자는 돌아와서 문제에 대한 솔루션을 공유하고 때로는 사실을 만들어냅니다. 때로는 Wiki 페이지, 버그 보고서 등이 발생하지만 대부분의 경우에는 그렇지 않습니다. 또한, 우리는 문제가 다시 발생했을 때 이것이 완료되었음을 항상 알지 못합니다. 우리의 현재 시스템은 우리의 지지자들에게 이러한 것들을 기억하기 위해 의존하며, 그것을 기억하는 사람들이 당시를보고 있지 않을 때, 우리는 2 번 문제로 돌아가서 사용자를 소외 시키거나, 문제를 전혀, 심지어도 문서화하거나 해결하지 못할 수 있습니다.
Client/Frontend (Readline, Curses, GTK, QT), 진단 (서명 진단 트리 파일), BOT (IRC), 서버 (문제 추적기)
클라이언트는 사용자가 프로그램을 선택할 수있는 ReportBug 스타일 마법사가 될 것입니다 (기술 수준이 낮은 기술 수준에서, "filemanager"와 같은 일반적인 이름을 사용하고 실제 프로그램 이름을 자동으로 감지하거나 사용자가 창을 클릭하고 명령을 클릭하고 명령을받을 수있는 Grab Fuction을 사용하고 다양한 문제에 대한 설명을 입력하고 (네트워크, 사운드, 충돌, 패키지 구성 등)가 있어야합니다. 문제 ID와 이메일은 개인 정보 보호를 위해 사용자에게 다시 튀어 나왔으며, 사용자가 추적기를 이메일로 보내서 중지하라고 지시하여 추적기를 추가로 선택할 수 있습니다).
첫 번째 계층은 진단을 사용하여 간단한 테스트를 수행하고 추가 정기를 요청하고 정보를 수집하고 문제에 대한 보고서/로그를 작성합니다.
로그는 IPS, MAC ID, 사용자 이름, 경로/파일 이름과 같은 개인 데이터를 제거하거나 대체하기 위해 구문 분석/직렬화/멸균되어야합니다.
그런 다음 잘 알려진, 마모 및 전투 테스트 간단한 솔루션을 기반으로 문제를 식별하는 자동 진단 프로세스를 통해 문제를 해결할 수없는 경우, 클라이언트는 두 번째 계층으로 보고서를보고 버그 보고서 (및/또는 포럼/위키 게시물)를 조회하고 이미 가지고있는 기존 지식 데이터베이스에서 사용자에게 표시합니다.
문제가 해결되지 않은 상태로 유지되면 3 단계에서 문제를 문제 추적기로 전달하고 ID 번호를 제공 한 다음 고객 자체 내에서 이미 가지고있는 지원 도구 (IRC/Mailing Lists)로 전달할 수 있으며 IRC를 사용하는 경우 Pianobar의 "문제가 없음"이 발행되지 않은 봇서에 의해 봇이 발행 될 것입니다. 솔루션을 받거나 떠나기로 결정하지 않으면 문제가 열려 있고 메일 링리스트로 전달 될 수 있으며 ID 번호로 트래커 웹 사이트를 방문하거나 트래커의 문제에 대한 이메일 알림을 암송하여 후속 조치를 취할 수 있습니다.
문제가 여전히 해결되지 않으면 BTS (BTS에 대한 보고서 제출, 지지자들이 소프트웨어 문제로 결정함에 따라 BTS에 대한 보고서 제출) 또는 업스트림과 같은 4 단계로 전달할 수 있습니다.
진단 트리 파일은 일종의 XML 또는 그와 같은 종류 일 수 있으며, 서명 및 검증해야 할 것입니다. 핵심 진단 트리는 보고서 버그가하는 일과 매우 흡사 할 것입니다. 시스템에 대한 예비 정보를 수집하고 데베이안, 아치, APT 선구자 등의 특징이 무엇인지에 대해 언급 될 것인지에 대한 설명이 될 것인지 확인합니다. 사운드 테스트를 수행하고 사용자에게 소리를 듣고 믹서를 확인하고 연결을 확인하도록 요청하는 것 등.
이 진단 트리 파일은 또한 해당 문제 유형에 맞는 더 많은 정보를 수집하는 명령을 실행하여 추가 정보 수집을 용이하게합니다. 이러한 명령은 사용자가 표시하고 설명하고 확인해야하며, 보고서/로그/출력이 표시되고 (선택적으로) 개인 정보를 제거하기 위해 구문 분석/직렬화/스택화해야합니다. 이러한 진단은 서명하고 평가해야하며, 문제 추적기는 좋은 포럼의 등급 시스템과 같은 방식으로 그렇게 할 수 있으며, GPG 서명을 사용하면 솔루션을 평가하면 클라이언트가 신뢰를 높이는 것뿐만 아니라 진단의 일부에 기여한 지지자들의 신뢰를 높일 수 있습니다.
가능한 경우 Chroots와 같은 것들에서 커널 기반 보안 메커니즘에 이르는 모든 보안 메커니즘을 사용하여 진단을 잠그기 위해 사용해야하며 가능한 한 간단하고 통제하지 않아야합니다. 우리는 지각 진단 도구를 만들고 싶지 않고 알려진 구성 문제, 간단한 테스트에 대한 간단한 점검, 추가 지원을 위해 데이터를 컴파일하려고합니다.
IRC 봇은 사용자가 IRC 지원 채널에 대한 도관/프록시 일뿐 만 아니라 (많은 토론을 위해) 아마도 사용자를 대신하여 생성 된 사용자 ID 또는 이슈 번호로 사용자를 대신하여 사용자를 대신하여 사용자가 문제와 관련된 내용 만 볼 수 있도록 할 수있을뿐만 아니라, 문제 추적기가 나중에 문제에 대한 문제에 속하는 것이 무엇인지, 우연한 도구에 대한 문제와 기존 도구, WIKI 및 FOROME, WIKI, WIKI, WIKI, WIKI 및 FOROME에 대한 해결책을 알고 있어야합니다. 그런. 이 작업은 다양한 방식으로 수행 할 수 있으며 IRC 클라이언트 스크립트를 작성하거나 클라이언트 기능이 일반적인 Nick과 같이 이러한 ID를 탭하여 사용하는 데 사용될 수 있습니다. 또는 지지자가 봇이 "로그온"하도록 메시지를 보내서 봇과 대화하면 정보를 서명 한 사용자에게 다시 보낼 수 있습니다.
봇은 또한 진단에 의해 수집되고 사용자가 제출 한 정보를 사용하여 컴파일 된 보고서에 대한 액세스를 용이하게하여 매우 일반적인 명령을 실행하고 페이스트 빈 등을 사용하는 것에 대한 모든 수다쟁이를 강화합니다. 또한 BOT는 일반적인 독립형 IRC 클라이언트의 누군가가 추적기 (필요한 경우에도 알려져 있고 등록 된 지지자에 의해서만)에서 새로운 문제를 열기위한 클라이언트 인터페이스로 작동 할 수 있습니다.
간단히 말해서 봇은 IRC 지원 채널에 Diss를 바인딩하는 접착제이며, 사용자의 선호 언어, 데비안의 지점에 따라 정보가 올바른 채널에 감기되도록주의를 기울여야합니다. 심지어 다른 채널에 대한 특정 채널을 가지고 있기 때문에 다른 채널에 대한 특정 채널을 가지고 있기 때문에, 그들이 가지고있는 패키지 또는 발행 Catergory에 따라 어떤 패키지 또는 발행을하는지에 따라 어떤 패키지 또는 발행을하는지가
추적기에는 문제에 관한 메타 데이터가 포함되며, 문제 식별자를 생성하고, 사용자가 제공 한 CC 주소를 추적하고, 보고서가있는 위치 (Paste.debian.net 가능성이 가장 높음) 및 포럼, 메일 목록, BTS 또는 고객 또는 지지자 가이 문제에 연결할 수있는 다른 것들을 추적합니다. 그것은 일종의 새로운 Wiki 또는 포럼 그 자체가되어서는 안되며, 문제에 대한 메타 데이터와 함께 연결하고 붙이는 프론트 엔드 일뿐입니다. BTS와 비슷한 웹 인터페이스가 있어야합니다.
문제와 버그는 다릅니다. 버그는 소프트웨어의 실제 문제로, 문제는 종종 Pebcak 또는 그와 같은 경우에만 있습니다. 그렇기 때문에 새로운 트래커를 만들어야하는 이유입니다.이 추적기는 문제를 단기 추적하고 올바른 최종 휴식 장소에 도달하는 데 도움이되기 때문입니다. 트래커는 봇과 클라이언트에게 기존 정보 봇에 사실을 제작하는 데 필요한 정보를 제공하고, 버그 보고서를 제출하거나, 메일 링리스트에 이메일을 발행하고, 관심있는 당사자가 어떤 일이 발생했는지, 어디에서 찾을 수 있는지 알아낼 수있는 장소 역할을합니다. 그것은 우리의 모든 기존 시스템을 대체하는 것이 아니라 래퍼입니다. 우리가 이미 가지고있는 모든 구성 요소를 포함하여 Diss의 모든 구성 요소를 결합시키는 것은 접착제입니다.
우리는 단순히 기존 시스템을 개선하는 것이 여러 번 제안되었으며, 이는 이것의 일부입니다. 그러나 그것은 대신이 아닙니다. 그것은 여전히 문제 #2를 소외시키는 문제가 여전히 있어야합니다. 이것은 OS 자체의 소프트웨어가 1 년 이상의 학습 정책과 실습이 필요하지 않은 직관적 인 방식으로 모든 것을 사용하여 통합하고 촉진하는 소프트웨어입니다.
기존 시스템 개선과 관련 하여이 프로젝트와 그 기고자들은 등록이 필요한 모든 데비안 지원 시스템에서 등록을 통합하고 해당 시스템의 현재 팀과 협력하여 시너지 효과로 통합 할 것입니다.
또한 기존 시스템은 다른 영역에서 작업하는 현재 개발자의 탈진시 사용/조정 될 수 있습니다. 예를 들어 BTS와 트래커는 하나 일 수 있으며 이러한 "문제"는 관리자가 귀찮게하지 않는 훨씬 더 낮은 버그가 될 수 있으며 보고서는 다른 기능을 포함시키기 위해 확장 될 수 있으며, 기존 IRC 봇은 기능을 추가 할 수 있습니다. 이것은 단일 새로운 소프트웨어를 만드는 것을 목표로하는 프로젝트 일뿐 만 아니라 앞으로 우리에게 더 나은 서비스를 제공하기 위해 우리가 지금 필요한 모든 것을 적응시키는 것입니다.
프로그래머가 필요합니다. Python에 능숙한 사람들은 이러한 작업에 적합한 것처럼 보이며, 코딩하기 쉽고 기본 시스템 외부에서 적은 종속성으로 필요한 것들을 개발할 수있을 정도로 강력하고 유연합니다. 신뢰 기반 시스템 및 서비스, GPG 서명 등을 능가하는 사람들. GUI/Frontend 프로그래밍 경험이있는 사람들. 데비안 개발 과정에 익숙한 사람들과 사용자와 개발자 모두의 모든 관심사. 소켓, HTTP, 이메일 프로토콜 등을 사용하여 클라이언트/서버 네트워크 스택을 프로그래밍 할 수있는 사람들은 데비안 지원 시스템을위한 강력한 API를 개발할 수있는 사람들이 효과적으로 통신 할 수 있으므로 웹에서 애플리케이션을 통합 해야하는 지식이 필요합니다.
우리는 기존 시스템에 대한 입력 및 계획, 기존 팀의 노력이 필요하며 모든 데비안 사이트 및 서비스에서 작동하는 균일 한 데비안 로그인 자격 증명 시스템을 통합 할 수 있도록 지원합니다.
우리는이 프로젝트의 웹 존재와 문서화 및 인터페이스 작업을 수행하여 상태 정보 및 프로젝트 목표를 명확하게 정의하는 사람들이 필요합니다.
이 프로젝트는 2017 년 10 월 13 일 금요일의 이른 아침 시간에 미국/EST 시대에 시작되었습니다. 이 글을 쓰는 시점에서 우리는 24 시간에도 들어 가지 않았으며, 이미 6 명 정도의 사람들이 채널에 어울리고 있으며 다양한 포럼에 응답합니다. 우리는이 시점에서 아이디어를 던지고 프로젝트와 디자인을 형성 할 예비 결정을 신중하게 결정하려고 노력하고 있습니다.
여기서 첫 번째 목표는 위키와 함께 확고한 웹 존재를 설정 하고이 통합 시스템의 해부학과 진행 상황을 다이어그램하여 사람들이 우리가 어디에서 왔는지, 어디로 가고 있는지, 얼마나 멀리 있는지 이해할 수있는 것입니다.
두 번째 목표는이 시스템의 기능과 통신을 정의하는 API를 살펴 보는 것입니다. 저는 경험이 풍부한 프로그래머가 아니지만 수십 년 동안 수행 한 것을 보았습니다. 때로는 다른 것을 만들기 위해 무언가 (도구)를 만들어야하는 것을 보았습니다. 처음에는 문제 추적기가 없으면 문제는 지속되지 않을 것이며, 단순히 개발 채널에 살고있는 초보 봇과 대화하는 클라이언트 일 것입니다.
이것은 우리가 빠르게 밀고 배포하고자하는 것이 아니라는 점을 강조해야합니다. 우리는 아직 작업 프레임 워크를 얻고 API가 아직 없기 때문에 통합을 촉진하기 위해 기존 서비스를 수정하지 않고 일반 채널 외부의 광범위한 알파 테스트를 수행하려고합니다. 관리자와 Debian Developer Circle 내에있는 구성 요소와 관심이있는 구성 요소와 관심이 있으면 비 생산 테스트/불안정한 시스템에서만 사용하기위한 베타 테스트 단계를 시작하고자합니다. 진단을위한 안전한 신뢰 메커니즘의 구현에 대한 확신이 있으면 시스템은 실제로 SID를 위해 포장되어 미래의 데비안 안정 릴리스로 출시 될 수 있습니다. 진단 파일은 별도의 엄격한 테스트 및 서명/검증 프로세스를 기반으로 새로운 데비안 릴리스주기를 기다리지 않고 시간이 지남에 따라 개발 될 수있는 일종의 저장소를 사용할 가능성이 높습니다.
장기적으로 Debian Installer는 일반/전문가 설치 모드 이상의 첫 단계로보다 강력한 기술 결정을 내리고 있으며,이 지원 클라이언트는 고급 또는 전문가 수준을 선택하지 않는 시스템에 기본적으로 자동 설치됩니다. 우리는 모든 지지자들이 자유 범위 지원뿐만 아니라 신뢰 기반 시스템에 등록하고 GPG 서명을 사용하여 지식 기반이 더 높은 품질과 신뢰할 수있는 것을보고 싶습니다.
Diss Wiki
레딧 스레드
데비안 포럼 트레드
데비안 프로젝트 메일 링리스트 스레드
데비안-데벨 메일 링리스트 스레드
데비안 사용자 메일 링리스트 스레드
2017 년 3 월 Debian-Project Mailing List의 관련 게시물
