Russian Fedora

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

Content (44 страница со старыми записями)

Обсуждение реорганизации всего процесса разработки Fedora

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

Matthew Miller, участник Fedora Cloud SIG и инженер Red Hat, выступил с предложением разделить Fedora на несколько частей - базовая часть, общая для всех, и надстройки, создаваемые в рамках рабочих групп. Базовая часть будет иметь необычное и свежее название - Fedora Core. Его предложение уже с интересом изучается русскоязычными аналитиками на OpenNET.ru
Проблема, которую пытается решить Matthew, заключается в том, что у нас, внутри проекта, есть части, движущиеся с разной скоростью.
Например, Firefox и ядро обновляются быстрее всех других, и независимо от версии релиза. Получается, что внутри системы с якобы фиксированным API/ABI, есть части, разрабатываемые по принципу rolling release. Это не единственный пример - разработка приложений Cloud и Virtualization идет настолько быстро, что жесткие требования к API/ABI внутри релиза просто связывает руки мэйнтейнеру, заставляя его тратить много времени на не очень интересную и осмысленную работу по бэкпортированию патчей в старые версии. Опять же пользователи порой хотят и посидеть, и поплясать одновременно - чтоб были стабильные версии всего, кроме вот того и того, которые, как пользователю хочется, должны быть самые распоследние. Мэйнтейнерам постоянно регулярно нарушать политики по недопущению смены API внутри релиза, и Matthew хочет декриминализировать эту практику, выделив проблемные области в особенные сущности. В слайдах он приводит ряд примеров, когда существующая ориентация на пакеты (RPM) мешает, например, установка последней версии приложения из Git.
К сожалению, его небесспорное предложение прямо сейчас полностью несовместимо с существующей инфраструктурой. RPM, являясь, самой продвинутой системой управления пакетами, не имеет развитой инфраструктуры сборки и пересборки, доступной продвинутому пользователю. Не хватает многих нужных функций. Например, сервис для т.н. "chain builds" появился лишь недавно, и, к сожалению, пока непонятно каково его будущее, и какова скорость развития. Получается, что каждый дистрибутив поднимает свои системы для решения этой задачи. Просто сидя, скажем, на 17й Fedora, выбрать пакеты из Rawhide, чтоб они пересобрались для 17, кликая мышкой по чекбоксам не получится - инфраструктуры для этого пока нет.
Непонятно, что делать с багзиллой, на какие компоненты открывать тикеты, в случае нахождения ошибок в таких вот пересобранных пакетах? Неясно, как в этой системе будут обеспечиваться повторяемость результатов и идентичность систем, если какие-то компоненты будут плавно изменяться со временем. Что касается сборки пакетов из VCS, то этот таг spec-файла RPM только начинает входить в оборот у мэйнтейнеров, и пока несет лишь информативную нагрузку.
Идеи, конечно, возникли не на пустом месте. Уже обсуждалось разделение EPEL на ряд слоев, обновляющихся с разной скоростью, плюс недавно Red Hat официально представила Software Collections, содержащие актуальные версии современного ПО для разработки.
Некоторые аналитики даже поспешили сделать вывод, что Red Hat нужно срочно обкатать новую технологию на тестовых хомячках перед тем, как выпустить ее в продажу, но, разумеется, это беспочвенные домыслы, и низкопробная конспирология.
Так или иначе, это очень хорошо, что были очерчены некоторые негативные моменты, и создан добротный [STRIKEOUT:shitstorm] тред в мэйллисте. Fedora Project, в отличие от некоторых других дистрибутивов, никогда не сторонилась радикальных перемен, если этого требует историческая необходимость. Например, не так давно мы вновь переосмысливали наше место в жизни, в очередной раз уточняя для кого мы, кроме нас самих, делаем дистрибутив и инфраструктуру? Раньше все было просто - ведущие разработчики OSS и активные квалифицированные (умеющие пользоваться diff и patch, как минимум) пользователи, желающие сотрудничать, это был наш контингент. Нас всегда было немного, порядка 10%, но мы всегда были людьми, которые создают почти весь Open Source, сеть Internet и все сложные индустриальные решения, и это было просто и понятно. Но в последнее время мы заметили ряд существенных изменений:
  • Взрывной рост Internet совпал с растущей популярностью Mac OS X среди разработчиков
  • GitHub создал для разработчиков социальную сеть, которую все разработчики так долго ждали, повысив связность коммьюнити. Появление GitHub полностью изменило то, как выпускается открытое ПО, одновременно сделав Git де-факто стандартом разработчика, растоптав нескольких конкурентов.
  • Появление Cloud и Virtualization технологий в датацентрах. Это радикально изменило то, как можно разворачивать, обновлять, и масштабировать системы.
  • 3D-принтеры, ARM, Maker-культура, Open Hardware
  • Слом застарелых стереотипов о том, как должен выглядеть десктоп, и каковы задачи, на нем решаемые. Появление сразу букета новых решений (спасибо, GNOME 3, ты показал пользователям, что существует много других вариантов!) и нового класса мобильного оборудования.

