Иван Денисов писал(а):
Пётр, идея с раскидыванием ББ по разным репозиториям просто кошмарна. Во первых, он и так маленький, нечего там раскидывать, просто. Весь репозиторий в сжатом виде 7M. Во вторых, представьте недоумение нового участника сообщества... Как он должен догодаться как склеить это чудо? В третьих, кто это будет выделять какие-то области ответственности? Как это себе представляешь?
Суть не в размере подсистем/сборки, а в насыщенности кода каждой из подсистем. Лично я стараюсь не переоценивать возможностей своего мозга. Конечно, легко, например, поменять сигнатуру хука в System и тут же поправить реализацию в Std, лично, никого не спрашивая и ни с кем не взаимодействуя. Но потом таких правок накопится критическая масса и они просто взорвут концепцию компонентного каркаса изнутри, останется только монолит из перекрёстных правок.
Новые участники сообщества скачают архив с сайта. Напомню, что мы тут говорим про группу шаристых товарисчей, изъявивших желание стать новым центром. Ну какие новички, о чём вы? Давайте, всё же, без эмоций.
Распределение будет происходить меритократически, по предыдущим заслугам - мы все знаем, что Илья Ермаков разбирается в ядре ББ лучше меня. Значит, разумнее отдать контроль над Kernel ему, значит, подсистема System уходит оберонкору. И так далее. В итоге либо люди закончатся, либо подсистемы.
Роман М. писал(а):
Можно иметь два репозитория: первый - поддерживаемый сопровождающими (maintainers) сборку ББ (ранее упомянутый "центр") и второй, независимый от первого - поддерживаемый различными группами разработчиков.
Роман, второй репозиторий уже существует, это
http://oberoncore.ru/bbcc/subs/start. Надо ограничить обсуждение проблемами "BlackBox Center", а именно
консервативное эволюционное развитие минорных версий BlackBox, начиная с последней версии Ominc.
Роман М. писал(а):
Согласен. Однако также нужно продумать способы создания сборки. Конечно, всегда можно заниматься этим вручную. Только стоит ли?
А ведь можно и автоматически. В случае, если ocf/osf и прочие не находятся в репозитории стандартной сборки ББ, просто автоматически создать сборку в ZIP из неё не получится.
Таким образом, приходим к необходимости инструмента автоматической сборки ББ для того, чтобы не хранить статичный код в репозитории.
Эхэхэх, когда-то я поднимал
тему.
В данном случае, у нас получается состояние полностью неоткомпилированного ББ, который с помощью рабочего ББ приводится в рабочее состояние и упаковывается в архив для публикации. Автоматически или нет, сейчас это не важно. Сейчас достаточно того, что некий мейнтейнер соберёт снимки всех подсистем, проверит их и запустит процесс. Ну или не сможет запустить, и напишет багрепорт.