Слияние кода завершено, страница обновится автоматически
Содержание сгенерировано с помощью DocToc
Ниже мы описываем процесс вклада в GitLab по двум причинам:
Несколько человек из [команды GitLab][team] помогают членам сообщества получить свои вклады принятыми путём выполнения наших требований к завершению работы ([Определение завершения][done]).
Что вы можете ожидать от них, описано по адресу https://about.gitlab.com/jobs/merge-request-coach/.
Если задача сложная и требует внимания конкретного человека, назначение может быть хорошим вариантом, но назначение задач может отпугнуть других людей от участия в решении этой задачи. Мы нуждаемся во всех вкладах, поэтому это никогда не должно быть препятствием. Также, назначенный человек может не иметь времени несколько недель, так что другие люди могут чувствовать себя свободными взять на себя управление.
Будьте добры к тем, кто пытается внести свой вклад. Будьте осведомлены о том, что некоторые люди могут быть носителями иностранного английского языка, они могут не понять вещи или они могут быть очень чувствительны к тому, как вы формулируете вещи. Используйте эмодзи для выражения ваших чувств (сердце, звезда, улыбка и т.д.). Некоторые хорошие советы по рецензированию кода можно найти в нашем [руководстве по рецензированию кода].
После 7го числа (по часовому поясу Тихоокеанского стандартного времени) каждого месяца создается RC1 следующего выпуска (который будет выпущен 22го числа) и развернут на GitLab.com и стабильной ветке этого выпуска. После заморозки стабильных веток риск внезапного слияния, которое может сломать систему, снижается.
Эти типы слияний для следующего выпуска требуют особого рассмотрения:
Основные возможности должны быть представлены ментору до 1го числа. Это значит, что:
Хорошо, если запрос на слияние еще не полностью готов, но это позволяет ментору достаточно времени, чтобы сделать решение о том, сможет ли это попасть в выпуск до заморозки. Если ментор считает, что это не сможет попасть, он должен информировать разработчиков, работающих над этим, и менеджера продукта, ответственного за эту возможность.
Ментор также может выбрать назначить рецензента для проведения начальной проверки, но таким образом ментор маловероятен будет удивлен получением запроса на слияние позднее в цикле.
Маленькие возможности должны быть представлены рецензенту (не обязательно ментору) до 3го числа.
Большинство запросов на слияние от сообщества не имеют конкретной целевой точки выпуска. Однако, если один из них имеет такую цель и относится к одной из вышеупомянутых категорий, то это является обязанностью рецензента управлять данным общением и назначением на behalf of the community member.
После того, как слияния были представлены менторам и рецензентам, все остальные слияния должны быть представлены рецензентам до 7го числа. Это позволит рецензентам провести необходимые проверки и обеспечить качество перед заморозкой.
После 7го числа слияния больше не принимаются, кроме тех, которые уже были одобрены менторами и рецензентами. Это позволяет команде сосредоточиться на тестировании и подготовке к выпуску.
Перед каждым выпуском проводится ретроспективный анализ, где рассматриваются успехи и ошибки предыдущего цикла. Это помогает улучшить процессы и методологии для будущих выпусков.
После успешного тестирования и анализа, новый выпуск запускается 22го числа каждого месяца. Этот процесс включает в себя деплоймент на GitLab.com и стабильную ветку.
Если задача оформлена некорректно, следует обратиться к автору задачи с просьбой устранить недостатки.
Если проблема существует в старой версии, следует указать, что она должна быть решена в новой версии.
Для запросов поддержки и вопросов конфигурации следует предоставить подробную информацию и рекомендации по решению проблемы.
Если код оформлен некорректно, следует указать нарушения и предложить правильный формат.
Если проблема была исправлена в новой версии, следует указать номер версии и ссылку на исправление.
Если слияние оформлено некорректно, следует указать нарушения и предложить правильный формат.
Если задача не продвинулась за определённый период времени, её следует закрыть.
Если слияние не продвинулось за определённый период времени, его следует закрыть.
Слияния, которые соответствуют требованиям, должны быть приняты.
Только те слияния, тесты которых прошли успешно, должны быть приняты.
Трекер задач на GitHub должен быть закрыт после завершения работы над всеми задачами.
Таким образом, этот документ служит руководством для всех участников проекта GitLab, обеспечивая четкость и согласованность в работе над различными задачами и слияниями.Запросы на слияние все еще должны быть завершены, следуя [определению завершения][done]. Единственное исключение — документация, которую можно оставить после заморозки, если:
Все запросы на слияние Community Edition от членов команды GitLab, слиянные на день заморозки (7го числа), должны иметь соответствующее слияние Enterprise Edition, даже если нет конфликтов. Это делается для уменьшения размера последующего слияния EE, поскольку мы часто слиям много в CE на день выпуска. Для получения более подробной информации см. [ограничение конфликтов с EE при разработке на CE][limit_ee_conflicts].
Как только стабильная ветка заморожена, только исправления регрессий (баги, внесенные в ту же самую версию) и безопасности будут переноситься в стабильную ветку. Любые запросы на слияние, перенесенные в стабильную ветку для предыдущего выпуска, также будут перенесены в последнюю стабильную ветку. Эти исправления будут доставлены в следующий RC для данного выпуска, если это произошло до 22го числа. Если исправления были завершены 22го числа или позже, они будут доставлены в патч для данного выпуска.
Если вы считаете, что запрос на слияние должен быть включен в RC или патч, хотя он не соответствует этим требованиям, вы можете запросить исключение. Исключения требуют одобрения трех человек помимо разработчика:
Вы можете найти этих людей на странице команды.
Решение о том, будет ли сделано исключение, зависит от соотношения пользы и срочности изменения (насколько важно для компании, чтобы это было выпущено прямо сейчас, а не через месяц) против потенциально отрицательного влияния (вещи ломаются без достаточного времени комфортно найти и исправить их перед выпуском 22го числа). Когда есть сомнения, мы предпочитаем не переносить.
Например, возможно, что исключение будет сделано для простого улучшения производительности 1-5 строк (например, добавление индекса базы данных или добавление includes к запросу), но не для новой возможности, независимо от того, насколько она мала или тщательно протестирована.
Во время заморозки новых возможностей все запросы на слияние, предназначенные для следующего выпуска, должны иметь правильно назначенное название и метку ~"Pick into Stable", чтобы менеджеры выпуска могли найти и перенести их. Запросы на слияние без названия и этой метки не будут слиты ни в одну стабильную ветку.
После каждого выпуска мы проводим звонок для ретроспективного анализа, где обсуждаем, что пошло хорошо, что пошло плохо и что мы можем улучшить для следующего выпуска. Заметки ретроспективного анализа являются общественными и вы приглашены высказывать свое мнение по ним. Если вас интересует, вы можете даже присоединиться к [звонку ретроспективного анализа][retro-kickoff-call], на первый рабочий день после 22го числа в 18:00 CET / 11:00 PST.
Перед работой над следующим выпуском мы проводим звонок для запуска, чтобы объяснить, что мы ожидаем выпустить в следующем выпуске. Заметки запуска являются общественными и вы приглашены высказывать свое мнение по ним. Если вас интересует, вы можете даже присоединиться к [звонку запуска][retro-kickoff-call], на первый рабочий день после 7го числа в 18:00 CET / 11:00 PST.
Спасибо за ваш отчет о задаче. Пожалуйста, переформатируйте ваш отчет, чтобы он соответствовал правилам вклада.
Спасибо за отчет об ошибке, но мы поддерживаем только запросы на исправление проблем для последней стабильной версии GitLab. Я закрываю этот запрос, но если вы все еще сталкиваетесь с этой проблемой в последней стабильной версии, пожалуйста, откройте новый запрос (не забудьте сослаться на старый запрос(ы)). Убедитесь, что вы также предоставили необходимую отладочную информацию в соответствии с правилами использования трекера ошибок, указанными в наших правилах участия.
Благодарим вас за интерес к GitLab. Мы не используем трекер ошибок для запросов поддержки и вопросов конфигурации. Пожалуйста, проверьте нашу страницу получение помощи для получения информации о доступных вариантах поддержки. Также обратите внимание на правила участия для получения дополнительной информации.
Пожалуйста, используйте ```` для форматирования вывода консоли, журналов и кода, так как это очень сложно читать без этого.
Спасибо за ваш интерес к улучшению базы кода GitLab! Обновите ваш запрос слияния в соответствии с правилами участия.
Прошло уже более двух недель (и выпущена новая версия), как мы получили ответ от вас. Я закрываю этот запрос, но если вы всё ещё сталкиваетесь с этой проблемой, пожалуйста, откройте новый запрос (не забудьте сослаться на старый запрос(ы)). Убедитесь, что вы также предоставили необходимую отладочную информацию в соответствии с правилами использования трекера ошибок, указанными в наших правилах участия.
Этот запрос слияния был закрыт, поскольку запрос дополнительной информации не получил реакции более чем за две недели. Если вы отреагируете и будете придерживаться правил запроса слияния в наших правилах участия, мы снова его откроем.
Есть ли запрос на нашем трекере ошибок, который похож на этот? Вы можете привязать его здесь? Пожалуйста, будьте уверены, что новая функциональность, которая не помечена как "принимающая запросы слияния", может не попасть в GitLab.
Мы можем принять запрос слияния только тогда, когда все тесты проходят успешно. Я только что перезапустил сборку. Если тесты всё ещё не проходят после этого перезапуска и вы уверены, что это не связано с изменениями вашего кода, пожалуйста, перезапустите слияние с master, чтобы увидеть, решает ли это проблему.
Мы в настоящее время завершаем процесс закрытия нашего трекера ошибок на GitHub, чтобы предотвратить дублирование с трекером ошибок на GitLab.com. Поскольку это старый запрос, я закрываю его сейчас. Если вы считаете, что это всё ещё является проблемой, я рекомендую вам открыть его на трекере ошибок GitLab.com.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )