Комментарии 51
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
>какойнить VCS
Мой вопрос немного конкретнее. Код итак в svn, но не могу же я дать всем туда доступ. Наверное надо как то организовать прием кода в виде патчей, или отдельные ветки, и мержить нужные изменения. Но как сделать это грамотно, правильно распределить права, сделать удобным для всех…
Опять же, Trac это хорошо, но отчего то я его обчень редко встречаю в качестве баг-трекера в известных open source проектах. Используют чаще дургие движки.
Мой вопрос немного конкретнее. Код итак в svn, но не могу же я дать всем туда доступ. Наверное надо как то организовать прием кода в виде патчей, или отдельные ветки, и мержить нужные изменения. Но как сделать это грамотно, правильно распределить права, сделать удобным для всех…
Опять же, Trac это хорошо, но отчего то я его обчень редко встречаю в качестве баг-трекера в известных open source проектах. Используют чаще дургие движки.
Trac на питоне, соответственно надо либо хостера с питоном — либо если свой сервер — стравить и настраивать.
Из личного опыта: у меня почему-то trac работал очень и очень медленно. Не знаю с чем связано, с траком, с mod_python, или с кривыми руками (на этом же сервере крутится куча всего php — все летает)
Из личного опыта: у меня почему-то trac работал очень и очень медленно. Не знаю с чем связано, с траком, с mod_python, или с кривыми руками (на этом же сервере крутится куча всего php — все летает)
А почему не дать нормальный доступ разработчикам? Имхо, контроль версий для того и придуман, чтобы всегда можно было откатиться (при необходимости)
потому что тогда работа превратится в постоянные откаты. одному взбредет в голову одно сделать, другому другое. Следить за комитами, разбираться кто что сделал а потом откатывать все это прямо в транке это неправильно. Так же если человек не думает учавствовать в разработке, но зато нашел небольшую ошибку и её исправил, намного проще сделать патч и прислать. Ну будет же он ради чего-то ставить себе сабвершен, тортайс и тд.
Естетсвенно некоторые разработчики будут допускаться напрямую в транк, но я ничего не слышал об опенсорс проектах в которые могут комитить все кому не лень. Это бардак будет.
Естетсвенно некоторые разработчики будут допускаться напрямую в транк, но я ничего не слышал об опенсорс проектах в которые могут комитить все кому не лень. Это бардак будет.
Верно. Решение — небольшое количество комиттеров имеют доступ в trunk, остальные пользуются ветками и патчами. Посмотрите, как это сделано в проектах на google code.
Как вы построите комьюнити — так и будет. Вообще опенсорс подразумевает не хаотическое движение а упорядоченное. И упорядочивать — забота комьюнити драйвера.
НЛО прилетело и опубликовало эту надпись здесь
Не хочешь отдавать, обновляй вручную
open source все-таки не подразумевает вымогательства ;)
open source все-таки не подразумевает вымогательства ;)
а это и не вымогательство, это свободный выбор.
выбор должен быть таким — пользоваться вашей разработкой или не пользоваться вашей разработкой
а я что этот выбор отбираю? и денег я не требую, и год весь открыт. Например тырят статьи с хабра все кому ни лень. Я же предлагаю делать это официально, с обязательной ссылкой на источник, что владельцу ресурса даже выгодно. Просто через систему обновлений я смогу получать информацию обо всех установках движка. Отключив систему обновления, пользователь просто не позволит мне знать об инсталляции, и соответственно у меня не будет возможности импортировать контент.
Но опять же, можно залезть в код и немножко подправив его, запретить получение контента, оставив обновление. Опенсорс же))) Так что выбор общирный!
Но опять же, можно залезть в код и немножко подправив его, запретить получение контента, оставив обновление. Опенсорс же))) Так что выбор общирный!
Сделай репозиторий, и закинь его куда-нибудь (http://code.google.com/intl/ru/ и т.п.). У тех же svn насколько я знаю, можно весь репозиторий копировать, так что можно несколько копий иметь если надо.
у меня есть svn репозиторий на собственном сервере. Так что это не проблема. Вопрос именно в организации, причем в основном не только получения кода, но именно получения комитов.
А в чем проблема получения коммитов? Эти же коммиты не будут сразу вливаться в trunk
Google Code или GitHub — для того, чтоб иметь багтрекер какой-никакой и нормально уже настроенную систему контроля версий.
Далее. В trunk'е, например, висит текущая версия. Она же доступна для скачивания в виде .zip/.tar.gz с сайта. На этой же версии крутится demo системы
В ветке development идет собственно development. Туда приходят все коммиты от зарегистрированых в проекте пользователей (для этого и нужен хостинг на Гитхабе/гуглокоде, например)
Все приходящие коммиты рассматриваются хозяином проекта или устанавливается peer review, обкатка и т.п.
Как только достигли следующей версии, она сливается в транк, обновляется .zip/.tar.gz/demo
Google Code или GitHub — для того, чтоб иметь багтрекер какой-никакой и нормально уже настроенную систему контроля версий.
Далее. В trunk'е, например, висит текущая версия. Она же доступна для скачивания в виде .zip/.tar.gz с сайта. На этой же версии крутится demo системы
В ветке development идет собственно development. Туда приходят все коммиты от зарегистрированых в проекте пользователей (для этого и нужен хостинг на Гитхабе/гуглокоде, например)
Все приходящие коммиты рассматриваются хозяином проекта или устанавливается peer review, обкатка и т.п.
Как только достигли следующей версии, она сливается в транк, обновляется .zip/.tar.gz/demo
Пример. На своем опыте
Есть проект: github.com/ngerakines/erlang_couchdb/tree
Мне захотелось в него что-то добавить. Я его форкнул: github.com/dmitriid/erlang_couchdb/tree/master
Добавил кой-чего: github.com/dmitriid/erlang_couchdb/commit/6cd2b690402215355600fd254e316ee18637a208
Отправил так называемый pull request участникам. Авторы залили изменения себе: github.com/ngerakines/erlang_couchdb/commits/master
В следующий раз я просто стяну с главной ветки произошедшие там изменения и буду вносить свои изменения и отсылать их авторам
Есть проект: github.com/ngerakines/erlang_couchdb/tree
Мне захотелось в него что-то добавить. Я его форкнул: github.com/dmitriid/erlang_couchdb/tree/master
Добавил кой-чего: github.com/dmitriid/erlang_couchdb/commit/6cd2b690402215355600fd254e316ee18637a208
Отправил так называемый pull request участникам. Авторы залили изменения себе: github.com/ngerakines/erlang_couchdb/commits/master
В следующий раз я просто стяну с главной ветки произошедшие там изменения и буду вносить свои изменения и отсылать их авторам
«взамен обязуя пользователей движка отдавать мне контент своих блогов, фото и других сервисов, позволяя мне их публиковать на свое усмотрение, со ссылкой на источник.»
ссылка на первоисточник конечно хорошо, но осадочек как говорят остался…
ссылка на первоисточник конечно хорошо, но осадочек как говорят остался…
Почему OpenSource? С какой целью? Что вы от этого получите?
Если хотите получить рабочие руки, то надо думать не о траках и эсвээнах, а о том, что пишет Фогель в своей книге
В противном случае никакой разницы не будет между тем, что вы создадите проект или просто архив на FTP положить под MIT или BSD лицензией.
Лицензию можете любую брать, можете как угодно изменять любую из лицензий, вот только она уже не будет называться как раньше.
Если хотите получить рабочие руки, то надо думать не о траках и эсвээнах, а о том, что пишет Фогель в своей книге
В противном случае никакой разницы не будет между тем, что вы создадите проект или просто архив на FTP положить под MIT или BSD лицензией.
Лицензию можете любую брать, можете как угодно изменять любую из лицензий, вот только она уже не будет называться как раньше.
Я бы не сказал что цель получить рабочие руки. До сих пор я разрабатывал сам, и сделано немало. Могу и дальше продолжать в том же духе. Почему OpenSource тогда? Опуская то что я в целом поклонник открытого кода, я вижу это лучшим способом распространения приложения мною созданного. Почему я хочу сделать все по уму. Ну это просто, у меня есть проект, я хочу получить опыт в управлении не только коммерческим ПО, но и открытым. Если к разработке кто-то подключится, замечательно. Но основная цель ни создать все условия для этого, а получить опыт создания таких условий.
Так, а что вы имели ввиду под словами «а о том, что пишет Фогель»? За линк спасибо, прочту, но я так понимаю он там ни одну мысль имел ввиду. Вы о какой именнно? :))
Так, а что вы имели ввиду под словами «а о том, что пишет Фогель»? За линк спасибо, прочту, но я так понимаю он там ни одну мысль имел ввиду. Вы о какой именнно? :))
Спасибо за ссылку на книгу. Я тоже планирую опенсорсить свой проект, так что книжку прочту с большим интересом :)
еще одно спасибо за книгу, вот ссылочка на русский вариант http:// producingoss. com / ru / (пробелы убрать где надо, карма не дает постить ссылки)
Google Code лучший выбор. Легко завести проект, удобная легковестная среда.
мне кажется, тут идея должна быть следующая:
а) находятся люди, который вообще хотят участвовать в вашем проекте — вы им создаете отдельные branch ветки (не думаю, что будет уж очень много желающих)
б) после того, как кто то производит комиты в branch — вы просто поначалу следите, если нравится принимается в trunk, если нет — не принимаете. После нескольких приемом от одного пользователя — думаю можно уже и позволять ему комитить в trunk. Ну и соответственно все конечные версии должны быть в tags
в) ну и те люди, который переходят в стадию возможности комитов в trunk — само собой должны выполнять только те задачи, которые согласованы issue трекером.
Вот я вижу как то так. В общем огромную роль будет играть все равно человеческий фактор.
а) находятся люди, который вообще хотят участвовать в вашем проекте — вы им создаете отдельные branch ветки (не думаю, что будет уж очень много желающих)
б) после того, как кто то производит комиты в branch — вы просто поначалу следите, если нравится принимается в trunk, если нет — не принимаете. После нескольких приемом от одного пользователя — думаю можно уже и позволять ему комитить в trunk. Ну и соответственно все конечные версии должны быть в tags
в) ну и те люди, который переходят в стадию возможности комитов в trunk — само собой должны выполнять только те задачи, которые согласованы issue трекером.
Вот я вижу как то так. В общем огромную роль будет играть все равно человеческий фактор.
это понятно. но имено потому что я не расчитываю на ажиотаж, мне инетерсны маленькие правки, то есть те кто исправил у себя багу, и готов поделится со мной этим исправлением. Естественно он не будет ради этого просить меня создать ему ветку, и тд. минимум мне необходимо предоставить систему публикации патчей, а желательно сравнительно простой способ внести изменения в свн, не тратя много времени и сил.
Вообще сейчас я задумался об отдельной веттке, одной для всех с полным доступом, и одной паралельной ветке со стабильным кодом, куда я смогу мержить правки пользователей.
Вообще сейчас я задумался об отдельной веттке, одной для всех с полным доступом, и одной паралельной ветке со стабильным кодом, куда я смогу мержить правки пользователей.
Могу посоветовать почитать статью Think GPL:
aceler.ru/features/think_gpl
Думать об открытии проекта нужно начинать с момента его создания, тогда действительно можно сэкономить ресурсы.
aceler.ru/features/think_gpl
Думать об открытии проекта нужно начинать с момента его создания, тогда действительно можно сэкономить ресурсы.
Можно глянуть на такое штуки как assembla. у них там богатый выбор всяких VCS, багтрекеров и прочего.
По поводу мутных лицензий — лучше сделать полностью свободный вариант, который будет идти под выбранной лицензией (GPL — наш выбор). и в дополнение к нему сделать вариант с другой лицензией и с всякими ограничениями. по поводу смешанных/измененных лицензий мне вообще это дело кажется мутным в юридическом плане, но я вспоминаю что-то на тему лицензии psi, у них там была какая-то дополнительная оговорка вроде на линкование с Qt
По поводу мутных лицензий — лучше сделать полностью свободный вариант, который будет идти под выбранной лицензией (GPL — наш выбор). и в дополнение к нему сделать вариант с другой лицензией и с всякими ограничениями. по поводу смешанных/измененных лицензий мне вообще это дело кажется мутным в юридическом плане, но я вспоминаю что-то на тему лицензии psi, у них там была какая-то дополнительная оговорка вроде на линкование с Qt
Мне кажется, что Google Code подойдет. Там и SVN, и Wiki и удобный просмотр кода онлайн. А ты — как владелец проекта (его основатель) — будешь следить за тем кому даешь доступ в репозиторий. Checkout там можно анонимный делать, а вот коммитить только те могут, кому владелец проекта доступ дал.
Имхо об этом ты и говоришь.
Имхо об этом ты и говоришь.
ну я просто не понимаю зачем мне Google Code если у меня есть свой сервер (VDS) и все права я могу самостоятельно раздавать. Мне то как раз надо сделать так что бы и права не раздавать каждому что хочет пару строк в коде исправить, и бардака не допустить.
1. У Вас всегда будет Ваш сервер? Вечно? (тем более, что он VDS)
2. Вам интересно будет перетаскивать все репозитории, баг-трекинг системы на новый в случае появления оного?
3. Вам нужно тратить своё время на резервные копии ваших репозиториев, когда эти опен-сорс проекты могут никогда не принести прибыли или даже окупать свой сервер, на котором они лежат
4. Вы не думаете, что через пару лет Вы плюнете на всё это и прикроете «свою лавочку» (я имею в виду Ваш сервер с репозиториями)? Что тогда делать разработчикам, которые вдруг заинтересованы в Вашем проекте?
*. Самый плохой вариант: а если с Вами случится… Вы хотите дать жизнь проекту или держать его в своих руках?..
P.S. А у себя (для своих pet-projects, на своём домашнем медиа-центре/сервере репозиториев и баг-трекинга — поверьте даже когда я один занимаюсь разработкой — очень удобно), я использую Ubuntu + SVN + Redmine. Мне нравится. :)
2. Вам интересно будет перетаскивать все репозитории, баг-трекинг системы на новый в случае появления оного?
3. Вам нужно тратить своё время на резервные копии ваших репозиториев, когда эти опен-сорс проекты могут никогда не принести прибыли или даже окупать свой сервер, на котором они лежат
4. Вы не думаете, что через пару лет Вы плюнете на всё это и прикроете «свою лавочку» (я имею в виду Ваш сервер с репозиториями)? Что тогда делать разработчикам, которые вдруг заинтересованы в Вашем проекте?
*. Самый плохой вариант: а если с Вами случится… Вы хотите дать жизнь проекту или держать его в своих руках?..
P.S. А у себя (для своих pet-projects, на своём домашнем медиа-центре/сервере репозиториев и баг-трекинга — поверьте даже когда я один занимаюсь разработкой — очень удобно), я использую Ubuntu + SVN + Redmine. Мне нравится. :)
логика в ваших словах есть)))
я как то пользовался соурсфоржом, svn тормозит ооочень сильно. с тех пор решил поднять свой сервер.
но меня беспокоит отсутвие гибкости. на своем сервере я сам себе хозяин, могу выбрать любой софт (вообще сейчас к mercurial присматриваюсь), настроить его как мне удобно.
Может стоит организовать синхронизацию, на случай форсмажора. Но опять же, думать об этом надо когда я пойму что проект нужен и популярен. Пока все что мне нужно, организовать разработку, а это даже проще сделать на своем сервере.
я как то пользовался соурсфоржом, svn тормозит ооочень сильно. с тех пор решил поднять свой сервер.
но меня беспокоит отсутвие гибкости. на своем сервере я сам себе хозяин, могу выбрать любой софт (вообще сейчас к mercurial присматриваюсь), настроить его как мне удобно.
Может стоит организовать синхронизацию, на случай форсмажора. Но опять же, думать об этом надо когда я пойму что проект нужен и популярен. Пока все что мне нужно, организовать разработку, а это даже проще сделать на своем сервере.
Но ведь потом может придётся менять инфраструктуру разработки, при переносе на тот же Google Code или ещё куда-нибудь, где можно хостить опен-сорс PHP проекты.
P.S. Да ещё! А в качестве резервного копирования репозиторитарного кода и базы данных Redmine я накропал мелкий скриптик, который с помощью PHPMailer помогает мне использовать поистине огромный ящик на Gmail: раз в сутки у меня туда посылается архивированный бэкап ;)
Так что, если уж у Гугла упадут все его «облачные» дисковые ёмкости, то и мои резервные копии тоже упадут ;)
P.S. Да ещё! А в качестве резервного копирования репозиторитарного кода и базы данных Redmine я накропал мелкий скриптик, который с помощью PHPMailer помогает мне использовать поистине огромный ящик на Gmail: раз в сутки у меня туда посылается архивированный бэкап ;)
Так что, если уж у Гугла упадут все его «облачные» дисковые ёмкости, то и мои резервные копии тоже упадут ;)
Рома, все уже украдено до тебя. В гуглокоде есть все или почти все, что может тебе понадобиться.
Потому что там уже все настроено и готово к использованию — с раздачей прав и т.п.
Хм… у меня сейчас два опенсурс проекта, но они не очень крупные:
droidjvc — эмулятор x86 для андроида
droidgear — эмулятор сеги для андроида
android-starcraft — ну старик под него
Но я один его разрабатываю, особых проблем пока нету.
droidjvc — эмулятор x86 для андроида
droidgear — эмулятор сеги для андроида
android-starcraft — ну старик под него
Но я один его разрабатываю, особых проблем пока нету.
скажите а почему дизайн такой не очень?
и вообще оформление постов и блоков как-то неаккуратно…
если вы собираетесь продвигать как движок, то он в своей стандартной поставке должен хотя бы неплохо выглядеть (см. WordPress, Joomla)
и вообще оформление постов и блоков как-то неаккуратно…
если вы собираетесь продвигать как движок, то он в своей стандартной поставке должен хотя бы неплохо выглядеть (см. WordPress, Joomla)
я не дизайнер(((
Да вобщем причесать дефолтный дизайн можно всегда. Если бы вы видели начальный вариант, вы бы меня похвалили :))
Вот один из первых вариантов
Да вобщем причесать дефолтный дизайн можно всегда. Если бы вы видели начальный вариант, вы бы меня похвалили :))
Вот один из первых вариантов
попробуйте sourceforge.net/, мекка для ОС проектов.
По поводу коммитов, вроде обычно сначала пишут в багтрекинг патчи, обсуждают, а потом коммитят в основную ветку.
Да и можно давать каждому по ветке, и периодически их сливать.
гуглкод тоже подойдет, он пошустрее будет но не так много возможностей.
По поводу коммитов, вроде обычно сначала пишут в багтрекинг патчи, обсуждают, а потом коммитят в основную ветку.
Да и можно давать каждому по ветке, и периодически их сливать.
гуглкод тоже подойдет, он пошустрее будет но не так много возможностей.
опенсорс-книга producingoss.com/ «Producing Open Source Software» by Karl Fogel, How to Run a Successful Free Software Project
Добрый день,
Из своего опыта замечу (пара собственных проектов и в паре участвую), что когда проект только начинается либо становится опен-соурс, и этот проект мало известен, то делается примерно следующее. Вы пишете заметку в FAQ/Wiki, что те кому нужен доступ писали лично вам/на мэиллист проекта, и просили коммит доступ с описанием того что они хотят сделать, так же стоит просить о небольших коммитах, 50/100/200 строк когда и коммит, иначе вам будет сложно разбираться в новом коде. Вопрос простого получения коммит доступа очень важен на ранних этапах развития проекта. Сейчас очень много опен-соурс проектов и найти разработчиков желающих помочь, достаточно сложно. Так же, важно заметить, что бранчи (ветки) были изначально придуманы не для контроля прав доступа к основному репозиторию.
Насчет вики/баг тракинга/и все остального, я бы посоветовал, для начала ставить то что больше всего радует глаз и будет проще всего поставить (out-of-the-box), время ведь как известно золото :)
Из своего опыта замечу (пара собственных проектов и в паре участвую), что когда проект только начинается либо становится опен-соурс, и этот проект мало известен, то делается примерно следующее. Вы пишете заметку в FAQ/Wiki, что те кому нужен доступ писали лично вам/на мэиллист проекта, и просили коммит доступ с описанием того что они хотят сделать, так же стоит просить о небольших коммитах, 50/100/200 строк когда и коммит, иначе вам будет сложно разбираться в новом коде. Вопрос простого получения коммит доступа очень важен на ранних этапах развития проекта. Сейчас очень много опен-соурс проектов и найти разработчиков желающих помочь, достаточно сложно. Так же, важно заметить, что бранчи (ветки) были изначально придуманы не для контроля прав доступа к основному репозиторию.
Насчет вики/баг тракинга/и все остального, я бы посоветовал, для начала ставить то что больше всего радует глаз и будет проще всего поставить (out-of-the-box), время ведь как известно золото :)
Какой замечательный термин, «вкрации». Кстати, что это? :)
Redmine.org GPL2
Есть всё что нужно для ведения проекта. Поддержка Subversion, Darcs, Mercurial, Cvs, Bazaar, Git, Filesystem
Смутить может только что он на Ruby
Есть всё что нужно для ведения проекта. Поддержка Subversion, Darcs, Mercurial, Cvs, Bazaar, Git, Filesystem
Смутить может только что он на Ruby
Мне не жалко — это MIT или BSD license, а не GPL/LGPL
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как создать свой opensource проект