Посмотрел на организацию "гаража". Честно говоря, бардак, конечно. Для начала можно глянуть статью
MaemoGarageStartUp, там есть некая попытка донести основные принципы. Как я понял, в общих чертах, надо действовать так:
1. Завести себе аккаунт на
garage.maemo.org. Например, пусть будет
coolhacker.
2. Залезть в меню
Register Progect. Откроется формочка, в которой надо ввести начальные данные о проекте:
- Project Full Name: полное имя проекта, типа "My cool project"
- Project Purpose And Summarization: тут надо подробно описать что это за проект и какое он отношение имеет к maemo. По идее от того, насколько грамотно здесь составлен текст, зависит решение модератора о принятии проекта в гараж. Следует избегать слов "test", "testing", "porn" и т.п. Это описание не выставляется на публичное обозрение, его прочтет только модератор гаража.
- License: под какой лицензией выпускается. Истинный простор для фантазии, но помните о пункте 3.3 в Terms Of Use. Можете сразу поставить BSD, и не надо ломать голову.
- Project Public Description: то, что пользователи будут видеть в описании на домашней странице проекта. Этот текст можно составить попроще и подоходчивее, кроме того, его можно потом поменять. Кстати, по этому тексту работает поиск, но проект не будет находиться сразу после создания, пока вы не позаботитесь о присвоении ему правильной категории (см. ниже)
- Project Unix Name: это такое уникальное имя (3-15 символов), которое потом будет фигурировать в настройках сервара, да и везде, где только можно. И в качестве имени репозитория в SVN, и в качестве части доменного имени перед garage.maemo.org (домашняя страница проекта). Пусть это будет cool-appy (надо сразу заметить, что имя пакета все равно может от него отличаться)
Дальше надо все это заsubmitить администратору, который должен вынести решение в течение 3х суток. На практике, можете получить "добро" уже через
10 минут. Еще вам напишут, что созданы списки рассылки под ваш новый проект, а также, куда идти для администрирования проекта.
3. Теперь надо грамотно импортировать исходник в SVN. Делаем темповый каталог в файловой системе, создаем там подкаталоги:
mkdir trunk tags branches. Идем в trunk, туда кладем
только необходимые для сборки файлы. Возвращаемся на уровень выше и говорим:
svn import --username coolhacker https://garage.maemo.org/svn/cool-appyУ вас спросят пароль пользователя coolhacker и это правильно, т.к. кому попало, слава Аллаху, коммитить в ваш новоиспеченный проект нельзя. Также вас наверняка обложит "post-commit"-скрипт по поводу невозможности копирования файлов куда-то в
/var/www. Это нормально: если бы на одном уровне с
trunk,
branches и
tags вы еще бы создали
www, то это был бы web-корень вашего проекта по адресу
cool-appy.garage.maemo.org. По дефолту работает перенаправление на резюме проекта, но со временем, когда будет что сказать людям, можно обзавестись чем-то более презентабельным.
Дальше этот темповый каталог....
можно спокойно убить! Да, таковы реалии жизни в cvs/svn - вести разработку надо в рабочей копии. Иначе запутаетесь, насмерть. Ну хорошо, не убивайте, сделайте tgz и спрячьте на черный день на сменный носитель. Мало ли что ;)
4. Получаем рабочую копию.
mkdir work && cd work
svn co --username coolhacker https://garage.maemo.org/svn/cool-appy/trunkТеперь надо бы убедиться, что мы ничего не забыли положить в SVN, дабы скачивающий исходники народ не обломался на компиляции. Последовательность действий по сборке стандартного пакета обычно такая:
./autogen.sh && ./configure && make debНестандартные шаги стоит описать в README или, если это того заслуживает, в отдельном файле INSTALL.
5. Можете с интересом походить по веб-интерфейсу гаража, поизучать, что получилось. Самое главное, что бросается в глаза - это грустная надпись
This project has not released any files. С вероятностью 90% прочтя такое, пользователь уйдет со страницы, и даже не заглянет в svn, хоть там и есть все необходимое. Вывод -
надо релизить!
Если вы успешно исполнили make deb, то наверняка образовался каталог debian-build, а там лежат два важных файла -
cool-appy_0.0.1.tar.gz и
cool-appy_0.0.1_armel.deb. Их-то и надо выложить в публичный доступ тем, у которого под руками нет framework-а для превращения исходника в бинарный пакет.
Файл
cool-appy_0.0.1_i386.deb, который, например, получился при сборке пакета в окружении X86, особенно никому кроме вас не нужен, поэтому выкладывая его в публичный доступ - сначала трижды подумайте,
зачем вы это собрались делать.
Тыкаем на ссылку
[View All Project Files] и попадаем на страницу с одним только названием пакета
cool-appy. Но это не беда: жмем на
To create a new release click here. Попадаем в форму релиза:
- Package ID: тут по умолчанию показывается unix-name проекта, его можно поменять или добавить вообще несколько пакетов в проект - почему бы и нет?
- Release Name: пишем гордое 0.0.1, именно так и будет называться наш релиз на странице скачивания файлов
- Release Date: дата и время создания релиза, для истории. Интересно, а задним числом можно? ;)
- File Name: здесь надо указать имя готового файла с пакетом для загрузки, для начала cool-appy_0.0.1_armel.deb
- File Type: ясно дело, .deb!
- Processor Type: полагаю, что если оно должно работать на таблетке - то ARM
- Release Notes & ChangeLog: считается хорошим тоном их указывать, хотя бы со второго релиза (чтобы можно было понять, в чем отличие от предыдущего). Но можно и нагло оставить их пустыми: все равно дотошный пользователь докопается до debian/changelog.
Ну и... собственно всё! После загрузки, файл появится в общем доступе. Можно еще добавить в релиз cool-appy_0.0.1.tar.gz, пометив, что File Type = tar.gz, а Processor Type - any.
6. Из административного меню выберите ссылку
Trove Categorization. Настало время расставить все по местам: написать про то, для кого этот пакет (разработчик, юзер или админ), статус разработки (обдумываю, пре-альфа, альфа, бета, стабильный, устарел) и т.д. Главное - в конце все-таки пояснить, с какой версией Internet Tablet он скомпилирован, чтобы не было попыток совместить несовместимое.
7. Дайте новость, путем административного меню
News Admin: пусть о вашем проекте узнают все!
Ну вот, вроде бы и всё. Возвращаясь к вопросу о бардаке: вся его прелесть в том, что никто не мешает написать про GPL и не выложить исходников, или, наоборот - выложить исходники, но не зарелизить не одного файла. Хранить в SVN файлы можно как попало: например, не использовать каталог trunk вообще. Все это не прибавляет порядка, конечно... Но такова жизнь!
