break, благодарю, что откликнулись. Выходит, что затронутая проблема интересует только Вас и меня, а остальным до лампочки.., впрочем, все как всегда и наш форум не исключение. Не привыкли еще в нашей стране высказывать свое мнение, а жаль.

Извините, не пойму о чем речь.

Сейчас и так все изменения из lp:kicad сливаются к нам (синхронизируется в нашу сторону). За исключением вырезанного BOM.
Синхронумерацию не представляю как сделать с lp:kicad, да и зачем это делать?

AVL, не принимайте на свой счет мое утверждение, что «затронутые проблемы интересуют только break и меня» т. к. я говорил о «народном мнении» дополнительно к обмену мнениями с Вами в нашей беседе. То есть Вы могли бы сейчас не отвечать на мое сообщение и все было бы в рамках нормы. Но коль скоро Вы просите пояснений, попробую выразиться более пространно. Итак, я писал:

Здесь я напоминаю Ваши слова:

При этом я вопрошаю, а что же мешает при этой сборке указать номер основной стабильной ветки, на основании которой она сделана и только после этого выложить на наш фтп? А в свойствах сборки указать, что эта сборка GOST-COMMITTERS, если это так необходимо. Вроде бы мысль моя простая и понятная, не так ли?
Далее я писал:

Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.
Сейчас нумерация Ваших сборок ничего не говорит о версии сборки, на основании которой она сделана, да и о версии Вашего генератора с менеджером тоже ничего не говорит. Если бы у Вас была отдельная ветка генератора с менеджером со своей нумерацией, который бы «прикручивался при сборке», а сама сборка бы имела номер соответствующий основной ветке, а в инфо на сборку была бы указана текущая версия генератора с менеджером, то информация была бы исчерпывающей и вся путаница с версиями бы исчезла.
Правда, если так сделать, то Вы будете разработчиком лишь русифицированной ГОСТ-сборки Кикада, но, похоже, у Вас более глобальные амбиции - завлечь на свою ветку всех отвергнутых Жан Пьером, а это уже совсем другая история...
-=-=-=-=-=-=-=-
AVL, если теперь Вам все стало понятно, можете мне не отвечать. Мне к уже сказанному все равно добавить уже нечего. Дождусь когда ГОСТ-сборка с генератором и менеджером хоть немного устаканится, тогда и потестирую. Может быть тогда что-то и напишу.

Сообщение отредактировал Aldan - Jun 11 2013, 22:41

Честно говоря, проблема версий совершенно не волнует. Для работы это почти не важно. Для работы важно знать какие новые печеньки появились, чтобы осознанно качать. Я чаще качаю чисто из любопытства или периодично раз в несколько месяцев, смотря сколько работы, чтобы попытаться увидеть новшества Билды и версии нужны разработчикам, чтобы не потеряться )))

Тут нужно понимать, что люди работают над проектом по доброте душевной, и грызть мозг еще из-за такой мелочи ... нафиг нужно

Если мои слова воспринимаются в таком деструктивном ключе, то я, конечно, умолкаю. Действительно, надо же знать меру "улучшательству", а то ведь можно и отбить всякую охоту к работе. Пусть все развивается так, как удобно тем, кто работает, а пользователи уж как-то приспособятся

Сообщение отредактировал Aldan - Jun 12 2013, 05:59

Здесь придется указывать 2 ревизии тогда: первая - номер из lp:kicad/stable (вбивать при каждом коммите руками), вторая - номер из lp:~kicad-gost-committers/kicad/kicad.
По скольку будет следующая ситуация:
ответвились мы к примеру от ревизии 4020 ветки lp:kicad/stable. Далее ветка 4020 не меняется какое-то время, а мы за это время в свою стабильную ветку сделали 3 своих корректирующие баги коммита. Поэтому придется указывать 2 ревизии.
Теперь вопрос, а надо ли это? Почему мы не можем обойтись автоматическим механизмом вставки ревизии? У потенциальной ветки lp:~kicad-gost-committers/kicad/kicad-stable будет собственная нумерация ревизий точно так же как и у lp:kicad/stable собственная нумерация, не совпадающая с lp:kicad.
По суфиксу GOST-COMMITTERS)-stable можно будет понять, что это из GOST-COMMITTERS стабильной ветки. То есть номер уникальный в целом.
Если необходимо будет поднять информацию из чего произошли исходники конкретной ревизии, так это все есть в рамках инструментария bazaar (смотрим bzr qlog), там видны все слияния. Также можно это посмотреть на launchpad для интересующей ветки в комментариях коммитов.

С другой стороны, могу понять, что номер ревизии из lp:kicad/stable может быть полезным, если кто-то захочет опубликовать баг здесь: https://bugs.launchpad.net/kicad.
То есть пользователь видит проблему в конкретной сборке GOST-COMMITTERS)-stable, смотрит какая у нее ревизия соответствующая lp:kicad/stable, устанавливает соответстующую сборку lp:kicad/stable, проверяет, если проблема сохраняется, то публикует баг здесь: https://bugs.launchpad.net/kicad.

То есть вопрос, можем ли мы обойтись выяснением ревизии через bzr qlog / launchpad сайт? Или это очень не удобно и нужно все-таки руками вписывать номер ревизии из lp:kicad/stable в нашу стабильную ветку как доп.информацию?


Ветка lp:~kicad-gost-committers/kicad/kicad не ограничивается ГОСТом как таковым. Сюда может добавляться любая полезная функциональность. Помимо генератора КД + менеджера компонентов, в этой ветке также уже есть конвертер pcad2kicad и реанимированный BOM.
Насчет завлекания, ветка в плане разработки ориентирована на:
1) новых разработчиков, которые просто изначально начали работать в lp:~kicad-gost-committers/kicad/kicad, например, узнали про нее из данного форума.
2) разработчиков, которые видят, что происходит в lp:kicad и не жаждут желанием отправлять патчи в lp:kicad по той или иной причине.
3) разработчиков, у которых уже есть печальный опыт попыток работы с lp:kicad
4) разработчиков из lp:kicad (вдруг кто-то из их админов захочет к нам присоединиться я если что не против)

Сообщение отредактировал AVL - Jun 12 2013, 07:26

Я думаю, что иметь номер ревизии из lp:kicad/stable сразу в about будет весьма полезно. Иначе часть багрепортов будет потеряна: не каждый из пользователей станет заниматься выяснением ревизии через bzr qlog / launchpad сайт.

ИМХО, ревизию lp:kicad можно указывать в комментарии к мержу.
Если уж фактически форкнулись, то для разработчиков будет вполне достаточно.
При багрепорте можно посмотреть, когда и с какой ревизией мержились, и фиксилось ли это в жпш-ветке.

Кстати, а когда (от какой ревизии) отпочковались?
Может уже пора там патч формировать и сюда накатывать? Они там довольно активно ваяют.


Сообщение отредактировал faa - Jun 12 2013, 09:46

AVL, все сводится к вопросу: оставить все по-прежнему, интегрируя в основную сборку свои ГОСТ-фичи, или же организовать новую ветку Кикад, что неминуемо выльется в форк невзирая на все усилия по синхронизации.

А вот и ответ на вопрос - «фактически форкнулись», т. е. выбор сделан. Так что все мои прежние вопросы и предложения были изначально бессмысленными, поэтому забудьте все, что я писал и я смиренно умолкаю

Ну изначально я делал ветку от ревизии 3592 lp:kicad (02 июня 2012 года) когда начал работу по интеграции и переработке pcad2kicad. С того времени периодически подтягиваю измения из lp:kicad к себе.

