И еще о распределенных средствах поддержки разработки

[vitus_wagner]

Что, собственно, бывает нужно от системы поддержки разработки? Очевидно, что система поддержки разработки это больше чем система управления версиями.

1. Управление версиями
2. Управление issues/тикетами.
3. Некая knowledge base для внутрипроектного применения (в наше время обычно wiki).
4. Управление правами (на коммиты, на постинг/обработку issues, на редактирование wiki).
5. Публикация релизов
6. Интеграция с репозиториями библиотек и прочего софта, от которого мы зависим.

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

Что из этого умеет собственно git? Он делает п.1 и немного п.6 (submodules и subtrees, обе фичи кривые).

Что из этого делает fossil - все кроме 4 и 6. При этом 4 он не делает by design. Хипп считает, что список юзеров на каждом из узлов - личное дело администратора узла и репликации не подлежит.

Кстати, хорошего решения для п.6 я вообще не знаю. externals в subversion не лучше submodules в git.

Но главное для распределенной системы разработки - это п.4. Придумать способ который позволяет коммитить куда попало, чтобы оно потом по всем узлам расползлость, причем коммитить не кому попало, а только тем, кому владелец проекта дал на то право - это несколько нетривиальная задача.

В принципе, ее решением мог бы быть authorized_keys файл в формате ssh, закоммиченный непосредственно в репозитории. Если человек аутентифицируется ключом, содержащимся в этом файле, значит он правильный коммитер. Правда, встает вопрос о том, что такое "аутентифицироваться ключом". Если коммит по ssh, то тут все понятно. Хотя лично мне с моей политикой "на каждом устройстве свой ключ" будет несколько напряжно это дело менеджить. Если же человек коммитится по http, то тут немного непонятно как быть.
Можно, конечно каждому проекту стать своим собственным CA, и выписать пользователям на их ssh-ключи X509-сертификаты. git можно с конфирурировать чтобы при пуше по https предъявлял клиентский сертификат.

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

Было бы проще, если бы сущестововал глобальный CA, выдающий бесплатно сертификаты не для сайтов, как Let's Encrypt, а для юзеров (идентифицируемых их E-Mail).

В принципе, конечно, существует cacert.org, но его рутовый сертификат отовсюду выпилили. А так идея там красивая - web of trust over x509. Comodo выдает Free S/MIME certificates но там в пользовательском соглашении явно запрещено использовать его для авторизации на https-сайтах.

Comments

[sur_kg]

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

Расплывчато высказано. Я с первой попытки прочитал "коммит должен попасть только в те узлы, которые имеют на него право на чтение".

[vitus_wagner]

У нас тут open source. Право на чтение всего по определению имеют все. А вот на запись...

[z3vv5yqifqx6]

Кстати, тоже не совсем всегда по определению — чтобы любители синхронных объявлений давали время заранее потестировать исправления для общих проблем используемых программой протоколов, надо иметь какую-то площадку для общения ключевых разработчиков, где можно временно скрывать обсуждения и патчи. Выплаты от Google сторонним исследователям безопасности имеют условием отложенное объявление. Так что некоторые проекты могут предпочесть пойти на такой компромисс, чтобы лучше тестировать исправления проблем, найденных исследователями, решившими взять денег у Google Project Zero.

[sur_kg]

А если понимать неизвращенно, то проще всего прикрутить к каждому репозиторию синхронизируемый ACL с аутентификацией по OpenID.

А для распределенного администрирования прав ACL тоже должен быть под распределенным версионным контролем :)

[vitus_wagner]

Ну, в общем, идея хранить список прав доступа в том же репозитории, она напрашивается. Ибо очевидно решает задачу синхронизации. А вот спасет ли здесь openid, это бо-о-ольшой вопрос. openid все же предназначен для аутентификации владельцев одних вебсайтов на других вебсайтах.

Здесь же мы имеем задачу аутентификации пользователя интернета (который коннектится к нам с помощью клиента системы управления версиями). Традиционно в git для идентификации коммитеров используются их E-Mail адреса. А для openid-а точкой входа является какая-нибудь http(s) url.

Я бы уж скорее ssh-вый authorized_keys в репозиторий коммитил.

[sur_kg]

Да, и еще. Коммиты должны быть с цифровой подписью?

[vitus_wagner]

Сейчас - не должны. Хотя git предусматривает возможность подписи коммитов, пользуются ей исключительно редко. И понятно почему.

[z3vv5yqifqx6]

а) 2/3 в принципе можно решать стандартизацией настроек Bugs Everywhere/Ikiwiki/что-нибудь из той же серии. Ну то есть репозиторий как хранилище информации, и выбрать интерфейс к этому.

б) Проблема с софтом, от которого мы зависим — что где интеграция исходников upstream, там и вопросы о том, как нам это надо собирать, после чего ненавязчиво вырастает source-based package manager и можно обсуждать форму этого вырастания.

в) Мне кажется, что если хотеть пункт 4, то внутренняя модель происходящего должна быть как у Monotone, а не как у Git. Ну да, можно потом постфактум упихать в git, если очень уж надо.

