I2P 제안 프로세스 | Proposals | I2P - 보이지 않는 인터넷 프로젝트

Overview

이 문서는 I2P 사양을 변경하는 방법, I2P 제안이 작동하는 방식, 및 I2P 제안과 사양 간의 관계를 설명한다.

이 문서는 Tor 제안 프로세스에서採用되었으며, 아래의 많은 내용은 원래 Nick Mathewson이 작성하였다.

이 문서는 정보 제공을 위한 문서이다.

Motivation

이전에는 I2P 사양을 업데이트하는 우리의 프로세스가 상대적으로 비공식적이었다: 개발 포럼에서 제안을 만들고 변경 사항을 논의한 다음, 일치된 후 사양을 초안 변경 사항으로 패치하고(반드시 그 순서대로는 아님), 최종적으로 변경 사항을 구현하였다.

이것은 몇 가지 문제가 있었다.

첫째, 가장 효율적인 경우에도 이전 프로세스는 종종 사양과 코드가 일치하지 않는 경우가 있었다. 최악의 경우는 구현이 연기된 경우였다: 사양과 코드가 버전이 변경될 때까지 일치하지 않는 경우가 있었다.

둘째, 논의에 참여하기가 어려웠다. 왜냐하면 언제든지 논의 스레드의 어느 부분이 제안의 일부인지, 또는 사양에 어떤 변경 사항이 구현되었는지 명확하지 않았기 때문이다. 개발 포럼은 I2P 내에서만 접근할 수 있으므로, 제안은 I2P를 사용하는 사람들만 볼 수 있었다.

셋째, 제안이 포럼 스레드 목록의 여러 페이지 뒤로 묻히기 때문에 일부 제안을 잊어 버리기 쉽かった.

How to change the specs now

첫째, 누군가가 제안 문서를 작성한다. 그것은 변경해야 할 내용을 자세히 설명해야 하며, 그것을 구현하는 방법에 대한 아이디어를 제공해야 한다. 충분히 발전하면 그것은 제안이 된다.

RFC와 마찬가지로, 모든 제안에는 번호가 있다. 그러나 RFC와는 달리, 제안은 시간이 지남에 따라 변경될 수 있으며, 최종적으로 승인되거나 거부될 때까지 동일한 번호를 유지한다. 각 제안의 기록은 I2P 웹사이트 저장소에 저장된다.

한 번 제안이 저장소에 있으면, 우리는 해당 스레드에서 그것을 논의하고 일치된 좋은 아이디어인지, 구현할 수 있을 만큼 충분히 자세한지 확인할 때까지 그것을 개선해야 한다. 이것이 발생하면, 우리는 제안을 구현하고 사양에 통합한다. 따라서, 사양은 I2P 프로토콜에 대한 정식 문서이다: 구현된 기능에 대한 정식 문서는 절대 제안이 아니다.

(이 프로세스는 Python Enhancement Process와 매우 유사하지만, 주요 차이점은 I2P 제안이 구현 후 사양에 다시 통합된다는 것이다. 반면에 PEP는 새로운 사양이 된다.)

Small changes

まだ, 코드를 거의 즉시 작성할 수 있거나 코드 변경이 필요하지 않은 경우에 사양에 직접 작은 변경 사항을 만들 수 있다. 이 문서는 현재 개발자의 의도를 반영한다. 미래에 항상 이 프로세스를 사용할 것이라는 영구적인 약속이 아니다: 우리는 정말 흥奮하고 카페인이나 M&M에 의해 자극된 밤새도록 해킹 세션에서 무언가를 구현하기 위해 달려가도 좋다.

How new proposals get added

제안을 제출하려면, 개발 포럼에 게시하거나 제안이 첨부된 티켓을 생성한다.

한 번 아이디어가 제안되면, 적절하게 형식화된(아래 참조) 초안이 존재하고, 활발한 개발 커뮤니티 내에서 대략적인 일치가 존재하는 경우, 제안 편집자가 공식적으로 제안을 추가한다.

현재 제안 편집자는 zzz와 str4d이다.

What should go in a proposal

모든 제안에는 다음 필드를 포함하는 헤더가 있어야 한다:

:author:
:created:
:thread:
:lastupdated:
:status:

author 필드는 이 제안의 저자의 이름을 포함해야 한다.
thread 필드는 이 제안이 원래 게시된 개발 포럼 스레드에 대한 링크 또는 이 제안을 논의하기 위해 생성된 새 스레드에 대한 링크가 되어야 한다.
lastupdated 필드는 초기에 created 필드와 동일해야 하며, 제안이 변경될 때마다 업데이트되어야 한다.

다음 필드는 필요에 따라 설정되어야 한다:

:supercedes:
:supercededby:
:editor:

supercedes 필드는 이 제안이 대체하는 모든 제안의 쉼표로 구분된 목록이다. 이러한 제안은 거부되어야 하며, supercededby 필드는 이 제안의 번호로 설정되어야 한다.
editor 필드는 이 제안에 상당한 변경 사항이 있지만 내용을 크게 변경하지 않는 경우에 설정되어야 한다. 내용이 크게 변경되는 경우, 추가적인 author를 추가하거나, 이 제안을 대체하는 새로운 제안을 생성해야 한다.

다음 필드는 선택 사항이지만 권장된다:

:target:
:implementedin:

