Board.KolibriOS.org

dunkaist wrote:Here are questions and issues to be addressed if moving to git.

1. Unlike svn revision numbers, git hashes are not increasing numbers.
   • This creates navigation difficulties for pages like history of builds.
   • It becomes harder to binary search prebuilt images.
   • It is harder to tell if the commit c0ffee is newer than the commit deadbeef.
2. Git hashes are longer than svn revision numbers, UI fixes may be needed (at least on the blue screen).
3. Autobuild scripts operate on svn revision numbers, and are to be updated to work with git hashes. Some scripts are written in perl.
4. There are existing references to svn.
   • In source and documentation files.
   • In board posts.
5. There is sf18.13 that returns svn revision number.
   • And maybe programs using it, who knows.
6. Current setup uses svn keywords and properties, e.g. Revision and eol-style. How to provide this functionality with git?
7. WebSVN should be replaced.
8. Existing svn tags and branches should somehow be moved to git.

1. We can continue maintaining revision number (starting from the latest SVN commit) - one file and it's done.
   • Solved if we use revision number.
   • Solved if we use revision number.
   • We always can append revision number to a commit message using git hook.
2. Solved if we use revision number.
3. I'll take care of the scripts.
4. The more we wait the more references we have.
   • With revision system we can leave it, just replace SVN by Rev. in places that need it.
   • The same for board posts.
5. Not a problem if we maintain revision number.
6. Havent checked how SVN does it, but I think we can create symple script that does this instead of svn.
7. As mentioned, there are similar systems for git, but IDK how difficult it will be for server maintainers.
8. I'll take care of it, it's big but essentially simple work TMK.

Switching to git may give us lots of opportunities, starting from smaller repo size and simpler environment for new developers (most of newbies start from git IMO) up to being able to move to GitHub.

Do we have any other problems with switching to git? If no, I'm ready to start it incrementally.

я очень извиняюсь за то что вставляю здесь свое совсем не весомое мнение но этот топик по своей сути чем то напоминает вот этот:
http://board.kolibrios.org/viewtopic.php?f=4&p=77574
и я не смог понять планируется ли полный переезд или паралельное сосуществование.

z525 wrote:и я не смог понять планируется ли полный переезд или паралельное сосуществование.

There is still no strict plan. Because it seems that most people don't care. My understanding is that there will be a git repo on kolibrios.org with a read-only mirror on Github.

dunkaist wrote:

z525 wrote:и я не смог понять планируется ли полный переезд или паралельное сосуществование.

There is still no strict plan. Because it seems that most people don't care. My understanding is that there will be a git repo on kolibrios.org with a read-only mirror on Github.

How we will merge pull requests from github if our server will be on kolibrios.org?

E.g. via git apply: first download a patch and then apply it.

Я считаю что мигрировать на Гитхаб не стоит или только в режиме чтения поскольку они проводят блокировки по политическим причинам.
https://www.cnews.ru/news/top/2019-07-2 ... v_iz_kryma
https://habr.com/ru/news/t/461415/
https://xakep.ru/2019/07/26/github-sanctioned/

dunkaist wrote: My understanding is that there will be a git repo on kolibrios.org with a read-only mirror on Github.

Why not vice versa: repo on GitHub and mirror on git.kolibros.org ? ReactOS does so.
If repo is on GitHub its easier to merge pull requests, can add contributors by their github account, etc

dunkaist wrote:

z525 wrote:My understanding is that there will be a git repo on kolibrios.org with a read-only mirror on Github.

I keep this.

Я думаю, что переезд на github можно начинать. Предлагаю разделить проект на части и создать следующие репозитории:

• kolibrios-kernel - ядро колибри.

• kolibrios-drivers - драйверы.

• kolibrios-apps - нативные приложения

• kolibrios-libs - нативные библиотеки

• kolibrios-ports - потры программ/бибилиотек/дров

И общий репозиторий kolibrios, который будет объединять их.
Систему сборки tup заменить на Meson.
Отказаться от компилятора майкрософт и kos32-gcc и использовать MinGW и TCC.

Если зимой помочить штаны, то будет тепло, но не долго. Полная миграция на GitHub (подразумевается сайт, а не система контроля версий) попадает под действие законов СГА, с блокировкой разработчиков из стран второго сорта (по мнению федерального правительства СГА).

Было очень приятно в 2021 году видеть после регистрации на сайте HP, с целью скачать новую версию биос, сообщение "На вашу второсортную страну наложено эмбарго правительства СГА". Сервер продавать можно, а обновление для него качать нельзя. Поправку Джексона — Вэника не отменят никогда (хотя формально отменили).

I have not read the FULL 4 pages of comments but I believe that I have an idea of what is going on. My perception of this situation is that most feel that GIT would be better to use than SVN (I feel the same) but most are hesitant to use GitHub for many reasons. Why not a middle ground of a local, Kolibri controlled, GitLab instance that is then mirrored/forked onto GitHub. We would get the added benefits of GIT, the access to a larger user base from GitHub, plus the centralized control of the "master" repository still in the control here.

Just a thought though.

By moving to GitHub, I wanted to push the project. Because github is a social network. And there is simply no one to do git on our server and that's it.

Great information, thanks for sharing it with us

Я против переезда на GitHub.

А теперь хоть за хоть против. Гитхаб пока ещё живой, но думаю его скоро отрубят.