Если у нас глобальные права на запись, значит у нас глобальное понятие ветки. Если у нас глобальное понятие ветки, значит у нас у одной ветки может быть две головы (на разных концах планеты), а значит и отдельная копия должна уметь понимать, что у ветки несколько голов, а ещё хранить историю, что когда в какую ветку клали (как делают примерно все, кроме git).

Каждый commit надо подписывать ключом автора (или автора-на-конкретной-машине) автоматически (ну medium-security ключом, который разблокируется раз в подход к машине), после чего каждый узел волен посмотреть на вписанное в ветку и решить, что из этого выкинуть совсем, что хранить, но не считать кандидатом на самое-свежее, а из чего выбирать голову; в репозитории хранится рекомендуемый ACL.

Про хранение правил доступа в самой VCS в Monotone думали, но не собрались, например: http://wiki.monotone.ca/VersionedPolicy/

[vitus_wagner]

Глобальное понятие ветки у нас есть и так. И голов там может быть столько, сколько рабочих копий есть на компьютерах разработчиков. Нам могут push завернуть, заставив предварительно сделать pull и отрезолвить конфликты, это да.

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

А вот подписывать ли каждый коммит или каждый пуш - тут возникают интересные социальные последствия. Если мы подписываем каждый коммит, то коммит от имени спонсируемого новичка в общем репозитории не появится. Появится коммит спонсора с указанием в теле commit message что "вообще-то это написал такой-то, а я только проверил и закоммитил".

А если подписывать/аутентифицировать пуш, то коммиты новичков пойдут под их именами.

[z3vv5yqifqx6]

Ну вот по мнению git, если у Вас есть копия, то её ветки — это другие ветки, просто с пометками, куда делать push. А уж если upstream выглядит как три зеркала, то это будет таки три ветки в списке remote.

Я согласен, что голов будет столько, сколько машин разработчиков — и именно поэтому поддерживаю прямолинейный подход по допущению этого и в одном репозитории. Автозеркалирование без проблем создаст многоголовые ветки и будет ждать, пока человек глазами посмотрит и сделает merge. Но да, merge всё равно делать надо, и конфликты надо разруливать вручную, конечно.

Даже git, который вообще-то не особо умеет работать с метаданными, умеет отличать author и committer. Ну или commit от новичка мог бы быть предком пустого commit от одобрившего. Или можно сделать по уму и сказать, что коммит с approve от доверенного участника становится частью ветки в политике по умолчанию.

[filin]

Мне представляется более интересной идея pull с авторизацией. В смысле, push можно только туда, где администратор узла дал право. Как в fossil. А между узлами — ну, узел может по своей инициативе рассказывать, какие коммиты у него есть. А пропихнуть насильно не может.

При этом узел-получатель решает, хочет ли он этот коммит, на основании того, кто коммитил (PGP-подпись, и нехрен сюда лезть с централизованной по замыслу X509), и того, кто раздает (знакомый ли узел).

Мержить может оказаться нетривиально, если ты доверяешь не всем коммиттерам предложенного тебе набора коммитов. Но тут тоже есть политика. Если коммит от доверенного человека зависит от коммита от недоверенного, его можно пробовать втянуть для последующего cherry-pick, а можно решить, что его не надо тянуть вообще.

А что до интеграции с репозиториями зависимых библиотек, то тут лишняя интеграция вредна. Сделай себе копию, и завись от конкретного состояния кода в этой копии. От глобального указателя на это состояние. Чтобы можно было стянуть его с любой копии апстрима, в которой это состояние есть. Давая доступ к своему коду, давай также и доступ к своей копии того, от чего зависишь. Хотя бы к упоминаемому срезу.

[vitus_wagner]

Ну то есть в плане зависимостей тебе модель subtree нравится (как и мне) гораздо больше, чем submodule.

[vitus_wagner]

По X509 я предлагал аутентифицировать http-push, а не коммиты подписывать.

[z3vv5yqifqx6]

> От глобального указателя на это состояние.

Кажется, даже git submodule хранит идентификатор commit. Копию держать полезно, конечно.


(Если помечтать, то я бы хотел версионную систему, которая относительно разумно и относительно прозрачно позволяет как выделить поддиректорию в отдельный кусок — ну как Subversion позволяла взять кусочек и работать с ним, только дружественно к распределённости — и подцепить кусок — как раз как Вы говорите; в частности, это позволяло бы начинать с модели «репозиторий для всего моего кода» и выделять куски и включать вещи, которые исходно жили отдельно, по мере желания).

[z3vv5yqifqx6]

> узел-получатель решает, хочет ли он этот коммит

Это примерно как Monotone предлагает; вопрос как устроить логику для удобного распространения рекомендуемых ACL (ну кроме хранения скрипта для ACL в ветке)

[avnik]

> Мне представляется более интересной идея pull с авторизацией. В смысле, push можно
> только туда, где администратор узла дал право. Как в fossil. А между узлами — ну,
> узел может по своей инициативе рассказывать, какие коммиты у него есть. А
> пропихнуть насильно не может.

