Библиотека сайта rus-linux.net
Свой свободный программный проект. Часть 3
Оригинал: Running a free software project
Автор: John Calcote
Дата: 9 октября 2007
Перевод: Александр Тарасов aka oioki
Дата перевода: 21 сентября 2007
При копировании материала обязательны указание автора, переводчика и ссылки на оригинал статьи и настоящую страницу как первоисточник перевода!
Первая часть
Вторая часть
Обсуждение статьи на форуме LOR
Выпуск программ: tarball-ы, бинарные пакеты и средства autotools
Знаете ли вы кого-нибудь, у кого есть 27 компьютеров с тремя работающими версиями 9 разных операционных систем? Мало кто из индивидуальных разработчиков свободных программ может себе позволить такое оборудование для сборки и отладки своих программ. Некоторые крупные компании спонсируют популярные свободные проекты, предоставляют оборудование администраторам проектов. Даже если вы начинающий индивидуальный разработчик, то возможно получить доступ к таким ресурсам, к примеру, с помощью openSUSE Build Service, но об этом далее.
Сначала нужно определиться, какую платформу поддерживать. В мире свободных программ преобладают три платформы: Win32, Mac и Linux/Unix. Для сред Win32 и Mac вы как разработчик можете сделать не так много; реально организовать лишь отдельные, не связанные между собой установщики, которые будут работать лишь на конкретной платформе. Если вы все-таки решитесь поддерживать версии для Win32 или Mac, то нужно определиться конкретнее с версиями платформ, а затем найти соответствующие компьютер и ОС, на которых вы будете проверять работоспособность своей программы и создавать пакеты.
В мире Linux/Unix ваши возможности расширяются. При правильном выборе средств разработки тестирование, сборка и создание пакетов производятся на большинстве современных дистрибутивов GNU/Linux и Unix всего лишь несколькими командами.
Рекомендую использовать GNU Autotools. Значительной проблемой Autotools является практически отсутствие нормальной документации. Действительно, инструментарием Autotools сложно овладеть. Но когда вы постигли основы и поняли схему процесса Autotools, документация, которая раньше казалась непонятной, становится полезным источником более глубокой информации. Хорошим началом в изучении Autotools может стать книга "The Goat Book" (которую можно взять здесь).
Почему я выбираю Autotools? У меня есть знакомый, которые считает меня сумасшедшим из-за того, что я использую Autotools. У него тоже есть свой свободный проект, и он вручную пишет для него make-файлы. В течение нескольких лет я пытался ему показать, как можно создавать конфигурационные файлы с помощью Autotools, но он все равно садился и проводил час или два за написанием своих make-файлов. В конце концов, они оказывались очень сложными, негибкими, их было сложно читать и понимать, они были менее функциональными и более хрупкими, чем мои конфигурационные файлы, созданные Autotools. И что же. Сегодня он спросил у меня, как перевести свой проект на Autotools.
Просто когда вы узнаете все, что можно делать с помощью Autotools (причем это будет делаться автоматически), у вас навсегда отпадет желание писать свою систему сборки. Люди, которые разрабатывали средства Autotools и поддерживают его сегодня, знают все до мелочей в таком деле, как тестирование, сборка и распространение свободных программ. Autotools объединяет решение всех этих задач.
Некоторые предпочитают другие высокоуровневые системы (Scons, CMake и т.д.). Эти средства хороши, они постоянно развиваются, все более приближаясь к Autotools, но я не видел ни одной системы, которая бы имела функциональность, аналогичную Autotools. Сторонники этих альтернативных инструментов утверждают, что пользователь сам может дополнить эти недоделки, написав чуть более длинный скрипт. Но зачем это делать, если результат от этого лучше не будет? Скрипты остаются такими же сложными, негибкими и трудными в понимании. В чем отличие от Autotools? В конце концов, любой, кто знаком с миром Linux/Unix, также знаком и со стандартной процедурой "configure; make", и ничего больше не нужно. Итак, я настаиваю на своем: Autotools - лучший инструмент в своем роде. Начните с "The Goat Book" и посмотрите, как Autotools применяются в других свободных проектах.
Выпуск бинарных пакетов
Большинство известных дистрибутивов GNU/Linux или Unix используют свою собственную систему установки пакетов. К примеру, в SUSE и Red Hat Linux используется система пакетов Red Hat RPM, а Ubuntu использует адаптированную Debian-систему. У вас должны быть веские причины для создания пакета отдельно для какого-либо дистрибутива. В большинстве случае разработчики свободных программ не тратят на это время, и их продукты распространяются в виде исходных текстов, а уже потом разработчики дистрибутивов создают на их основе пакет для своего дистрибутива. Сборка и установка программы из архива с исходными текстами (т.н. tarball) обычно допустима лишь на GNU/Linux или Unix.
Но все же есть плюсы в самостоятельном создании своих бинарных пакетов. Во-первых, вы самолично поддерживаете установочные скрипты, и можете провести установку программы по-своему. В процессе написания установочного скрипта для пакета могут обнаружиться недостатки архитектуры программы, да такие, что сборщикам дистрибутива (если бы они создавали пакет) пришлось бы писать патчи для вашей программы. А создав свой пакет, вы сможете обнаружить такие недостатки и самому их исправить. Сборщики дистрибутивов даже не скажут вам о таких проблемах - у них не хватило бы времени, если бы они общались с разработчиками всех проектов, которые содержатся в дистрибутиве.
Если после этого вы хотите создать свой бинарный пакет, обратите внимание на онлайн-службу компиляции и создания пакетов, такую как openSUSE Build Service. Эта относительно новая служба напоминает большую ферму компиляции с веб-интерфейсом. Здесь предоставляются машины и версии ОС, есть возможность выбора целевой платформы, архитектуры и формата выходного пакета. Процедура проста. Вы предоставляете tarball, модифицированный файл RPM-спецификации (spec-файл) и выбираете платформу, а служба сама собирает бинарный пакет, который можно впоследствии загрузить прямо с этого же сайта. При изменении исходных текстов или spec-файла, проект автоматически пересобирается, и обновляются все ссылки на пакет. Начать можно с чтения документации и экспериментов. Также рекомендую подписаться на рассылку на главной странице.
Выпуск версии программы
Рассмотрим процесс создания пакетов вашего проекта. Он может простым, как выгрузка архивов tarball (zip или tar.gz), либо более сложным, таким как сборка и выгрузка пакетов для нескольких аппаратных платформ и конфигураций. Чем больше вы сделаете для своих пользователей, тем больше они будут ценить ваш проект. Когда свободное ПО только начинало зарождаться, проекты распространялись исключительно в виде архивов с исходными текстами. Но сегодня аудитория пользователей стала намного более разнообразной в смысле компьютерной грамотности: какая-то часть пользователей просто проигнорирует ваш проект, если он устанавливается не с помощью Windows MSI (а другие - по причине наличия MSI!).
В конце концов, вы сами решаете, как предоставлять свой проект пользователям, помимо обязательного распространения в исходных текстах. Единственное, что позволю отметить: лучше начинать с малого и расти, чем начать с неохватно большого. Если вы начнете снабжать пользователей пакетами для Win32 MSI, для Red Hat/SUSE RPM и для Debian с Ubuntu, а потом внезапно уберете пакеты Debian/Ubuntu из-за нехватки времени и т.п., то люди будут весьма скверно относиться к вашей персоне, да и проекту. Если же вы начнете выпускать лишь архивы исходных текстов, потом добавите установщик Windows MSI и пакеты Red Hat/SUSE RPM, пользователи будут вами восхищаться. Результат, как видите, один, но в одном случае у людей отбирают, а в другом они получают.
На SourceForge выпуск новой версии начинается с загрузки на их FTP-сервер по адресу ftp://upload.sourceforge.net. Зайдите как "anonymous", введите свой почтовый ящик в качестве пароля. Затем перейдите в каталог "incoming". Если вы пользуетесь консольным клиентом на не-UNIX платформе, не забудьте переключиться в режим бинарной передачи, чтобы протокол FTP не попортил бинарные файлы при загрузке. Выкладывайте на FTP новую версию и выходите.
Рисунок 8: Доступ к файловой системе SourceForge.net
Теперь откройте меню "Admin" на странице вашего проекта на SourceForge и выберите пункт "File Releases", как показано на рисунке 8. SourceForge группирует выпуски в понятиях "packages" (пакеты) и "releases" (выпуски). Эти концепции выделены на рисунке 9. Пакет - это группа файлов, которые всегда должны поставляться вместе. Зачастую свободные проекты состоят лишь из одного пакета. Количество пакетов зависит от сложности вашей программы и от того, как вы хотите выпускать ее. Когда увеличивается версия программы, вместе с пакетом создается новый выпуск. К примеру, вы хотите распространять версии своего проекта на C и Java. В этом случае если подпроекты поддерживаются раздельно, вы наверняка захотите иметь отдельные пакеты для C и Java. После разделения этих двух подпроектов на два пакета у вас появится возможность выпускать новые версии каждого из проектов по различному расписанию.
Рисунок 9: Пакеты и выпуски
Итак, после определения пакетов вы создаете новый выпуск (см. рисунок 10). Название выпуска как правило должно содержать версию программы. К примеру, можно назвать выпуск "1.0.7". Этот номер версии будет отображаться в качестве имени выпуска на странице download. Посмотрите на другие проекты SourceForge и вы увидите, как там это сделано.
Рисунок 10: Создание нового выпуска
На странице конфигурации выпусков, на шаге первом (см. рисунок 11) можно добавить замечания и информацию об изменениях в новой версии (т.н. ChangeLog). Можно загрузить уже написанные тексты и отметить галочкой "Preserve my pre-formatted text". При загрузке первого пакета замечания и ChangeLog можно опустить.
Рисунок 11: Создание выпуска, шаг 1
На шаге втором (см. рисунок 12) нужно добавить файлы в выпуск. На этой странице вы должны увидеть свои файлы (среди файлов других разработчиков), ранее вами загруженные в каталог incoming. У любого пользователя имеется доступ к файлам в каталоге incoming в течение 24-часового периода. Будьте порядочны, не трогайте чужих файлов. Лучше отметьте свои и нажмите кнопку "Add Files and/or Refresh View".
Рисунок 12: Создание выпуска, шаг 2
После завершения обновления настанет третий шаг, вы увидите список записей, соответствующих файлам, выбранным вами на предыдущем шаге (см. рисунок 13). Здесь нужно для каждой записи в списке выбрать тип процессора и тип файла, после чего нужно нажать кнопку "Update/Refresh" (по разу для каждого файла). Согласен, это немного неудобно, зато работает; будем надеяться, что разработчики SourceForge вскоре порадуют нас более удобным интерфейсом. Теперь попробуйте выбрать те процессор и тип файла, которые лучшим образом ассоциируются с добавляемым файлом, хотя это не принципиально. Можно выбрать нейтральное "Other Source File" или "Other Binary Package", но что-то выбрать должны обязательно, иначе файл не появится на странице download вашего проекта.
Рисунок 13: Создание выпуска, шаги 3 и 4
Наконец, на четвертом шаге можно указать, нужно ли разослать уведомления по e-mail всем, кто следит за вашим пакетом. Если пока число интересующихся равно нулю, можно пропустить этот шаг.
Теперь я рекомендую вам побыть в шкуре пользователя. Закройте все окна браузера и откройте страницу своего проекта. Загрузите и установите все пакеты, как будто вы и есть пользователь. Если что-то в этом процессе окажется неочевидным, сложным или неправильно работающим, значит, нужно исправить свои ошибки и попробовать заново.
Расскажите о своем проекте
Итак, вы убедились, что загрузка и установка вашей программы нормально работает. Теперь здравая мысль - пойти в пункт "Publicity" в меню "Admin" и почитать, каким образом можно известить весь мир о вашем проекте.
Рисунок 14: Включение и создание новостей на SourceForge.net
Сначала включите новости проекта (см. рисунок 14). Теперь вы сможете быстро создавать новости. Огромное количество людей во всем мире следят за новостями SourceForge, и, конечно, весть о вашем проекте не пройдет незамеченной. Значит, нужно создать новостной выпуск. Ссылка, позволяющая это сделать, глубоко закопана в интерфейсе, на рисунке 14 она выделена. Итак, вы выпустили новую версию своего проекта, и хотите рассказать об этом миру. Свежая новость появится в верхней части главной страницы вашего проекта. Но она также может быть выбрана для показа на главной странице самого SourceForge, под надписью "Project News". Если ваш проект станет популярным, а ваши новости будут хорошо написаны, вполне вероятно, что ваша новость будет отобрана для показа в главной новостной ленте. Достижение этого - очень хороший результат, лучше, чем можно себе представить.
Вы также можете принимать участие в голосовании на написание статей о вашем проекте в таких журналах, как Free Software Magazine или более традиционных бумажных журналах типа Dr. Dobb. SlashDot и другие технические новостные сайты также хороший способ приобрести известность. Но будьте осторожны со своими словами. Всем этим сайтам нужна информация, а не маркетинг. Если ваш проект популярен и узнаваем, то новость стоит опубликовать, но если вы только начинаете, то стоит задуматься, многим ли нужна ваша новая версия. Вот если ваша программа решает обычную проблему уникальным способом, тогда это действительно стоит новостной заметки.
FreshMeat - тоже хороший новостной сайт о свободных программах. Чтобы иметь возможность анонсировать новые выпуски программы, нужно зарегистрироваться и добавить проект в свою учетную запись. После этого можно будет публиковать заметки о новых выпусках своей программы, однако помните, что все новости модерируются.
Заключение
Поддерживать свободный программный проект нелегко, но это может воздасться. Если ваш проект будет популярен, он даже может приносить вам прибыль. В завершение посоветую вам не делать все в одиночку. Если вам поступает предложение о помощи от других людей, отнеситесь к этому любезно и позвольте им помочь вам. Сначала, правда, нужно проверить их способности, и если все хорошо, давайте им нужные права. Есть много способов помочь вашему проекту - можно писать документацию, совершенствовать веб-сайт проекта, следить за системой сборки и выпуска новых версий и, конечно, собственно писать программы. Чем более квалифицированные люди будут работать с вами, тем больше шансов, что ваш проект станет успешным.