как вести разработку

[ArchiTecTor]

Предлагаю здесь вести и заводить все наши задачи по реализации, плюс обсуждать некоторые моменты по ним. достаточно удобно, можно закрывать задачи коммитами и т.д.
https://help.github.com/en/articles/closing-issues-using-keywords

[nikitos1550]

https://github.com/nikitos1550/hi3519v101_go/wiki/Quick-start вот тут описал минимальное приложение, которое можно попробовать сделать.

[ArchiTecTor]

• 1 требование которое считаю обязательным, используем линтеры, в го обязательно нужно прогонять код через gofmt
  по умолчанию в том же vs code плагин для го умеет все сам
• 2 требование, давайте делить репозиторий по ветвям, масте как умолчальная ветка, будет для продакшена и стабильных релизов, testing ветка для разработки, в мастер ничего не коммитим, только мержим из testing
• 3 требование, не заливаем в репозиторий код, который не сможет работать у другого участника команды, т.е. чтоб все зависимости и все такое могло решиться автоматически или 1 общей и всем известной команды (в жопу непонятные make make_me_ktulhu)
• 4 документация, тесты, вот давайте представим что без них жизни нет и кто не пишет яростное фи..

[wsnk]

Как это в жопу make? =)
По поводу "не собраться у другого участника" - как будем проверять? Я слабо знаком с возможностями github'а, но наверняка можно сделать хук, чтобы по коммиту в testing запускалась сборка (и тесты) на дев. серваке.
По другим пунктам всё ок.

[ArchiTecTor]

нет я сказал конкретно

в жопу непонятные make make_me_ktulhu

не make в целом, а плохо говорящие названия в целях, да и лишние цели в принципе

нормальная практика make install, make tests, make all

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

[wsnk]

Тогда согласен по всем пунктам

[nikitos1550]

1. plus
2. plus, master после какого-то момента сделаем с CI на камеры автоматом, по хуку из github`а или иным способом (это будет иметь смысл когда будет какое-то минимально рабочее приложение). testing тогда для рабочего кода, от него бренчуем себе делаем что-то и pull request назад в testing.
3. plus что касается testingа и masterа, для других бренчей наверное это смысла не имеет или я что-то не так понял?
4. plus никогда не пробовал такие практики, но давай попробуем, нужны только какие-то конкре

тные соображения, как это внедрять.

Было бы не плохо сделать отдельную страничку в вики со сводом таких правил. Мне пока сложно с ходу что-то написать, нужно в голове сначала систематизировать.

[wsnk]

В выходные поковырялся в проекте. Придумал несколько предложений.

По коду

1. Давайте в языках, в которых tab не является специальным символом-разделителем, делать отступы пробелами. Почему: у разных редакторов/IDE разные представления о том, как надо отображать tab'ы. Как следствие - красиво выглядящий код у одного разработчика может превратится в мешанину отсупов у другого. По сути сейчас единственным tab-зависимым языком у нас явялется makefile. В остальных предлагаю использовать пробелы. Лично на мои вкус наиболее красив отступ в 4 пробела.

По языкам.
У нас сейчас используются следующие языки/наречия (возможно что-то упустил):
C(11), python2.7, makefile, bash, go
Ещё есть тулз-специфичные конфиг-файлы и C-подобный язык для Arduino, но это особые случае. Предлагаю:

1. Минимизировать использования bash. Понятно, что какие-то небольшие скрипты на bash обычно выглядят понятно и элегантны. Но какие-то мал-мало сложные вещи предлагаю делать на python. Он и мощнее и, на мои взгляд, более читабелен.
2. Особой необходимости в третьем python я пока не заметил, но всё же давайте, по возможности, писать совместимый код. Например, вместо
   print "Hello"
   писать
   print("Hello")
3. Я люблю исключения =) Работа с ними, конечно, отличается от работы с кодами ошибок, но код, как мне кажется, становится короче и как следствие понятнее. Если нет противников - давайте их использовать.
4. Коль скоро периодически возникает необходимость что-то сделать на C, предлагаю добавить в наш стек технологий C++ и, по возможности, использовать его.

По репозиторию

1. Сейчас у нас вкомиченно много юзер-специфик штук. Типа номер и порт камеры, образ rootfs и т.д. Давайте это всё добавим в гитигнор и уберем из репы? Всё равно они постоянно меняются/пересобираются. Стабильные штуки, типа ядра, думаю могут остаться.
2. Вероятно холиварное предложение. Предлагаю разделить репу на две: одну с проектным кодом и тулзами общего назначения (типа бёрнера, билдрута и т.д.), а в другую сложить чисто наше внутреннее: код для ардуинки, настройки сети и т.д. Т.е. сделать так, чтобы в проектном репозитории не было кода, завязанного на наш конкретный дев-сервер.

[ArchiTecTor]

Приятно видеть человека со схожими взглядами на стилистику в коде!
Я все и везде за, за исключением 2 репозитория, пока нужно все в одном.
А вот позже, перед выходом в опенсоурс тот-же, мы разделим это на кишки и лицо.
Вот тогда да.
А сейчас это добавляет сложности, 2 репозитория геморрой и встраивать друг в друга и пользоваться тоже, поддерживать.
Про исключения я как бы тоже за, хорошо Александрова тут нет, он бы выел за них половину мозга. Но дозированно давайте, чтоб не было все-таки ловли Exception, а более конкретных исключений.
Про 3 питон согласен, тут надо уже какой-то линтер согласовать и внедрить в хуки коммитов, чтобы безжалостно отсекать попытки писать на старом питоне. Лучше сразу перейти на 3.6-3.7 попробовать, тем более что в билруте это как опция.

[wsnk]

А если, тогда, не отдельный репозиторий, а отдельную папочку? =)
Чтобы не перемешивать общий код и нашу внутреннюю инфраструктурную кухню? Потом и отделить легче будет.

[ArchiTecTor]

Да, так и надо, мой голос за

[nikitos1550]

Код

1. Да, без проблем, 4 спейса на таб это вроде даже как "стандарт"
   Языки
5. Мы немножко обсудили, предлагаю пока остановиться на Си, если будет явно видно, что есть смысл заменить на с++, то без проблем поменяем.
   Репо
6. я у себя в локальной ветке вынес Makefile.param который можно инклудить, это более менее решает проблему, его в гитигнор и все тип топ
7. У меня изначально все было разбито на 3 репозитория: тулчейн+кернел+убут, рутфс, приложение (и еще была задумка на веб интерфейс, но пока не дошли руки до чего-то серьезного)
   Тут я пока думаю, что стоит оставить один репозиторий, пока мы не сделаем некое минимальное приложение, потому что так будет намного проще. Разбивать стоит когда уже будет понятна структура приложения (на пример раньше я всегда грузил модули ядра шелл скриптом и это было часть рутфс, сейчас это ембед в приложение и все упрощает по организации окружения), когда будет несколько чипов поддерживаться (2 разных), тогда сразу станет понятно как разбивать все.

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

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