вторник, 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 - мой форк, который включает некоторые мои пакеты, в данный момент это:
  • cl-routes
  • garbage-pools
  • restas
  • wiki-parser
  • cl-closure-template
Со временем, по мере возможности, собираюсь добавить и другие свои библиотеки.

4 комментария:

  1. зачем форкать ради добавления своих пакетов? пришлите мэйнтейнеру патч и всех делов.

    (зачем люди вообще форкают вещи на ровном месте, предъявляя в качестве повода странные (на грани неадеквата, как по мне) претензии, типа "не тем VCS пользуются"? ну вот не понимаю.)

    ОтветитьУдалить
  2. @cmm
    А почему не форкать, если можно форкнуть? Я так думаю, что чем больше форков, тем лучше. В чём суть проблемы?

    > зачем люди вообще форкают
    Не замечали, что каждый раз, когда выделаете git clone или аналог для других распределенных систем, вы делаете fork? В этом, собственно, вся суть распределенных систем контроля версий

    ОтветитьУдалить
  3. > Не замечали, что каждый раз, когда выделаете git clone или аналог для других распределенных систем, вы делаете fork?

    clone — это такое техническое понятие, а fork — это такое скорее социальное понятие.  мне почему-то кажется что вы и сами чудесно понимаете разницу.

    ОтветитьУдалить
  4. @cmm
    Тогда надо говорить, что есть разные виды форков. Один вариант, известный ранее, это просто разделение проекта на две (или более) независимых линий. В этом случае разработчики разных версий работают независимо, что приводит к некоторому распылению ресурсов и сложностью с выбором для конечного пользователя. Однако, сейчас, после широкого распространения распределенных систем контроля версий, возможен другой вариант: я делаю форк проекта, вношу в него свои изменения, но при этом постоянно синхронизируюсь с оригинальной версией. Т.е. в моей версии содержится всё из оригинальной, плюс мои изменения. И если кто-то хочем пользоваться моими пакетами, он может взять мой форк, ничего при этом не потеряв. Поскольку у меня проектов около десятка, то мне сложно вести диалог с разработчиками оригинального clbuild через список рассылки без доступа на запись к репозитарию.

    Кстати, как пример, у меня есть свой форк cl-pdf, который включает в себя патчи (других людей), которые были в списке рассылки, но которые разработчик cl-pdf игнорирует (он кажется вообще фактически перестал заниматься развитием проекта). Доказывать кому-то, что моя версия лучше оригинальной - не такое просто занятие. Но я могу легко внести изменения (по поводу cl-pdf) в свой форк clbuild.

    ОтветитьУдалить