Наверное вопрос наивный, но все же. С недавнего времени я большую часть рабочего времени занимаюсь разработкой одного молодого open source проекта. В основном он делается 4-мя людьми в двух университетах, но к нему проявляют интерес все больше внешнего народу (contributor'ов). Хочется чего-нибудь почитать на тему управления кодом, написанным этими внешними людьми. Это может быть как патчи, так и новая функциональность. Собственно чего хочется:
1) избежать всякой нестабильности при добавлении их кода.
2) минимизировать другие негативные эффекты чужого кода (кривой дизайн) и так далее.
3) предотвратить возможные проблемы, связанные с интеллектуальной собственность (сам проект под Apache License 2).
Мне представляется, что придется таки одному члену команды нести ответственность за каждую мало-мальски крупную ветку, в которую коммитят внешние разработчики. Он должен решать когда она достаточно протестирована, стабильна и готова к сливу в транк. Я не уверен, правда, насколько эта модель масштабируется.
Короче, наверняка умные люди уже написали немало на эту тему, так что порекомендуйте что-нить. Пока нашел "Managing Open Source Projects" от 2001г. Никакого опыта пока особо нет.
PS. Your Patch Will Suck прочитал =)
PPS. Коммерциализация пока не планируется.
19.04.2012 13:02, kl написал:
> 1) избежать всякой нестабильности при добавлении их кода.
Обвешивать все автоматическими тестами. Все остальное похоронит тебя под
кучей согласовательной работы. И требовать от всех покрытия тестами их
кода.
> 2) минимизировать другие негативные эффекты чужого кода (кривой дизайн) > и так далее.
Максимально разделять модули и минимизировать зависимости. То бишь, в
случае отвала некоторого модуля, весь остальной код должен жить, как ни
в чем не бывало (ну почти).
Здравствуйте, Vzhyk, Вы писали:
V>19.04.2012 13:02, kl написал:
>> 1) избежать всякой нестабильности при добавлении их кода. V>Обвешивать все автоматическими тестами. Все остальное похоронит тебя под V>кучей согласовательной работы. И требовать от всех покрытия тестами их V>кода.
Я это понимаю, сам первое время (пока знакомлюсь с внутренностями) пишу практически только тестовый код. Проблема скорее организационная: мне легко требовать тестов от постоянных участников проекта (грубо говоря, у меня есть рычаги чтобы это проконтролировать). Но все сложнее с внешними участниками. Я не могу сам следить за всеми их ветками. С одной стороны я не хочу сливать код в транк, пока он не протестирован, а с другой, я хочу организовать работу так, что внешние участники не теряли энтузиазма.
>> 2) минимизировать другие негативные эффекты чужого кода (кривой дизайн) >> и так далее. V>Максимально разделять модули и минимизировать зависимости. То бишь, в V>случае отвала некоторого модуля, весь остальной код должен жить, как ни V>в чем не бывало (ну почти).
20.04.2012 15:36, kl написал:
> Я это понимаю, сам первое время (пока знакомлюсь с внутренностями) пишу > практически только тестовый код. Проблема скорее организационная: мне > легко требовать тестов от постоянных участников проекта (грубо говоря, у > меня есть рычаги чтобы это проконтролировать). Но все сложнее с внешними > участниками. Я не могу сам следить за всеми их ветками. С одной стороны > я не хочу сливать код в транк, пока он не протестирован, а с другой, я > хочу организовать работу так, что внешние участники не теряли энтузиазма.
Возможно я не умею готовить ветки. Но не люблю, когда в проекте море
веток, как это все потом сливать.
По мне лучше разработку всю вести в транке и по мере необходимости
отпочковывать версии и там уже никаких фич, только фиксы.
Ну невозможно быть хорошим для всех и всего. Чем-то нужно жертвовать.
