[Devel] [Задача 7606] Виртуальный стенд

Evgeny Sinelnikov sin на etersoft.ru
Ср Сен 28 17:50:08 MSD 2011


28 сентября 2011 г. 16:28 пользователь Vitaly Lipatov <lav на etersoft.ru> написал:
> В сообщении от Среда 28 сентября 2011 Evgeny Sinelnikov написал(a):
> ...
>> > Можно уточнить, изучал ли ты содержимое пакета vbox-server,
>> > установленного на virtualbox, и использовал ли его?
>>
>> Я его брал за основу, запуска машин. К сожалению, в нём нет механизма
>> хуков или возможности использования произвольного списка для
>> автозапуска.
> Видимо, и не появится, если просто копировать функции из одного скрипта в
> другой.

Если бы эти чудные скрипты проектировались и упаковывались так, чтобы
их можно было включить и использовать отдельно, то я бы так и
сделал...

Ничего плохого в cut&paste не вижу. То, что работает, стоит
тиражировать. Я вот не пойму, если бы я сам написал подобные функции,
потратив на это больше времени и усилий, то это было бы мне в плюс что
ли?


>> > У нас давно сделано это решение, и не очень ясно, что за велосипед в
>> > rc.local.vbox.
>>
>> "У нас давно" ничего не сделано. А то, что сделано нужно переделывать,
> Ну как же -- все функции в rc.local.vbox взяты из /etc/init.d/vboxmachines. Это
> и сделано.

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

>> в случае не предусмотренных вариантов использования. Подробности
>> задачи я описал здесь:
>> http://bugs.etersoft.ru/show_bug.cgi?id=7689
>>
>> Конкретные предложения о том, как стоит сделать лучше рассмотреть и
>> реализовать приветствуются. Упрёки вида, что это за велосипед,
>> принимаются только в варианте предложения о том, как должен выглядеть
>> не велосипед в данной задаче. Я её описал в баге 7689. Я согласен её
> Ну нужно было всего лишь добавить в пакет возможность выполнять факультативный
> скрипт перед запуском машин. И вписать в него эти losetup.

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

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

> Я вижу это как обработку /etc/vbox/machines.d (с файлами *.list со списками
> машин и *.sh с предварительными командами.
> Так, чтобы service vbox start yauza использовала файлы
> /etc/vbox/machines.d/yauza.list и /etc/vbox/machines.d/yauza.sh

Я перенёс это предложение в задачу:
http://bugs.etersoft.ru/show_bug.cgi?id=7689

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

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

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

Предлагаю, вместо любого подобного упрёка создавать багу, в которой
предлагаются конкретные предложения по улучшению сделанного, на скорую
руку, варианта решения своей задачи.

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

Ведь одно дело - выполнить задачу, чтобы другие могли ей пользоваться,
а другое обобщить своё решение для будущих задач.

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

От такого подхода надо уходить.

> А как должен выглядеть не велосипед, я уверен, ты лучше меня знаешь.

Не всегда. Всё самое сложное замаскировано своей самоочевидностью.
Так, что не бойтесь быть капитаном очевидность - делайте отдельные
баги.


-- 
Sin (Sinelnikov Evgeny)


Подробная информация о списке рассылки Devel