target 필드는 이 제안이 구현되기를希望하는 버전을 설명해야 한다(만약 Open 또는 Accepted인 경우).
implementedin 필드는 이 제안이 구현된 버전을 설명해야 한다(만약 Finished 또는 Closed인 경우).

제안의 본문은 이 제안이 무엇인지, 무엇을 하는지, 어떤 상태인지 설명하는 Overview 섹션으로 시작해야 한다.

Overview 이후, 제안은 더 자유롭게 된다. 제안의 길이와 복잡성에 따라, 제안은 적절한 섹션으로 나누거나, 짧은 논의 형식을 따를 수 있다. 모든 제안에는 다음 정보를 포함해야 한다. 그러나 이러한 정보가 이러한 이름의 섹션에 포함될 필요는 없다.

Motivation: 이 제안이 무엇을 해결하려고 하는가? 왜 이 문제가 중요하나요? 여러 가지 접근 방식이 가능하다면, 왜 이 접근 방식을 취하는가?
Design: 새로운 또는 수정된 기능이 무엇인지, 어떻게 작동하는지, 어떻게 상호 작용하는지, I2P의 나머지 부분과 어떻게 상호 작용하는지에 대한 높은 수준의 보기. 이것은 제안의 주요 본문이다. 일부 제안은 Motivation과 Design으로 시작하여 Design이 약간 맞을 때까지 사양을 기다릴 수 있다.
Security implications: 제안된 변경 사항이 익명성에 미치는 영향, 이러한 영향이 얼마나 잘 이해되는지 등에 대한 설명.
Specification: 이 제안을 구현하기 위해 I2P 사양에 추가해야 할 내용에 대한 자세한 설명. 이것은 사양이 최종적으로 포함할 내용과 거의 동일한 수준의 자세함이어야 한다. 독립적인 프로그래머가 이 제안의 사양을 기반으로 호환되는 구현을 작성할 수 있어야 한다.
Compatibility: I2P의 버전이 이 제안을 따르는 경우, 버전이 이 제안을 따르지 않는 경우와 호환되는지 여부. 호환성이 가능하다면, 어떻게 호환성을 달성할 수 있는지 설명한다. 일반적으로, 우리는 호환성을 유지하려고 노력한다. 2008년 3월 이후 “flag day” 변경을 하지 않았으며, 다시 한 번 하지 않으려고 한다.
Implementation: 이 제안이 I2P의 현재 아키텍처에서 구현하기 어려울 경우, 문서에는 구현 방법에 대한 일부 논의가 포함될 수 있다. 실제 패치는 공개 monotone 브랜치에 또는 Trac에 업로드되어야 한다.
Performance and scalability notes: 이 기능이 성능(메모리, CPU, 대역폭) 또는 확장성에 영향을 미칠 경우, 성능 저하를 피하고, 중요하지 않은 성능 개선에 시간을 낭비하지 않도록 영향을 분석해야 한다.
References: 이 제안이 외부 문서를 참조하는 경우, 이러한 문서가 나열되어야 한다.

Proposal status

Open: 논의 중인 제안.
Accepted: 제안이 완료되었으며, 구현할 계획이다. 이 지점 이후로, 제안의 실질적인 변경 사항은 피해야 하며, 프로세스가どこ선가 실패한 표시로 간주되어야 한다.
Finished: 제안이 승인되어 구현되었다. 이 지점 이후로, 제안은 변경되어서는 안 된다.
Closed: 제안이 승인되어 구현되었으며, 주요 사양 문서에 병합되었다. 이 지점 이후로, 제안은 변경되어서는 안 된다.
Rejected: 우리는 이 제안에서 설명한 기능을 구현하지 않을 것이다. 그러나 우리는 이 제안의 다른 버전을 구현할 수 있다. 자세한 내용은 문서의 댓글을 참조하라. 이 지점 이후로, 제안은 변경되어서는 안 된다. 다른 버전의 아이디어를 제기하려면, 새로운 제안을 작성해야 한다.
Draft: 이것은 아직 완전한 제안이 아니다. 아직 누락된 부분이 있다. 새로운 제안을 추가하지 말고, 대신 “ideas” 하위 디렉토리에 넣어라.
Needs-Revision: 제안의 아이디어는 좋지만, 제안이 있는 그대로는 심각한 문제가 있어 승인될 수 없다. 자세한 내용은 문서의 댓글을 참조하라.
Dead: 제안이 오랫동안 건드려지지 않았으며, 곧 완료될 것 같지 않다. 새로운 후원자가 나타나면 다시 “Open"으로 될 수 있다.
Needs-Research: 이 제안이 좋은 아이디어인지 여부를 명확히 하기 전에 해결해야 할 연구 문제가 있다.
Meta: 이것은 제안이 아니다. 제안에 대한 문서이다.
Reserve: 이 제안은 현재 구현할 계획이 없지만, 나중에 이 제안에서 설명한 것과 유사한 것을 하기로 결정하면 다시 살릴 수 있다.
Informational: 이 제안은正在進行中인 마지막 단어이다. 이것은 새로운 하위 시스템에 대한 새로운 사양으로 복사 및 붙여넣기되지 않는 한 사양이 되지 않을 것이다.

편집자는 일치된 의견과 자신의 재량에 따라 제안의 올바른 상태를 유지한다.

Proposal numbering

000-099는 특별한 메타 제안을 위한 예약 번호이다. 100 이상은 실제 제안에 사용된다. 번호는 재사용되지 않는다.