Temurin-build: Предложение: позвольте авторам PR объединить свои собственные PR, где это возможно.

@sxa полностью доволен этим изменением, я бы предложил бота, который добавляет метку ready-to-merge и пингует автору

@gdams сразу вырвал у меня слова как за одобрение, так и за предложение бота. +1 от меня за это 👍

Согласовано - имеет смысл и с нашими ТЗ.

Хотя я понимаю мотивацию, я не хочу больше шума (GitHub уже уведомляет меня об одобрении). Кроме того, нам нужны инструменты, чтобы добиться этого. В противном случае все быстро развалится: как мне узнать (как утверждающий), может ли человек объединить изменение? Как мы узнаем, в каком репозитории есть это правило, а в каком нет? Уменьшая коллективную собственность, мы фактически препятствуем появлению новых участников. Если я отвечаю за то, чтобы все прошло гладко, я должен зарезервировать время и, возможно, подождать несколько часов, пока конвейеры не пройдут. Конечно, я не получаю уведомления об этом.

Итак, если некоторые люди хотят контролировать свои PR, они должны это иметь. Создайте метку, которая указывает, что автор хочет слиться, и найдите способ принудительно это сделать, чтобы никто не слился случайно.

Я не хочу больше шума (GitHub уже уведомляет меня об одобрении)

Какого дополнительного шума вы от этого ждете? Это связано с тем, что бот добавляет тег, или вы думаете о чем-то другом?

Если я отвечаю за то, чтобы все прошло гладко, я должен зарезервировать время и, возможно, ждать часы

Я понимаю, но мой контраргумент в том, что это гораздо лучший вариант, чем те часы, которые я потратил на отладку, почему что-то внезапно пошло не так, что является частой проблемой, с которой неизбежно сталкиваемся я и @andrew-m-leonard , вот почему я на самом деле не думаю, что автору нужно активно принимать это решение - я уверен, что многие авторы предпочли бы, чтобы кто-то другой имел дело с любыми последствиями их PR :-)

Кроме того, нам нужны инструменты для обеспечения соблюдения этого

На первый взгляд это кажется немного противоречащим вашему комментарию о том, что больше уведомлений не требуется. Честно говоря, я лично предпочел бы не применять его, если только мы не можем ожидать, что люди будут просто разумно относиться к нему - как я сказал, может возникнуть необходимость отменить такое постановление, и я бы предпочел, чтобы это не требовало дополнительных накладных расходов. Заголовок гласит: «Позвольте авторам PR», т.е. я хочу призвать рецензентов не «объединяться по умолчанию», когда они что-то бегло просматривают.

Как мы узнаем, в каком репозитории есть это правило, а в каком нет?

Мы могли бы добавить эту информацию в шаблон PR, который должен прояснить его - в любом случае я не думаю, что это причина, по крайней мере, не пробовать его здесь. Мне любопытно, почему вы думаете, что это может отпугнуть новых участников? Они не должны быть затронуты, если нет варианта использования, о котором я не думаю, или вы думаете о новых сотрудниках, которые получат привилегии для слияния?

