Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Canonical потеряла еще пару разработчиков

Сanonical продолжает терять квалифицированный персонал. Сначала уже известный вам разработчик systemd, Martin Pitt, объявил в своем блоге, что уходит в Red Hat. Пруфпик!

/images/martin_pitt_redhat.jpg

Сразу же за ним о своем уходе объявил и другой инженер Canonical, Daniel Holbach. Он пока не решил, где будет работать дальше.

Как стать контрибьютором в open source проект — идеи для первого патча и прочие рекомендации

По случаю перезапуска сайта хочется привести без сокращений статью, которую написал Aleksander Alekseev. Удивительно, но нас до сих пор спрашивают некоторые начинающие OSS-энтузиасты, с чего бы им начать общение с OSS-сообществом? Как раз на этот вопрос и пытается ответить Aleksander в этой статье:

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

Между прочим, интересный вопрос — а зачем это вообще кому-то может быть нужно? Для большинства людей работа над открытыми проектами — это в первую очередь возможность получить колоссальный опыт разработки, а также сделать нечто, чем будут пользоваться миллионы людей по всему миру (возможно, даже не зная об этом) ну как минимум еще ближайшие лет 10. Не стоит также списывать со счетов желание понять, как внутри устроены, скажем, операционные системы или компиляторы. Я пишу здесь об этом по той причине, что без достаточно сильной мотивации вы вряд ли найдете лишнее время для работы над каким-то там опенсорсом. Поэтому первым делом поймите для себя, что именно привлекает вас в данном конкретном проекте.

Примечание: Также вас может заинтересовать статья Как я прокачиваю владение английским языком. В мире open source, как правило, все разработчики общаются между собой на английском языке.

Далее предполагается, что вы определились с проектом, а также разобрались, как он компилируется, как прогоняются тесты, как происходит установка, а также нашли описание процесса разработки и место, куда нужно посылать патчи. Это не сложно. Примеры см в заметках Сборка LLVM-стека из исходников и чем она так интересна, PostgreSQL: сборка из исходников и настройка под Linux и Памятка по сборке ядра Linux из исходного кода. Также не повредит разобраться, как отлаживать проект. Тут все сильно зависит, помимо прочего, от используемого в проекте языка программирования, а также используемой вами ОС. Если проект написан на C или C++, то обратите внимание на мои заметки, посвященные GDB, LLDB и WinDbg. В любой непонятной ситуации не стесняйтесь обратиться за помощью в мейлинг лист или IRC-канал проекта.

Итак, с чего же можно начать:

  • Опечатки. Начните с малого. В любом достаточно крупном проекте полно опечаток, как в документации, так и в комментариях к коду. Патчу, который их исправляет, гарантированно все будут очень рады, а шансы сломать что-то таким патчем равны нулю. А значит его почти наверняка быстро примут. В процессе у вас сложится хорошее понимание, как в данном конкретном проекте нужно оформлять патчи, куда их нужно слать, и так далее.
  • Code review. Большинство программистов обожают писать код, но не очень любят читать или тестировать его. Поэтому многие проекты испытывают нехватку в ревьюверах. Будучи новичком в проекте, вы совершенно бесценны, как ревьювер! Ведь вещи, которые другим разработчикам могут казаться «очевидными», для вас таковыми не являются. При этом делать code review сравнительно просто. Как минимум, нужно проверить, что код действительно делает то, что нужно, ничего не ломает, проходит все тесты и сам покрыт тестами, не сыпет ворнингами при компиляции, хорошо документирован, оформлен в соответствии с принятым в проекте code style, не ломает обратную совместимость, и не содержит явных ошибок (например, утечки ресурсов). Что интересно, читая чужой код, вы быстро разберетесь во внутреннем устройстве проекта. Не бойтесь пропустить какие-то ошибки. Коммиттер, а также другие ревьюверы, прекрасно понимают, что вы работаете над проектом недавно, и в любом случае перепроверят за вами.
  • Исправление багов. На какие-то баги вы можете налететь сами. Особенно, если проект, над которым вы работаете — это библиотека. Но куда большие багов обычно репортят другие пользователи проекта. Проверьте багтрекер. Найдите первый понравившийся баг и попытайтесь его воспроизвести. Если не получается, постарайтесь выяснить у багрепортера детали. Может оказаться, что баг не воспроизводится или даже уже был исправлен. Закрыв тикет без какого-либо исправления, вы тоже окажете помощь проекту. Еще в поиске багов вам могут помочь санитайзеры и статические анализаторы кода.
  • Оптимизация. Обычно это халява, так как в сущности от вас требуется переписать код, чтобы он делал то же самое, только быстрее. Правда, чтобы найти настоящее «бутылочное горлышко», нужно не просто придумать синтетический бенчмарк, а иметь какую-то реальную и достаточно большую нагрузку. Само собой разумеется, выполнение оптимизации потребует от вас хорошего владения средствами профилирования кода.
  • Тесты. Печально, но факт — тесты программисты писать тоже не любят. Определите степень покрытия кода тестами, найдите непокрытые участки кода, напишите для них тесты. Удивительно, но многие программисты не понимают разницу между модульными и интеграционными тестами и никогда не слышали про property-based тесты. Если в проекте нет одного из этих видов тестов, предложите патч, который его добавляет.
  • Документация. А еще программисты часто не любят писать документацию. Проверьте, нет ли белых пятен в официальной документации или man-страницах проекта. Бывает еще так, что в документации есть несостыковки, устаревшая информация, или просто битые ссылки. Возможно, документацию можно улучшить, добавив в нее наглядных примеров.
  • Рефакторинг. В любом достаточно старом проекте есть места, которые можно переписать чуть лучше, чем они написаны сейчас. Большой файл с исходным кодом можно разбить на несколько, десяток параметров, передаваемых процедуре, можно объединить в одну структуру, и так далее. Важно, чтобы код не только решал стоящую перед ним задачу, но и был при этом читаемым!