Все это приводит к тому, что коммьюнити Fedora Project обязано меняться, подстраиваться под разработчиков нового оборудования и его пользователей, участвовать в мероприятиях по Open Hardware, включать самое последнее ПО для виртуализации и облаков, развивать новейшие десктопные технологии, не забывая предоставлять возможность выбора, создавать механизмы для "кастомизации" дистрибутива, желательно без установки gcc и rpmbuild, идти на компромиссы при установке и обновлению ПО. Кое-что у нас получается, кое-что пока не очень (особенно по инфраструктуре, где мы всегда рады новым добровольцам), но главное - у нас [STRIKEOUT:никакой стабильности] никакого застоя.

Наоборот - градус только растет, и веселье только начинается.

Присоединяйтесь к нам, т.к. во-1 сейчас у нас для начинающих очень много возможностей увековечить себя, а во-2 мы играем ключевую роль в принятии решений о том, каким будет Open Source в будущем!

image0

Регулирование подсветки на Windows 8 compatibility устройствах побеждено

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

Вчера ( 21.07.2013 ) в ядро Linux были включены несколько патчей, которые решают проблему регулирования подсветки на некоторых устройствах.
Скоро Linus Torvalds выпустит Linux 3.11-rc2. В этой версии ядра уже интегрированы все патчи.
Суть проблемы заключается в следующем:
Windows 8 представила новую политику управления подсветкой, чтобы графические драйверы управляли ей.
Эта проблема проявляется у различных поставщиков:
  • Lenovo - некорректное поведение
  • Некоторые Dell - полный отказ
  • Возможно другие
Самое простое, что можно сделать - это отключить ACPI управление подсветкой, если прошивка указывает на поддержку Windows 8, но вполне возможно, что некоторые графические драйверы могу по-прежнему использовать функциональность ACPI как основную. Один из патчей легко отключает регулирование подсветкой через ACPI на машинах, совместимых с Windows 8, когда используется Intel GPU. Его можно применить для AMD, Nvidia и других видеокарт, но на данный момент мы не имеем сообщений, что там сломалось управление подсветкой.
На данный момент ( спустя более, чем полгода ) мы интегрировали в ядро 4 патча:
Первый патч от Aaron Lu экспортирует ACPICA переменную из которой можно понять, считает ли BIOS, что мы совместимы с Windows 8.

Второй патч от Matthew Garret инициализирует ACPI видео, даже если он не будет использоваться после (что необходимо для управления подсветкой на ноутбуках Thinkpad).
Третий патч реализует обходной путь для i915. Берём на себя управление подсветкой, если прошивка думает, что мы имеем дело с Windows 8. Данный патч основывается на работе нескольких разработчиков, в том числе Matthew Garrett, Chun-Yi Lee, Seth Forshee и Aaron Lu.
Последний патч от Aaron Lu заставляет нас идти вслед за Windows 8, сообщив прошивке с помощью метода _DOS, что она не должна автоматически изменять яркость так, что яркостью было бы невозможно управлять через GUI.

