Board.KolibriOS.org

I suggest to reuse the positive experience of ReactOS and migrate the code development and issues management to GitHub.
Probably main site pages too.

It will give also much easier bug reporting, process of sending patches will be much easier, will attract new contributors.

Примите моё против.
Далее немного мыслей вслух.

У Колибри ОС сложилась очень низкая ниша. Не ждите прироста новых участников и лавров других проектов на GitHub без сильных изменений (но тогда Колибри не будет Колибри) - получилось так, что ассемблер связал её. Ассемблер это похоже основной фактор, который защищает ОС от посягательств новых участников. Никакие портированные языки не смогли убедить людей писать под Колибри.
Перейдя на GitHub сейчас вы получите мифический прирост отчётности о багах и несколько новых участников, но рискуете разрушить проект. А это один из успешных проектов разработчиков из СНГ. Что его разрушит? Команде, которая сейчас занимается поддержанием проекта, удобно работать с SVN. Более чем уверен, что при переходе кто-то отвалится, а найти замену в новых лицах маловероятно. Каждый такой человек - это часть души Колибри. При уходе таких людей, проект будет погибать.
Искать новые силы нужно здесь.

Добавить кнопку "Донат" и договориться о внедрении ос в некие продукты (после адаптации ядра и реализации доп. функционала, например, работы с датчиками) - вот более перспективный вариант для Колибри ОС на мой взгляд.
P.S. Я могу ошибаться.

А одновременного варианта SVN и Github в синхронизации кода не может быть?
и в чём положительный опыт с ReactOS?

@Kopa - it is possible, yes. They got more attention and new contributors.

I agree with XVilka about "more attention and new contributors" especially about the kernel developers.
It would be good if they were at least 10.
Instead of current 3.5

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

Perhaps we could follow the example of flashrom successful open source project. They have:

1) "official primary" repository - https://review.coreboot.org/#/admin/projects/flashrom
It is hosted on their own platform, and from this "1)" repository everyone is cloning their source before building it
2) "Github mirror" repository - https://github.com/flashrom/flashrom
Which is actually not just a simple mirror, there are also supported issues and pull requests
that, if they are accepted by maintainers, will be merged to the "official primary" repository as well

This approach will unite the two worlds:
1) "oldbies", the core members of KolibriOS community, would continue using your current repository because they are already used to this workflow
2) "newbies", who are already familiar with Github and just want to make a quick Github pull request without having to learn how to use your infrastructure

Regarding your poll - "Migrate to GitHub? [Yes/No]" - I voted "No" because I don't think it is a good idea to just destroy the current infrastructure and just jump to Github - because that will make us 100% dependant on Github and its' problems. Sometimes, although rarely, Github experiences the downtimes and significant slowdowns, sometimes it could be mistakenly blocked at Russia by Roskomnadzor for a few days, also KolibriOS could mistakenly receive a DMCA from some troll company and Github instantly complies with DMCA requests so the KolibriOS repository will be temporarily unavailable, etc. So it would be stupid to just switch to Github. However, we could preserve the current infrastructure while making Github an alternative way to get the people's code into KolibriOS. These ways are not mutually exclusive, they could co-exist

Возможно тема устарела, но всё-таки вставляю свою 5 копеек. Технические плюсы перехода на git и в частности на сервис github:

• Pull Request - отпадает необходимость выкладывать исходники на форум. Всегда можно отправить PR и возможно ответственные лица его примут;
• Code Review - можно дать советы по PR, перед тем как слить в репозиторий. Например, попросить отформатировать код в соответствии с CodingStyle;
• Возможность иметь стабильную ветку и ветку разработки.
• Хорошая возможность для разработчиков повысить свой contribution activity в профиле github.

В соседней теме yogev_ezra писал:
Не вижу в этом никакой проблемы: автосборщик вызывается с помощью webhooks, а далее репозиторий клонируется на машину для сборки.

Just put some files, parts. And use this like bugtracker, issues etc.

Я могу поставить Gitea https://gitea.io/en-us/

Для SVN уже нет актуальных визуальных средств СКВ. Резурректить VisualSVN лень

С командной строкой ....

Под Windows я продолжаю пользоваться последней ночной сборкой RapidSVN, работающую с любым имеющимся клиентом, подходящим по экспортам. Собрал для него SVN 1.10 на основе сборки CollabsNet, часть библиотек собрал из исходников. Пользуюсь сам, всё работает.

Требует библиотек MSVC 2010, совместимо с Windows XP. Для попадания в импорты RapidSVN при сборке использовался флаг _USE_32BIT_TIME_T, то есть сборка работоспособна только до 2038 года.

Скачать: RapidSVN, SVN 1.10.

_________________
Разработчик языка программирования Кантор