내가 일하는 곳에서는 버그 및 기능 추적을 위해 Bugzilla를 광범위하게 사용합니다. 우리는 타임 라인을보다 잘 관리 할 수 있도록 구축 된 이정표를 활용하지만 때로는 우선 순위 변경과 마일스톤을 재구성해야합니다. 이 시간 동안 우리는 "한 번에 여러 버그를 변경"기능을 사용하여 주변을 이동하지만 그 결과는 관련된 모든 사람을위한 버그 스팸 톤입니다 (실제로 변경 작업을 수행하는 사람 제외).bugzilla에서 여러 버그를 동시에 수정할 때 전자 메일 사용 안 함
한 번에 많은 버그가 변경되면 이메일을 쉽게 끄는 방법이 있습니까?
예,하지만 관리자 액세스가 필요합니다. 관리 섹션에서 매개 변수 : Email : mail_delivery_method으로 이동하여 테스트 (디스크의 파일로 전자 메일을 스풀링) 또는 없음 (전자 메일을 완전히 사용 불가능하게 설정)으로 설정하십시오. 그런 다음 변경하고 이메일을 다시 활성화하십시오. announcehtml에 메시지를 넣으면 시스템을 사용하는 다른 사용자가 버그를 변경하는 동안 이메일을 보낼 수 없다는 것을 알 수 있습니다.
"우선 순위, 상태, 심각도 또는 중요 시점 변경"을 이메일로 보내는 옵션을 선택 해제하도록 사용자를 설득하거나 기본 옵션을 설정할 수도 있습니다.
불행히도 쉽게 볼 수 없습니다. 최선의 방법은 전자 메일 기본 설정을 설정하여 해당 이벤트에 대한 전자 메일이 생성되지 않도록하는 방법에 대한 명시적인 지침을 보내는 것입니다. 당신은 그 (것)들을위한 그들의 특혜를 새롭게 할 수 있었다, 나는 가정한다.
몇 가지 방법으로 코드에서 원하는 것을 구현할 수 있습니다. 예를 들어 process_bug.cgi에 논리를 추가하여 해당 이벤트에 대한 전자 메일을 생성 할 수 있습니다.
다음에 버그가 수정 될 때까지 전자 메일을 생성하지 않는 "조용한"변경을 허용하는 template/en/default/list/edit-multiple.html.tmpl의 확인란을 아주 오래된 Bugzilla에 추가했습니다. 새 버그 전자 메일은 lastdiffed 이후 변경된 모든 것을 발송하므로 lastdiffed를 업데이트하지 않으면 결국 변경 사항이 적용됩니다.
그러나 나는 이들 중 아무 것도하지 말라고 설득하고 싶습니다. 우리가 추가 한 조용한 변경 체크 박스를 사용하는 것을 꺼려합니다. 이는 내가 가능한 각 수신자의 판단을 대체한다는 것을 의미하기 때문입니다. 나는 이것이 이정표 등에 대해서는 괜찮다고 생각하지만, 일반적으로 나는 각 사용자의 기호를 존중하고 싶다.
당신은 코드 또는 템플릿의 일부 변경 사항을 구현하기로 결정하는 경우
, 당신은 후보 패치가 관련 버그가있는 경우 등,또 다른 참조, 그들에 대해 얘기 irc.mozilla.org에 #mozwebtools를 방문한다 우리는 모질라의 버전이 아니라는 것입니다. 사람들이 원치 않는 이메일을 쉽게 걸러 낼 수 있도록 보내는 이메일마다 헤더를 추가한다는 것입니다.
터널 끝 부분에 약간의 빛이 있습니다. 나는 Max Kanat-Alexander (그리고 주요한 공헌자 인 사람들)와 우리가 하나의 변화가 많은 "set"으로 많은 버그들에 대한 많은 변화를 고려하는 방법을 생각하고 있음을 안다. 이것이 구현되면 "여러 번 버그를 동시에 변경"을 수신자 당 하나의 이메일로 결합하는 것이 더 실현 가능해집니다.
이 관련 버그, FTR입니다 : https://bugzilla.mozilla.org/show_bug.cgi?id=26943
5 년 후,이 기능을 버그질라 (commit 1d96fa1와 2015년 3월 13일)의 마스터 지점에 최선을 다하고있다는 현재 버그질라 6 전달을 위해 추적됩니다.0
이 기능 요청에는 몇 가지 버그가 있지만 실제 수정이 발생한 버그는 Bug #1062718
입니다.