Опубликованы рекомендации для разработчиков оборудования на базе AArch64 (64-битный ARM)

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

Наш товарищ, велосипедист и участник Fedora ARM SIG Jon Masters, опубликовал свои рекомендации разработчикам оборудования на базе AArch64. Он входит в Linaro Technical Steering Committee от Linaro Enterprise Group, поэтому можно быть уверенным, что его рекомендации вскоре будут стандартизированы.

В стандарте на AArch64 будет указываться, что оборудование должно использовать UEFI, грузиться без дополнительных загрузчиков, и использовать ACPI, а не Device Tree. В целом, это все повторяет архитектурные решения, использованные в референсной AArch64 платформе, спроектированной при его помощи. Больше не нужно будет возиться с U-Boot, а вместо этого придется возиться с UEFI. Одновременно с уходом в прошлое U-Boot, уходит и DTC (и это после того, как его только-только начали внедрять ARM-разработчики) - его даже немного жалко, т.к. это был первый существенный шаг к стандартизации ARM-оборудования. С другой стороны, это очень здорово, что уровень унификации ARM достигает уровня x86/x86_64 машин. Как сказал наш коллега, Adam Jackson, Linux, это не выбор, это жесткая стандартизация, - повторим за ним это еще раз.

К сожалению, Jon отключил комментации у себя в Google+, поэтому обсуждение его рекомендаций (высказанных в довольно приказной форме, что отметили некоторые разработчики) идет в ленте Google+ его коллеги по разработке ядра Linux, инженера Intel и участника Fedora, Arjan van de Ven.

CyanogenMod включил SELinux в последних сборках.

Вы уже могли слышать, что группой заинтересованных лиц велась работа по интеграции SELinux в Android, и он там уже добавлен с версии 4.2. Но существует много устройств, на которых Android 4.2 никогда не будет доступен по официальным каналам, да и на многих устройствах с версией 4.2 он тоже не будет работать (это зависит от производителя устройства, и его туманных и противоречивых маркетинговых соображений). Поэтому очень здорово, что проект CyanogenMod официально объявил, что в проекте начат переход на SELinux.

Уже отправлены на рассмотрение первые патчи. Пока SELinux работает в permissive режиме, так что устанавливайте, собирайте статистику, отправляйте в багтрекер проекта. Без тестирования пользователями тут не обойтись. Главное, не отключайте его, если какое-то кривое проприетарное приложение начнет жаловаться.

Вышел ModemManager 1.0

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

Aleksander Morgado, инженер дружественной нам компании Lanedo и активный пользователь Fedora со стажем, анонсировал долгожданный выход ModemManager 1.0.0, вспомогательный компонент NetworkManager, предназначенный для управления модемами и устройствами сотовой связи. Новость уже обсуждается на OpenNET и Linux.org.ru.

Russian Fedora на FrOSCon 2013 - 24-25 августа

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

Однако есть и вторая, немаловажная часть: одновременно с попыткой обозначить присутствие Fedora в России, мы стараемся напомнить и международному сообществу о существовании России (как обширного русскоязычного сообщества) в Fedora. Здесь мы тоже достигли заметных успехов - съездили на DevConf.cz, где пообщались с известными участниками Fedora (не раз и не два напомнив им о проблемах кириллических шрифтов и раскладок), присоединились к Fedora Ambassadors, ворвались в топ-листы команды Fedora QA - но останавливаться рано.

Вот мы и не останавливаемся, а спешим объявить что команда Russian Fedora (в моём лице) отправляетcя на `FrOSCon <http://www.froscon.de/en/home/>`__ - ежегодную конференцию разработчиков открытого и свободного ПО, проходящую 24 и 25 августа в городе Sankt Augustin около Кёльна, и не в качестве гостя, а как официальный представитель Fedora Project, чтобы принять участие в работе Fedora Dev Room и стенда Fedora.