Если позволите, хотелось бы дать еще пару советов. (1) Чем меньше ваш патч, чем больше шансов, что его примут. В частности, «заодно» подправлять отступы в не связанных с вашим патчем местах — очень плохая идея. (2) На первых порах любая прихоть коммиттера для вас — закон. Если коммиттер просит вас что-то исправить в патче, просто сделайте это, даже если ваши предпочтения не совпадают с предпочтениями коммиттера. Спор с ним попросту ни к чему не приведет. (3) Будьте предельно вежливы, используйте как можно больше слов please, thank you, и так далее. Любая грубость, троллинг, сарказм и так далее совершенно недопустимы!

Также не забывайте, что контрибьютить можно не только в виде патчей. Отвечать на вопросы в IRC и пользовательском списке рассылки, дополнять и исправлять wiki-сайт проекта, освещать новости проекта в своем блоге (можно создать рассылку ProjectName Weekly, если ее еще нет), писать обучающие статьи или, возможно, даже книги, посвященные проекту, организовать локальные юзергруппы, и так далее — все это тоже очень важные вклады в развитие проекта!

А контрибьютите ли вы в open source проекты и если да, то в какие, и каким образом?

Расписание DevConf.cz 2017

Помимо FOSDEM 2017 уже довольно давно опубликовали и расписание DevConf.cz 2017. К сожалению, в этом году организаторы были вынуждены ввести обязательную регистрацию участников, которая, по правде говоря, совсем не обременительная. В этом году мероприятие будет проходить с 27 по 29 января. Приезжайте в Брно, будем раны увидеться.

Обновление сайта

Уважаемые читатели (и писатели), добро пожаловать на наш обновленный сайт, созданный по последнему слову техники.

Главное изменение - смена движка сайта с громоздкого Drupal на легковесный статический генератор Nikola.

Что нам это дает?

  • Код сайта вместе с содержимым находится в репозитории rf-web. Репозиторий открыт, управление содержимым сайта происходит целиком и полностью через GitHub.

    Хотите опубликовать собственный материал? Присылайте pull-request.

    Хотите исправить опечатку или неточность в чужой статье? Просто присылайте pull-request.

    Не нравится оформление страницы? Всё так же присылайте pull-request.

    Хотели бы добавить несколько статических страниц? ..

    ну дальше я думаю понятно :)

  • Писать статьи можно в rst-формате в своём любимом текстовом редакторе, а можно напрямую с помощью web-интерфейса GitHub.

  • При мердже сайт автоматически обновляется благодаря настроенной автопубликации через Travis CI.

Что сделано

  • Все старые статьи экспортированы из Drupal и доступны по старым ссылкам.
  • Включена RSS-лента.
  • Для статей сайта подключена внешняя система комментариев. На данный момент это Google Plus.
  • Основные элементы оформления перенесены со старого сайта.

Недоработки

  • Система комментариев пока не протестирована, так что будем разбираться по ходу дела.
  • Много мелких недочетов в оформлении.
  • Не хватает содержательных статических страниц и FAQ.
  • При экспорте html был сконвертирован в rst-формат, в связи с чем у старых статей время от времени встречается некорректное форматирование. Такие статьи помечены как "архивные".

