현재 릴리스에 패치를 포함시킬 수 있습니까? 그렇다면 어떻게?

그래서 얼마 전 Compiz 's Place Window plugin에서 버그 가보고 되었습니다 . 영향을받는 사람들에게는 상당히 큰 회귀입니다. 주로 그놈 폴백을 사용하는 사람들은 보고서에 의해 판단됩니다.

패치는 얼마 후 등장했습니다. 테스트를 위해 PPA를 만들었으며 지금까지 관련된 모든 사람이 문제가 해결되었다고보고했습니다. 심지어 다른 버그 도 수정 합니다. 나는 표준 Unity 데스크탑으로 테스트를 수행했으며 (테스트를 위해) 부작용이 보이지 않았다고 말할 수 있습니다.

나는 이것을 두 가지 주요 이유로 우분투에 지금 밀어 넣고 싶다.

• 난 이기적이야. Compiz의 새 버전이 12.04로 푸시 될 때마다 PPA를 업데이트하고 싶지 않습니다.
• 우분투 사용자가 어리석은 작은 버그로 인해 창을 날아 다니는 것을 원하지 않습니다.

이 패치가 가능한 빨리 Ubuntu의 Compiz 버전에 적용되기를 원하므로 이러한 버그를 수정 한 것으로 표시하고 우리의 삶에 나아갈 수 있습니다.

이것을 우분투로 끌어 당기려면 누구의 다리를 껴안아 야합니까?

나는이 프로젝트를 유지하지 않고 그것은 업스트림 일이지만 우분투에 상당히 필수적입니다. Compiz에 갈 수는 있지만 패치를 수락하면 Ubuntu 근처에 있기 전에 수개월 (최소한의 릴리스)이 될 것이라고 생각합니다.

그리고 올바른 사람을 찾을 때 가능한 한 매끄럽게 프로세스를 만들 수 있습니까?

나는 그들이 내 요청을 보길 원한다. "그래, 모두 훌륭해 보인다." 나는 패치의 측면을 다루는 17 라운드의 이메일을 원하지 않습니다. 더 중요한 것은, 그들의 시간도 낭비하고 싶지 않다는 것입니다.

그리고 무엇을 제공해야합니까? 내 포장 기술은 ... 탄탄합니다. 이것은 재배포를 위해 패키지를 패치하는 첫 번째 시도 였으므로 모든 단일 패키징 오류를 사람에게 알려주었습니다. 원래 패치에 만족할까요 (그래서 직접 적용 할 수 있습니까) 또는 diff / changelog가 약간 깨끗해 지도록 패키지를 다시 만들어야합니까 (몇 번 갔고 버전 관리가 완료되었습니다).

_{참고 : 이 질문 은 Compiz 에 관한 것이지만 답변이 다른 스타일의 패키지도 해결할 수 있다면 문제를 해결하는 방법에 대한 권위 있고 포괄적 인 스레드가 필요합니다.}

Dobey가 언급했듯이 패치가 이미 릴리스 된 Ubuntu 버전으로 승인 되려면 안정 릴리스 업데이트 를 거쳐야합니다. SRU ( ) 프로세스를 . SRU 입장의 기준은 매우 높습니다. 프로세스의 배후에있는 생각을 요약하는 간단한 방법은 "우리가 아는 버그가 우리가 모르는 버그보다 낫습니다." 실제로, 그것은 목표로하는 버그 수정 만이 허용되고 너무 "간섭"하지 않는 변경은 없음을 의미합니다.

SRU를 진행하려면 몇 가지 요구 사항이 충족되어야합니다.

• 버그는 현재 개발 릴리스 (즉, quantal)에서 수정되었습니다.
• 버그 보고서의 설명은 안정 릴리스에서 픽스가 필요한 이유에 대한 정당화, 버그를 재현하고 수정되었는지 테스트하기위한 테스트 케이스 및 픽스의 회귀 가능성에 대한 설명을 포함하도록 업데이트되어야합니다.
• 런치 패드 팀 ubuntu-sru은 버그 보고서를 구독해야합니다.
• 그런 다음 패키지가 릴리스되어 업로드됩니다. -proposed이를 위해서는 스폰서 쉽 프로세스 를 거쳐야 합니다 (자세한 내용은 아래 참조).