Поэтому, во-первых, присоединяйтесь, Кёльн - это недалеко. Программа конференции не такая обширная как на DevConf.cz, но тем не менее есть много интересного. Во-вторых, ищите стенд Fedora, у нас будет самый лучший 3d-принтер и как всегда интересные разговоры. А в-третьих, если вы не можете поехать самостоятельно, но какие-то доклады вас особенно заинтересовали - напишите мне и я постараюсь поприсутствовать на этом докладе и написать развернутый отчет о происходящем.

Короткие новости

Инженер Red Hat, мэйнтейнер ряда подсистем ядра и участник Fedora, Hans de Goede объявил о выходе Fedora 19 для ARM-чипов Allwinner A10, A10s, A13, A20. Одной из важных новинок этого релиза является поддержка еще одного чипа - A20.

Участник Fedora Ruby SIG Bohuslav Kabrda официально стал мэйнтейнером python в Fedora и объявил о планах на перевод Fedora c python2 на python3:

  • Перевод Fedora с yum на dnf к 22 релизу
  • Полный переход на python3 в mock (при создании сборочной инфраструктуры не будет использоваться python2)
  • Переписывание (очередное!) Anaconda для работы с python3
  • Удаление python2 из LiveCD после перехода на dnf

После этого, Bohuslav предлагает сделать еще один радикальный шаг и переименовать python3 в python, а нынешний python в python2. Это потребует полной пересборки всех зависимых пакетов, и вероятно потребует переименования некоторых из них. Последнее предложение вызвало неодобрение некоторых участников Fedora, и вероятно не будет реализовано.

Ralph Bean анонсировал очередное инфраструктурное изменение. Наша инфраструктура переводится на использование открытого сервиса libravatar вместо закрытого и проприетарного gravatar. Мы предлагаем и другим сервисам рассмотреть возможность такого перехода.

Инженер Red Hat и участник Fedora и Debian David Airlie анонсировал у себя в блоге Virgil, виртуальный 3D-ускоритель для Qemu. Теперь Qemu полностью догнал по десктопным фичам VirtualBox и VMware, и вскоре, как только Virgil достигнет "production" уровня качества, они будут не нужны обычному пользователю. К сожалению, David ведет блог на LiveJournal, который в российском сегменте интернета отключают спецслужбы во время все учащающихся народных протестов в Москве. Так что если он у вас в какое-то время не открывается, не волнуйтесь - выходите на улицу, поучаствуйте в несанкционированных протестных мероприятиях, и попробуйте чуть позднее.

В то время, как Canonical все больше закрывает процесс разработки (аналитики Linux.org.ru убеждали, что это не закрытие, а "соборная модель" - таков уровень лучших из тамошних аналитиков), участники Fedora Project ведут разработку гласно и открыто. Немногие знают, что проект наших участников, coreutils, регулярно публикует отчеты не только о добавленных новых фичах, но и об отвергнутых и будущих. А в проектах участников ваших дистрибутивов достигнут такой уровень прозрачности? Ну, конечно, если в рамках вашего дистрибутива хоть что-то разрабатывается вообще.

В связи с грядущим переходом Debian на новую систему инициализации (пока все-еще есть интрига - на systemd, за переход на который голосует большинство, или на Upstart, который обеспечил бы хорошую совместимость с единственным успешным проектом на базе Debian, Ubuntu) многие участники проекта обращаются к нам, за советами, участвуют в разработке Fedora, чтоб протестировать функциональность их приложений с systemd. Среди последних - Daniel Pocock, участник Debian, с недавних пор участник Fedora, и разработчик reSIProcate, известный вам по его фиче из Fedora 19 - Federated VoIP. В своем блоге Daniel интересуется различными особенностями работы systemd и делится своими хотелками.

К сожалению страусиная позиция проекта Debian ("Debian is about choice"), которая затрудняет им выбирать ключевые компоненты, распыляя и так незначительные людские ресурсы на плохую поддержку конкурирующих решений, привела к тому, что выбор все-таки делается, но другими - Fedora или даже Canonical. База инсталляций Debian разъедается массовым переходом его пользователей на Ubuntu LTS, а его активные участники уходят в Fedora, чтоб иметь возможность разрабатывать и внедрять новые технологии в современном окружении. Это все приводит к дальнейшей деградации качества разрабатывающихся веток дистрибутива, которую тестируют все меньше технически грамотных людей (как известно все бета-тестеры у нас, а в других дистрибутивах - что останется).

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

