LINUX.ORG.RU

Советы по увеличению качества управления релизами открытого ПО


0

0

Martin Michlmayr, в 2003 и 2004 годах занимавший пост лидера проекта Debian, начал публиковать результаты анализа проблем, появляющихся во время подготовки релиза, и рекомендаций по их устранению для популярных открытых проектов (Debian, GCC, GNOME, Linux kernel, OpenOffice.org, Plone, X.org).

Если коротко:
Debian -- нет плана и разработчики не хотят его придерживаться
GCC -- занятый релиз-менеджер, слишком много веток
GNOME -- наоборот, слишком быстрый цикл разработки (6 месяцев)
Linux Kernel -- нет стабильной версии 2.6, разница между версиями и несвязанность bugzilla с стилем разработки
OpenOffice.org -- слишком быстрый цикл разработки (3 месяца)
Plone -- долго выпускают релиз после анонса
X.org -- новый интерфейс между драйвером и оборудованием.

>>> Полная версия

★★★★★

Проверено: Shaman007 ()

Re: Советы по увеличению качества управления релизами открытого ПО

> начал публикацию результатов анализа проблем с подготовкой релизов и рекомендаций по их ликвидации

Проблемы с рекомендациями по ликвидации релизов???

manntes ★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>Debian -- нету плана и разработчики не хотят его придерживаться

Дайте же наконец плана разработчикам Debian!

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

Так нет плана или он есть, но разработчики не хотят его придерживаться?

Xellos ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

> GNOME -- наоборот, сшиком быстрый цикл разработки (6 месяцев) > OpenOffice.org -- слишком быстрый цикл разработки (3 месяца)

то есть по-его мнению быстрый цикл разработки это плохо? то есть то что работает, фиксятся баги, появляются новые фичи, довольные пользователи - плохо? ну в общем дядька из дебиана не удивил, раз дебиан раз в 3 года выпускается, просто ему кажется что все должны так же тормозить как и разработка debian'a.

mator ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

Разве имеет право автор новости писать своё мнения в самой новости? Ведь новость - это изложение факта, а не мнение автора.

redbaron ★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

"увеличение качества" как-то не по-русски звучит, может быть качество все же улучшают....

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

Это не больше чем просто перечисление тезисов.

Прежде чем судить, лучше бы было прочитать оригинал.

catap ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>результатов анализа проблем с подготовкой релизов и рекомендаций по их ликвидации

не осилил. мож попроще как-нить сказать?

ЗЫ нет слова "нету" (это так... на будущее)

Deady ()

Re: Советы по увеличению качества управления релизами открытого ПО

> Debian -- нету плана и разработчики не хотят его придерживаться

Так как плана нет, то нечего и придерживатся... логично=)

Rain ★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

начал публикацию результатов анализа проблем с подготовкой релизов и рекомендаций по их ликвидации для популярных открытых проектов

Начал публиковать результаты анализа проблем, которые идут во время подготовки рилиза, и рекомендации по их ликвидации для открытых проектов.

catap ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

2.6.16 не стабильное? Как раз же для таких умников делали...

Valmont ★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

Вообще он есть, только он постоянно срывается, и все прикрываются фразой "как только будет готов"!

catap ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

нет слова "нету" в русском языке

UrfinKnight ()

Re: Советы по увеличению качества управления релизами открытого ПО

нету это разговорное слово.

Кстати, а что такое "русский язык"? Раз вы так категорично заявляете что этого в нем нет?

catap ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>Начал публиковать результаты анализа проблем, которые идут во время подготовки рилиза, и рекомендации по их ликвидации для открытых проектов.

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

имхо так лучше

Deady ()

Re: Советы по увеличению качества управления релизами открытого ПО

не проявляющихся, а появляющихся. "проявляется" несет несколько иную смысловую нагрузку, не подходящую к данному контексту :)

я там очепятался постом выше.

Deady ()

Re: Советы по увеличению качества управления релизами открытого ПО

> Martin Michlmayr, в 2003 и 2004 годах занимавший пост лидера проекта Debian,

> Debian -- нет плана и разработчики не хотят его придерживаться

Не этот ли дядя предлагал в свое время перевести все debian-овские конфиги на XML? Если да, то пусть он засунет свой план себе в задницу и придерживает его как можно дольше.

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

> посчитаем сколько времени прошло между 4 и 5 RHEL' ом.. ??

RHEL - чисто enterprise-дистрибутив. Ему во-первых не нужно выходить часто, этого не хотят покупатели. Никому не интересно раз в пол-года обновлять сервер. Во-вторых, выпуск RHEL сопровождается огромным объемом тестирования, на порядки больше, чем выпуск Debian и большинства других дистрибутивов - потому что если в debian что-то не дотестируют, просто выпустят патч, а в RHEL сильно увеличится нагрузка на техподдержку и они могут попасть на бабки. В-третьих, ему нужны сертификации и гарантии совместимости различного софта; дистрибутив не может быть выпущен, пока он не будет протестирован хотя бы самыми крупными партнерами. В-четвертых, у RHEL есть план, релизы по нему происходят нечасто, но он существует и жестко выполняется. Просто очень много времени уходит на тестирование. Вспомни, сколько месяцев назад был выпущен RHEL5beta1 и когда вышла финальная версия.

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