Не пойму какой патч
Последний раз 07 июня 2013 года подтягивал изменения из lp:kicad (их ревизия 4199) в lp:~kicad-gost-committers/kicad/kicad (наша ревизия 4137).
Изменения из lp:kicad подтягиваю простой командой:
bzr merge lp:kicad
В большинстве случаев мерж выполняется автоматом. Но иногда могут быть конфликты, когда в lp:kicad кто-то изменил файлы, которые также менялись в lp:~kicad-gost-committers/kicad/kicad.
Эти дни пока больше не мержил с lp:kicad, потому что они сделали еще более глубокую вырезку функциональности BOM. Придется еще больше удаленных ими исходников брать на наше сопровождение. Я сейчас занят интеграцией новых форматок.


Я пока не воспринимаю lp:~kicad-gost-committers/kicad/kicad как полноценный форк. Не превышен некий порог, чтобы это так назвать.
Пока делаются максимальные усилия не рассинхронизироваться с lp:kicad. На данный момент можно одни нажатием влить lp:~kicad-gost-committers/kicad/kicad в lp:kicad, было бы желание со стороны lp:kicad. И точно так же пока еще достаточно гладко вливаются изменения из lp:kicad в lp:~kicad-gost-committers/kicad/kicad.

Сообщение отредактировал AVL - Jun 12 2013, 11:59

AVL, на мой взгляд, чем больше будет нововведений в вашей ветке, тем труднее будет обеспечивать ее синхронизацию с основной и, во избежание нарастающих непродуктивных потерь ресурса разработчиков, постепенно вожжи соответствия будут отпущены. Это очевидная ситуация сидения между двух стульев, так что просто придется принять окончательное решение о форке раз уж движение в эту сторону одобрено. Ну, а вести форк малыми силами та еще задача, и неприятностей на таком пути может быть предостаточно.
Кроме того, оцените реальное положение вещей: faa — в последнее время надолго выпадает даже из общения, Константин Барановский тоже серьезно занят, viknn — не обновлял документацию к Кикаду с марта 2012 из-за своей загруженности, и т. д. Все это означает, что у разработчиков Кикад-ГОСТ катастрофически не хватает сил и времени, поэтому получится ли в такой ситуации тянуть форк — большой вопрос.
И еще, человечество не зря разделило программные продукты на тестовые и стабильные, дабы для конечных пользователей доходили именно стабильные финальные релизы. Однако, в нашей с Вами беседе выяснилась Ваша нелюбовь к стабильном сборкам из-за их отсталости и я просто не уверен в том, что теперь, после того, как «форкнулись», увижу еще хоть одну из них.
AVL, прошу Вас, не отвечайте мне, чтобы и я не должен был Вам отвечать. Благоразумнее завершить нашу беседу на эту тему. Сейчас все решит то, как все ГОСТ-разработчики выработают новые правила игры и все придет к некому новому общему знаменателю.

Сообщение отредактировал Aldan - Jun 12 2013, 16:48

зачем Make танет boost из сети, если у меня уже установлен libboost-dev ?

Я не вникал в эту часть, но на сколько понимаю, он тянет boost конкретной версии, и скорее всего не проверяет наличие никаких установленных пакетов. В любой момент разработчиками KiCad может быть принято решение перейти на другую версию boost, и тогда будет автоматом при сборке KiCad перезакачана соответствующая версия boost.

Сообщение отредактировал AVL - Jun 12 2013, 16:47

Повторно реанимирован BOM ("eeschema->Tools->Generate Bill of Materials") после очередной попытки в lp:kicad вырезать все до корня.
На текущий момент lp:~kicad-gost-committers/kicad/kicad полностью синхронизирован с lp:kicad.
Актуальная ревизия 4146 в lp:~kicad-gost-committers/kicad/kicad, которая соответствует ревизии 4209 lp:kicad (testing)

Сообщение отредактировал AVL - Jun 13 2013, 05:56

Спасибо!
А 4209 lp:kicad - это stable или нет?