Как известно, все высокотехнологичные разработки происходят в Fedora, чтоб впоследствии работать на базе RHEL (или бесплатного производного дистрибутива). В частности, в разработке medical imaging Fedora гораздо популярнее, чем конкурирующие дистрибутивы (в отличие от игровой статистики Steam, где хорошо виден дисбаланс, довольно предсказуемый, если учесть кто является пользователями различных дистрибутивов). Одной из ведущих коммерческих компаний, предлагающей услуги на базе собственного opensource стека библиотек и приложений, является Kitware. Недавно инженеры этой компании с радостным удивлением узнали, что бОльшая часть их инструкций по установке их ПО на Fedora/RHEL устарела, и почти все необходимое ПО уже доступно из коробки.

Кстати, имейте в виду - присоединяясь к Fedora вы, возможно, спасаете себя от врачебной ошибки из-за неправильно работающего дорогостоящего медицинского оборудования. А ваш самосборный дистрибутив умеет из коробки обрабатывать фотоснимки с томографа?

И опять - новые "фичи" Fedora 20

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

Теперь это уже не фичи, а "изменения", но пока по привычке называется по-старому. Итак, были анонсированы:

Новые "фичи" Fedora 20

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

Начиная с 20го релиза процесс принятия фич сильно изменен. Теперь FESCo голосует лишь за фичи, которые влияют на систему в целом (например, смена версии GCC или Glibc), а остальные нововведения теперь называются "self-contained change" и просто анонсируется в списке рассылки devel@lists.fedoraproject.org. Это нововведение должно упростить работу FESCo и привлечь больше людей к обсуждению фич. Новая система принятия фич пока обкатывается, но бюрократия бюрократией, а народ уже вовсю предлагает улучшения и изменения. Уже были анонсированы:
  • Включение Ryu, сетевой операционной системы, предназначенной для создания и управления программно-конфигурируемых сетей (например, для OpenStack). Эту фичу планировали включить в Fedora 19, но тогда не уложились в срок.

  • Обновление Glibc до версии 2.18.

  • Наконец-то! Перевод ARM из вторичных в основные архитектуры.

    Над этой фичей работали начиная с Fedora 15 и первоначально планировали закончить к Fedora 18, но не удалось в срок решить ряд организационных и технических проблем. Даже сейчас обсуждение этой фичи идет непросто, и высказываются различные опасения - от увеличения времени сборки, до анархии среди ARM-оборудования, несоответствия доступных фич таковым на нынешних основных системах, и проблем с виртуализацией. Но когда-то придется начать, так что может и к лучшему, что начнут пораньше, с некоторыми нерешенными проблемами. Если фичу примут, то основной архитектурой будет armv7hl. Популярный мини-компьютер Raspberry Pi спроектирован с использованием более старой архитектуры, так что на нем будет работать лишь специализированная сборка).

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

  • Включение Hadoop, известной платформы для решения Big Data задач.

  • Оживилась работа над системой управления сертификатами безопасности.

    Сейчас почти каждое приложение управляет ими по-своему и хранит их в своих местах. Хочется централизовать механизм работы с ними (не теряя возможность изолировать какие-то приложения в системе управления сертификатами) - это принесет ряд очевидных улучшений. Мы не ожидаем полного решения общей задачи к 20му релизу, но надеемся сделать еще один важный шаг в нужную сторону. В этот раз будет интегрирован общий инструментарий и начат процесс перевода приложения на его использование.

  • KDE переводится с KDM на SDDM.

    Теперь дисплейный менеджер по умолчанию будет SDDM. Желающие будут иметь возможность установить KDM, но это не рекомендуется.

  • KDE 4.11

  • Восстановление работы kexec/kdump на системах с secureboot.

    Сейчас работа kexec/kdump при активированном secureboot запрещена.

  • Fedora Haskell SIG работает над включением веб-фреймворка Yesod, написанного, как нетрудно догадаться на Haskell.

  • Поддержка архитектуры ARM в libvirt на системаx x86/x86_64.

    Сейчас запуск виртуальной машины ARM на архитектуре x86 с помощью libvirt невозможен - только вручную.

  • И еще одна фича, относящаяся к виртуализации - управление снапшотами виртуальных машин в virt-manager.

    Вся необходимая функциональность уже добавлена в qemu и libvirt, и осталось доработать GUI.