Я считаю, что эта проблема, по крайней мере частично, является попыткой решить тот случай, когда рецензенты не внимательно прочитали комментарии или запросы автора («пожалуйста, подождите, пока xxxx не будет проверен ...», «это изменение необходимо согласовать. -согласовано с изменениями x и y ... "," Я специально прошу Z проверить это изменение ... "). Когда эти запросы игнорируются рецензентами, которые затем переходят к слиянию, это нехорошо.

Это также было проблемой в репозитории openjdk-tests, где проводились поспешные проверки и слияния без достаточного понимания или тестирования. Это очень напрягает команду. Это побудило нас добавить 2-го рецензента необходимые ворота, чтобы решить эту проблему. В случае репозитория тестов я в основном не хочу, чтобы создатель слился, потому что у нас есть много создателей, у которых нет доступа на запись. Если я что-то просмотрел и действительно хочу, чтобы они слились (поскольку я знаю, что у них есть разрешения на запись, я могу запросить их слияние, когда они будут готовы).

Я не хочу, чтобы кто-то не понимающий, как правильно тестировать пиар, сливал его. В большинстве случаев мы не участвуем в гонках по проекту. Мы должны спокойно оценить каждый PR и трезво решить объединить их, когда они будут полностью протестированы и в сроки, которые имеют смысл для изменения (ряд возможностей, включая, но не ограничиваясь, 1. слияние как можно скорее, потому что все сломано, и это может не станет хуже, или 2. на следующий день, когда кто-то сможет посмотреть сборку, или 3. после предстоящего релиза, чтобы не дестабилизировать проект). Нам действительно нужно решить, как мы справимся с этим.

Если у составителя есть особые просьбы или комментарии относительно PR, их следует прочитать / понять / принять во внимание. Мы можем выбрать поведение по умолчанию, а затем ожидать, что автор и рецензенты будут общаться посредством комментариев к плану слияния, если он отличается от поведения по умолчанию. Все это требует, чтобы и рецензенты, и автор обращали внимание и общались. Если бы все это уже сделали, возможно, это обсуждение вообще не понадобится.

Что касается комментариев

Какого дополнительного шума вы от этого ждете? Это связано с тем, что бот добавляет тег, или вы думаете о чем-то другом?

Джорджу и Моргану нужен бот, который пингует автора.

Я понимаю, но мой контраргумент в том, что это намного лучший вариант, чем те часы, которые я потратил на отладку, почему что-то внезапно пошло не так.

Это не хорошо. Но и предлагаемое здесь решение ужасно. У нас уже есть проблема со спонсором, и теперь мы хотим усугубить ее так же, как это сделал OpenJDK, усложнив участие (Скара, кажется, пытается частично ее отменить). Проблема, которую вы описываете, вызвана тем, что openjdk-build находится в ужасном состоянии. А еще наваливаем PR на то, что не готово. И они не готовы, потому что мы не позволяем участникам оценить, находятся ли их PR в хорошей форме. Я здесь не новичок и редко понимаю это правильно.

Заголовок гласит: «Позвольте авторам PR», т.е. я хочу призвать рецензентов не «объединяться по умолчанию», когда они что-то бегло просматривают.

Не работает. Я предлагаю такой ярлык, как «самослияние». Если вы добавите это в один из своих PR, некоторые инструменты не позволят мне выполнить слияние. Этот пиар будет ждать вас. Если кто-то еще хочет слиться, он сначала должен удалить этот ярлык. Это заставит их остановиться.

Мне любопытно, почему вы думаете, что это может отпугнуть новых участников?

Если я где-то новенький, я хочу, чтобы кто-нибудь присматривал за мной, делая мои взносы. Мысль о том, чтобы сломать то, что затрагивает большое количество людей, ужасает. Так что по умолчанию работа рецензента заключается в том, чтобы включить мой PR в проект, потому что тогда «это был не я». Если мы сможем получить эту функцию самослияния в качестве дополнительной функции, хорошо.

Что касается комментария

Если у составителя есть особые просьбы или комментарии относительно PR, их следует прочитать / понять / принять во внимание. Мы можем выбрать поведение по умолчанию, а затем ожидать, что автор и рецензенты будут общаться посредством комментариев к плану слияния, если он отличается от поведения по умолчанию. Все это требует, чтобы и рецензенты, и автор обращали внимание и общались. Если бы все это уже сделали, возможно, это обсуждение вообще не понадобится.

💯 Но: Это сложно. Мы должны помогать людям поступать правильно, не просматривая вручную контрольные списки (плохие примеры: 8u-dev и 11u-dev). Бот Skara вроде как движется в правильном направлении, хотя очень шумно.

Мне нравится идея самослияния лейбла, поддерживаемая инструментами, обеспечивающими ее выполнение. Мне особенно нравится, что мы обсуждаем различные способы, которые мы хотим улучшить как проект и как глобальную команду. 👍

Джорджу и Моргану нужен бот, который пингует автора.

Это уже существует . Я просто предлагаю дополнить его более полезной информацией (пожалуйста, пингуйте кого-нибудь, чтобы запустить тесты). https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59 намеревается сделать это, сделав шум более полезным, чем просто шум. Это может помочь и с точкой зрения няни, которую вы подняли

Я просто предлагаю дополнить его более полезной информацией (пожалуйста, пингуйте кого-нибудь, чтобы запустить тесты).

Хотя бот говорит, что нужно делать дальше, он не указывает, кто может выполнить эти шаги и где найти эту информацию. Это также не требует первоначальной проверки кода, что, мы надеемся, является целью этого упражнения (из-за того, что наши машины сохраняют состояние, мы не хотим запускать на них непроверенный код).

Небольшое примечание: https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/issues/59. Новичок вряд ли сможет сам придумать. Им нужна четкая цель и пошаговое руководство, что делать («Получить информацию из этого API, отобразить ее, ...»). В нынешнем виде билет скорее на ветерана 😉

Можем ли мы использовать «Черновик» для этой цели, т. Е. Если Автор хочет объединить его, он помечает его как Черновик, организует рецензирование и, когда они счастливы, объединяется ... поскольку это предпосылка для некоторых случаев мы хотим быть уверены, что он готов к слиянию, поэтому до этого момента это черновик ...

Можем ли мы использовать «Черновик» для этой цели, т. Е. Если Автор хочет объединить его, он помечает его как Черновик, организует рецензирование и, когда они счастливы, объединяется ... поскольку это предпосылка для некоторых случаев мы хотим быть уверены, что он готов к слиянию, поэтому до этого момента это черновик ...

Моя проблема с этим заключается в том, как указано в исходном описании: «[черновик] может выглядеть как« не готов к рассмотрению »для людей, которые в противном случае могли бы просмотреть». Я думаю, что есть важная разница между черновиком (я все еще активно меняю материал) и готовым к рассмотрению (ищу отзывы, но это не значит, что я полностью уверен, что он будет работать после слияния)

(Пишу это довольно быстро, так как я должен быть сейчас на собрании - извиняюсь, если мнение неясное)

Но и предлагаемое здесь решение ужасно.
что затрудняет внесение вклада

Я думаю, что называть это «ужасным» немного резковато. Это предназначено для решения проблемы, с которой я регулярно сталкиваюсь в настоящее время.

Так что по умолчанию работа рецензента заключается в том, чтобы включить мой PR в проект, потому что тогда «это был не я».

Задача рецензентов - поощрять вклад и помогать им исправлять любые проблемы, а в случае новых (читающих напуганных, напуганных мыслью о том, что что-то сломать) это ничего не изменит (они не могут объединиться. в конце концов), так что я не понимаю, в чем проблема. Добавление дополнительных ярлыков (либо self-merge или ready-to-merge лично мне кажутся немного дополнительными накладными расходами, но я бы не отказался от них, если это то, чего хотят люди. Я просто не хочу продолжить в ситуации, когда инициаторы PR не несут никакой ответственности после слияния (особенно в рамках текущих членов группы - я в порядке, если новый участник столкнется с проблемой с чем-то, что они добавили - в этом случае рецензент должен надеяться Помогите им отладить, если он сработает и выйдет из строя - это часть процесса обучения и произойдет независимо)

Если я где-то новенький, я хочу, чтобы кто-нибудь присматривал за мной, делая мои взносы.

Я полностью согласен, поэтому я пытался настаивать на улучшении документации, но это часто казалось единственной причиной - я думаю, что мы потеряли активных людей в проекте, а не приобрели их за последний год, и рабочая нагрузка не уменьшилась. вниз, так что сделать это не так-то просто. Я действительно думаю, что это отдельно от этого предложения, которое не должно изменить этот сценарий.

Я думаю, что называть это «ужасным» немного резковато. Это предназначено для решения проблемы, с которой я регулярно сталкиваюсь в настоящее время.

Вы не заметили у меня на лбу этикетку с надписью «ОСТОРОЖНО, сильных мнений»? :ухмылка:

Опять же, здесь мы пытаемся исправить не ту проблему. Вы бы столкнулись с этими проблемами значительно реже, если бы PR были правильно подтверждены. Если проблема синтаксиса bash может сделать ее незамеченной в основной ветке и вызвать разрывы сборки, проблема не в том, кто что-то объединяет, или в том, что автора нет, чтобы нянчиться с проблемой. Я отталкиваюсь, потому что то, что вы предлагаете, пытается обойти проблему, а не исправить ее. Состояние openjdk-build известно уже давно, но мы пока не готовы, потому что это еще не так сильно повредило. У нас есть деньги на менеджеров сообщества, а на что нет, но у нас нет денег или людей, чтобы решить наши основные проблемы.

Нам нужно меньше проблем, не больше. Как только мы устраняем боль с помощью быстрой победы, мы склонны забывать о ее существовании. Пример: с 2d9445348c70ec565874fb92f4c09971f71a5d23, PR-тестирование на macOS было отключено путем добавления комментария. С a82104c77a79d707d533415163cf00dac33678d4 мы потеряли часть, которая была закомментирована. Кто теперь помнит, что у нас было PR-тестирование macOS, что оно было отключено и что мы должны вернуть его? Это даже не проблема.

TSC следует сосредоточить на таких проблемах, как глаз Саурона во «Властелине колец».

Задача рецензентов - поощрять вклад и помогать им исправлять любые проблемы, а в случае новых (читающих напуганных, напуганных мыслью о том, что что-то сломать) это ничего не изменит (они не могут объединиться. в конце концов), так что я не понимаю, в чем проблема.

Мы собираемся научить рецензентов отказываться от PR после того, как они нажмут кнопку «Утвердить», потому что это значение по умолчанию. Как новичок / человек без привилегий, вы должны найти и преследовать кого-нибудь, чтобы слиться от вашего имени. Это опыт OpenJDK, и мне он не нравится (это не раскопка в сторону OpenJDK, все как будто есть по какой-то причине).

Вы не заметили у меня на лбу этикетку с надписью «ОСТОРОЖНО, сильных мнений»? ухмылка

Пропустил, но тогда у меня не было видеозвонка с вами в последнее время ;-) Хороший пример на тестере macos PR ...

Мы собираемся научить рецензентов отказываться от PR после того, как они нажмут кнопку «Утвердить», потому что это значение по умолчанию. Как новичок / человек без привилегий, вы должны найти и преследовать кого-нибудь, чтобы слиться от вашего имени. Это опыт OpenJDK, и мне он не нравится (это не раскопка в сторону OpenJDK, все как будто есть по какой-то причине).

Я надеюсь, что в этом проекте этого не произойдет, и если это произойдет, я надеюсь, что мы справимся с этим. Я по-прежнему готов рискнуть лично. На данный момент с такой небольшой командой (что является частью проблемы ... и не является проблемой для openjdk), я думаю, утверждающие (это в значительной степени @gdams @karianna @ andrew-m-leonard @ M-Davies и я сам, который делает их для этого репо) все знают, кто способен объединять вещи, а кто нет, поэтому я надеюсь, что они не оставят тех, кто не выполняет обязательства, в темноте и не будут иметь слишком много накладных расходов. Я был бы рад, если бы мы смогли масштабировать команду до такой степени, что в этой политике больше не было необходимости. Я действительно думаю, что стоит попробовать, и если мы увидим такие проблемы, мы можем вернуться к ним. Я просто не хочу "ничего не делать"