Temurin-build: 제안 : PR 작성자가 실용적인 경우 자신의 PR을 병합하도록합니다.

@sxa 이 변경 사항에 완전히 만족합니다. ready-to-merge 레이블을 추가하고 작성자에게 핑을 보내는 봇을 제안합니다.

@gdams 는 승인 및 봇 제안을 위해 내 입에서 바로 단어를 가져

동의 함-우리 TZ도 의미가 있습니다.

동기는 이해하지만 더 많은 소음을 원하지 않습니다 (GitHub에서 이미 승인을 알 렸습니다). 또한이를 시행하기위한 도구가 필요합니다. 그렇지 않으면 모든 것이 빠르게 무너질 것입니다. 승인자로서 변경 사항을 병합 할 수 있는지 어떻게 알 수 있습니까? 해당 규칙이있는 저장소와 그렇지 않은 저장소를 어떻게 알 수 있습니까? 공동 소유권을 줄임으로써 우리는 실제로 새로운 기여자들을 막습니다. 모든 것이 순조롭게 진행될 책임이 있다면 시간을 예약하고 파이프 라인이 통과 할 때까지 몇 시간을 기다려야합니다. 물론 나는 그것에 대한 알림을받지 못합니다.

따라서 일부 사람들이 자신의 PR을 관리하고 싶다면 그것을 가져야합니다. 작성자가 병합을 원함을 나타내는 레이블을 만들고 실수로 병합하지 않도록 강제하는 방법을 찾습니다.

더 많은 소음을 원하지 않습니다 (GitHub에서 이미 승인 알림).

이것에서 어떤 추가 소음이 예상됩니까? 태그를 추가하는 봇이있는 것과 관련이 있습니까? 아니면 다른 것에 대해 생각하고 있습니까?

모든 것이 순조롭게 진행될 책임이 있다면 시간을 예약하고 몇 시간을 기다려야합니다

나는 그것을 알지만, 내 반론은 그것이 왜 갑자기 잘못되었는지 디버깅하는 데 시간을 소비하는 것보다 훨씬 더 나은 옵션이라는 것입니다. , 이것이 제가 실제로 저자가 적극적으로 결정을 내려야한다고 생각하지 않는 이유입니다. 많은 저자들이 PR에서 나온 결과를 다른 사람이 처리 할 것이라고 확신합니다. :-)

또한이를 시행하기위한 도구가 필요합니다.

표면적으로는 더 많은 알림을 원하지 않는다는 귀하의 의견과 약간 상충되는 것 같습니다. 솔직히 나는 사람들이 그것에 대해 현명하다고 기대할 수 없다면 개인적으로 그것을 시행 하지 않을 것입니다. 이 제목은 "Let PR originators"라고되어 있습니다. 즉, 리뷰어가 무언가를 빠르게 살펴본 후에는 "기본적으로 병합"하지 않도록 권장하고 싶습니다.

해당 규칙이있는 저장소와 그렇지 않은 저장소를 어떻게 알 수 있습니까?

우리는 그 정보를 PR 템플릿에 추가 할 수 있습니다.이 정보는 명확하게해야합니다. 어느 쪽이든 그것이 적어도 여기서 시도하지 않는 이유라고 생각하지 않습니다. 왜 새로운 기여자를 낙담시킬 수 있다고 생각하는지 궁금합니다. 내가 생각하지 않는 사용 사례가 없거나 병합 권한을 얻을 새로운 공동 작업자에 대해 생각하고 있지 않는 한 영향을받지 않아야합니다.