На подходе еще несколько фич - ждите!

Rust, Copr и изменения в инфраструктуре

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

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

Как известно, в Fedora не поощряется создание сторонних репозиториев (т.н. PPA).

Для любого DevOps не составит большого труда назвать несколько причин, по которым это плохая идея. Однако, иногда очень хочется, и вот для таких случаев в Fedora есть персональные репозитории, использовать которые официально не рекомендуется. Создание и управление этими репозиториями было организовано очень неудобно и требовало многих ручных действий. Поэтому было решено написать с нуля специальный сервис для создания и управления официально нерекомендуемыми персональными репозиториями. Встречайте copr. Это полнофункциональная сборочная система, позволяющая подключать сторонние репозитарии, использовать уже собранные в copr пакеты (т.н. "chain builds"), и дающая пользователям больше свободы, чем жестко зарегулированный Koji. Получилось, что это не замена Koji, а скорее аналог OBS. Пока система находится в бета-тестировании, но скоро о ней объявят более официально. Основную работу по созданию сервиса выполнили Seth Vidal и участник Fedora Ruby SIG Bohuslav Kabrda, который и презентовал его широкой публике.

Copr уже реально используется. Например, с его помощью пользователям Fedora сделана доступной тестовая сборка языка Rust для Fedora 18 и Rawhide (Lubomir Rintel собрал для Fedora 19 - вот такой вот разнобой с этими PPA).

Ralph Bean продолжает продолжать улучшать инфраструктуру, добавляя в нее элементы соцсети. В строй введен новый узел - Tagger, с помощью которого можно присваивать тэги различным пакетам. Теперь начинающие пользователи с первого взгляда на облако тэгов смогут понять, что пакет perl-Params-Validate имеет отношение к Perl и Validation. Ralph очень горд этим прорывом в usability, призывает всех его попробовать и надеется на появление специализированного приложения, входящего в состав GNOME и делающего сервис еще более доступным для начинающих пользователей.

Раз уж заговорили об интеграции, то уже известная вам Fedora Infrastructure message bus получила новый узел - Simon Chopin, участник GSoC 2013 от коммьюнити Debian, в рамках проекта по соединению различных компонентов проекта Debian с помощью fedmsg, разрабатывает совместимый с ним источник событий от различных сервисов Debian. Дух захватывает от открывающихся перспектив междистрибутивного взаимодействия! Автоматизированное уведомление о багах-дупликатах, сообщения о новых патчах, да мало ли что еще! И раз уж заговорили об междистрибутивной интеграции, то видится отличный кандидат из числа сервисов, которые должны быть подключены (и события от которых должны обрабатываться) в Fedora Infrastructure message bus. Это Upstream Tracker, созданный отечественными разработчиками из ROSA.

Среди участников Fedora уже обсуждаются возможности abi-compliance-checker, другой разработки инженеров компании ROSA, и подключение Web-сервиса со стандартизированным API к Fedora Infrastructure для автоматического мониторинга вносимых изменений и раннего предупреждения ошибок совместимости звучит хорошей идеей.

К сожалению, на все рук не хватает - если вы свободны и желаете помочь, то мы будем только рады. Например, недавно мы с огорчением узнали, что ABRT, автоматическая "собиралка" ошибок в прикладном ПО, работает очень топорно и назначает ошибки в Bugzilla порой совсем не на те компоненты, что надо. Вроде-бы это не так уже и тяжело исправить, если есть свободное время. Это выглядит, как задача начального уровня (студент, интерн, junior developer, и т.п.) Ну и раз уж заговорили о студентах, Fedora Security SIG решила поменять свое назначение.

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