Как поучаствовать

Так как мы используем стандартные возможности GitHub, для участия достаточно освоиться с базовой документацией Как поучаствовать с помощью Issues и Pull Requests

Процедура собственно сборки сайта описана в README. Обратите внимание на необходимость использования Python 3.


Присоединяйтесь, вам зачтется.

Вышел RFRemix 25 - с Wayland в сеансе GNOME

Доступен для загрузки RFRemix 25, ремикс основанный на репозиториях Fedora, RPM Fusion и Russian Fedora. На этот раз RPM Fusion оправился от всех своих болячек и сделал все свои репозитории в срок. Fedora/RFRemix 25 - это первый релиз, в котором рабочий стол GNOME по-умолчанию использует Wayland. Одни говорят, что это хорошо, у других не всё так гладно, но начало положено.

Что у нас нового и старого

  • Для загрузки доступны две большие редакции RFRemix Server и Workstation (включая сетевые установки), а также Live-образы с различными рабочими столами;
  • Различные мультимедиа-кодеки, которых нет в оригинальной Fedora, а также Flash доступны из коробки;
  • Многие пакеты из репозиториев Russian Fedora доступны из приложения GNOME Software (Программы);
  • Так же у нас пересобран freetype с subpixel rendering;
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда) и навсегда выкинули infinality, который не работал;
  • В образы Workstation (GNOME 3.22) по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и включается в gnome-tweak-tool;
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
  • Хромиум пересобран с поддержкой GTK3 и правильных кодеков;
  • Также мы обновили систему сборки. Теперь Live-образы максимально схожи с апстримовскими.

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

Образы

Для загрузки доступны Live образы Workstation (GNOME), KDE (Plasma 5), LXDE, XFCE, MATE и Cinnamon. DVD и netinstall образ RFRemix Server и netinstall образ RFRemix Workstation.

Куда сходить спросить, пожаловаться

Обновление

Для обновления с предыдущих версий желательно сперва обновить текущую систему, а затем отдайте команду:

dnf --releasever=25 distro-sync --refresh --nogpgcheck
http://tigro.info/wp/wp-content/uploads/2016/11/Выделение_024.png

Вышел RFRemix 25 Beta

Это архивная статья

Для загрузки доступен RFRemix 25 Beta. Всё как обычно, как и раньше. Для загрузки доступны Live-образы KDE, LXDE, XFCE, MATE, Cinnamon, а также Workstation версия с GNOME 3.22. Доступна Серверная редакция, образы сетевой установки и установочный DVD образ Workstation (не известно зачем, но в Fedora решили тоже его собирать).


25

RFRemix основан на репозиториях Fedora, RPM Fusion, который за полгода стал живее всех живых, вот что делает с проектами нормальная инфраструктура, и на репозиториях Russian Fedora. Fedora с каждым релизом становится всё лучше и лучше и всё меньше изменений требуется вносить в образы.

Основные отличия

  • Freetype пересобран с subpixel rendering.
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда).
  • В образы Workstation по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и включается в gnome-tweak-tool.
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.
  • Мы продолжаем провайдить Chromium, так как тот что в репозитории Fedora очень плохо работает с видео.
  • Telegram теперь собирается из исходников.
  • RFRemix Server [ i686 ] [ x86_64 ]
  • RFRemix Workstation [ i686 ] [ x86_64 ]
  • Образы Live [ i686 ] [ x86_64 ]

Куда сходить спросить, пожаловаться

Обновление

Для обновления с предыдущих версий RFRemix нужно сперва полностью обновить текущую систему, а затем отдайте команду:

dnf --releasever=25 distro-sync --nogpgcheck

Релиз RFRemix 25 намечен на 15 ноября одновременно с релизом Fedora.

Дистрибутивы OpenStack 9

Это архивная статья

Вслед за выходом "ванильного" OpenStack Mitaka, тринадцатой версии OpenStack, начали выходить и дистрибутивы от вендоров. Сначала вышел Mirantis OpenStack 9.0, а через пару месяцев вышел и Red Hat OpenStack 9.0.

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

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

Большие изменения еще грядут. Пока OpenStack все еще использует виртуалки, а что-то подсказывает, что будет переход на контейнеры. Это чувствуют и в Docker Inc, которые видимо сразу после Red Hat Summit поехали на VMworld 2016. Там ни с кем не ссорились.