Migrate to GitHub

Find out what others think about your ideas

POLL Migrate to GitHub

Total votes: 83
Yes
55%
46
No
45%
37

  • Версия 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 мало помечен, если вообще помечен (при осуществлении поиска)
  • Мигрировать с SVN на GIT однозначно надо и вот почему:
    - SVN устарел, ему уже не учат, а самостоятельно разобраться сложнее
    - GIT сейчас преподают в вузах, его проще освоить
    - один репозиторий для всего: ядро, утилиты, скины; это всё стоит разделить
    - merge/pull requests упрощат просмотр кода и его добавление в основной репозиторий
    - во многих git СКВ можно создавать Wiki репозитории с документацией

    Что касаемо платформы, то это может быть не только GitHub.
    Если репозитории должны быть на внешнем сервисе, то: GitHub, GitLab, BitBucket и другие.
    Если репозитории должны быть на своих сервисах, то: Gitea, GitLab, BitBucket и другие.

    Это уже более спорное предложение, но можно полностью перейти на инфраструктуру Atlassian:
    - BitBucket -- система контроля версий
    - Confluence -- документация
    - Jira -- менеджер задач и багов проектов
  • И кто будет это все делать?
    Валить все на Leency по крайней мере не по-дружески - на нем висят оба сайта и группы
    А сам я репозиторий вряд ли делать буду
    Я один из тех, кто ещё не программист, но уже не новичок.
    Редактор в группе "KolibriOS - официальная группа".
  • Я могу этим заняться. Но для начала надо определиться со следующими вопросами:

    1. Развернуть свои сервисы или использовать готовые?
    При использование своих сервисов можно настроить их интеграцию, сделать Acrive Directory, создать пользователей, тогда потребуется только одна учётная запись для репозитория, багтрекера, вики и прочего. При этом усложняется администрирование и создание новых учётных записей с нужными правами доступа.
    С другой стороны можно использовать GitHub, GitLab или другой схожий сервис, в котором уже будет баг трекер и wiki. Поэтому поднятие своих сервисов будет оправдано, если их будет 3+ (сайты не в Счёт) и они все будут нужны и не содержать дублированного функционала. (Например, делать свой баг трекер при наличии такового в репо).
    Я за внешний GitLub.

    2. Вид самого репозитория.
    В текущем виде это один монолитный репозиторий, там и ядро, и утилиты, и скрины.
    Предлагаю сделать группу KolibriOS, а в ней:
    - репо или подгруппу Kernel для ядра,
    - подгруппу Skins для скинов,
    - подгруппу Utilities для утилит,
    И так далее...
    (В gitlub точно можно делать подгруппы, про другие сервисы не шарю)
    С одной стороны это может усложнить сборки (особенно ночные), но с другой стороны, я думаю, можно будет самому выбирать, какое ПО ты хочешь видеть в своей сборке.

    3. Документация (она же Википедия)
    Либо сделать один репозиторий со всей документацией, либо в каждом отдельном репозитории делать его локальную документацию. А можно объединить: общий репо с докухой, описывающий основные понятия и ссылающийся на другие локальные вики репозитории.

    4. Разграничения прав доступа.
    Надо продумать кто и какими правами будет обладать. Например, может ли простой гость сделать мерж/пул реквест или ему надо сначала вступить в группу. Кто будет смотреть и подтверждать реквесты?
    Логично будет сделать активных давних разработчиков держателями (owner) проекта, а ребят из беседы, которые иногда что-то делают, -- разработчиками или сопровождающим.

    5. Нужна ли история SVN?
    Все прошлые ревизии можно превратить в коммит в новом репо с теми же датами и авторами. Но нужно ли это на самом деле?
  • Это надо обсудить со всем сообществом и главным разработчиком, которого до сих пор не видно на горизонте
    Создай тему в опросах, а я репостну в группах у себя
    Я один из тех, кто ещё не программист, но уже не новичок.
    Редактор в группе "KolibriOS - официальная группа".
  • Spoiler:
    Хорошая подборка. Не работал с GitHub, но говорят это удобно и современно. Возможно это верное решение, но утверждать не буду ибо не с SVN не с Git пока не работал. Но это пока. Главное чтобы все где-то зеркально хранилось, если GitHub падет. Там наверняка есть функция архивирования.
    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 (Система которую можно запустить только на виртуальной машине).
  • 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.
    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 (Система которую можно запустить только на виртуальной машине).
  • git != github
    Лично мне - все равно, SVN или GIT. Github может когда сам захочет удалять файлы.
  • 2 синхронизирущихся хранилища - вот мой ответ
    Я один из тех, кто ещё не программист, но уже не новичок.
    Редактор в группе "KolibriOS - официальная группа".
  • Ну и про Git вроде в топике не упоминалось, а сразу про GitHub.
    В любом случае нужно резервное копирование.
    Местный 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 (Система которую можно запустить только на виртуальной машине).
  • Плюсую за git, но не github. Лучше развернуть что-то легковесное на своём сервере (gitweb/cgit/etc) или использовать какие-то легковесные публичные платформы вроде repo.or.cz/sourcehut.org/etc.
  • Maybe AsmBB??? That is SVN on Assembler :D
    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 (Система которую можно запустить только на виртуальной машине).
  • AsmBB - это ассемблерный веб-движок для форумов, а тут разговор идёт про version control system.

    Ну а если вспомнили JohnFound, то я точно знаю его субъективное мнение по сабжу.
    Иван за Fossil, без вариантов.
  • Who is online

    Users browsing this forum: Yandex [Bot] and 6 guests