Spot on sir.floppy121 wrote:XVilka wrote:
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
Migrate to GitHub
Версия KolibriOS 5, 14-ти летней давности на Github
KolibriOS ported to LLVM (6 years ago)
Unofficial mirror of repo.or.cz/kolibrios.git websvn.kolibrios.org
This is a clone of an SVN repository at svn /kolibrios.org
KolibriOS github mirror (3-4 years ago)
ashmew2/kolibriosSVN (4 years ago)
KolibiOS (2 years ago)
kolibrios-clone (4 years ago)
KolibriOS_v5938 (4 years ago)
P.S. Мигрировать не призываю, но что то много версий KolibriOS на Github
А, это пустой репозиторий https://github.com/KolibriOS/kolibrios.org
А тэгом KolibriOS какой то код на Github мало помечен, если вообще помечен (при осуществлении поиска)
KolibriOS ported to LLVM (6 years ago)
Unofficial mirror of repo.or.cz/kolibrios.git websvn.kolibrios.org
This is a clone of an SVN repository at svn /kolibrios.org
KolibriOS github mirror (3-4 years ago)
ashmew2/kolibriosSVN (4 years ago)
KolibiOS (2 years ago)
kolibrios-clone (4 years ago)
KolibriOS_v5938 (4 years ago)
P.S. Мигрировать не призываю, но что то много версий KolibriOS на Github
А, это пустой репозиторий https://github.com/KolibriOS/kolibrios.org
А тэгом KolibriOS какой то код на Github мало помечен, если вообще помечен (при осуществлении поиска)
Мигрировать с SVN на GIT однозначно надо и вот почему:
- SVN устарел, ему уже не учат, а самостоятельно разобраться сложнее
- GIT сейчас преподают в вузах, его проще освоить
- один репозиторий для всего: ядро, утилиты, скины; это всё стоит разделить
- merge/pull requests упрощат просмотр кода и его добавление в основной репозиторий
- во многих git СКВ можно создавать Wiki репозитории с документацией
Что касаемо платформы, то это может быть не только GitHub.
Если репозитории должны быть на внешнем сервисе, то: GitHub, GitLab, BitBucket и другие.
Если репозитории должны быть на своих сервисах, то: Gitea, GitLab, BitBucket и другие.
Это уже более спорное предложение, но можно полностью перейти на инфраструктуру Atlassian:
- BitBucket -- система контроля версий
- Confluence -- документация
- Jira -- менеджер задач и багов проектов
- SVN устарел, ему уже не учат, а самостоятельно разобраться сложнее
- GIT сейчас преподают в вузах, его проще освоить
- один репозиторий для всего: ядро, утилиты, скины; это всё стоит разделить
- merge/pull requests упрощат просмотр кода и его добавление в основной репозиторий
- во многих git СКВ можно создавать Wiki репозитории с документацией
Что касаемо платформы, то это может быть не только GitHub.
Если репозитории должны быть на внешнем сервисе, то: GitHub, GitLab, BitBucket и другие.
Если репозитории должны быть на своих сервисах, то: Gitea, GitLab, BitBucket и другие.
Это уже более спорное предложение, но можно полностью перейти на инфраструктуру Atlassian:
- BitBucket -- система контроля версий
- Confluence -- документация
- Jira -- менеджер задач и багов проектов
И кто будет это все делать?
Валить все на Leency по крайней мере не по-дружески - на нем висят оба сайта и группы
А сам я репозиторий вряд ли делать буду
Валить все на Leency по крайней мере не по-дружески - на нем висят оба сайта и группы
А сам я репозиторий вряд ли делать буду
Я могу этим заняться. Но для начала надо определиться со следующими вопросами:
1. Развернуть свои сервисы или использовать готовые?
При использование своих сервисов можно настроить их интеграцию, сделать Acrive Directory, создать пользователей, тогда потребуется только одна учётная запись для репозитория, багтрекера, вики и прочего. При этом усложняется администрирование и создание новых учётных записей с нужными правами доступа.
С другой стороны можно использовать GitHub, GitLab или другой схожий сервис, в котором уже будет баг трекер и wiki. Поэтому поднятие своих сервисов будет оправдано, если их будет 3+ (сайты не в Счёт) и они все будут нужны и не содержать дублированного функционала. (Например, делать свой баг трекер при наличии такового в репо).
Я за внешний GitLub.
2. Вид самого репозитория.
В текущем виде это один монолитный репозиторий, там и ядро, и утилиты, и скрины.
Предлагаю сделать группу KolibriOS, а в ней:
- репо или подгруппу Kernel для ядра,
- подгруппу Skins для скинов,
- подгруппу Utilities для утилит,
И так далее...
(В gitlub точно можно делать подгруппы, про другие сервисы не шарю)
С одной стороны это может усложнить сборки (особенно ночные), но с другой стороны, я думаю, можно будет самому выбирать, какое ПО ты хочешь видеть в своей сборке.
3. Документация (она же Википедия)
Либо сделать один репозиторий со всей документацией, либо в каждом отдельном репозитории делать его локальную документацию. А можно объединить: общий репо с докухой, описывающий основные понятия и ссылающийся на другие локальные вики репозитории.
4. Разграничения прав доступа.
Надо продумать кто и какими правами будет обладать. Например, может ли простой гость сделать мерж/пул реквест или ему надо сначала вступить в группу. Кто будет смотреть и подтверждать реквесты?
Логично будет сделать активных давних разработчиков держателями (owner) проекта, а ребят из беседы, которые иногда что-то делают, -- разработчиками или сопровождающим.
5. Нужна ли история SVN?
Все прошлые ревизии можно превратить в коммит в новом репо с теми же датами и авторами. Но нужно ли это на самом деле?
1. Развернуть свои сервисы или использовать готовые?
При использование своих сервисов можно настроить их интеграцию, сделать Acrive Directory, создать пользователей, тогда потребуется только одна учётная запись для репозитория, багтрекера, вики и прочего. При этом усложняется администрирование и создание новых учётных записей с нужными правами доступа.
С другой стороны можно использовать GitHub, GitLab или другой схожий сервис, в котором уже будет баг трекер и wiki. Поэтому поднятие своих сервисов будет оправдано, если их будет 3+ (сайты не в Счёт) и они все будут нужны и не содержать дублированного функционала. (Например, делать свой баг трекер при наличии такового в репо).
Я за внешний GitLub.
2. Вид самого репозитория.
В текущем виде это один монолитный репозиторий, там и ядро, и утилиты, и скрины.
Предлагаю сделать группу KolibriOS, а в ней:
- репо или подгруппу Kernel для ядра,
- подгруппу Skins для скинов,
- подгруппу Utilities для утилит,
И так далее...
(В gitlub точно можно делать подгруппы, про другие сервисы не шарю)
С одной стороны это может усложнить сборки (особенно ночные), но с другой стороны, я думаю, можно будет самому выбирать, какое ПО ты хочешь видеть в своей сборке.
3. Документация (она же Википедия)
Либо сделать один репозиторий со всей документацией, либо в каждом отдельном репозитории делать его локальную документацию. А можно объединить: общий репо с докухой, описывающий основные понятия и ссылающийся на другие локальные вики репозитории.
4. Разграничения прав доступа.
Надо продумать кто и какими правами будет обладать. Например, может ли простой гость сделать мерж/пул реквест или ему надо сначала вступить в группу. Кто будет смотреть и подтверждать реквесты?
Логично будет сделать активных давних разработчиков держателями (owner) проекта, а ребят из беседы, которые иногда что-то делают, -- разработчиками или сопровождающим.
5. Нужна ли история SVN?
Все прошлые ревизии можно превратить в коммит в новом репо с теми же датами и авторами. Но нужно ли это на самом деле?
Это надо обсудить со всем сообществом и главным разработчиком, которого до сих пор не видно на горизонте
Создай тему в опросах, а я репостну в группах у себя
Создай тему в опросах, а я репостну в группах у себя
Spoiler:
Kopa wrote:Версия KolibriOS 5, 14-ти летней давности на Github
KolibriOS ported to LLVM (6 years ago)
Unofficial mirror of repo.or.cz/kolibrios.git websvn.kolibrios.org
This is a clone of an SVN repository at svn /kolibrios.org
KolibriOS github mirror (3-4 years ago)
ashmew2/kolibriosSVN (4 years ago)
KolibiOS (2 years ago)
kolibrios-clone (4 years ago)
KolibriOS_v5938 (4 years ago)
2004: Kolibri OS - Operating system that fits on a single floppy disk (Система которая умещается на дискете).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
Migrating to Github will make your project some much more "professional"
I think I'll change my mind about GitHub.
Yes, it is popular, but it is a very strange service.
For example, you can't create an empty folder.
It is difficult to move a file from one folder to another.
Perhaps SVN is more convenient in this regard.
Yes, it is popular, but it is a very strange service.
For example, you can't create an empty folder.
It is difficult to move a file from one folder to another.
Perhaps SVN is more convenient in this regard.
2004: Kolibri OS - Operating system that fits on a single floppy disk (Система которая умещается на дискете).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
git != github
Лично мне - все равно, SVN или GIT. Github может когда сам захочет удалять файлы.
Лично мне - все равно, SVN или GIT. Github может когда сам захочет удалять файлы.
2 синхронизирущихся хранилища - вот мой ответ
Ну и про Git вроде в топике не упоминалось, а сразу про GitHub.
В любом случае нужно резервное копирование.
Местный SVN должен быть.
Как только Kolibri появится на GitHub его наверно начнут сразу форкать.
Появиться Assembler Bolgenos OS наверно...
В любом случае нужно резервное копирование.
Местный SVN должен быть.
Как только Kolibri появится на GitHub его наверно начнут сразу форкать.
Появиться Assembler Bolgenos OS наверно...
2004: Kolibri OS - Operating system that fits on a single floppy disk (Система которая умещается на дискете).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
Плюсую за git, но не github. Лучше развернуть что-то легковесное на своём сервере (gitweb/cgit/etc) или использовать какие-то легковесные публичные платформы вроде repo.or.cz/sourcehut.org/etc.
Maybe AsmBB??? That is SVN on Assembler
Kolibiri OS is on Assembler too... Much symbolic...
https://asm32.info/fossil/asmbb/timelin ... a0a76758c8
Writed by Bulgarian developer "John Found"
Kolibiri OS is on Assembler too... Much symbolic...
https://asm32.info/fossil/asmbb/timelin ... a0a76758c8
Writed by Bulgarian developer "John Found"
2004: Kolibri OS - Operating system that fits on a single floppy disk (Система которая умещается на дискете).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
2020: Kolibri OS - Operating system that can only be run under Virtual machine (Система которую можно запустить только на виртуальной машине).
AsmBB - это ассемблерный веб-движок для форумов, а тут разговор идёт про version control system.
Ну а если вспомнили JohnFound, то я точно знаю его субъективное мнение по сабжу.
Иван за Fossil, без вариантов.
Ну а если вспомнили JohnFound, то я точно знаю его субъективное мнение по сабжу.
Иван за Fossil, без вариантов.
Who is online
Users browsing this forum: No registered users and 1 guest