Я думаю тут скорее философский вопрос: можно ли называть что-то hg/git, если интерфейсы совпадают, а ядро и инфра свои

Мне, как пользователю hg в фб довольно пофиг в обычный день , что под капотом; при этом "интерфейс" hg очень сильно влияет на то, как люди разрабатывают

Нельзя конечно. У тебя много стораджей повторяют интерфейс S3, но они же не являются Амазоном С3

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

Последний опрос на сегодня, обещаю)

А если в машине мотор или систему выхлопа поменять, можно её по-старому называть?)  я просто думал что hg это в первую очередь протокол, а не реализация

Можно но до определенного момента, потом надо и клиент и протокол допиливать у мс есть проект - scalar

У нас тоже кастомная реализация (кривая)

Насколько я слышал, ваша реализация не решает проблемы больших репозиториев, т.е. не умеет делать нормальный sparse checkout (нормальный == не тащить ненужную историю и ненужные части source tree)

Фреймворки говорите, jQuery умер говорите https://twitter.com/levelsio/status/1308145873843560449?s=21

ваш код приносит деньги когда он работает, а не когда вы его пишете (ц)

levelsio в принципе крутой перец, который умеет в стартапы )

номадлист тоже на пхп, кстати ) это его же проект https://nomadlist.com/open )

Именно

Bitbucket субъективно выигрывает в интеграции с jira, confluence, fisheye. Так же имхо более удобная работа с PR. Из минусов - нет поддержки markdown удобной в продуктах (через плагины не очень удобно). Отдельная боль это bamboo. YML спеки не интегрированны с crowd группами безопасности. Поэтому если есть нужда скрыть билдпланы одних клиентов от других клиентов - приходится использовать java spec всегда (шаблон один во всех проектах по факту). Вторая проблема с bamboo - он просто ничего не умеет, поэтому решили эту проблему используя docker + buildkit как ci раннер. Такой подход оказался супер удобным и в основаном убрал всю боль работы с bamboo. Отдельные пути в графе сборки мультистеп билда это запуск тестов, сонара и т.д. работает все в много потоков, само паралелится и кешируется. Задача бамбу же одна - пробросить секреты в args и запустить docker build. Пару раз такие докер билд пайплайны переносили в github actions - вообще легко, т.к. там тоже есть buildkit. В гитлаб тоже переносили, но там были сложности с remote agents в докере. Еще у гитлаба есть свой docker registry - но он как бы бесполезен, все равно нужно свой отдельный поднимать. Так же с гитлабом идёт mattermost - он офигенен, поэтому мы его отдельно подняли без гитлаба. В целом и имхо гитлаб хорош для небольшой компании где все работают над одним продуктом и все технари. Но субъективно для небольшой технической команды github удобнее (actions тащат). Имхо нет смысла гитлаб использовать если уже есть набор атлассиан продуктов - они покрывают больше сценариев и удобны для взаимодействия с пм, по, контентщиками, сеошниками, менеджерами и т.п.

Там ещё обычная vps с SQLite

Спасибо :)

У кого-нибудь был опыт кастомизации TestRail?

Тестировщики хотят что-то типа автодополнения, как в IDE (Пишешь !some и он тебе меню предлагает, где есть !somecommand1, !somecommand2 и т.п.).
Документация не особо богата на примеры сложнее, чем Hello World в алёрте, поэтому если у вас было что-то подобное — подскажите, как лучше всего решить проблему эту?

крутая идея, но юридически закопаешься.

предвижу "наша бета версия работает только в штатах и только с C-Corp"