О пользе свободного времени для локализации
Опубликовано 29.3.2012 01:48 пользователем mama-sun
Сегодня вечером Кевин Раймонд (Kévin Raymond) сообщил в рассылке для переводчиков об обновлении содержимого сайта fedoracommunity.org, на котором собраны сайты всех региональных сообществ Fedora. Никаких кардинальных изменений, но тем не менее модули для перевода пополнились новыми строками. Поскольку материал для перевода очень простой и к тому же у меня выдался спокойный вечер, я быстренько перевела новые строки.
Эту заметку можно было бы не писать, потому что труд пустяковый, но мне хотелось отметить такую простую, но важную возможность помочь свободному проекту. Нужно только время и желание :) Конечно, далеко не все материалы для перевода просты, большиство требует знаний и подготовки. Но если внимательно следить за проектом, то всегда можно найти что-нибудь подходящее.
Так что присоединяйтесь!
(Если что, команда локализации тусуется здесь , а о том, как к ней присоединиться, написано здесь).
Эту заметку можно было бы не писать, потому что труд пустяковый, но мне хотелось отметить такую простую, но важную возможность помочь свободному проекту. Нужно только время и желание :) Конечно, далеко не все материалы для перевода просты, большиство требует знаний и подготовки. Но если внимательно следить за проектом, то всегда можно найти что-нибудь подходящее.
Так что присоединяйтесь!
(Если что, команда локализации тусуется здесь , а о том, как к ней присоединиться, написано здесь).
29 марта: Тестовый день Gnome Shell Software Rendering
Опубликовано 28.3.2012 22:16 пользователем bookwar
Приглашаем принять участие в завтрашнем тестировании работы Gnome Shell на системах без аппаратной поддержки 3D.
Тестирование очень простое: достаточно загрузить Live-образ и проверить, что запустился Gnome Shell.
К тестированию приглашаются:
- старое x86-железо, в частности, процессоры не поддерживающие SSE2 (AMD Geode и pre-Athlon-64, Intel pre-Pentium-4 и т.п.),
- ARM, PowerPC, и прочие не x86-архитектуры,
- виртуальные машины, отличные от KVM,
- старые видеокарты: Intel 8xx, Radeon pre-R300, NVIDIA pre-GeForce-6,
Инструкция по участию: Test Day: 2012-03-29 Gnome Shell Software Rendering
Не забывайте отписываться о результатах на вики-странице!
Роспуск управляющего комитета Glibc
Опубликовано 27.3.2012 15:35 пользователем Peter Lemenkov
Сегодня было объявлено о самороспуске управляющего комитета Glibc. Признав, что текущая модель управления разработкой уже не отвечает требованиям времени, было единогласно решено самораспуститься и передать управление разработкой в руки сообщества (благо оно вокруг Glibc сформировалось очень опытное). Мы ждем больше подробностей в ближайшее время, но уже сейчас отзывы очень положительные.
Поддержка NVIDIA Kepler в Nouveau
Опубликовано 24.3.2012 12:39 пользователем Peter Lemenkov
Phoronix сообщает, что начальная поддержка новейшей видеоархитектуры от NVIDIA - Kepler, была добавлена в Nouveau инженерами Red Hat и участниками проекта Fedora David Airlie и Ben Skeggs (который также активно участвует в проекте Debian) спустя считанные часы после официального анонса компанией-производителем. Пока, конечно, там ничего особо нет, но как минимум, карта теперь не будет работать под управлением совершенно примитивного vesa-драйвера. И это - без какой-либо техдокументации от NVIDIA. Сравните с ATI/AMD картами, которые, несмотря на имеющуюся документацию и официальную поддержку от производителя, получают ту же базовую функциональность спустя недели после официального анонса. Еще для сравнения с ATI - Intel стараются реализовывать поддержку оборудования в драйверах до его официального анонсирования.
Проблемы с UEFI на Macbook Air.
Опубликовано 24.3.2012 11:51 пользователем Peter Lemenkov
Активный участник проекта Fedora и работник Red Hat, Matthew Garrett, продолжает продолжать серию статей про проблемы с UEFI. В этот раз он натолкнулся на удивительную проблему - UEFI позволяет прошивке wi-fi карты изменять память ядра напрямую, без участия процессора (DMA). Прочитайте статью целиком, это очень увлекательное чтение о том, как сложно было поймать за руку firmware за таким хулиганством. Кстати, предлагаем пофантазировать, какие возможности открываются с такой функциональностью UEFI.
Darkserver и работа над ошибками в Fedora
Опубликовано 24.3.2012 10:49 пользователем Peter Lemenkov
Участником Fedora и работником Red Hat Kushal Das было официально объявлено о введении в строй Darkserver, специального сервиса, для онлайн-хранения полной информации о сборке приложения. На этом сервисе по так называемому build-id будут доступны ссылки на логи сборки, debug-информацию и собранные RPM-пакеты в Koji.
Наверное все знают или догадываются, что в Open Source одной из важнейших ситуаций в общении между разработчиками и пользователями, является исправление ошибок. В идеальном мире пользователь, столкнувшись с ошибкой, изучает ситуацию, при которой она возникла, запускает дебаггер, проводит пошаговую отладку, находит ошибку, тратит некоторое время на пересборки и подготовку патча с исправлением, регистрируется на feature/issue-трекере (если уже не зарегистрирован), подробно сообщает об ошибке и условиях, при которой она возникает, и прилагает исправление. Разработчики дружелюбно приветствуют его, успешно воспроизводят ошибку по описанию и с радостью принимают его исправление. В этой-же реальности все намного сложнее, болезненнее и менее захватывающе.
Зачастую пользователь не умеет пользоваться отладчиком, так что разбираться с логами отладки и бэктрейсом падения приходится мэйнтейнеру. Для этого хорошо бы как-то получить сами логи, а, значит, у пользователя должен быть доступ к отладочной информации. Пользователь может просто не желать или даже не иметь возможности скачивать и ставить сотни мегабайт debuginfo пакетов ради нахождения причины ошибки, а готов предоставить лишь coredump-файл. Пользователь может пересобрать пакет сам, поставить его откуда-то еще, со сторонних репозиториев, а значит надо еще удостовериться, сможет-ли мэйнтейнер узнать, является ли приложение входящим в его зону ответственности или нет?
Для решения этих и некоторых других задач, у Fedora было уже довольно много сделано. Были сделаны репозитории, хранящие дополнительную отладочную информацию (debuginfo пакеты), был сделан метод автоматического уведомления мэйнтейнеров об ошибках (программа abrt), была реализована "фича" по добавлению BuildID в приложения, чтоб автоматически сопоставлять coredump, версию пакета и debuginfo. Теперь добавлен еще один элемент - сервис, с которого, с помощью API, можно получить информацию о приложении, имея лишь coredump, оперируя с backtrace или производя манипуляции с самим приложением. С помощью этой информации, можно указать на информацию в Koji, о пакете, в который входит приложение, создавшее coredump.
К сожалению, этого еще мало, хотя уже очень много по сравнению с куцыми возможностями работы над ошибками в проприетарных системах. Несмотря на то, что все кирпичики уже есть, полноценной распределенной системы анализа ошибок еще нет. Пользователь до сих пор нуждается в скачивании debuginfo пакетов - например, если он желает разбираться с ошибкой лично, а не отправлять логи падения на сервер (в которых, так как это моментальный снимок "внутренностей" программы, может содержаться его личная информация). Для преодоления этой сложности ранее были предложены некоторые решения, например специальная файловая система на базе FUSE - DebuginfoFS, но они так и не были доведены до конца. Кстати, это хорошая тема для студента-участника GSoC!
Вообще, проблема принятия пользовательских отчетов об ошибках и реакции на них, это то, что отличает серьезное коммьюнити от кучки тинейджеров форкающих форк форка форка. Например, понятно, что для успешного исправления ошибки, хорошо бы чтоб разработчик смог ее воспроизвести. Это значит, что у разработчика должна быть точно такая же среда, как и у пользователя. А как этого добиться, если у пользователя туча "USE-флагов", "система настроена под себя", "система оптимизирована пересборкой с -O99 под мою архитектуру" и т.п.? Можно, конечно, исправить проблему и в этом случае, но каков тогда будет КПД исправления? В дистрибутивах с повторяющимися результатами, с идентичными бинарными сборками, исправление сразу затронет всех пользователей продукта, а в системах "настроенных под себя" - может быть ограничено лишь некоторой группой пользователей. Опять-же, чем многочисленнее и/или технически грамотнее количество пользователей, тем более точно будет описана проблема, тем четче будут ответы на вопросы разработчика, что может значительно ускорить исправление. А как быть, если мэйнтейнер приложения в твоем дистрибутиве никогда им сам не пользовался, не знает, как оно устроено, и просто добился того, что оно как-то собралось? В некоторых дистрибутивах есть мэйнтейнеры, которые на добровольных началах управляют сотнями пакетов приложений (порой они еще и по своей наивности гордятся этим). А ведь в общем случае, это значит, что в целом ими производится некачественная работа над ошибками. Еще надо отметить, что некоторые, ставшие популярными среди начинающих, "простые" дистрибутивы в явном виде сообщают, что сообщения об ошибках надо посылать сразу в upstream, т.е. полностью отстраняются от участия в исправлении. Удивительно, но их фанбои порой громко кричат о "безглючности" их "простого" и "передового" дистрибутива "с самым свежим софтом". Конечно, если закрыть глаза на проблему, то она сразу-же исчезнет.
Наверное все знают или догадываются, что в Open Source одной из важнейших ситуаций в общении между разработчиками и пользователями, является исправление ошибок. В идеальном мире пользователь, столкнувшись с ошибкой, изучает ситуацию, при которой она возникла, запускает дебаггер, проводит пошаговую отладку, находит ошибку, тратит некоторое время на пересборки и подготовку патча с исправлением, регистрируется на feature/issue-трекере (если уже не зарегистрирован), подробно сообщает об ошибке и условиях, при которой она возникает, и прилагает исправление. Разработчики дружелюбно приветствуют его, успешно воспроизводят ошибку по описанию и с радостью принимают его исправление. В этой-же реальности все намного сложнее, болезненнее и менее захватывающе.
Зачастую пользователь не умеет пользоваться отладчиком, так что разбираться с логами отладки и бэктрейсом падения приходится мэйнтейнеру. Для этого хорошо бы как-то получить сами логи, а, значит, у пользователя должен быть доступ к отладочной информации. Пользователь может просто не желать или даже не иметь возможности скачивать и ставить сотни мегабайт debuginfo пакетов ради нахождения причины ошибки, а готов предоставить лишь coredump-файл. Пользователь может пересобрать пакет сам, поставить его откуда-то еще, со сторонних репозиториев, а значит надо еще удостовериться, сможет-ли мэйнтейнер узнать, является ли приложение входящим в его зону ответственности или нет?
Для решения этих и некоторых других задач, у Fedora было уже довольно много сделано. Были сделаны репозитории, хранящие дополнительную отладочную информацию (debuginfo пакеты), был сделан метод автоматического уведомления мэйнтейнеров об ошибках (программа abrt), была реализована "фича" по добавлению BuildID в приложения, чтоб автоматически сопоставлять coredump, версию пакета и debuginfo. Теперь добавлен еще один элемент - сервис, с которого, с помощью API, можно получить информацию о приложении, имея лишь coredump, оперируя с backtrace или производя манипуляции с самим приложением. С помощью этой информации, можно указать на информацию в Koji, о пакете, в который входит приложение, создавшее coredump.
К сожалению, этого еще мало, хотя уже очень много по сравнению с куцыми возможностями работы над ошибками в проприетарных системах. Несмотря на то, что все кирпичики уже есть, полноценной распределенной системы анализа ошибок еще нет. Пользователь до сих пор нуждается в скачивании debuginfo пакетов - например, если он желает разбираться с ошибкой лично, а не отправлять логи падения на сервер (в которых, так как это моментальный снимок "внутренностей" программы, может содержаться его личная информация). Для преодоления этой сложности ранее были предложены некоторые решения, например специальная файловая система на базе FUSE - DebuginfoFS, но они так и не были доведены до конца. Кстати, это хорошая тема для студента-участника GSoC!
Вообще, проблема принятия пользовательских отчетов об ошибках и реакции на них, это то, что отличает серьезное коммьюнити от кучки тинейджеров форкающих форк форка форка. Например, понятно, что для успешного исправления ошибки, хорошо бы чтоб разработчик смог ее воспроизвести. Это значит, что у разработчика должна быть точно такая же среда, как и у пользователя. А как этого добиться, если у пользователя туча "USE-флагов", "система настроена под себя", "система оптимизирована пересборкой с -O99 под мою архитектуру" и т.п.? Можно, конечно, исправить проблему и в этом случае, но каков тогда будет КПД исправления? В дистрибутивах с повторяющимися результатами, с идентичными бинарными сборками, исправление сразу затронет всех пользователей продукта, а в системах "настроенных под себя" - может быть ограничено лишь некоторой группой пользователей. Опять-же, чем многочисленнее и/или технически грамотнее количество пользователей, тем более точно будет описана проблема, тем четче будут ответы на вопросы разработчика, что может значительно ускорить исправление. А как быть, если мэйнтейнер приложения в твоем дистрибутиве никогда им сам не пользовался, не знает, как оно устроено, и просто добился того, что оно как-то собралось? В некоторых дистрибутивах есть мэйнтейнеры, которые на добровольных началах управляют сотнями пакетов приложений (порой они еще и по своей наивности гордятся этим). А ведь в общем случае, это значит, что в целом ими производится некачественная работа над ошибками. Еще надо отметить, что некоторые, ставшие популярными среди начинающих, "простые" дистрибутивы в явном виде сообщают, что сообщения об ошибках надо посылать сразу в upstream, т.е. полностью отстраняются от участия в исправлении. Удивительно, но их фанбои порой громко кричат о "безглючности" их "простого" и "передового" дистрибутива "с самым свежим софтом". Конечно, если закрыть глаза на проблему, то она сразу-же исчезнет.
Сбор предложений вариантов названия для Fedora 18
Опубликовано 20.3.2012 13:34 пользователем mama-sun
Сообщество Fedora не стоит на месте и уже потихоньку начинает подготовку к Fedora 18. Традиционно первым шагом является выбор кодового названия релиза. О том, как это происходит, я уже писала в предверии Fedora 15 (см. пост).Как обычно, любой желающий может предложить свой вариант на специальной странице в вики, перед этим обязательно(!) ознакомившись с правилами. Кроме правил и воображения вас ничто не должно ограничивать!
Интересно посмотреть, кто будет соревноваться с Beefy Miracle :)
Ну а историю названий Fedora можно посмотреть здесь.
UPD. Названия можно будет добавлять до 27 марта включительно.
FESCo отменил переход на Journald
Опубликовано 20.3.2012 00:25 пользователем Peter Lemenkov
На прошедшем сегодня собрании FESCo начали принимать "фичи" для Fedora 18. Среди принятых:
- Одно из больших планирующихся изменений, это ARM будет основной архитектурой. Ошибка сборки пакета на ней теперь будет блокировать включение его в Fedora (как это обстояло с PPC и PPC64 архитектурами раньше).
- Обновление pcre до версии 8.30. С этой версии в pcre доступна поддержка UTF-16.
- Поддержка режима HotSpot в Networkmanager.
- Реорганизация метаданных для yum. Сейчас они хранятся в виде одного большого comps-файла, что невыгодно в ряде случаев.
- Обновление RPM до версии 4.10. Это, в основном, исправления ошибок и оптимизации, так-что обычные пользователи скорее всего ничего и не заметят.
- Перемещение мандата kerberos из /tmp в /run/user/$USERNAME
- .
Fedora и Google Summer of Code 2012
Опубликовано 17.3.2012 01:17 пользователем Peter Lemenkov
Только что анонсировали утвержденный список проектов, которые приняты в качестве организаций в Google Summer of Code 2012. В этот раз участвует 70 организаций, среди которых и Fedora. Дружный коллектив Russian Fedora всячески рекомендует начинающим и не очень разработчикам, которые на этот сезон еще учатся, и которым уже есть 18 лет, попробовать поучаствовать в этом проекте. Если вашу заявку примут, и если вы добьетесь успеха, то вы получите не только 5000 долларов, но и уникальный опыт разработки в темпе, близком к вашему (но чуть-чуть ускоренном вашим ментором), при участии опытных старших товарищей.
Для тех, кто еще не слышал, формат вашего участия таков. Сначала, вы выбираете проект, в котором вы можете принять участие. Не бойтесь того, что из опыта у вас за плечами только желание этот опыт получить - необязательно досконально во всем разбираться. Ключевой момент GSoC, это обучение, а не платная разработка, так что не бойтесь, что вы вчера узнали, что такое Apache, PHP и GCC, а уже хотите начать переписывать весь интернет. Еще не бойтесь, что вы так и не узнали, что такое GCC - в рамках проекта нужны не только системные программисты, но, например, web-разработчики. Еще такой момент - лучше выбрать проект, который вы лично используете, так как гораздо больше мотивации исправлять то, с чем лично сталкиваешься, чем выполнять какую-то абстрактную задачу.
Итак, вы выбрали проект. Теперь немедленно регистрируйтесь на сайте Google Summer of Code и срочно ищите "менторов" с помощью средств коммуникаций, принятых в выбранном проекте (список рассылки, джаббер-конференция, ирка). Менторы, это те, кто будет подталкивать вас, когда у вас кончится эйфория и вдохновение, и кто будет оценивать вашу работу. Они же будут помогать вам своими советами и учить вас взаимодействию в среде opensource разработчиков. Практика показывает, что по ряду причин, именно этого "инжиниринга" процесса разработки и не хватает русскоязычным разработчикам, так что это очень и очень ценно. Выйдя на контакт с потенциальными менторами вы сообщаете им о своем желании и рассказываете о своей идее, как можно улучшить их проект. Они соглашаются с вами, соглашаются с оговорками или полностью разбивают вашу идею (предлагая какие-то свои). Здесь есть момент произвола и сильное влияние человеческого фактора, что неизбежно.
Предположим, переговоры прошли нормально, и вы договорились c потенциальным ментором об идее, которую будете реализовывать. На проект Google выделяет несколько "слотов" (в зависимости от неких непубличных оценок значимости проектов внутри Google), и теперь вы конкурируете с другими студентами за слоты. Вас и вашего ментора будут интервьюировать другие представители выбранного проекта, чтоб затем открыто и публично решить, какие-же предложения выглядят более привлекательными для участия в GSoC. Ваша заявка может выглядеть техничнее прочих, но, например, у других представителей проекта может по разным причинам сложиться впечатление, что вы и ваш ментор не сумеете закончить ее в срок. Невыполненные в срок заявки серьезно понижают шансы проекта попасть в следующий GSoC, так что тут "ничего личного". У разных проектов есть свои варианты оценки предложения - от реальных тестовых заданий, которые выбираются из числа "janitorial" задач, до простого общения через feature/issue-tracker.
Если вашу задачу одобрили, и она заняла слот в рамках проекта, то тут начинается самая простая фаза - вы пишете код, настраиваете уже имеющиеся программы, проводите анализ. На этом этапе вам помогает ментор с инфраструктурой, с системой контроля версий, с issue tracker. Он дает рекомендации по желаемому рабочему графику, оценивает скорость и точность выполнения, общается с вами. По прошествии некоторого времени вы завершаете задачу, получаете деньги и заносите строчку в резюме, прикалывая туда и рекомендации от вашего ментора.
Все очень просто - проще, чем, например, устроиться на работу в Яндекс, VKontakte, Facebook или Google. Для участия крайне желательно уметь письменно общаться на английском, хотя-бы с акцентом, так как общение, это очень важный фактор в разработке, а общаться придется на английском. Есть проекты, где традиционно есть русскоязычные менторы, но тем не менее, очень поможет знание международного языка. Насчет русскоязычных менторов, мы советуем обратиться к нам, в Fedora, к Alexandre Prokoudine и LinuxGraphics, к коллективу GIS-Lab. Напоследок, прочитайте подробный отчет от участника GSoC о том, с чем ему пришлось столкнуться.
Мы желаем вам удачи, какой бы вы ни выбрали проект для участия. Помните, вы не только получаете возможность улучшить открытые проекты под руководством специалистов в своей предметной области, но и вашу работу профинансируют. Немногие участники Open Source движения могут припомнить столь тепличных условий для начала карьеры разработчика.
Для тех, кто еще не слышал, формат вашего участия таков. Сначала, вы выбираете проект, в котором вы можете принять участие. Не бойтесь того, что из опыта у вас за плечами только желание этот опыт получить - необязательно досконально во всем разбираться. Ключевой момент GSoC, это обучение, а не платная разработка, так что не бойтесь, что вы вчера узнали, что такое Apache, PHP и GCC, а уже хотите начать переписывать весь интернет. Еще не бойтесь, что вы так и не узнали, что такое GCC - в рамках проекта нужны не только системные программисты, но, например, web-разработчики. Еще такой момент - лучше выбрать проект, который вы лично используете, так как гораздо больше мотивации исправлять то, с чем лично сталкиваешься, чем выполнять какую-то абстрактную задачу.
Итак, вы выбрали проект. Теперь немедленно регистрируйтесь на сайте Google Summer of Code и срочно ищите "менторов" с помощью средств коммуникаций, принятых в выбранном проекте (список рассылки, джаббер-конференция, ирка). Менторы, это те, кто будет подталкивать вас, когда у вас кончится эйфория и вдохновение, и кто будет оценивать вашу работу. Они же будут помогать вам своими советами и учить вас взаимодействию в среде opensource разработчиков. Практика показывает, что по ряду причин, именно этого "инжиниринга" процесса разработки и не хватает русскоязычным разработчикам, так что это очень и очень ценно. Выйдя на контакт с потенциальными менторами вы сообщаете им о своем желании и рассказываете о своей идее, как можно улучшить их проект. Они соглашаются с вами, соглашаются с оговорками или полностью разбивают вашу идею (предлагая какие-то свои). Здесь есть момент произвола и сильное влияние человеческого фактора, что неизбежно.
Предположим, переговоры прошли нормально, и вы договорились c потенциальным ментором об идее, которую будете реализовывать. На проект Google выделяет несколько "слотов" (в зависимости от неких непубличных оценок значимости проектов внутри Google), и теперь вы конкурируете с другими студентами за слоты. Вас и вашего ментора будут интервьюировать другие представители выбранного проекта, чтоб затем открыто и публично решить, какие-же предложения выглядят более привлекательными для участия в GSoC. Ваша заявка может выглядеть техничнее прочих, но, например, у других представителей проекта может по разным причинам сложиться впечатление, что вы и ваш ментор не сумеете закончить ее в срок. Невыполненные в срок заявки серьезно понижают шансы проекта попасть в следующий GSoC, так что тут "ничего личного". У разных проектов есть свои варианты оценки предложения - от реальных тестовых заданий, которые выбираются из числа "janitorial" задач, до простого общения через feature/issue-tracker.
Если вашу задачу одобрили, и она заняла слот в рамках проекта, то тут начинается самая простая фаза - вы пишете код, настраиваете уже имеющиеся программы, проводите анализ. На этом этапе вам помогает ментор с инфраструктурой, с системой контроля версий, с issue tracker. Он дает рекомендации по желаемому рабочему графику, оценивает скорость и точность выполнения, общается с вами. По прошествии некоторого времени вы завершаете задачу, получаете деньги и заносите строчку в резюме, прикалывая туда и рекомендации от вашего ментора.
Все очень просто - проще, чем, например, устроиться на работу в Яндекс, VKontakte, Facebook или Google. Для участия крайне желательно уметь письменно общаться на английском, хотя-бы с акцентом, так как общение, это очень важный фактор в разработке, а общаться придется на английском. Есть проекты, где традиционно есть русскоязычные менторы, но тем не менее, очень поможет знание международного языка. Насчет русскоязычных менторов, мы советуем обратиться к нам, в Fedora, к Alexandre Prokoudine и LinuxGraphics, к коллективу GIS-Lab. Напоследок, прочитайте подробный отчет от участника GSoC о том, с чем ему пришлось столкнуться.
Мы желаем вам удачи, какой бы вы ни выбрали проект для участия. Помните, вы не только получаете возможность улучшить открытые проекты под руководством специалистов в своей предметной области, но и вашу работу профинансируют. Немногие участники Open Source движения могут припомнить столь тепличных условий для начала карьеры разработчика.
15 марта: день тестирования GNOME Shell в Fedora
Опубликовано 15.3.2012 13:01 пользователем mama-sun
Начиная с сегодняшнего дня команда Fedora проводит тестирования GNOME Shell и дополнений к GNOME.
Тестировать предлагается работоспособность всех задействованных в Fedora 17 возможностей оболочки GNOME 3, а так же доступных дополнений. К тестированию приглашаются пользователи GNOME независимо от используемого дистрибутива - проект Fedora передаёт все исправления в upstream, поэтому выявленные в рамках мероприятия ошибки, позволят дополнительно стабилизировать готовящийся релиз GNOME 3.4.
- Официальная страница тестового дня
- Live-образы:
- i686 - контрольная сумма SHA256SUM
5a0f70bd863f95e016c93e01556c058e4faea63c04dc1a3e56ec25ecd7cecbd1
- x86_64 - контрольная сумма SHA256SUM
4ee9523cf832043fe73cd57743dacb82f5ae4240d98016a4ccd12314724dfd30
- i686 - контрольная сумма SHA256SUM
Тестировать предлагается работоспособность всех задействованных в Fedora 17 возможностей оболочки GNOME 3, а так же доступных дополнений. К тестированию приглашаются пользователи GNOME независимо от используемого дистрибутива - проект Fedora передаёт все исправления в upstream, поэтому выявленные в рамках мероприятия ошибки, позволят дополнительно стабилизировать готовящийся релиз GNOME 3.4.
Страницы
- « первая
- ‹ предыдущая
- …
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- …
- следующая ›
- последняя »
Обменная кнопка проекта: 