[Aldan 0]

Aldan

Мой "опыт дурака" ;) говорит то же самое.

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

[AVL 0]

Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.

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

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

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

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

Синхронумерацию не представляю как сделать с lp:kicad, да и зачем это делать?

[Aldan 0]

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

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

Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.

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

могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.

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

Далее я писал:

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

Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.

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

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

-=-=-=-=-=-=-=-

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

Изменено 11 июня, 2013 пользователем Aldan

[tema-electric 0]

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

 

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

[Aldan 0]

грызть мозг еще из-за такой мелочи ... нафиг нужно :)

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

Изменено 12 июня, 2013 пользователем Aldan

[AVL 0]

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

...

Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.

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

 

Здесь придется указывать 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 (вдруг кто-то из их админов захочет к нам присоединиться ;) я если что не против)

Изменено 12 июня, 2013 пользователем AVL

[AHTOXA 14]

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

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

[faa 4]

ИМХО, ревизию lp:kicad можно указывать в комментарии к мержу.

Если уж фактически форкнулись, то для разработчиков будет вполне достаточно.

При багрепорте можно посмотреть, когда и с какой ревизией мержились, и фиксилось ли это в жпш-ветке.

 

Кстати, а когда (от какой ревизии) отпочковались?

Может уже пора там патч формировать и сюда накатывать? Они там довольно активно ваяют.

 

Изменено 12 июня, 2013 пользователем faa

[Aldan 0]

Здесь придется указывать 2 ревизии...

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

Если уж фактически форкнулись

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

 

[AVL 0]

Кстати, а когда (от какой ревизии) отпочковались?

Ну изначально я делал ветку от ревизии 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. Придется еще больше удаленных ими исходников брать на наше сопровождение. Я сейчас занят интеграцией новых форматок.

 

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

 

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

Я пока не воспринимаю 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.

Изменено 12 июня, 2013 пользователем AVL

[Aldan 0]

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

Пока делаются максимальные усилия не рассинхронизироваться с lp:kicad.

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

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

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

AVL, прошу Вас, не отвечайте мне, чтобы и я не должен был Вам отвечать. Благоразумнее завершить нашу беседу на эту тему. Сейчас все решит то, как все ГОСТ-разработчики выработают новые правила игры и все придет к некому новому общему знаменателю.

Изменено 12 июня, 2013 пользователем Aldan

[zöner 0]

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

[AVL 0]

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

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

Изменено 12 июня, 2013 пользователем AVL

[AVL 0]

Повторно реанимирован 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) :)

Изменено 13 июня, 2013 пользователем AVL

[AHTOXA 14]

Спасибо!

А 4209 lp:kicad - это stable или нет?