- cl-routes
- garbage-pools
- restas
- wiki-parser
- cl-closure-template
Со временем, по мере возможности, собираюсь добавить и другие свои библиотеки.
вторник, 5 января 2010 г.
clbuild
Решил немного по разбираться с clbuild и должен сказать, что это удивительно тупой проект: столько усилий на бесперспективную системы, ибо она не претендует на что-то большое, плюс убивающий (не теоретически, но на практике) идею распределенных систем контроля версий darcs. Увы, но вне Gentoo это остаётся пожалуй самым простым способом установки CL-пакетов. Поэтому, решил это дело немного форкнуть. Итак, во-первых теперь есть http://github.com/archimag/clbuild-origin - git-версия оригинального darcs-репозитория, предназначена для желающих форкнуть это дело. Буду стараться сихронизировать с darcs более-менее регулярно, для чего использую тормозящий darcs-to-git. Во-вторых, есть http://github.com/archimag/clbuild-archimag - мой форк, который включает некоторые мои пакеты, в данный момент это:
Подписаться на:
Комментарии к сообщению (Atom)
зачем форкать ради добавления своих пакетов? пришлите мэйнтейнеру патч и всех делов.
ОтветитьУдалить(зачем люди вообще форкают вещи на ровном месте, предъявляя в качестве повода странные (на грани неадеквата, как по мне) претензии, типа "не тем VCS пользуются"? ну вот не понимаю.)
@cmm
ОтветитьУдалитьА почему не форкать, если можно форкнуть? Я так думаю, что чем больше форков, тем лучше. В чём суть проблемы?
> зачем люди вообще форкают
Не замечали, что каждый раз, когда выделаете git clone или аналог для других распределенных систем, вы делаете fork? В этом, собственно, вся суть распределенных систем контроля версий
> Не замечали, что каждый раз, когда выделаете git clone или аналог для других распределенных систем, вы делаете fork?
ОтветитьУдалитьclone — это такое техническое понятие, а fork — это такое скорее социальное понятие. мне почему-то кажется что вы и сами чудесно понимаете разницу.
@cmm
ОтветитьУдалитьТогда надо говорить, что есть разные виды форков. Один вариант, известный ранее, это просто разделение проекта на две (или более) независимых линий. В этом случае разработчики разных версий работают независимо, что приводит к некоторому распылению ресурсов и сложностью с выбором для конечного пользователя. Однако, сейчас, после широкого распространения распределенных систем контроля версий, возможен другой вариант: я делаю форк проекта, вношу в него свои изменения, но при этом постоянно синхронизируюсь с оригинальной версией. Т.е. в моей версии содержится всё из оригинальной, плюс мои изменения. И если кто-то хочем пользоваться моими пакетами, он может взять мой форк, ничего при этом не потеряв. Поскольку у меня проектов около десятка, то мне сложно вести диалог с разработчиками оригинального clbuild через список рассылки без доступа на запись к репозитарию.
Кстати, как пример, у меня есть свой форк cl-pdf, который включает в себя патчи (других людей), которые были в списке рассылки, но которые разработчик cl-pdf игнорирует (он кажется вообще фактически перестал заниматься развитием проекта). Доказывать кому-то, что моя версия лучше оригинальной - не такое просто занятие. Но я могу легко внести изменения (по поводу cl-pdf) в свой форк clbuild.