Модель разработки Голоса

Как есть

Команда @goloscore сейчас работает не по типу opensource-проекта. По сути, они приватно пилят изменения без предварительного обсуждения и согласования, потом пост-фактум уведомляют о готовности кода. Приходите, review-те, создавайте issues.

Сейчас имеем, что команда разработки примерно озвучила внедрённые изменения на уровне "for users", типа, такие-то и такие-то изменения в экономике.

А где описание архитектурных изменений? От команды было много нареканий по поводу качества кода стима, при этом они сами так и не удосужились чётко изложить, как же именно они улучшили архитектуру демона.

Извините, но в DPOS-системе так быть не должно.

Как должно быть

Существует некий git-репозиторий с кодом проекта. Напрямую никто в него не коммитит. В него лишь принимаются Pull request. Для одобрения PR и мёржа в репозиторий требуется согласие 17 из 19 топ-делегатов.

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

Таким образом, весь процесс становится прозрачен и понятен. Новые изменения придётся обсуждать с community. Повысится качество кода и улучшатся commit messages.

Например вот такие однострочные описания коммитов

530a342caa82fc93ae2b8a30d9dad395ef5d4764 Asset default container type initialization fixes
01a220dcc11d14bb6b6efc1b57102d131ec55ef2 Asset default initialization changes
d066ae962485db1a5d524fd1fe0516242ba311d2 Versioned asset name storage initialization changes
aa585047fab7a3cdfbe073f25a0c18e11d7f67b1 fc submodule updated
428e8d673e44315160acf402f833559608428ccd Account name registration fee removed
e8e0ea9ad6ebfa9c1ca90d88ccc01500fa44a7de More plugin operations unpack issues fixes

изменятся на вот примерно такие:

Prevent int128 from requiring more than MAXALIGN alignment.

Our initial work with int128 neglected alignment considerations, an
oversight that came back to bite us in bug #14897 from Vincent Lachenal.
It is unsurprising that int128 might have a 16-byte alignment requirement;
what's slightly more surprising is that even notoriously lax Intel chips
sometimes enforce that.

Raising MAXALIGN seems out of the question: the costs in wasted disk and
memory space would be significant, and there would also be an on-disk
compatibility break.  Nor does it seem very practical to try to allow some
data structures to have more-than-MAXALIGN alignment requirement, as we'd
have to push knowledge of that throughout various code that copies data
structures around.

The only way out of the box is to make type int128 conform to the system's
alignment assumptions.  Fortunately, gcc supports that via its
__attribute__(aligned()) pragma; and since we don't currently support
int128 on non-gcc-workalike compilers, we shouldn't be losing any platform
support this way.

Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and
called it a day, I did a little bit of extra work to make the code more
portable than that: it will also support int128 on compilers without
__attribute__(aligned()), if the native alignment of their 128-bit-int
type is no more than that of int64.

Add a regression test case that exercises the one known instance of the
problem, in parallel aggregation over a bigint column.

This will need to be back-patched, along with the preparatory commit
91aec93e6.  But let's see what the buildfarm makes of it first.

Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org

Учитесь https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary