Когда много файлов в реквесте, ревьювер просматривает все и делает замечания, например, по пяти файлам.
Автор реквеста отправляет коммит с фиксами. И теперь ревьюверу нужно снова просмотреть все файлы, которые он уже просмотрел. Потому что нет никакого механизма на сегодняшний день быть уверенным, что в последнем коммите автор не изменил «по пути» что-нибудь ещё.
Если же ревьювить не по изменениям целого реквеста, а по коммитам, то в больших реквестах это неудобно тем, что:
1. Ревьювер теряет контекст, если в одном коммите вносятся изменения, которые логически связаны с изменениями с другого коммита. Ревьювер видит только изменения с одного коммита.
2. Если автор смёрджил все коммиты в один и отправил форсированно, то всё равно смотреть придётся уже все изменения.
Собственно, этим и обеспечивается удобство и ясность интерфейса: то, что нужно часто — находится под рукой, а всё остальное убрано с глаз.
Я согласен со многим Вами сказанным.
А она там есть? :) А для чего их нужно сортировать? Мой любимый подход — не накапливать, тогда не надо будет сортироваться. Если серьёзно — issues гитхаба просто не очень подходят для проектов, в которых ими нужно полноценно «управлять». Хотя некоторые проекты (вроде Go — 25к issues) как-то умудряются этим пользоваться.
Не всегда получается не накапливать. А когда количество ишьюс разрастается, начинается ад при работе с интерфейсом гитхаба.
Конечно, это минус — для таких проектов. А для всех остальных, которых намного-намного больше — это плюс, потому что issues гитхаба единственный настолько простой и удобный трекер, что в него реально добавлять мелкие TODO по коду вместо того, чтобы вставлять их в код комментариями. Не скажу за гитлаб (мало пользовался), но при мысли о том, чтобы вместо комментария TODO пойти создать issue в Redmine или JIRA возникает только одно желание — выкинуть эту мысль из головы.
Ну здесь разность подходов.
Я предпочитаю не добавлять тудушки в код. Вместо этого лучше добавить ишью с нужной меткой. Это и визуально лучше видно, и позволяет лучше распланировать время разработчика в команде, и позволяет взять задачу кому-то другому.
Этот же подход приветствуется в гитлабе. Например, в мёрдж реквесте можно из дискуссии в один клик создать новую ишью с автоматической подстановкой контекста.
Это нужно при возникновении ситуации, когда происходит ревью кода и ревьювер находит какую-то вещь, которую нужно поправить, но эта правка выходит за рамки работы текущего реквеста.
Тогда удобно кликом создать ишью и двигаться дальше, не отвлекаясь на ответвления в задаче.
Кроме этого, гитлабовцы часто создают ишью прямо из каналов слака в процессе обсуждения чего-либо. Одна команда — и готово. Не выходя из слака.
Вот честно, никогда не было претензий к скорости загрузки страниц на гитхабе — наоборот, его скорость работы только радует. Что касается «несколько раз кликать» — вопрос в том, как часто это приходится делать. Обычно — крайне редко, потому что все часто используемые фичи находятся как раз на расстоянии одного клика.
Сколько ярких слов я выговаривал в адрес «прекраснейшего» дизайна гитхаба, пытаясь найти ссылки на milestones, labels, gists и my projects (до сих пор плююсь), пока не запомнил визуально, где эти ссылки находятся.
А сортировка issues / PRs, которая не запоминается, у меня вообще в голове не укладывается.
Есть и другие мелочи, которые после гитлаба корёжат мои привычки и чувство удобства. :)
Это просто как пример того, что интерфейс становится неплохим, когда привыкаешь и запоминаешь, что где находится.
Это не так. UI/UX гитхаба абсолютное большинство считает лучше альтернатив, включая гитлаб. Да, в офисе будут юзать гитлаб без проблем, он вполне приемлемый… но стоит возникнуть вопросу куда разместить личный мелкий проект — сразу бегут туда, где удобнее, и обычно это не гитлаб.
Это очень спорное утверждение.
На гитхаб бегут потому что он самый популярный. Куча народа там, он у людей на слуху. А для некоторых людей ещё и «гит == гитхаб». Примерно как «линукс == убунту».
Поэтому я за конкуренцию. От этого выигрывают все.
Имеется ввиду скроллбар менюшки при ограничениях по вертикали?
избавьтесь от самовыскакивающих popup менюшек.
Много копий было сломано на эту тему. Проводились UX surveys, спорили, собирали фидбек.
Думаю, что в ближайшее время на это никто не пойдёт. Если только придёт куча народа и поставит свои «пальцы вверх».
Персонально мне меню гитилаба нравится гораздо больше, т.к. требует только один клик для доступа к нужным разделам + ждать только один раз загрузку страницы.
На гитхабе же нужно кликать несколько раз + ждать загрузку страниц после каждого клика.
то, что некоторые выскакивающие подменюшки содержат только заголовок, а некоторые и заголовок и подпункты — уже плохо
Согласен. Даже где-то такой ишью был.
В любом случае написал в UX team.
По большому счёту — всё это про одно и то же: навигация должна быть простая, линейная и очевидная. У вас же там разнообразие и многоуровневость. Всё это признак того, что вы не справились с управлением сложностью (что, вообще-то, ключевой навык при разработке софта) — у вас много функционала, неясно как его представить юзеру по-простому, и вы его вывалили как получилось, попытавшись замаскировать сложность скрывая части меню (popup-ами и collapse-ом), но от этой маскировки стало только хуже.
Согласен. Лично я тоже предпочитаю упрощённые интерфейс, а не поиск по настройкам. :)
Правда гитхабовский интерфейс для меня далёк от оптимального, как и гитлабовский. Поэтому на сегодняшний день оба интерфейса — это вопрос привычки.
те же репы, которые отметили друзья — этой фишкой много прикольных разработок было найдено. Тут довольно долго можно перечислять, потому что на гитлабе довольно скупо все с соц составляющей. Но репы которые отметили друзья — для меня киллер фича гихаба в плане социалки.
Постараюсь добиться конкретных сроков. Я и сам на гитхабе пользуюсь лентой активности друзей.
ps: у гитлаба с социалкой скупо из-за того, что приоритетов не было в эту сторону. Сейчас же с развитием ситуации вокруг гитхаба возможно взгляд руководства немного изменится.
на гитхабе есть travis и appveyour, а гитлаб дает тебе только linux раннеры с ограничением на бесплатное проц время. А если тебе нужны раннеры для винды или макоси, плати деньги. Это большущий минус гитлаба и причина оставаться на гитхабе
Может я не понял смысл слова раннер в данном контексте, но GitLab Runner (запускалка пайплайнов) доступна для Linux, Windows, MacOS X, FreeBSD: docs.gitlab.com/runner/install/index.html
Если же речь идёт про запуск пайплайнов в каком-то конкретном окружении, то это можно сделать с помощью image.
1. Про AssciiDoc отписал манагеру.
2. Боковую менюшку выстрадали всем коллективом. Менять её в ближайшее время не будут. Это крайне маловероятно. Но если что-то улучишть в рамках текущей концепции — это можно, если есть какие-то конкретные предложения.
Приоритетом issues эту не починишь, это надо переманивать юзабилистов из гитхаба и делать что они посоветуют.
Я могу напрямую обратиться к ребятам из UX team. Но сами понимаете, если я им скажу общие слова «надо бы улучшить в общем», они мне так и ответят «улучшим в общем». :)
Что конкретно нужно добавить? Какие-то фичи, кнопки, что-то ещё?
Чего именно не хватает?
2) меньше готовых CI
Речь идёт про шаблоны к CI? Если да, то каких конкретно не хватает?
3) печальная производительность в боевых условиях
В целом такая проблема существует. Она понимается внутри компании, и вопросам производительности отводится существенная роль.
На бэке наиболее медленные компоненты переписываются на голанге. Например, работа с гитом сейчас в процессе миграции с redcarpet на gitaly.
Плюс рефакторинг и оптимизация кода.
В новом 11-м релизе наконец-то выпилили spinach и портировали всё, что оставалось, на rspec. Конкретных цифр не назову, но в целом производительность прогона тестов повысилась, и качество покрытия тестами улучшилось.
На фронте идёт миграция на VueJS в сторону отдельных SPA. Да и в целом отчистка и оптимизация кода. Фронтовики в слаке постоянно «в мыле». :)
Дбашники и админы тоже постоянно оптимизируют и конфигурируют код и инфраструктуру.
Если есть замечания по каким-то конкретным местам, напишите, пожалуйста. Я посмотрю, можно ли привлечь дополнительное внимание манагеров на эти проблемы.
когда конкурент (вероятнее всего это будет gitlab) станет удобнее гитхаба.
Чем сегодняшний гитлаб неудобен по сравнению с гитхабом?
Если есть что-то конкретное, то попробую посодействовать в изменении приоритета соответствующих issues.
Без контекста вообще непонятно, зачем использовать более длинный future perfect вместо обычного future simple.
Есть ещё конструкции с «should/might/etc + have», например, she should have returned the book.
Не знаю, насколько это «тонкости» языка, но запомнить довольно просто.
Всё, что should/may/etc + have расценивается как «должен был/мог бы/пр что-то сделать, но просохатил момент».
She should have returned the book — она должна была вернуть книгу (контекст: но не сделала этого/просохатила/пропёрлась/затупила/и т.д.).
You should've done that thing. But now you're fired!
Ты должен был сделать эту вещь. Но теперь ты уволен!
She will returned the book — ошибка синтаксиса. :)
Если имелось ввиду «she will have returned the book», то ситуация аналогичная как и с present/past perfect. Просто акцентируем внимание на каком-то моменте в будущем. И этот момент играет какую-то важную роль для понимания конекста. Я такое встречал редко.
She will return the book — она вернёт книгу. На момент времени, к которому она вернёт книгу, нам пофигу, поэтому future simple.
Perfect употребляется в том случае, если Вы хотите сакцентировать внимание, что действие было сделано, и сделано оно было к какому-то моменту в прошлом (past perfect) или в настоящем (present perfect).
Если же нет необходимости акцентировать внимание на завершённость действия к какому-то конкретному моменту, то употребляется простой past simple.
Примеры.
1. Она вернула книгу (нет акцента, к какому моменту она вернула книгу) -> past simple -> she returned the book.
2. Она вернула книгу (хотите указать, что она вернула к текущему моменту, и это важно знать) -> present perfect -> she has returned the book.
Здесь же можно добавить маркер времени, чтобы было уж совсем явно. Например, already или just. А можно и не добавлять, если по контексту и так понятно.
3. Она вернула книгу (хотите указать, что она вернула книгу к какому-то моменту в прошлом и это важно обозначить в текущем контексте) -> past perfect (past — потому что к моменту в прошлом) -> she had returned the book [тут какой-нибудь маркер момента в прошлом, если по контексту это требуется].
TLDR: контекст очень важен! Нет контекста, или нет маркеров момента, или обозначение момента не важно — past simple во все поля.
Отличная аллюзия!
Не хватает ответа от автора:
Потому что это мой выбор!. :)Пишу через полгода. :)
Южно-Сахалинск — это вполне себе цивилазиция в наши дни.
Но все остальные населённые пункты — уже уныние.
Но на больших реквестах вылазиет другая проблема.
Когда много файлов в реквесте, ревьювер просматривает все и делает замечания, например, по пяти файлам.
Автор реквеста отправляет коммит с фиксами. И теперь ревьюверу нужно снова просмотреть все файлы, которые он уже просмотрел. Потому что нет никакого механизма на сегодняшний день быть уверенным, что в последнем коммите автор не изменил «по пути» что-нибудь ещё.
Если же ревьювить не по изменениям целого реквеста, а по коммитам, то в больших реквестах это неудобно тем, что:
1. Ревьювер теряет контекст, если в одном коммите вносятся изменения, которые логически связаны с изменениями с другого коммита. Ревьювер видит только изменения с одного коммита.
2. Если автор смёрджил все коммиты в один и отправил форсированно, то всё равно смотреть придётся уже все изменения.
На эту тему есть gitlab.com/gitlab-org/gitlab-ce/issues/29682
В частности интересует Сахалин.
Мониторинг продакшена гитлабовский открыт для чтения любому.
monitor.gitlab.net/dashboard/db/github-importer
Я согласен со многим Вами сказанным.
Не всегда получается не накапливать. А когда количество ишьюс разрастается, начинается ад при работе с интерфейсом гитхаба.
Ну здесь разность подходов.
Я предпочитаю не добавлять тудушки в код. Вместо этого лучше добавить ишью с нужной меткой. Это и визуально лучше видно, и позволяет лучше распланировать время разработчика в команде, и позволяет взять задачу кому-то другому.
Этот же подход приветствуется в гитлабе. Например, в мёрдж реквесте можно из дискуссии в один клик создать новую ишью с автоматической подстановкой контекста.
Это нужно при возникновении ситуации, когда происходит ревью кода и ревьювер находит какую-то вещь, которую нужно поправить, но эта правка выходит за рамки работы текущего реквеста.
Тогда удобно кликом создать ишью и двигаться дальше, не отвлекаясь на ответвления в задаче.
Кроме этого, гитлабовцы часто создают ишью прямо из каналов слака в процессе обсуждения чего-либо. Одна команда — и готово. Не выходя из слака.
Сколько ярких слов я выговаривал в адрес «прекраснейшего» дизайна гитхаба, пытаясь найти ссылки на milestones, labels, gists и my projects (до сих пор плююсь), пока не запомнил визуально, где эти ссылки находятся.
А сортировка issues / PRs, которая не запоминается, у меня вообще в голове не укладывается.
Есть и другие мелочи, которые после гитлаба корёжат мои привычки и чувство удобства. :)
Это просто как пример того, что интерфейс становится неплохим, когда привыкаешь и запоминаешь, что где находится.
Это очень спорное утверждение.
На гитхаб бегут потому что он самый популярный. Куча народа там, он у людей на слуху. А для некоторых людей ещё и «гит == гитхаб». Примерно как «линукс == убунту».
Поэтому я за конкуренцию. От этого выигрывают все.
Имеется ввиду скроллбар менюшки при ограничениях по вертикали?
Много копий было сломано на эту тему. Проводились UX surveys, спорили, собирали фидбек.
Думаю, что в ближайшее время на это никто не пойдёт. Если только придёт куча народа и поставит свои «пальцы вверх».
Персонально мне меню гитилаба нравится гораздо больше, т.к. требует только один клик для доступа к нужным разделам + ждать только один раз загрузку страницы.
На гитхабе же нужно кликать несколько раз + ждать загрузку страниц после каждого клика.
Согласен. Даже где-то такой ишью был.
В любом случае написал в UX team.
Согласен. gitlab.com/gitlab-org/gitlab-ce/issues/41230
Согласен. Лично я тоже предпочитаю упрощённые интерфейс, а не поиск по настройкам. :)
Правда гитхабовский интерфейс для меня далёк от оптимального, как и гитлабовский. Поэтому на сегодняшний день оба интерфейса — это вопрос привычки.
Будем улучшать, что ж поделать.
Открывается достаточно быстро (смотря с чем сравнивать, конечно).
Диффы загружаются долго, согласен.
Работа по производительности мердж реквестов ведётся.
gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&label_name[]=merge%20requests
gitlab.com/gitlab-org/gitlab-ce/issues/30868
Постараюсь добиться конкретных сроков. Я и сам на гитхабе пользуюсь лентой активности друзей.
ps: у гитлаба с социалкой скупо из-за того, что приоритетов не было в эту сторону. Сейчас же с развитием ситуации вокруг гитхаба возможно взгляд руководства немного изменится.
Может я не понял смысл слова
раннерв данном контексте, но GitLab Runner (запускалка пайплайнов) доступна для Linux, Windows, MacOS X, FreeBSD: docs.gitlab.com/runner/install/index.htmlЕсли же речь идёт про запуск пайплайнов в каком-то конкретном окружении, то это можно сделать с помощью image.
2. Боковую менюшку выстрадали всем коллективом. Менять её в ближайшее время не будут. Это крайне маловероятно. Но если что-то улучишть в рамках текущей концепции — это можно, если есть какие-то конкретные предложения.
Я могу напрямую обратиться к ребятам из UX team. Но сами понимаете, если я им скажу общие слова «надо бы улучшить в общем», они мне так и ответят «улучшим в общем». :)
Что конкретно нужно добавить? Какие-то фичи, кнопки, что-то ещё?
Чего именно не хватает?
Речь идёт про шаблоны к CI? Если да, то каких конкретно не хватает?
В целом такая проблема существует. Она понимается внутри компании, и вопросам производительности отводится существенная роль.
На бэке наиболее медленные компоненты переписываются на голанге. Например, работа с гитом сейчас в процессе миграции с
redcarpetнаgitaly.Плюс рефакторинг и оптимизация кода.
В новом 11-м релизе наконец-то выпилили
spinachи портировали всё, что оставалось, наrspec. Конкретных цифр не назову, но в целом производительность прогона тестов повысилась, и качество покрытия тестами улучшилось.На фронте идёт миграция на
VueJSв сторону отдельных SPA. Да и в целом отчистка и оптимизация кода. Фронтовики в слаке постоянно «в мыле». :)Дбашники и админы тоже постоянно оптимизируют и конфигурируют код и инфраструктуру.
Если есть замечания по каким-то конкретным местам, напишите, пожалуйста. Я посмотрю, можно ли привлечь дополнительное внимание манагеров на эти проблемы.
Что-то нужно добавить? Или что-нибудь изменить?
Чем сегодняшний гитлаб неудобен по сравнению с гитхабом?
Если есть что-то конкретное, то попробую посодействовать в изменении приоритета соответствующих issues.
Squash and mergeпортирована вCommunity Edition. Доступна будет в11.0.Есть ещё конструкции с «should/might/etc + have», например, she should have returned the book.
Не знаю, насколько это «тонкости» языка, но запомнить довольно просто.
Всё, что should/may/etc + have расценивается как «должен был/мог бы/пр что-то сделать, но просохатил момент».
She should have returned the book — она должна была вернуть книгу (контекст: но не сделала этого/просохатила/пропёрлась/затупила/и т.д.).
You should've done that thing. But now you're fired!
Ты должен был сделать эту вещь. Но теперь ты уволен!
Если имелось ввиду «she will have returned the book», то ситуация аналогичная как и с present/past perfect. Просто акцентируем внимание на каком-то моменте в будущем. И этот момент играет какую-то важную роль для понимания конекста. Я такое встречал редко.
She will return the book — она вернёт книгу. На момент времени, к которому она вернёт книгу, нам пофигу, поэтому future simple.
Если же нет необходимости акцентировать внимание на завершённость действия к какому-то конкретному моменту, то употребляется простой past simple.
Примеры.
1. Она вернула книгу (нет акцента, к какому моменту она вернула книгу) -> past simple -> she returned the book.
2. Она вернула книгу (хотите указать, что она вернула к текущему моменту, и это важно знать) -> present perfect -> she has returned the book.
Здесь же можно добавить маркер времени, чтобы было уж совсем явно. Например, already или just. А можно и не добавлять, если по контексту и так понятно.
3. Она вернула книгу (хотите указать, что она вернула книгу к какому-то моменту в прошлом и это важно обозначить в текущем контексте) -> past perfect (past — потому что к моменту в прошлом) -> she had returned the book [тут какой-нибудь маркер момента в прошлом, если по контексту это требуется].
TLDR: контекст очень важен! Нет контекста, или нет маркеров момента, или обозначение момента не важно — past simple во все поля.
На translate.gitlab.com русскоязычных человека 2-3 всего заходят.
Приходите, голосуйте за переводы. :)