이 문제는 검토자가 작성자의 의견이나 요청을 완전히 읽지 않은 경우를 해결하려는 시도라고 생각합니다 ( "xxxx가 확인 될 때까지 기다리십시오 ...", "이 변경 사항은 공동 작업이 필요합니다." -x 및 y 변경 사항과 함께 조정됩니다 ... ","Z가이 변경 사항을 검토하도록 특별히 요청합니다 ... "). 검토자가 이러한 요청을 무시하고 병합을 진행하는 것은 좋은 일이 아닙니다.

이것은 또한 충분한 이해 나 테스트없이 성급한 검토와 병합이 발생한 openjdk-tests repo의 문제였습니다. 이것은 팀에게 매우 스트레스입니다. 이 문제를 해결하기 위해 두 번째 검토 자 필수 게이트를 추가하라는 메시지가 표시되었습니다. 테스트 저장소의 경우 쓰기 액세스 권한이없는 많은 작성자가 있기 때문에 작성자가 병합되는 것을 대부분 원하지 않습니다. 검토 한 내용을 병합하고 싶은 경우 (쓰기 권한이 있음을 알고 있으므로 준비가되면 병합하도록 요청할 수 있습니다).

PR을 제대로 테스트하는 방법을 이해하지 못하는 사람이 PR을 병합하는 것을 원하지 않습니다. 대부분의 경우 우리는 프로젝트에서 경쟁하지 않습니다. 우리는 각 PR을 침착하게 평가하고 완전히 테스트되고 변경 사항에 적합한 타이밍에이를 병합하기로 신중하게 결정해야합니다 (1. 모든 것이 손상되고 가능하므로 최대한 빨리 병합합니다. 더 나 빠지지 않거나 2. 다음날 누군가가 빌드를 볼 수있을 때 또는 3. 프로젝트를 불안정하게 만들지 않기 위해 다가오는 릴리스 이후). 이를 관리하는 방법은 실제로 우리가 결정해야 할 사항입니다.

작성자가 PR에 대한 특별한 요청이나 의견이있는 경우 해당 내용을 읽고 이해해야합니다. 기본 동작을 결정한 다음 기본 동작에서 벗어나면 작성자와 검토자가 병합 계획에 대한 의견을 통해 의사 소통을 할 수 있습니다. 이 모든 것이 검토 자와 작성자 모두주의를 기울이고 소통해야합니다. 모두가 이미 그렇게했다면 처음에는이 토론이 필요하지 않을 수도 있습니다.

@sxa 의 의견에 관하여 :

이것에서 어떤 추가 소음이 예상됩니까? 태그를 추가하는 봇이있는 것과 관련이 있습니까? 아니면 다른 것에 대해 생각하고 있습니까?

George와 Morgan은 작성자를 핑하는 봇을 원합니다.

나는 그것을 얻지 만, 내 반론은 그것이 갑자기 왜 무언가가 잘못되었는지 디버깅하는 데 소비 한 시간보다 훨씬 더 나은 옵션이라는 것입니다.

이것은 좋지 않습니다. 그러나 여기에서 제공되는 솔루션도 끔찍합니다. 우리는 이미 기여자 문제를 가지고 있으며 OpenJDK가 기여하는 것을 더 어렵게함으로써 OpenJDK가 한 것과 같은 방식으로 더 악화시키고 자합니다 (Skara는 그것의 일부를 취소하려고하는 것 같습니다). 당신이 설명하는 문제는 openjdk-build가 끔찍한 모양에 있기 때문에 발생합니다. 그리고 준비되지 않은 PR을 그 위에 쌓습니다. 또한 기여자가 자신의 PR이 양호한 상태인지 여부를 측정 할 수 없도록 만들기 때문에 준비가되지 않았습니다. 나는 여기에서 새로운 것이 아니며 거의 제대로 이해하지 못합니다.

이 제목은 "Let PR originators"라고되어 있습니다. 즉, 리뷰어가 무언가를 빠르게 살펴본 후에는 "기본적으로 병합"하지 않도록 권장하고 싶습니다.

작동하지 않습니다. 내가 제안하는 것은 "self-merge"와 같은 레이블입니다. PR 중 하나에 추가하면 일부 도구로 인해 병합이 발생하지 않습니다. 그 PR은 당신을 기다릴 것입니다. 다른 사람이 병합하려는 경우 먼저 해당 레이블을 제거해야합니다. 그러면 일시 중지됩니다.

왜 새로운 기여자를 낙담시킬 수 있다고 생각하는지 궁금합니다.

내가 어딘가에 새로 온다면 누군가 내 기여를 통해 나를 돌봐주기를 원합니다. 많은 사람들에게 영향을 미치는 무언가를 깨뜨린다는 생각은 무섭습니다. 따라서 기본적으로 내 PR을 프로젝트에 적용하는 것은 검토 자의 일이어야합니다. 자동 병합 기능을 옵트 인 기능으로 사용할 수 있다면 괜찮습니다.

@smlambert 의 의견에 관하여 :

작성자가 PR에 대한 특별한 요청이나 의견이있는 경우 해당 내용을 읽고 이해해야합니다. 기본 동작을 결정한 다음 기본 동작에서 벗어나면 작성자와 검토자가 병합 계획에 대한 의견을 통해 의사 소통을 할 수 있습니다. 이 모든 것이 검토 자와 작성자 모두주의를 기울이고 소통해야합니다. 모두가 이미 그렇게했다면 처음에는이 토론이 필요하지 않을 수도 있습니다.

💯하지만 : 어렵습니다. 우리는 사람들이 수동으로 체크리스트를 거치지 않고도 올바른 일을하도록 도와야합니다 (나쁜 예 : 8u-dev 및 11u-dev). Skara 봇은 매우 시끄럽지 만 올바른 방향으로 가고있는 것 같습니다.

나는 그것을 강제하는 도구로 지원되는 자체 병합 레이블 아이디어를 좋아합니다. 특히 프로젝트 및 글로벌 팀으로서 개선하고 싶은 다양한 방법을 논의하고 있다는 점이 마음에 듭니다. 👍

George와 Morgan은 작성자를 핑하는 봇을 원합니다.

이미 존재합니다 . 더 유용한 정보로 확장하는 것이 좋습니다. https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59 는 소음보다 소음을 더 유용하게 만들어이를 수행하려고합니다. 당신이 올린 베이비 시팅 포인트에도 도움이 될 수 있습니다

더 유용한 정보로 확장하는 것이 좋습니다.

봇은 다음에 수행해야 할 작업을 말하지만 해당 단계를 수행 할 수있는 사람이나 해당 정보를 찾을 수있는 위치는 언급하지 않습니다. 또한이 연습의 요점 인 초기 코드 검토가 필요하지 않습니다 (시스템의 상태 저장 특성 때문에 확인되지 않은 코드를 실행하지 않기를 원합니다).

참고 : https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59. 새로 온 사람은 스스로 아이디어를 내놓을 수 없을 것입니다. 명확한 목표와해야 할 일을 단계별로 안내해야합니다 ( "해당 API에서 정보 가져 오기, 표시, ..."). 현재 입장권은 베테랑을위한 것입니다 😉

이 목적을 위해 "Draft"를 사용할 수 있습니까? 즉, 작성자가이를 병합하려는 경우 Draft로 표시하고 리뷰를 정렬하고 만족할 때 병합합니다. 여기서 전제는 일부 경우에 대한 것입니다. 병합 할 준비가되었는지 확인하고 싶으므로 그 시점까지 초안이됩니다.

이 목적을 위해 "Draft"를 사용할 수 있습니까? 즉, 작성자가이를 병합하려는 경우 Draft로 표시하고 리뷰를 정렬하고 만족할 때 병합합니다. 여기서 전제는 일부 경우에 대한 것입니다. 병합 할 준비가되었는지 확인하고 싶으므로 그 시점까지 초안이됩니다.

내 문제는 원래 설명에 명시된대로입니다. "[초안]은 다른 방법으로 검토 할 수있는 사람들에게"검토 준비가되지 않음 "처럼 보일 수 있습니다." 초안 (아직도 적극적으로 변경 중임)과 검토 할 준비가되어있는 것 (피드백을 찾고 있지만 병합 할 때 작동 할 것이라고 확신하는 것은 아닙니다)간에 중요한 차이가 있다고 생각합니다.

(지금 회의에 참석해야하므로이 글을 아주 빨리 작성하세요.보기가 명확하지 않으면 사과드립니다)

그러나 여기에서 제공되는 솔루션도 끔찍합니다.
기여하기 더 어렵게

나는 그것을 "끔찍하다"라고 부르는 것이 조금 가혹하다고 생각합니다. 이것은 내가 현재 정기적으로 보는 문제를 해결하기위한 것입니다.

따라서 기본적으로 내 PR을 프로젝트에 적용하는 것은 검토 자의 일이어야합니다.

기여를 장려하고 문제를 해결하는 데 도움을주는 것은 확실히 리뷰어의 일이어야하며, 새로운 (무서움을 읽고, 무언가를 깨뜨리는 생각에 겁을 먹은) 기여자의 경우 이것은 아무것도 변경하지 않을 것입니다 (그들은 자신을 합칠 수 없습니다. 결국) 그래서 나는 우려가 무엇인지 명확하지 않습니다. 추가 레이블 ( self-merge 또는 ready-to-merge 추가하는 것은 개인적으로 나에게 약간의 부담이되는 것처럼 보이지만 사람들이 원하는 것이라면 괜찮을 것입니다. PR 작성자가 병합 후 책임이없는 상황에서 계속 진행합니다 (특히 현재 그룹 구성원 내에서-새 기여자가 자신이 입력 한 내용에 문제가 발생해도 괜찮습니다.이 경우 검토자가 바라는대로 들어가고 실패하는 경우 디버그하도록 도와주세요. 이는 학습 경험의 일부이며 상관없이 발생합니다.)

내가 어딘가에 새로 온다면 누군가 내 기여를 통해 나를 돌봐주기를 원합니다.

나는 이것이 문서 개선을 위해 노력한 이유에 완전히 동의하지만, 종종 고독한 원인처럼 느껴집니다. 프로젝트에서 활동적인 사람들을 작년에 확보하기보다 잃어버린 것 같습니다. 그리고 작업량은 사라지지 않았습니다. 그렇게하는 것이 그렇게 쉬운 일이 아닙니다. 나는 그것이이 제안과는 별개라고 생각한다. 그것은 그 시나리오를 바꾸지 말아야한다.

나는 그것을 "끔찍하다"라고 부르는 것이 조금 가혹하다고 생각합니다. 이것은 내가 현재 정기적으로 보는 문제를 해결하기위한 것입니다.

내 이마에 "BEWARE Strong 의견"이라는 레이블이 붙은 것을 보지 못 하셨나요? :이를 드러내고 웃다:

다시, 우리는 여기서 잘못된 문제를 해결하려고 노력하고 있습니다. PR이 적절하게 검증 된 경우 이러한 문제가 훨씬 줄어들 것입니다. bash 구문 문제로 인해 기본 브랜치에서 감지되지 않고 빌드 중단이 발생할 수있는 경우 문제는 무언가를 병합하거나 작성자가 문제를 처리 할 수있는 사람이 아닙니다. 나는 당신이 제안하는 것이 문제를 해결하는 대신 해결하려고 시도하기 때문에 반발합니다. openjdk-build의 상태는 오랫동안 알려져 왔지만 아직 충분히 아프지 않았기 때문에 우리는 캔을 차고 있습니다. 우리에게는 커뮤니티 관리자를위한 돈이 있지만 핵심 문제를 해결할 사람이나 돈이 없습니다.

우리는 더 적은 문제가 아니라 더 적은 문제가 필요합니다. 빠른 승리로 고통을 제거하자마자 존재조차 잊는 경향이 있습니다. 예 : 2d9445348c70ec565874fb92f4c09971f71a5d23에서 macOS에서의 PR 테스트는 주석 처리를 통해 비활성화되었습니다. a82104c77a79d707d533415163cf00dac33678d4에서는 주석 처리 된 부분이 손실되었습니다. 이제 macOS PR 테스트를 받았으며 비활성화되었으며 다시 가져와야한다는 사실을 누가 기억합니까? 그것에 대한 문제조차 없습니다.

TSC는 반지의 제왕에서 사우론의 눈과 같은 문제에 집중해야합니다.

기여를 장려하고 문제를 해결하는 데 도움을주는 것은 확실히 리뷰어의 일이어야하며, 새로운 (무서움을 읽고, 무언가를 깨뜨리는 생각에 겁을 먹은) 기여자의 경우 이것은 아무것도 변경하지 않을 것입니다 (그들은 자신을 합칠 수 없습니다. 결국) 그래서 나는 우려가 무엇인지 명확하지 않습니다.

리뷰어가 "승인"버튼을 누르면 PR을 포기하도록 교육 할 것입니다. 이것이 기본값이기 때문입니다. 특권이없는 신규 이민자 / 사람으로서, 당신은 당신을 대신하여 합병 할 누군가를 찾아서 쫓아 야합니다. 그것이 OpenJDK 경험이고, 나는 그 경험을 좋아하지 않습니다 (이것은 OpenJDK에 대한 탐구가 아닙니다. 상황은 이유가 있습니다).

내 이마에 "BEWARE Strong 의견"이라는 레이블이 붙은 것을 보지 못 하셨나요? 이를 드러내고 웃다

그것을 놓쳤지만 최근에 당신과 화상 통화를하지 않았습니다 ;-)하지만 macos PR 테스터의 좋은 예 ...

리뷰어가 "승인"버튼을 누르면 PR을 포기하도록 교육 할 것입니다. 이것이 기본값이기 때문입니다. 특권이없는 신규 이민자 / 사람으로서, 당신은 당신을 대신하여 합병 할 누군가를 찾아서 쫓아 야합니다. 그것이 OpenJDK 경험이고, 나는 그 경험을 좋아하지 않습니다 (이것은 OpenJDK에 대한 탐구가 아닙니다. 상황은 이유가 있습니다).

이 프로젝트에서는 그렇지 않기를 바라며 만약 그렇다면 우리가 처리 할 수 ​​있기를 바랍니다. 나는 여전히 개인적으로 위험을 감수 할 의향이 있습니다. 지금은 작은 팀 (문제의 일부이며 openjdk에게는 문제가되지 않음)과 함께 승인자 (대부분 @gdams @karianna @ andrew-m-leonard @ M-Davies 및 이 repo를 위해 그들을 수행하는 나) 모두가 일을 병합 할 수있는 사람과 그렇지 않은 사람을 모두 알고 있으므로 비 커밋을 어둠 속에 두지 않고 오버 헤드가 너무 많지 않기를 바랍니다. 이 정책이 더 이상 필요하지 않은 지점까지 팀을 확장 할 수 있다면 기쁩니다. 시도해 볼 가치가 있다고 생각하며 그러한 문제를 발견하면 다시 방문 할 수 있습니다. 난 그냥 "아무것도하지"싶지 않아