장고 코드에 패치를 붙여줘서 항상 고맙게 생각하고 있습니다. 실제로 관련 패치가 포함된 버그 보고서는 패치가 없는 버그 보고서보다 훨씬 빠르게 수정됩니다.
설명서에서 단어를 변경하는 등 매우 사소한 문제를 수정하는 경우 패치를 제공하는 기본 방법은 Trac 티켓 없이 GitHub 풀 요청을 사용하는 것입니다.
pull 요청을 사용하는 방법에 대한 자세한 내용은 :doc:’working-with-git’을 참조하십시오.
전 세계에 수백 명의 기여자가 있는 오픈소스 프로젝트에서는 작업이 중복되지 않고 기여자가 최대한 효과적으로 작업할 수 있도록 커뮤니케이션을 효율적으로 관리하는 것이 중요합니다.
따라서 우리의 정책은 특정 버그나 기능이 작업 중임을 다른 개발자에게 알리기 위해 티켓을 “청구”하는 기여자를 위한 것입니다.
원하는 기여가 확인되었고 이를 수정할 수 있는 능력이 있는 경우(코딩 능력, Django 내부 지식 및 시간 가용성으로 측정됨) 다음 단계를 수행하여 해당 기여를 청구합니다.
참고
Django Software Foundation은 Django에 사소한 패치 이상의 기여를 하는 모든 사람이 “Colvator License Agreement”에 서명하고 제출하도록 요청하며, 이를 통해 Django Software Foundation은 모든 기여에 대한 명확한 라이센스를 보유할 수 있습니다.
티켓을 수령한 후에는 적시에 해당 티켓을 처리해야 할 책임이 있습니다. 만약 여러분이 그것을 할 시간이 없다면, 그것을 청구하지 않거나, 애초에 청구하지 마세요!
If there’s no sign of progress on a particular claimed ticket for a week or two, another developer may ask you to relinquish the ticket claim so that it’s no longer monopolized and somebody else can claim it.
티켓을 수령했는데 코딩하는 데 오랜 시간(일 또는 몇 주)이 걸리는 경우 티켓에 댓글을 달아 모든 사용자를 최신 상태로 유지하십시오. 정기적인 업데이트를 제공하지 않고 진행 상황 보고서 요청에 응답하지 않으면 티켓에 대한 청구가 취소될 수 있습니다.
항상 그렇듯이, 더 많은 의사소통이 덜 소통하는 것보다 더 낫습니다!
어떤 경우에는 티켓을 청구하는 단계를 거치는 것이 지나치기도 합니다.
설명서의 오타 또는 수정하는 데 몇 분밖에 걸리지 않는 작은 버그와 같은 작은 변경 사항이 있는 경우 티켓 청구에 대한 루프를 건너뛰지 않아도 됩니다. 패치를 직접 제출하면 완료됩니다!
패치가 준비되어 있는 경우 티켓에 패치를 제출하는 것은 다른 사람이 요구했는지 여부에 관계없이 항상 허용됩니다.
최소한 다음 요구 사항을 충족하는 기여가 있는지 확인하십시오.
작업을 검토할 준비가 되었다고 생각되면 :doc:’a GitHub pull request’를 보내십시오. 먼저 :ref:”patch review checklist”를 사용하여 패치를 직접 검토하십시오.
어떤 이유로 풀 요청을 보낼 수 없는 경우 Trac에서 패치를 사용할 수도 있습니다. 이 스타일을 사용할 때는 다음 지침을 따르십시오.
작업 제출 방법과 상관없이 다음 단계를 따르십시오.
“비사소한” 패치는 작은 버그 수정 이상의 패치입니다. 장고 기능을 도입하여 일종의 디자인 결정을 내리는 패치입니다.
If you provide a non-trivial patch, include evidence that alternatives have been discussed on the Django Forum or django-developers list.
패치를 중요하지 않은 것으로 간주해야 하는지 확실하지 않으면 티켓에서 의견을 구하십시오.
Django의 코드가 더 이상 사용되지 않는 몇 가지 이유가 있습니다.
:ref:’감가상각 정책’에서 설명한 것처럼 기능을 사용하지 않는 Django의 첫 번째 릴리스(‘’A’)입니다.B’’)는 사용되지 않는 기능이 호출될 때 “제거된 장고 XX 경고”(여기서 XX는 기능이 제거될 장고 버전)를 발생시켜야 합니다. 테스트 범위가 양호하다고 가정하면, 경고가 활성화된 상태에서 :ref:’test Suite’를 실행하면 이러한 경고가 오류로 변환됩니다. ‘’’와 - 와 runtests.py’’’’입니다. 따라서 “RemovedInDjangoXXWarning”을 추가할 때 테스트를 실행할 때 발생하는 경고를 제거하거나 침묵시켜야 합니다.
첫 번째 단계는 Django가 사용하지 않는 동작의 사용을 제거하는 것입니다. 그런 다음 테스트 또는 클래스 수준에서 “ignore_warnings” 데코레이터를 사용하여 권장되지 않는 동작을 실제로 테스트하는 테스트에서 경고를 음소거할 수 있습니다.
특정 테스트의 경우:
from django.test import ignore_warnings
from django.utils.deprecation import RemovedInDjangoXXWarning
@ignore_warnings(category=RemovedInDjangoXXWarning)
def test_foo(self): ...
전체 테스트 사례의 경우:
from django.test import ignore_warnings
from django.utils.deprecation import RemovedInDjangoXXWarning
@ignore_warnings(category=RemovedInDjangoXXWarning)
class MyDeprecatedTests(unittest.TestCase): ...
You should also add a test for the deprecation warning:
from django.utils.deprecation import RemovedInDjangoXXWarning
def test_foo_deprecation_warning(self):
msg = "Expected deprecation message"
with self.assertWarnsMessage(RemovedInDjangoXXWarning, msg):
# invoke deprecated behavior
...
It’s important to include a RemovedInDjangoXXWarning
comment above code
which has no warning reference, but will need to be changed or removed when the
deprecation ends. This could include hooks which have been added to keep the
previous behavior, or standalone items that are unnecessary or unused when the
deprecation ends. For example:
import warnings
from django.utils.deprecation import RemovedInDjangoXXWarning
# RemovedInDjangoXXWarning.
def old_private_helper():
# Helper function that is only used in foo().
pass
def foo():
warnings.warn(
"foo() is deprecated.",
category=RemovedInDjangoXXWarning,
)
old_private_helper()
...
마지막으로 Django의 문서에는 다음과 같은 몇 가지 업데이트가 있습니다.
docs/internals/deprecation.txt
)에 추가합니다.이 단계를 완료하면 더 이상 사용되지 않습니다. 각 :term:’feature release’에서 새 버전과 일치하는 모든 “RemovedInDjangoXXWarning”s가 제거된다.
JavaScript 패치에 대한 자세한 내용은 :ref:’javascript-patches’ 설명서를 참조하십시오.
이 체크리스트를 사용하여 풀 요청을 검토합니다. 자신의 것이 아닌 풀 요청을 검토 중이고 아래의 모든 기준을 통과하면 해당 Trac 티켓의 “Triage Stage”를 “체크인 준비”로 설정하십시오. 풀 요청에 대한 개선 의견을 남긴 경우 검토 결과에 따라 “패치 개선 필요”, “문서 필요” 및/또는 “테스트 필요” 플래그를 Trac 티켓에 체크하십시오. 시간과 관심이 허락하는 대로 합병은 “체크인 준비 완료” 티켓을 최종 검토하며, 추가 작업이 필요할 경우 패치를 커밋하거나 “승인 완료”로 되돌립니다. 합병이 되기를 원한다면 패치를 철저히 검토하는 것이 신뢰를 얻는 좋은 방법입니다.
검토할 패치를 찾고 계십니까? Django Development Dashboard https://dashboard.djangoproject.com/의 “검토가 필요한 패치” 섹션을 확인하십시오. 패치를 검토하시겠습니까? 티켓의 추적 플래그가 해당 큐에 표시되도록 설정되었는지 확인합니다.
:ref:’decrating-a-feature’ 가이드를 참조하십시오.
black
, blacken-docs
, flake8
, or
isort
errors? You can install the pre-commit hooks to automatically catch these errors.docs/releases/A.B.txt
)에 참고 사항이 있습니까?5월 04, 2024