НовостиСобытияКонференцииФорумыIT@Work
Open Source:

Блог

Скорость реакции на критику

Сергей Голубев
03.02.2011 11:50:16
Теги: Mandriva

Вчера вечером я писал про ошибку в работе консольного проигрывателя ncmpc (точнее, эта программа не сам проигрыватель, а только клиент проигрывателя mpd) в системе Mandriva 2010.2. Дистрибутив я не стал указывать, поскольку для морали заметки это было совершенно не важно.
Утром того же дня в блоге ru_foss я написал о том же самом, только более конкретно, указав дистрибутив. Была какая-то надежда, что разработчики это прочтут и исправят досадную ошибку.
Итак, заметка в ru_foss была написана в 11.49. Статья "Качество или количество" была опубликована в 21.07. Ошибка была исправлена в 21.46 (в это время я уже выключил компьютер).
Сегодня утром система потребовала обновления и вот результат:

Мне кажется, что скоростные показатели реакции на критику очень достойные - ошибка была исправлена в течении одного дня.

Комментариев: 3

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Михаил Романов
23.02.2011 09:17:01

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

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

23.02.2011 09:38:25

А еще вот так бывает - http://community.livejournal.com/ru_foss/117057.html?thread=2585153#t2585153

Михаил Романов
23.02.2011 11:16:40

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

По хорошему, любой код, который ментейнер берет в репозиторий, должен пройти приемочное тестирование:
- самого кода
- на совместимость с уже добавленными компонентами

А далее начинаются все прелести поддержки, т.к. ментейнер (владелец репозитория/дистрибутива) - это, по идее, первый, кому обращается пользователь с вопросом или претензией:
- одному не нравится, что по умолчанию включается этот погодный виджет, а не тот;
- другой заявляет, что "у автора на сайте это уже два месяца как обновилось, а вы все еще стрье держите"
- у третьего оно просто не работает - чего-то лишнего он "накрутил".
- ....

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

P.S. Я не знаю, чем руководствался Андрей, но описаную мною ситуацию очень хорошо понимаю.
И это как раз проблема централизованного репозитория, когда владельцы дистрибутива вынуждены разделять ответсвенность перед пользователями с авторами программы. С точки зрения конечного пользователя это очень удобно, но с точки зрения поддержки - ад кромешный.
До последнего момента этот вопрос особо не всплывал в следствии все той присловутой таргет-группы Linux: технически ориентированные специалисты и энтузиасты, способные решать такие проблемы (типа использование сторонних репозиториев или установка ПО в обход репозитория) самостоятельно. Однако появление homе user oriented дистрибутивов начинает приносить новые открытия, а с ними и новые проблемы.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии