Что вас чаще всего бесит, когда вы пишете баг-репорты в открытые проекты?

Не вижу смысла.

Не пофиксят?

Может и пофиксят, вопрос только - когда? Мне же пользоваться надо сейчас, а не в далеком утопическом будущем.

P.S. проприетарщикам багрепорты иногда отправляю.

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

что-то удобнее?

Да, полно удобных багтрекеров. Я могу понять уведомления по почте, но писать в список рассылки и общаться таким образом - это жопа.

общаться таким образом - это жопа.

Это лучше всяких форумов.

Регистрация мешает. Игнорят репорты часто. Например, почти три месяца назад наткнулся на баг в MySQL коннекторе. Пропатчил, сделал репорт — до сих пор не просмотрели/пофиксили.

Не «Плохое знание английского языка», а «Плохое знание русского языка некоторыми разработчиками»

Непонятная форма для баг-репортов
Иные неудобства в интерфейсе баг-трекеров

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

не нашел варианта «если не буду их писать - меня уволят»

мне-то уже не актуально, но люди такие есть

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

багзиллы с тонной обязательных для заполнения полей

Для очень больших проектов это облегчает жизнь.

Теперь в моде github, так что стало много легче

Ага, в итоге получаем свалку, где можно без проблем заблудиться.

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

Свалка багов получается только когда разработчики заколачивают и перестают сортировать баги, закрывать дубликаты и т.п.

Разработчики не люди?

своя проблема, как не сообщаю о баге-говорят что он известный :(

Разработчики гораздо лучше знакомы со структурой своего проекта. Мне кажется им проще поправить поля чем заставлять каждого желающего помочь проекту учить наизусть новые аббревиатуры.

Не расстраивайся: чем больше народу могут воспроизвести баг, тем выше шансы что его поправят!

Всё равно обидно дубликаты плодить

Разработчики гораздо лучше знакомы со структурой своего проекта.

Если проект состоит из многих независимых компонентов, то нет. Например дистрибутивы, проекты вроде KDE.

Прикольно сообщать в gnome & Co: сообщил - тишина. Потом ту же проблему сообщил ещё кто-то - тишина, спустя месяцы ещё кто-то - и наконец, заметили. А твой оригинальный баг репорт пометили как... дубликат(!!!)

А вообще с гномом есть и другие весёлые истории. Например, про то, как один разработчик из Red Hat сломал работу другого разработчика fedora. Вместо того, чтобы сделать экспериментальную ветку и пробовать решения, он не долго думая решил просто заставить других его найти.

и т.д.

Необходимость общения через списки рассылки

Мои баги слишком долго не исправляются

Часто не могу найти баг-трекер

Грубость разработчиков

Иные проблемы

а именно - тупость разработчиков

У некоторых свободных проектов багтрекеры находятся в ж-пе мира
Необходимо регистрироваться (хотя это и понятно)
Остальное норм.

тупость разработчиков

Сходи патч напиши.

Сходи патч напиши

сходи обои поклей

done.

Лол.
*брофист*

— у вашего xen несколько Domain-0, вот выхлоп libvirt

— почему ты пишешь в рандомный пакет багу либвирта, идиот?

— вот выхлоп xm — у вашего xen реально несколько Domain-0

— (pokerface.jpg)

Больше не пытался.

besit slovo durackoe, kogda cht ot besit govoryat izidi, znachit v tebe bes a besnota po opredeleniyu tupost, sila bez uma. bit besanutim bit pochti debilom, poetomu termin razdrazhenie ili ottalkivanie podhodit v dannom kontekste gorazdo luchshe

Верно подмечено! Уволить не уволят, но премии лишат :)

Где вариант: «разработчикам пох на багрепорты»?

Не пойму как вы читаете мой комментарий неправильно? Где там про дублирование репорта? Я же говору «дополнительный комментарий», т.е. к уже существующему.

В порядке уменьшения: 1) Лень ->

2) Повтор проблемы должен быть на 100%, это отнимает много времени ->

3) Баги долго не правятся (например, wine с его багами по 5 лет, хотя там понятно: если ты сам не напишешь патч, то вряд ли кто-то другой напишет, так как разработчикам wine надо иметь ту же программу, которая нужна тебе. В любом случае, это деморализует, чтобы заливать что-то новое) ->

4) Необходимость регистрации (если бы трекеры (да, Github, речь о тебе!) поддерживали OpenID или Mozilla Persona мир был бы намного лучше, а вместо этого идет тенденция к отказу от обеих технологий, печально) ->

5) Не люблю интерфейс Github'а (после Bugzilla и JIRA уж слишком минималистичный, да и поиск/каталогизация там хуже)

Обычно так:

Необходимость общения через списки рассылки

Иногда даже так:

