Проект Buildroot перешёл на современный баг-трекер на базе gitlab.com, и теперь сообщать о найденных проблемах и делать предложения станет проще. Отправка коммитов по-прежнему производится через списки рассылки, как, например в ядре Linux.

Для справки. Проект Buildroot наравне с Yocto является одной из систем для создания кастомных операционных систем на базе Linux. Уже вышло множество материалов о том, как собрать свой Linux. Попробуйте, это весело.

>>> Источник: старый баг-трекер проекта Buildroot на busybox.net

github-backup — программа для скачивания с GitHub данных, связанных с клонированным репозиторием: форков, содержимого багтрекера, комментариев, викисайтов, milestones, pull requests, списка подписчиков.

Увидев, что даже произошедшее с программой youtube-dl, когда её репозиторий заблокировали вместе с багрекером и pull request’ами, мало кого подтолкнуло к отказу от зависимости от GitHub — даже не разработчика самой youtube-dl — Джои Хесс решил, что резервное копирование чего-либо, кроме исходного кода, пользователям GitHub неинтересно.

При этом сами git-репозитории исходного кода на GitHub архивируются автоматически сайтом https://softwareheritage.org/, а сторонние репозитории можно добавить туда только вручную, но эта функция глючит, да ещё и не поддерживает автоматическое обновление копий. Получается парадоксальная проблема: средний пользователь GitHub не думает о резервном копировании, но получает его, а для тех, кто использует свой сервер, может быть, именно для надёжности, автоматического архивирования не происходит, даже если их ПО пользуются.

Сайт и репозиторий github-backup пока будут доступны по адресу https://github-backup.branchable.com/, на который ссылка вон там, но с 29 декабря ей нужен новый мейнтейнер.

>>> Сообщение о прекращении поддержки

Вышла и потихоньку развивается бета-версия системы учёта технического долга. Система сделана в виде баг-трекера, который устанавливается параллельно основному трекеру проекта (jira, redmine и т.д.) на любое устройство с доступом в сеть (тестовый сервер, ноутбук разработчика, кофеварка и т.п.). Однако, вместо времени, использованного для решения проблемы, она учитывает время, потерянное в силу того, что проблема всё ещё не решена.

Идея такова: команда разработчиков заводит тикеты, описывающие те или иные проблемы разрабатываемого продукта (плохой код, недостаток документации, проблемы производительности, убогость внутреннего инструментария и т.д.), после чего логирует время и предлагает возможные решения. Далее, в зависимости от вменяемости заказчика/менеджера, тикеты либо вносятся уже в нормальный багтрекер, либо тихой сапой включаются в «официальные» фичи.

Поддерживаемые на данный момент функции:

• Заведение тикетов, смена статусов, комментарии;
• Теги а-ля stackoverflow;
• Учёт потраченного времени;
• Предложения решений (solution proposals) с оценкой времени на реализацию;
• Персональная настраиваемая лента событий и слежение за тикетами;
• Разнообразные отчёты, в т.ч. по тикетам, из-за которых уже потеряли больше времени, чем нужно на их исправление.

Проект реализован на языке Perl и использует базу данных sqlite. По ссылке содержится подробная инструкция по установке, скриншоты, текущий вишлист и всё такое.

>>> Гитхаб

Спустя десять лет выпущена новая версия GNU GNATS. Команда разработчиков выражает благодарность Alexandros Manoussakis из Juniper Networks, который проделал значительную работу.

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

Основные изменения:

( читать дальше... )

>>> Подробности

JIRA OpenJDK стала открытой для всех: http://bugs.openjdk.java.net

В старом багтрекере SUN нумерация была сквозной, независимой от проекта. В JIRA всё устроено немного иначе: каждый проект имет некоторый префикс (в нашем случае это «JDK»), после которого идёт дефис и номер бага. Соответственно то, что раньше в bugs.sun.com было багом 4459438 в JBS получило номер JDK-4459438 (cкриншот тикета).

Это событие давно ожидалось в Java-сообществе. Внутри Oracle оно давно не было секретом, но ожидалось, что официально о новой системе трекинга ошибок объявят на следующей неделе на конференции JavaOne. Видать, недотерпели! Впервые новость проскочила в паблик этой ночью в твиттере Бернарда (скриншот твита).

JIRA с гордым названием Java Bug System (JBS) появилась примерно год назад и пришла на замену старому сановскому багтрекеру, джавовая часть которого известна широкому пользователю как bugs.sun.com. Что же способствовало переходу?

Переходить на JIRA, на мой взгляд, было необходимо по многим причинам, среди которых:

• Старый багтрекер был не идеален, к тому же его надо поддерживать.
• Доступ к старому багтрекру можно было осуществить только из внутренней сети Sun/Oracle.
• Доступ к Java-части старого багтрекера для людей, не являющихся сотрудниками Sun/Oracle можно было осуществлять лишь через веб-интерфейс bugs.sun.com, которая тоже была не идеальна. Например, там есть некоторые проблемы с поиском багов.
• С 2006 года, в рамках проекта OpenJDK, сообщество активно включилось в разработку платформы Java. Нужны были новые инструменты.
• Такими инструментами стали мэйл-листы. Но сейчас они выглядят приветом из 20 века, не правда ли?
• Наконец, JIRA — самая крутая распространённая на сегодня платформа для трекинга багов.

Что же даёт переход на JIRA Java-организации, Java-сообществу и компании Oracle? Во-первых, жить станет просто удобнее и привычнее. Это реально шаг навстречу! Во-вторых, немного разгрузятся публичные мэйл-листы и в ближайшие год-два многие вещи из мэйл-листов перейдут в JBS JIRA. Ну и как следствие, в-третьих, я полагаю, что улучшится коммуникация между разработчиками платформы Java внутри компании Oracle и остальными разработчиками, что должно положительно сказаться на качестве финального продукта (Java SE 7 updates, Java SE 8, Java SE 9 и.т.д.).

Детальное описание нового багтрекера есть вот тут.

Так что you are welcome файлить баги. И конечно, фиксить!

(текст новости размещен по договоренности с автором, сотрудником Oracle)

>>> Источник

Тихо и незаметно вышла первая стабильная версия Picket - багтрекера основанного на фреймворке Django.

• поддержка любых БД, которые поддерживаются Django
• удобный интерфейс управления правами пользователей в багтрекере
• возможность принимать баги по электронной почте (help desk)
• гибкая настройка статусов прохождения бага
• интерфейс знакомый по известному багтрекеру Mantis
• распространяется под лицензией GPL v3

>>> Пост в блоге разработчиков

В ночь с 1-го на 2-е июля 2008 года свет увидели первые байты исходного кода открытого багтрекера, разработка которого ведется на Python в тесной связи с библиотекой Django.

В качестве основы для базы данных взята структура БД проекта Mantis. Однако, в нее уже внесены некоторые коррективы. Например, улучшено представление в БД механизма "видимости". Теперь "видимость" проектов и багов основана на группах пользователей (задействован стандартный механизм Django).

Вообще, основными целями проекта являются:

1. Создание легкой в установке и администрировании альтернативы Mantis, написанной на Python.
2. Обеспечение большего удобства работы, чем обеспечивает Мантис.

Для достижения второй цели планируется реализовать концептуально новый интерфейс панели управления багтрекером. Для реализации этой задачи проекту требуется дизайнер интерфейсов.

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

• программист Python,
• HTML-верстальщик,
• программист JavaScript.

Fill free to contribute to our project.

>>> Страница проекта Picket на sf.net