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

Например? Что такого вкусного в плюсах для МК, чего нет в обычных сях? Генерируемого бинаря на порядок большего размера? Или потребления оперативы в 2 раза больше? что именно?

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

На безрыбье- вполне можно и Issues из GitLab использовать. Вполне хватает для отслеживания и обработки багов. Эти Issue линкуются с коммитами и с тагами проекта, так что вполне себе система.
Конечно, иногда хочется большего, но так как минимальная необходимая функциональность уже есть- вопрос установки чего-то более навороченного утыкается в вопрос "а зачем, если и этого хватает".
Как только найду аргументы- тоже побегу устанавливать что-то дополнительное.
У меня вопрос стоит так: если уже используется GitLab, как и что доставить для более красивого трекинга багов? И можно ли при этом не ломать уже работающее?

Вот потому вы и не в курсе сложностей.
Одна из сложностей - разработать надёжную структуру системы безопасности.
Решить где разместить устройства безопасности и как их соединить. Потом сдать это надзорным органам и снять с себя отвественность.
Но прежде еще надо сделать диагностику системы безопасности, доступ к этой диагностике и чтобы эта безопасность не вызывала лишних простоев и остановок оборудования.

А так повредит кого-то эта "шестиметровая дурища" и свалят всё на вас.


Опять сместили тему на групповуху.

Эффективному разработчику не нужен багтреккер. Баги исправляются сразу же при появлении.
Просто никто не допускет чтобы они существовали дольше суток от момента их обнаружения.

Никогда не встречал такого, чтобы уникальные вещи, сделанные для внутренней эксплуатации, сертифицировали. У нас, например, и патентовать-то начали сравнительно недавно. Хотя уже не один десяток уникальных приборов сварганили. Просто не нужно это никому. Цель — получение достоверных научных результатов, а не сертификация никчемная.

Вот если на продажу, тогда — согласен, иной раз потребуют сертификацию изделия. Хотя, я не представляю, кто в России смог бы сертифицировать, скажем, эшелльный спектрограф.


И кто сообщит разработчику об обнаруженном баге? А если ПО используется многими?
В принципе, да — на разработку единичных железяк никакого багтрекера не нужно, но вот на клиентское ПО, работающее с этими железяками, очень даже пригодится. И пулл-риквесты народ слать будет.
Тем и удобен опенсорц: всякое закрытое ПО десятилетиями баги из версии в версию тащит, а в открытом они так долго не держатся.

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

Сообщение отредактировал mantech - Jan 14 2017, 18:54

А по-настоящему эффективный разработчик не допускает появления багов. И система контроля версий ему тоже ни к чему.
Он сразу пишет финальную версию. :-)

Напрямую, в машкодах ☺

Ага, пользователи оборудования щас в баг треккер полезут что-то писать.
Да им в суд легче подать.
Или на возврат денег. Думаю чаще всего так про баги и узнают разработчики фирмваре.


Тестирование не влечет необходимости в багтреккерах, ошибки исправляются сразу.
Зачем их администрировать? Это лишние накладные расходы.

Если это опенсорс, то будут.
Давно, кстати, меня терзает мысль: почему до сих пор никто не написал фрезерный станок на STM32? Было бы свободное время и куча денег, сам бы занялся этим вопросом. Для начала хотя бы сверлильный станок сделать, чтобы печатные платы сверлить... А то я уже третий год как забил на этот проектик.

Вы не понимаете о чем пишите.
Обычно замечания и баги - это все, что приходит от пользователей, а не только от разработчиков.
У меня есть проект, где незакрыто примерно сотня замечаний (из трехсот). Замечания- разные, от "не работает то-то при таком-то сочетании конфигурационных параметров" до "не выводится надпись Shutdown... во время пересброса telnet командой." или "хорошо бы добавить....". Это не только баги, у этих Issue могут быть разные метки, от "баг" до "сделать до выхода на пенсию".
Никакое замечание невозможно гарантированно устранить в течении суток, так как полная проверка для релиза занимает минимум неделю. И любое изменение влечет за собой полную проверку, иначе это не релиз а всего лишь багфикс.

Я бы сказал, что фраза "Эффективному разработчику не нужен багтреккер" должна быть заменена на "AlexandrY не нужен багтреккер".

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

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

Есть пользователи, которые таки да, пишут. Но я это не приветствую (создадут невесть что, или копию уже имеющегося). Однако есть разные системы, которые специально для этого созданы (чтобы пользователи писали), сам мечтаю такую использовать (еще чтобы и с тикетами и с разными красивостями и статистиками).
Но в основном пользователи пишут емейлы, по которым ручками создаются в системе сообщения об обнаруженных багах.


Ересь! Изыди, искуситель!
Я с такими антиобщественными явлениями борюсь всю сознательную жизнь, правда, применяя несколько другие термины

+100500
Ничто так не усложняет работу как средства её облегчения.
Мало того, что разработчику нужно держать в голове все нюансы задачи, железа, языка программирования, компилятора, IDE, отладчика, профилировщика, CVS и доксигена.
Так он еще, получается, должен держать в голове все нюансы работы с багтрекером.

Голова распухает от большого объема информации, которую нужно постоянно "иметь в виду"/"держать в голове". Соответственно вероятность ошибки растет

Сообщение отредактировал Укушенный воблой - Jan 14 2017, 21:01

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

Сообщение отредактировал Огурцов - Jan 14 2017, 21:26