Необходимость общения через форумы/комментарии

Регистрацию воспринимаю, как необходимое зло (тем более, для пакетов, в которых я сам заинтересован). Еще бесит, когда разработчиками по#$й на твои репорты (даже если с патчами). И копаться в чужом коде в попытках написания рабочего workaround'а =)

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

*регистрация

Грубость разработчиков

К счастью, встречается редко

А вот а в Debian BTS не надо регистрироваться. Достаточно со своей почты послать багрепорт.

Необходимость регистрации

Бесит. Почему нельзя заюзать OpenID? На крайняк, если уж совсем нужна моя регистрация...

— Списки рассылки — это, вообще адЪ. Ненавижу.

— Бесит часто обратная связь, когда тебя считают идиотом «а перезагружаться пробовали?» ©

Трекер похуже, чем GitHub еще надо поискать. Это просто свалка, которую владельцу надо самому структурировать. Возьмем, например, приоритет: приоритетов как таковых у Github'овского трекера нет, есть только цветные метки, которыми предлагается обвешивать баги, после чего весь трекер начинает напоминать новогоднюю ель. Для какого-нибудь несложного проекта (когда не хочется использовать блокнот) Github'овский трекер может и сойдет, но он не так хорош, как тут заявляется.

Про ненужность регистрации: а как насчет регистрации на самом Github? Причем, в отличие от Bitbucket, там нельзя использовать OAuth аккаунты в других сервисах (edit: хм, похоже что Atlassian оставили только создание аккаунта через Google. Жаль. Но в любом случае, тут есть альтернативный вариант в отличие от сабжа). Нет, я понимаю, что с точки зрения vendor lock-in это прекрасно, но зачем интегрироваться с таким «антисоциальным» сервисом совсем непонятно

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

люто бешено плюсую. один в один та же самая фигня

«Необходимость регистрации», и даже могу сказать более конкретно - необходимость регистрироваться для каждого (почти) проекта на новом багтрекере.

В идеале хотелось бы иметь систему, общепризнанную для большинства свободных проектов (может быть, под эгидой FSF), на худой конец - 2-3 конкурирующие системы, которые покрывали бы 90-95% свободных проектов. 2-3 аккаунта для обратной связи с разработчиками - это нормально, больше - уже напрягает.

«Иные проблемы» - как правило, багрепорт имеет смысл писать, удостоверившись, что проблема повторяется и в самой последней-распоследней версии программы (желательно, собраной из исходников последней ревизии svn/git/hg). Версия же, которая вошла в большинство популярных дистрибутивов, зачастую оказыается слишком «протухшей» для того, чтобы её проблемы заинтересовали разработчиков.

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

Трекер похуже, чем GitHub еще надо поискать. Это просто свалка,

Очередной ламерский субъектив.

которую владельцу надо самому структурировать

И это божественно. Каждый проект имеет не просто индивидуальный набор тем для багов, но индивидуальный набор измерений по которым эти баги можно классифицировать. Для условного ffmpeg это, например, поддержка разных форматов (...), ввод/вывод, платформы, gui/библиотека/документация и т.д. Для условной игры это совсем другие графика, звук, музыка, уровни, переводы. Если попытаться это заранее предусмотреть, получится условный говнотрекер в вакууме с кучей бесполезных полей для заполнения, который не решает задачи. Иначе это можно гибко настроить под конкретный проект, что и реализовано на github.

после чего весь трекер начинает напоминать новогоднюю ель

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

Про ненужность регистрации: а как насчет регистрации на самом Github?

И что? Сразу скажите что вы против регистрации как таковой - тогда разговор пойдёт в другое русло. Если же вы всё-таки признаёте что регистрация (какая-то) нужна, сразу скажите что вы за многократную (т.е. своя для каждого проекта) вместо однократной (для всех проектов) - тогда разговор можно будет не продолжать. Иначе получаем то что имеем - однократную регистрацию, а оная возможна только на самом популярном сервисе, а это github.

нельзя использовать OAuth аккаунты

vendor lock-in

А это смешно просто. Думаете что гугловский oauth избавит вас от зависимости от github? Открою секрет - вы будете зависеть и от google и от github.

«антисоциальным» сервисом совсем непонятно

Ваша паранойя никому не интересна. Идите пишите распределённый анонимный векторный github без vendor lock-in, если так жжёт.

PS. Хотя возможность авторизироваться на сторонних говнотрекерах через github была бы, пожалуй, весьма кстати. Но им это по всей видимости не нужно - они совсем не про удобство.

Меня сейчас кошмарит вот это (http://flavio.tordini.org/):

ERROR: Slow down; you move too fast.
ERROR: Duplicate reply detected; it looks as though you’ve already said that!
ERROR: The words you entered were incorrect