LINUX.ORG.RU

Проблемы с разработкой GCC


0

0

Mark Mitchell, главный релиз менеджер набора компиляторов GCC, выразил своё беспокойство текущим положением дел в разработке этого ПО. Критические ошибки долгое время не исправляются, другие висят в bugzilla'e по несколько месяцев, а иногда и больше года. Некоторые разработчики предлагают пропустить релиз 4.2 и обозвать его 4.3, исправив большую часть острых проблем. Высказываются также мысли о методах вознаграждения или наказания за игнорирование найденных ошибок или за появление оных, вследствие добавления нового кода.

Дискуссия целиком: http://gcc.gnu.org/ml/gcc/2007-04/thr...

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

Ответ на: комментарий от catap

> в случае close ты не знаешь за что ты платишь. Тебе от этого спокойнее?

> Лично я, работая в сфере software development, лучше буду использовать open, чем closed :)

Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;) Просто сравнивая свои затраты на притирку различных мелочей, которые сам бы никогда не заметил, но на которые пал глаз сотрудников QA, с затратами аналогичными у Open Source разработок, понимаю, что они счастливые люди, им не нужно вымарывать мелочи разные %20 процентов времени, они на них просто забивают.

anonymous
()
Ответ на: комментарий от anonymous

> Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;) Просто сравнивая свои затраты на притирку различных мелочей, которые сам бы никогда не заметил, но на которые пал глаз сотрудников QA, с затратами аналогичными у Open Source разработок, понимаю, что они счастливые люди, им не нужно вымарывать мелочи разные %20 процентов времени, они на них просто забивают.

Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

anonymous
()
Ответ на: комментарий от anonymous

>Лично я, работая в сфере software development-а считаю что вы работаете в какой-то неправильной под-области ;)

Вы кажется немного его не допоняли, он имел ввиду что с открытой библиотекой гораздо спокойнее на дуще, т.к. можно всегда багу исправить, чем с закрытой. Хотя может я недопонял? :)

akira_ag
()
Ответ на: комментарий от anonymous

Вышел в своё время 11-й Watcom C++. И поднялась агромаднейшая волна вопросов: а почему не работает то, почему не работает это. Со стереотипным ответом: поставь вот этот кусок от десятки. Пока не вышел через некоторое время весьма нехилый по размерам патч 11.5.

Таки да, второго примера я, пожалуй, не приведу. И тем не менее, с тех пор мифы о некоей присущей коммерческому ПО гарантии качества вызывают у меня сардоническую усмешку...

Цена сыра, к сожалению, не гарантирует от мышеловки...

Смоляное Чучелко

anonymous
()
Ответ на: комментарий от anonymous

>Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

Если бы ....

Много приходится работать с поддержкой Close Source продуктов

Обычная реакция на баги репорты, как из того анекдота - "а если нагнутся - болит, нет? вот так и ходи, бабушка"

anonymous
()
Ответ на: комментарий от anonymous

>Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

А что - метод пинания задниц стал хорошим катализатором качества? Что-то новое.

r ★★★★★
()
Ответ на: комментарий от r

Следил я полтора года где-то за gcc mail list, компилировал свою поделку раз в неделю свежескаченым gcc из основной ветки. Все ожидал супер чуда от новых фишек, bb-reordering, оптимизацию между функциями, автовекторизатора и прочих как мне казалось необходимых вещах. Фигня все это. Главное чтобы код правильный генерился. Все равно почти все современные процессоры его под себя переделывают, толку от оптимизации мало.

В принципе ничего нового в новости нет, так было всегда и Mitchell частенько сетовал что все рвутся добавлять супермодные фишки, а копаться в чужом древнем коде и исправлять что то не так прикольно. GCC изначально был написанне совсем хорошим образом, то есть не было общего процессорнонезависимого дерева на котором бы проходила оптимизация ( версии после 4.XX ), все проходы были на RTL, так что это каторжный труд все переносить на новый лад, переделывать. Распределение регистров до сих пор все ругают, но тут другая история - задача оказалась очень сложной.

Насколько я понял поводом для таких громких заявлений было то что RadHat прокатила 4.2, очевидно он должен был быть в FC7. Команда GCC разом лишилась огромной кучи тестеров, а тут еще известный и неприятный баг с alisaing-ом который невозможно пофиксить в 4.1 так как требуется слишком много изменений. Вот и хотел он переименовать и выпустить 4.3 как 4.2 и вообще забыть про 4.2. Народ возмутился и так далее.

Нормальная рабочая ситуация. Наверняка Google Summer проектов куча, к осени будет вам gcc как конфетка.

anonymous
()
Ответ на: комментарий от anonymous

Нет-нет, в Майкрософт отвечают за качество кода! Если ворд 97 намертво валился от слов "Таким образом, переданная информация..." и т.д., то ворд 2003 валится от "Правоспособность - это способность лица..." и т.д. Изменения в коде - налицо!

anonymous
()
Ответ на: комментарий от anonymous

> Да и по поводу общего качества - в Close Source, пусть и не всегда, обычно есть отвественное лицо, задом отвечающее за качество кода.

Наверное имеется в виду главпредседатель конторы, что включает кодерскую артель, и ж*па его толстая и мягкая, а волос - пышный и шелковистый, ага?

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