Комментарии 26
Ну, допустим, в OpenSource-среде это тоже не всегда быстро чинится.
Можно найти кучу багов, которые висят десятилетиями, с кучей жалоб в комментах, 100% reproducibility, даже с пулл-реквестами, но без попыток починить/вкоммитить это в mainline. Или даже с попытками reject по идеологическим причинам.
Растут форки и форки форков, которые начинают использовать, а потом их перестают поддерживать.
Простите, не буду гуглить и приводить примеры, но, думаю, многие приведут примеры с наболевшим.
В проприетарной среде — да, почти без исключений, это бы заняло от недели (в лучшем случае) до тех же десятилетий. И своя инициатива (fork/pull request) там уже не прокатит если нет знакомого высокого менеджера.
Можно найти кучу багов, которые висят десятилетиями, с кучей жалоб в комментах, 100% reproducibility, даже с пулл-реквестами, но без попыток починить/вкоммитить это в mainline. Или даже с попытками reject по идеологическим причинам.
Растут форки и форки форков, которые начинают использовать, а потом их перестают поддерживать.
Простите, не буду гуглить и приводить примеры, но, думаю, многие приведут примеры с наболевшим.
В проприетарной среде — да, почти без исключений, это бы заняло от недели (в лучшем случае) до тех же десятилетий. И своя инициатива (fork/pull request) там уже не прокатит если нет знакомого высокого менеджера.
Смотрите: и в opensource, и в проприетарной среде баги могут мариноваться десятилетиями. У меня самого много таких «success story», когда баги были открыты ещё в 200х году, и до сих пор актуальны. Более того, можно утверждать, что в проприетарной среде в условиях финансовой заинтересованности они могут фикситься быстрее (могут — не значит, что будут).
Я про другое. Я про то, что opensource позволяет исправить проблему не ожидая реакции апстрима/реселлера/саппорта.
Собственно, баг из поста на launchpad'е хорошо показывает: его ещё никто даже не confirm. И зная ubuntu, он таким и будет. Возможно, его никогда и не закроют, потому что через 3 месяца выйдет новый openstack и эту версию пометят obsolete.
Но мы его для себя исправили. Именно тут, а не в волшебном (оно быстро исправится) и находится сила opensource'а. Можешь пойти и сделать сам. Если не можешь — разницы между проприетарным и opensource'ным нет.
Я про другое. Я про то, что opensource позволяет исправить проблему не ожидая реакции апстрима/реселлера/саппорта.
Собственно, баг из поста на launchpad'е хорошо показывает: его ещё никто даже не confirm. И зная ubuntu, он таким и будет. Возможно, его никогда и не закроют, потому что через 3 месяца выйдет новый openstack и эту версию пометят obsolete.
Но мы его для себя исправили. Именно тут, а не в волшебном (оно быстро исправится) и находится сила opensource'а. Можешь пойти и сделать сам. Если не можешь — разницы между проприетарным и opensource'ным нет.
Очень верно подмечено: если можешь исправить.
Как-то нашел очень похожий источник бага — используется старая версия библиотеки, выпиливающей некорректные теги из Markdown.
Для исправления нужно «всего лишь» обновить библиотеку, но сделать это с уверенностью, что ничего не сломается — не могу.
Потому запостил и жду.
Как-то нашел очень похожий источник бага — используется старая версия библиотеки, выпиливающей некорректные теги из Markdown.
Для исправления нужно «всего лишь» обновить библиотеку, но сделать это с уверенностью, что ничего не сломается — не могу.
Потому запостил и жду.
Пока это питон поправить легко. А вот когда джава-скала-го то фикс уже не настолько тривиальный по времени и поддержке
Какая разница? Мы не редактируем код на продакшене, он всегда должен проходить через CI/тесты перед деплоем. А в процессе сборки пакета компилируется он или нет — это уже не важно. В openstack тесты выполняются почти час, так что это всё равно сильно дольше, чем просто «скомпилировать».
Тут вопрос в том, что нужно иметь рабочий delivery pipeline из гита в продакшен — и его чаще всего не так уж и просто сделать, особенно, если часть сборки выполняется вручную и авторы ничего такого про CI не думали.
Тут вопрос в том, что нужно иметь рабочий delivery pipeline из гита в продакшен — и его чаще всего не так уж и просто сделать, особенно, если часть сборки выполняется вручную и авторы ничего такого про CI не думали.
>Поучительная часть: Никогда недооценивай зависимости зависимостей.
Что, простите? :)
Что, простите? :)
Было странно, если при зависимости зависимости я не отказался бы от одинарного отрицания.
До этого комментария даже не сомневался, что речь об опечатке.
Попробуйте заменить слово "недооценивай" на другое. Например:
"никогда оценивай зависимости зависимостей". Звучит по-русски?
Лично я не смог в ресурсах по правилам русского языка сходу найти примеры, когда "никогда" с глаголом используется без отрицания. Противоположных примеров тьма.
Примерный синоним слова "недооценивать" — преуменьшать значение. Тогда: "никогда преуменьшай значение зависимости зависимостей". Если целью было сказать, что преуменьшать значение зависимости зависимостей — это не есть хорошо, то нужно было использовать отрицание: "никогда не недооценивай зависимости зависимостей".
P.S. Спасибо за статью.
Правильно будет «никогда не недооценивай». Т.к. конструкция «никогда не» как раз таки и просит нас перестать что-то делать (или вовсе не начинать). И получится как раз почти эквивалент «перестань недооценивать», чего вы вроде и хотели добиться.
Ну и такое количество «не» ещё больше навернет фразу, к чему вы и стремились.
Ну и такое количество «не» ещё больше навернет фразу, к чему вы и стремились.
Надо читать: всегда учитывай зависимости.
Вы потеряли двойные зависимости. Это хуже, чем кажется, потому что обычно прямые зависимости контролируются худо-бедно, а вот второй-третий уровень — нет. Точнее, они контролируются, но в рамках видения мира того, для кого это зависимости первого порядка. И видение мира одного постепенно начинает отклоняться от видения мира другого, и чем больше слоёв зависимости, тем более различается цвет забора (если понимаете о чём я).
А патчик вы будете выкладывать? Пока что к багу не приложено ни одной ссылки на геррит.
Интересно, сколько патч провисит потом на ревью.
Интересно, сколько патч провисит потом на ревью.
Патчик к чему? К python-rfc3986? Вот он, два года как зарелизен: https://github.com/sigmavirus24/rfc3986/pull/12/files
Проблема-то была не в коде, а в том¸что зависимость слишком старая в дистрибутиве. Решается установкой правильной версии пакета python-rfc3986 (>=0.2.2), о чём в комментарии к ланчпадовому багу я и написал.
Проблема-то была не в коде, а в том¸что зависимость слишком старая в дистрибутиве. Решается установкой правильной версии пакета python-rfc3986 (>=0.2.2), о чём в комментарии к ланчпадовому багу я и написал.
Тогда понятно. А то смотрю ветку newton в опенстековском и убунтовском репозиториях Новы, а там везде уже свежая версия прописана в requirements.
О, кстати, да. Сейчас посмотрел — зависимость-то прописана. Видимо, когда бубунтоводы её пакетировали, они снасильничали зависимости. Сейчас проверю.
Вообще, картинка потрясающая.
В ubuntu apt-get source выдаёт в requirements.txt rfc3986>=0.2.0
А в oslo.config stable/newton написано rfc3986>=0.2.2
И это не вина бубунты.
На https://releases.openstack.org/newton/index.html#oslo-config в newton идёт версия 3.17, (и там 0.2.0), а в git'е в бранче stable/newton что-то другое. И я не вижу ни тегов ни каких-то других методов понять, какая версия какому коммиту соответствует.
Халтурка со стороны авторов oslo.config, да. Более того, в git'е даже нет слова 3.17 нигде — ни в коде, ни в тегах, ни в git log'ах.
Вообще, картинка потрясающая.
В ubuntu apt-get source выдаёт в requirements.txt rfc3986>=0.2.0
А в oslo.config stable/newton написано rfc3986>=0.2.2
И это не вина бубунты.
На https://releases.openstack.org/newton/index.html#oslo-config в newton идёт версия 3.17, (и там 0.2.0), а в git'е в бранче stable/newton что-то другое. И я не вижу ни тегов ни каких-то других методов понять, какая версия какому коммиту соответствует.
Халтурка со стороны авторов oslo.config, да. Более того, в git'е даже нет слова 3.17 нигде — ни в коде, ни в тегах, ни в git log'ах.
В oslo.config обновили requirements из global requirements до релиза Newton.
https://github.com/openstack/oslo.config/commit/2f2c1839b7423185a6a48e7b3ca3c3274d5ba8f3
Также наличие этих изменений соответствует тегу 3.18.0 в oslo.config, а в 3.17.0 действительно их еще нет.
Возможно, что ошибся мейнтейнер Openstack релиза Newton, приняв в него старые версии oslo.config и упустив следующую актуальную.
https://github.com/openstack/oslo.config/commit/2f2c1839b7423185a6a48e7b3ca3c3274d5ba8f3
Также наличие этих изменений соответствует тегу 3.18.0 в oslo.config, а в 3.17.0 действительно их еще нет.
Возможно, что ошибся мейнтейнер Openstack релиза Newton, приняв в него старые версии oslo.config и упустив следующую актуальную.
У меня в связи с этим даже более серьёзный вопрос: а как я могу узнать какой коммит какой версии соответствует? Именно в oslo.config, где нет тегов в гите.
Есть теги: https://github.com/openstack/oslo.config/tags
И можно сравнить код под тегом и ветку, например:
https://github.com/openstack/oslo.config/compare/3.18.0...master
И можно сравнить код под тегом и ветку, например:
https://github.com/openstack/oslo.config/compare/3.18.0...master
Вот теперь и у меня вопрос. Можно увидеть нужные изменения и в 3.18.0 и в stable/newton отдельно.
А если посмотреть сравнение 3.18.0 против stable/newton, то получается, что нужные изменения появляются только в stable/newton.
А если посмотреть сравнение 3.18.0 против stable/newton, то получается, что нужные изменения появляются только в stable/newton.
В проприетарной среде — сделать алиас без дефиса, отправить ошибку, [записать в wiki], забыть.
Подскажите, по каким причинам ваш выбор остановился именно на Ubuntu, а не на, скажем, Debian?
Впрочем, в Debian та же петрушка — в Jessie 0.2.0-2, в не вышедшем еще Stretch — 0.3.1-2
Впрочем, в Debian та же петрушка — в Jessie 0.2.0-2, в не вышедшем еще Stretch — 0.3.1-2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История одного бага (#1653967)