Comments 39
А я год назад, всем инфу разослал о проблеме в модуле сетевого устройства.
Написал стать на хабре, с описанием проблем.
Спустя год, ничего не изменилось. Как проблема была, так и осталась.
Файл MAINTAINERS для того и существует чтобы знать кому посылать. Там ёще есть скрипт 'scripts/get_maintainer.pl' который показывает кто отвечает за какой участок кода. Надо послать человеку помеченному как М и в лист. Разработчики ядра получают сотни майлов в день. Многие из них, как Джефф (кстати отличный парень) зарегистрированы во многих листах. Обычно надо подождать две недели и написать снова.
Спасибо за пояснение!
Возможно, я плохо искал, но где можно найти информацию о том, куда/кому жаловаться на баги и где/кому задавать вопросы? Или это передаётся из уст в уста, как сейчас? Или нужно логическим путём понять, что жалоба на баг или вопрос -- это как недопатч, и потому если с патчами надо обращаться так-то, то и с репортами/вопросами нужно обращаться аналогично?
Из описания в MAINTAINERS следует:
Descriptions of section entries and preferred order
...
B: URI for where to file bugs. A web-page with detailed bug
filing info, a direct bug tracker link, or a mailto: URI.
C: URI for chat protocol, server and channel where developers
usually hang out, for example irc://server/channel.
Но в секции "FILE LOCKING (flock() and fcntl()/lockf())" нет ни B:, ни C:.
Ох, статья, как глоток свежего воздуха на нынешнем Хабре. Спасибо!
Итого, вы долбили письмами кучу людей при том что никакого бага нет, а есть специфицированное POSIX поведение. Что вам в результате и подтвердили.
Ну как минимум было бы неплохо пропатчить документацию.
Пропачить в какую сторону? Документация документирует то что принято в стандарте POSIX. Если автор недоволен принятым стандартом, он имеет полное право пойти и попытаться протолкнуть изменение в следующей версии. Очевидно что его никто не примет, потому что это ломает обратную совместимость, и максимум на что можно надеяться - это добавление новой функции, семантика которой учитывает существование потоков. Но ни багтрекер убунты, ни письма в личку товарищу Jeff Layton не являются хоть сколько-нибудь работающим способом внесения изменений в POSIX.
В документации нужно прямо отобразить, что данная функция не работает с многопоточкой. Чтобы там вначале большими буквами было написано НЕ ИСПОЛЬЗОВАТЬ С МНОГОПОТОЧКОЙ, ЕСЛИ У ВАС МНОГОПОТОЧКА СМ ...
Собственно, автору статьи мейнтейнер именно это и сказал - пропатчи, мол, друг, соответствующий man page.
С вашего позволения тезисно перескажу пост, чтобы более чётко артикулировать свою точку зрения.
Согласно POSIX, функция lockf должна возвращать ошибку, когда система замечает дедлок.
Linux реализует такой детектор дедлоков. И в документации, и в коде написано, что он может давать как false positive-ы, так и false negative-ы.
Я обнаружил случай, строго говоря, ещё одного false positive-а со стороны детектора дедлоков, не упомянутый в документации. Он касался распространённого сценария использования потоков в коде.
Я пожаловался на этот случай мейнтейнерам соответствующего кода.
У меня возникла смелая мысль, что раз детектор обладает такими интересными свойствами, то было бы хорошо по крайней мере поправить man, чтобы сказать: он плохо дружит с тредами.
На правку POSIX не претендую. Он здесь вообще почти не при делах.
Надеюсь, я ответил на ваш вопрос.
Багтрекер убунты мёртв. Вероятность, что они отреагируют на баг стремится к нулю. Багтрекер дебиана - живее всех живых.
Я недавно репортил баг в netdev (простыня из altnames ломала netlink), мне ответили в течение нескольких дней, причём патчем.
А в целом, багрепорт в opensource (даже с unit-тестом для гарантированого воспроизведения) - это пол-дела. Хороший багрепорт идёт с патчем.
Багтрекер дебиана - живее всех живых
Сарказм? У них же вроде нет багтрекера, только список рассылки?
По указанной ссылке как раз написано что чтобы отправить баг или добавить информацию к уже существующему багу нужно отправить email или напрямую или через спец. программу которая вызовет почтовый клиент с правильным шаблоном и больше способов общения не предусмотрено. Или я что-то упустил?
Да, отправка бага через почту или через reportbug (через ту же почту). Но баг-трекер-то от этого не исчезает. У багов есть номера, статус, трекинг по версиям и т.д.
Не исчезает, говорите? Есть номера, статус и это всё, говорите? Ну-ну...
Вот засегфаултил как-то мой git, отписал я как положено в тот "мыльный" баг-трекер, и в результате выяснилось внезапно, что очень всё знакомо вдруг и даже ветка где-то с фиксом лежит, про который попросту все позабыли. Что в последствии вылилось в дискуссию с моим описанием почему такой "мыльный" трекер вовсе не трекер, и чем реальный issue-tracker лучше. С ожидаемым результатом - здесь поговорка про инициативу и того незадачливого инициатора, которого она... ну того, значит.
@posthedgehog:касательно поиска контактного лица или ответа на конкретный вопрос люди пользуют IRC (libera.chat).
Для того же ядра можно спросить бота /msg alis LIST *kernel* для списка каналов куда можно постучатся (на вскидку #linux-kernel, #kernel или ##kernel).
Вы всё ещё про Дебиан, или про последний баг через почту в каком-то проекте, где вам не понравилось?
Я вообще про баг "трекеры" на основе е-майл и то просто конкретный пример как оно реально работает.
Кроме того, если внимательно посмотреть, место "где мне не понравилось" и есть как раз "трекер" куда человек своё issue из статьи бы и отправил (...@vger.kernel.org), оно что для git, что для всего остального там одинаково работает. И что-то мне говорит, что в случае с kernel (о чем собственно эта статья) количество тех issues всяко поболее будет чем у того же git, т. е. заблудиться там есть где. О чем кстати много где и не раз говорилось, и того же LBT на всяких разных конференциях только ленивый не спрашивал.
Я вообще про баг "трекеры" на основе е-майл и то просто конкретный пример как оно реально работает.
баг-трекер debian в вашей терминологии не «на основе е-майл», он не является списком рассылки, это классический баг-трекер со статусами, ответственными и т. п.
И что-то мне говорит, что в случае с kernel (о чем собственно эта статья) количество тех issues всяко поболее будет чем у того же git, т. е. заблудиться там есть где. О чем кстати много где и не раз говорилось, и того же LBT на всяких разных конференциях только ленивый не спрашивал.
у ядра давно есть обычная багзилла, вот вам пример:
https://bugzilla.kernel.org/show_bug.cgi?id=201331
у ядра давно есть обычная багзилла
Есть то она есть, только...
Once you know the subsystem that is causing the issue, you should send a bug report. Some maintainers prefer bugs to be reported via the kernel.org Bugzilla, while others prefer that bugs be reported via the subsystem mailing list.
да, вокруг ядра линукса сложилось сообщество разработчиков, предпочитающих списки рассылки. и это работает, сам проверял. и в статье написано, что если не забывать ставить в копию ответственного за этот участок кода, то ответ обычно не заставляет себя ждать.
если система есть и она работает, как говорится, кто мы такие, чтобы это менять?
Ну вот я и привел конкретный пример (хоть и не про ядро, но про ту же рассылку), где это не сработало... От слова совсем.
О чем собственно и речь... Хотя возможно это просто из области того исключения подтверждающего правило, однако... судя по слухам всё же нет.
И (пользуясь настоящими issue-tracker уже лет дцать с гаком) я действительно не очень представляю как это вообще может работать хорошо. Нельзя просто взять (здесь картинка) и сделать из почтового клиента полноценный современный трекер с полным его функционалом, я уж умолчу про github, gitlab и подобные.
Так то можно и код писать и ревьювить в блокноте, а вместо git (или др. какой distributed version control system) те же архивы юзать и patch-ами обмениваться, и т.д. Можно много чего, но зачем?.. И главный вопрос (хоть история и не терпит сослагательного наклонения), насколько лучше и быстрее и качественнее возможно оно было бы по другому.
В 2020-м в трекере Убунты мне ответили за два дня: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1875667
Сейчас на глаз там такая же скорость ответов:
https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&field.status%3Alist=CONFIRMED
Ради интереса закину репорт на ошибку в ядре 4.9 в Debian, чтобы сравнить скорость.
Багтрекер дебиана — живее всех живых.
очень сильно от майнтейнера зависит, вот вам живой пример:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827550
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952421
патч уже есть, проверен, нужно просто применить его и дело с концом.
P. S. в апстриме много лет движения не было, потому апстриму я патч не посылал. но в прошлом году внезапно случился релиз, я, увидев, что апстрим живой, послал письмо автору. он поблагодарил, сказал, что патч применил, и следующий релиз будет уже с ним, но, видимо, это случится ещё через пять лет )))
Я посмотрел, кажется, Keng-Yu Lin (мейнтейнер) вообще не выходит на связь. В такой ситуации пакет должен становиться orphaned, а если его никто не поднимет, то удаляться из архива.
поддержку именно этого пакета я бы мог взять на себя: релизы выходят раз в несколько лет, багрепортов тоже немного.
но посмотрел на процедуру становления разработчиком debian, что-то энтузиазм пропал )
У меня отвалился звук через hdmi на интеловской видеокарте под Дебианом. Последнее работающее ядро 4.19, а 5+ уже не работает. Куда и как лучше слать репорт? В Дебиан послал в августе 2021, ни ответа, ни привета.
а что за known solution? ИМХО странно упоминать что есть решение, но не давать ссылку
.
Это опечатка, имелось в виду что нет известных решений.
Необязательно ограничиваться одной сборкой Linux.
Главный по звуку в Linux есть Takashi Iwai github.com/tiwai, работает в SUSE. Ставите/грузите LiveUSB openSUSE и (если будет ошибка) можете получить ответ от него в bugzilla.opensuse.org.
Хоть форматирование сделайте на выдержки из документации на английском, в виде цитат м.б…
Очень интересное расследование, спасибо за статью.
Баг в ядре Linux и как правильно жаловаться