모든 일이 끝나면 SRU 팀은 패키지 -proposed가 버그 를 해결 하는지 확인 합니다. 그런 다음 -updates최소 7 일의 노화 기간이 지난 후 패키지가 푸시됩니다 .

적합한 사람 찾기

당신의 질문은 때때로 Launchpad가 패치가 죽는 곳처럼 보인다는 사실을 암시합니다. 슬프게도, 프로세스를 모르면 그렇게 느낄 수 있지만 실제로 그렇게 나쁘지는 않다고 맹세합니다. 운 좋게도 알아야 할 주요 사항은 간단합니다. 모든 세부 사항 및 힌트에 대해서는 후원 프로세스 를 확인하십시오 . 그러나 가장 중요한 부분은 ubuntu-sponsors팀을 버그 보고서에 등록하는 것입니다. 이를 통해 스폰서 쉽 대기열에 나타나고 정직한 우분투 개발자에게 진심으로 다가 갈 수 있습니다.

실시간으로 무언가 이야기해야 할 경우 #ubuntu-develFreenode IRC에서 트릭을 수행합니다. 현재 패치 파일럿에 대한 채널 주제를 확인하십시오. 그들은 당신을 돕기 위해 있습니다. 근무중인 조종사가없는 경우 채널에서 도움을 요청하십시오. 그러나 인내심을 가지십시오.

모든 준비 완료

프로세스를 최대한 빨리 진행하려면 몇 가지해야 할 일이 있습니다.

버그 설명을 다음과 같이 업데이트하십시오.

[타격]

다음은 버그가 사용자에게 미치는 영향에 대한 설명과 픽스를 안정 릴리스로 백 포트하는 이유에 대한 설명입니다.

[테스트 케이스]

1. 단계

2. 으로

3. 단계

4. 명령

5. 확인하기

6. 수정

[회귀 잠재력]

다음은 회귀 가능성에 대한 설명입니다.

[원본 보고서]

설명에 있었던 모든 것은 아래에 유지됩니다.

다음으로 패치를 준비하십시오. 업스트림 소스에 대한 패치가 아닌 모든 패키징 비트를 처리 하는 debdiff 를 제공하면 상황이 훨씬 빨라집니다 . 패키지 패치 시스템을 사용하는 경우이를 포함합니다. 다행히 add-patch에서 우분투는-DEV-도구는 당신을 위해 돌볼 수 있습니다.

이 과정을 살펴 보겠습니다. 먼저 버그 보고서에서 소스와 패치를 가져옵니다.

$ pull-lp-source compiz precise
$ wget https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/974242/+attachment/3141645/+files/fix-974242.patch 

이제 소스 패키지에 패치를 추가합니다 :

$ cd compiz-0.9.7.8/
$ add-patch ../fix-974242.patch

이 패치를 추가 할 것입니다 debian/patches실행 dch하는 새로운 항목을 추가 할 수하라는 debian/changelog제안 대상 항목을 조정하고 개발 버전으로 업로드 한 다음 버전 이하로 될 수 있도록 버전 번호가 증가합니다. 이렇게 :

compiz (1:0.9.7.8-0ubuntu1.1) precise-proposed; urgency=low

  * debian/patches/fix-974242.patch: [DESCRIBE CHANGES HERE]

 -- Your Name <you@example.com>  Mon, 11 Jun 2012 17:37:59 -0400

의 파일에는 debian/patches/fix-974242.patch편집 할 헤더가 있습니다.

## Description: add some description
## Origin/Author: add some origin or author
## Bug: bug URL

이제 새 소스 패키지를 빌드하십시오.

$ debuild -S -us

그리고 debdiff를 만드십시오 :

$ cd ..
$ debdiff compiz_0.9.7.8-0ubuntu1.dsc compiz_0.9.7.8-0ubuntu1.1.dsc > sru-for-lp-974242.debdiff

이제 결과 debdiff파일을 버그 보고서에 첨부 할 수 있습니다 .

12.04로 배송하려면 안정적인 릴리스 업데이트가 필요합니다. 허용되는 수정 유형 및 수정 절차는 https://wiki.ubuntu.com/StableReleaseUpdates 를 참조 하십시오 .