Ну так подписаные коммиты из определенныхв веток вполне можно и втягивать автоматом, и даже мержить (если есть подпись && нет конфликтов && ветка прописана как допустимая для мержа -- к примеру если от меня есть есть ветка avnik/pull-request/master и там подписаные моим ключом коммиты которых нет в мастере)

[jahr]

Точно, именно так.) Грубо говоря, нет никакого глобального состояния проекта в сети, проект в нужном состоянии собирается только локально на каждой машине на основе опбликованных "метаданных", коммиты именно "публикуются", а не форсятся куда-то в сеть. На свой опубликованный коммит можно навесить бранч или тег, если есть доступ к ключу этого бранча или тега, раздаваться он будет локально с машины коммитера, пока его кто-то еще к себе не копирует, ни на каких специальных нодах и серверах его нет. Прошу прощения за сумбурность, не успеваю сейчас нормально описать.)

[lumag]

В monotone есть проверки по RSA-ключу. Правда, не помню: являются ли сертификаты частью БД или они настраиваются отдельно.

[z3vv5yqifqx6]

Ревизии — состояния кода — живут сами по себе.

Сертификаты — утверждения про ревизию, что она сделана тем-то тогда-то в такой-то ветке с таким-то сообщением — хранятся в базе. author, branch, data, changelog — отдельные сертификаты, и можно создавать и другие (некоторые предусмотрены, но можно и вообще свои).

Ревизия без базовых сертификатов — это повод для предупреждений, но не фатальная проблема (ну, если пользователь не настроил, чтобы это была фатальная проблема).

В базе же хранятся виденные публичные ключи.

Доступ на сервер конфигурируется двумя отдельными текстовыми конфигами, на чтение и на запись.

Пользователь в принципе может настроить себе правила, какие подписи в какой ветке его устраивают, а какие нет. Для этого надо написать небольшую функцию на Lua и добавить её в конфигурационный файл на машине.

[filin]

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

Поэтому если уж сюда думать, то в сторону pluggable конструкции со специфицированным протоколом обмена информацией между VCS, трекером и базой знаний. При этом, конечно, информацию трекера и базы знаний тоже надо хранить в VCS. В формате, позволяющем поменять оные движки с сохранением информации, ага.

Но вполне возможно, что информация трекера и базы знаний — это отдельные репозитории. Потому что у нас, например, есть несколько довольно слабо связанных подсистем, и код хранится аж в четырех системах версионирования. И мне в работе нужны два репозитория из четырех (а один из двух ненужных я к себе тупо не втяну, места нет). А трекер и база знаний общие. В базе знаний, в частности, хранится информация о том, как именно связывать подсистемы.

[z3vv5yqifqx6]

Тонкости, про которые было бы интересно узнать мнения:

1) Информация — это не только обмен, но и упоминания. Упоминания в базе знаний обсуждений в системе отслеживания задач, или тех же задач в комментариях к ревизиям, а то и вовсе упоминания разделов базы знаний в комментариях в коде.

1а) Если обсуждения в системах отслеживания задач обычно можно себе позволить нумеровать по порядку, то вопрос устройства базы знаний интересен. Хочется поставить ссылку, которая одновременно достаточно точна и достаточно долгоживущая, но при этом не хочется запрещать масштабные перестановки текста для улучшения читаемости…

1б) Как все эти вещи, живущие в независимых репозиториях, будут ссылаться друг на друга — отдельно интересно. Но может быть хорошо бы сформулировать хотя бы решение в модели жизни как у Monotone: есть одна база данных, в которую можно положить много веток многих проектов, и ветки/проекты уже в силу этого имеют глобальные имена, по которым и сошлёмся.

2) Замена движка. На самом деле, если понятие сохранения информации для двух движков вообще имеет смысл, то эти два движка довольно сильно похожи. Не знаю там, Wagn интересная Wiki, но вот её модель жизни сильно отличается от некоторых других. И как вообще группируются задачи и что для них основное…

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

3) Вот сказано «поиск». Но поиск — это и поддержание «алфавитных» указателей, и как должны жить сгенерированные данные для поиска и тому подобных дополнительных возможностей? Локально? Или тоже в репозитории с пометкой, что при конфликте просто порождать с нуля заново?

Fossil, Veracity etc., кажется, не имеют этой проблемы в силу того, что нижний слой — уже база данных и можно попросить её построить нужные индексы.

Ikiwiki (это которая поверх версионки) и Smallest Federated Wiki (просто как пример распределённой Wiki) вроде считают, что данных не очень много и можно себе позволить их просто все прочесать.

[vitus_wagner]

Это ты прав. Правда, следует учесть что тракеры, например может хотеться тащить из сложной (командной) системы в простую (персональную). Например у таскворриора был прибамбас для импорта из jira.

[max630.net]

> Что из этого умеет собственно git? Он делает п.1 и немного п.6 (submodules и subtrees, обе фичи кривые).

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

[dbatyuk]

>> Хотя лично мне с моей политикой "на каждом устройстве свой ключ" будет несколько напряжно это дело менеджить.

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

[vitus_wagner]

Зачем функуию-то добавлять? Ключи уже лежат в этом репозитории в текстовмом файле.
Вопрос в том, что там возникает декартово произведение проектов на машины.