среда, 3 июня 2009 г.

Boost needs reviewers или “У соседа корова дохнет. Пустячок, а приятно”

В этот раз позволю себе откровенно позловредничать. Но сразу хочу подчеркнуть, что есть библиотеки и разработчики библиотек (против которых я ничего не имею), а есть сам Boost – организация со своими целями и проблемами. Вот про организацию речь и пойдет.

Цитаты из свежего письма в списке рассылки “Boost Announce”:

As always, we need experienced review managers. The review queue has
been growing substantially but we have had few volunteers, so manage
reviews if possible and if not please make sure to watch the review
schedule and participate.

We are also suffering from a lack of reviewers. While we all
understand time pressures and the need to complete paying work, the
strength of Boost is based on the detailed and informed reviews
submitted by you. A recent effort is trying to secure at least five
people who promise to submit reviews as a precondition to starting
the review period.

На мой взгляд, начинает проявляться изначальная проблема организации Boost-а: сбора разнородных библиотек под одну большую крышу. Это не правильная политика. По двум причинам (как минимум):

  1. Сам механизм отбора базируется на механизме добровольного review. За развитием Boost-а следят далеко не все практикующие программисты, а только небольшая их часть, которым это интересно. Среди этой небольшой части есть только часть тех, кто принимает участие в review. Ну и еще вопрос о том, насколько заинтересованы именно они в этой конкретной библиотеке.
  2. Попавшие в Boost библиотеки оказываются, я бы сказал, лучше распиаренными, чем их аналоги вне буста. Поскольку “Boost – это бренд” и сейчас многие программисты в поисках подходящего инструмента сначала заглядывают в Boost, а уже потом смотрят вокруг.

Из этих двух причин проистекают различные следствия.

Тот же процесс review. Откуда возьмутся толпы добровольцев, которые захотят рассматривать десятки предлагаемых к включению в Boost библиотек? Особенно, если изрядная часть этих библиотек решает какие-то специфические и нетривиальные задачи.

Далее, вошла в Boost библиотека и что потом? Пока автор библиотеки имеет желание и возможность ее развивать и поддерживать – она будет жить. А потом? Откуда возьмется новый доброволец, который будет занимается ей дальше? Если речь идет о какой-то очень востребованной и безальтернативной библиотеке (вроде Boost.Multindex), то желающие найдутся. А если это какой-нибудь FiniteStateMachine или Spirit?

Что будет происходить, когда в Boost будут предлагать включить альтернативные варианты уже имеющихся в нем библиотек? Вот сейчас есть Boost.Range. Хотят еще добавить какой-то RangeEx. В чем смысл существования под одной крышей обоих Range?

До каких пределов будет увеличиваться размер Boost-а? Сейчас его tar.bz2 архив занимает порядка 30Mb. Что будет дальше – 50Mb, 100Mb? И это при том, что в 1.5Mb архиве POCO практических инструментов для решения моих насущных задач оказывается больше, чем в 30Mb Boost-е.

Что, в конце-концов, представляет из себя Boost – это полигон для отбора новых библиотек в стандарную библиотеку будущих версий C++ или же это собрание production ready компонентов для использования в промышленной разработке? Если честно, то я не представляю, как оба эти качества могут объединяться в одном проекте.

А что, на мой взгляд, могло бы стать альтернативой Boost-а?

Во-первых, унифицированная кроссплатформенная система сборки C++ проектов. Тот же Scons. Ну или CMake. Хотя и мой Mxx_ru был бы не плох ;)

Во-вторых, унифицированная система дистрибуции C++ных библиотек. Аналог RubyGems. Т.е. нужен тебе C++ный компонентик (C++ный кирпичик -- C++ brick), скажем RangeEx, ты делаешь:

cppbrick install RangeEx --version ‘>1.3.0’

и получаешь компонент RangeEx с последней стабильной версией, номер которой больше 1.3.0.

В-третьих, централизованное хранилище доступных C++ компонентов. Аналог RubyForge. Кроме того, что это хранилище будет использоваться для загрузки нужных пользователям C++ компонентов, на нем еще будет вестись статистика использования компонентов. И данная статистика как раз будет одним из критериев определения востребованности и качества компонента.

В-четвертых, централизованная система тестирования компонентов. Например, когда новая версия компонента публикуется в хранилище, разработчик компонента указывает, какие версии сторонних компонентов ему нужны. Скажем, RangeEx версии 1.3.5 нуждается в Config 3.4.* и IteratorTraits 2.0. После публикации хранилище производит автоматическое тестирование RangeEx 1.3.5 с соответствующими версиями Config и IteratorTrais. И отчет тестирования публикуется вместе с описанием компонента. Чтобы потенциальные пользователи могли его увидеть. Можно пойти и еще дальше. Когда разработчик IteratorTraits публикует новую версию, которую он объявляет совместимой с версией 2.0, хранилище может автоматически протестировать ее со всеми компонентами, которые зависят от IteratorTrais 2.0. После чего отчеты тестирования могут быть отправлены как разработчику IteratorTraits, так и разработчикам использующих IteratorTraits компонентов.

Такой подход, на мой взгляд, позволит отказаться от процедуры review вообще. Человек делает библиотеку для себя, публикует ее. Если это хорошая библиотека, если она в достаточной степени задокументированна, то она будет использоваться. Если она будет использоваться и разработчик захочет ее развивать – он будет прислушиваться к мнениям и пожеланиям пользователей. Если же разработчик не захочет больше ей заниматься, то ничего страшного – она все равно останется опубликованной и для нее будет известно, с какими версиями сторонних компонентов она может работать.

Что еще важно, так это то, что я получаю возможность выбрать для себя только то, что нужно мне здесь и сейчас. И получить только это. Если мне нужен 100Kb RangeEx для которого потребуется 1Mb Config и 500Kb IteratorTraits, то я получу только 1.6Mb зависимостей для моего проекта. А на 30Mb, как сейчас.

Вот как-то так.

Отправить комментарий