Я с вами согласен. 
Но все эти отличия и так понятны. И вытекают они ровно из одного:
RHEL коммерческий продукт.
А я где нибудь могу посмотреть сколько ошибок они исправили по ходу тестирования RHEL5 ?
Можно посмотреть на сертификаты?
Можно увидеть кто "протестировал" rhel5 из их крупных партнеров?

Debian не позиционирует свои "stable" релизы как "серверные", но они "дефакто" ими являются, именно поэтому тестирование идет так долго..
Именно по этому stable "не нужно выходить часто," т.к. "Никому не интересно раз в пол-года обновлять сервер."

И я лично очень рад, что debian такой "тормоз". 

p.s.
однако это превращается в flame war... 
предлагаю дальше эту тему не обсуждать..

tugrik ★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

Только одно замечание: изначально было не то что долго разрабатывают debian, а то что нет плана, или его не принимают разработчики.

catap ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

Согласен только с высказыванием про GCC остальное муть... автор явно далёк от реальности и понимания того что в каждой области свои критерии и требования(и тенденции).
А с гцц надо что то делать. Не более 2 линеек надо иначе всякие регрессии перестают исправлять даже вроде как в топовых релизах.

stalkerg ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>RHEL - чисто enterprise-дистрибутив ... Во-вторых, выпуск RHEL >сопровождается огромным объемом тестирования, на порядки больше, чем >выпуск Debian и большинства других дистрибутивов - потому что если в >debian что-то не дотестируют, просто выпустят патч, а в RHEL сильно >увеличится нагрузка на техподдержку и они могут попасть на бабки.

Мне просто интересно анонимус располагает данными, о команде тестировщиков RHEL ? Или как обычно возглас "аналитика с лор".

vtVitus ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>Debian -- нет плана и разработчики не хотят его придерживаться

Фигасе, а я думал у них еще пару мешков плана оставалось

DIMON ★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

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

Gharik ()

Re: Советы по увеличению качества управления релизами открытого ПО

интересно, как под такой цикл можно распланировать переезд на gtk3, если он состоится до кардинальной ломки всего на свете

Syncro ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

Ну и что как дети слюни развели ? Сложно поддерживать ? Неудобно управлять ? Иди каменщиком работай или бананы продавай.

an ()

Re: Советы по увеличению качества управления релизами открытого ПО

пиляц - как же задолбали эти долбанные поборники грамматики и синтаксиса!!!

комплексы чтоль от вашей училки по русс. языку?

каменты оставить - такая дефекационна потребность есть, а умного сказать нечего.

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

> А что смертельного в фразе: "увеличение качества"?

А Вы сами задумайтесь. Хинт: "увеличение пениса" операция вполне реальная.

Gharik ()

Re: Советы по увеличению качества управления релизами открытого ПО

Тоже, что ли, советов понадавать...

GNOME -- несовместим с KDE KDE -- несовместим с GNOME OpenOffice.org -- слишком мало эмулирует глюков MSOffice X.org - до сих пор не вобрал в себя в качестве составных частей KDE и GNOME, а также кроссбраузерный плагин для быстрого просмотра и постинга на линукс.орг.ру.

Вспоминается гоголевская героиня, которая всё мечтала к носу одного жениха приставить губы другого, усы третьего, и получился бы полный вендекапе... ой, идеальный мужчина.

ЗЫ для особо сообразительных: к Мартину отношусь с уважением. Это я так, зубоскалю...

hobbit ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

>А я где нибудь могу посмотреть сколько ошибок они исправили по ходу тестирования RHEL5 ?

В багзилле забанили?

jackill ★★★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

> Пипец, аффтар преподал урок владения языком. Расстреливал бы за слова "увеличение качества", или силой заставлял бы качество управления ступенями дефекации увеличивать для пущей наглядности, пока не дойдёт.

Ну а ты в своем сообщении, как обычно, отличился эталонной грамотностью,деликатностью и остроумием...

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

> нет слова "нету" в русском языке

как же так? "жопа есть, а слова - нету"?

слово "нету" - очень даже русское. я, конечно, не лингвист, но это слово достаточно часто встречается в русской классической литературе. это ли не доказательство его права называться русским словом?

anonymous ()

Re: Советы по увеличению качества управления релизами открытого ПО

> Так нет плана или он есть, но разработчики не хотят его придерживаться?

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

VladimirP ★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

> нет слова "нету" в русском языке

Значит, надо ввести. Неудобно же, когда и отрицание, и отсутствие обозначается одним и тем же словом.

VladimirP ★★★ ()

Re: Советы по увеличению качества управления релизами открытого ПО

I'm a PhD student at Cambridge doing research about quality in free software projects, and I'm a member of Debian.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.