<div dir="ltr">I have been giving some thought to this. Once again Jörg has identified a key issue -- Those of us who have an interest in Oberon each may be interested in different aspects of Oberon, including the language, the core system, and the user interface/environment presented to the user.<div><br></div><div>Git gives its users a way to track changes to a codebase. Code review systems based on git help people working on that codebase to collaborate.</div><div><br></div><div>I think we are missing a tool in Oberon that would enable coordinated development without prescribing a central authority. A source-code packaging system could fill this need.  What we need is an Oberon-centric source-code package management system that allows for the completely independent development that is typical of Oberon coders.</div><div><br></div><div>I started sketching the requirements for an Oberon-style package management system here - <a href="https://github.com/io-core/technotes/blob/main/technote008.md">https://github.com/io-core/technotes/blob/main/technote008.md</a>. For example here --<a href="https://github.com/io-orig/System/blob/main/Edit.Pkg">https://github.com/io-orig/System/blob/main/Edit.Pkg</a>  is a package file for the text subsystem part of Oberon that might receive enhancements independently of other parts of Oberon. A complete Oberon 'System' corresponding to a Linux 'Distro' could be described in an index of packages like this - <a href="https://github.com/io-orig/System/blob/main/Packages.Ndx">https://github.com/io-orig/System/blob/main/Packages.Ndx</a></div><div><br></div><div>In the spirit of Oberon the packages descriptions are as simple as possible, just csv text files. No XML, JSON, etc. required. Simple to parse even from a minimal system.</div><div><br></div><div>The idea is that anybody can have a git repo or even just a local subdirectory that has Oberon source in it. That directory could have a complete Oberon system or just a few files. The Oberon Tetris module, for example, could be a package of its own. An 'ObTris.Pkg' file could report that it depends on 'at least' the core system (with a 'requires' line like this: <span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">r,[core]/Files,v5.0.0 </span>and provides a single file, like this - <span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">p,ObTris.Mod,cc84a2c0a7c9fa7244a02dbdc7e7f7bd15cfeb7d3903d14950666c95626897e0</span></div><div><br></div><div>I even wrote a go program to manage Oberon source code repositories like the above but I got distracted by other projects. I intend to return to <a href="https://github.com/io-core/Mod">https://github.com/io-core/Mod</a> eventually though, if someone else doesn't prepare a better system sooner.<br></div><div><br></div><div>Best Regards,</div><div><br></div><div>Chuck</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 25, 2020 at 2:38 AM D EMARD <<a href="mailto:vordah@gmail.com" target="_blank">vordah@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">git/github or any other similar source control thing with web interface<br>
handles well line-delimited source. It has some language auto-detector<br>
and syntax highlighter from web interface so if it recognizes<br>
something, it will report repository like 80% python 15% fortran<br>
5% unknown, all have it like this.<br>
<br>
Even if it is not a language but a line-delimited stuff like<br>
kicad PCB design and gerbers, it's also manageable by git.<br>
<br>
gIt can of course hold exe binaries or jpegs but repository<br>
size will then rapidly rise towards GB-"fat" dynosaurus<br>
<br>
No mirracles can be expected, git is not having any artifical<br>
knowledge between branches, it's up to developer A<br>
to look at other branch from developer B and see if he can<br>
directly "cherry-pick" some code changes (100% compatible)<br>
or should he manually rewrite them because API or compiler<br>
is different.<br>
<br>
It's just a collection of all things on one place so you don't<br>
need may internet connections to see what other developer<br>
has done, just refresh main tree and switch to whatever branch<br>
and look at branch history.<br>
<br>
Most important thing is giving each change a human-readable<br>
description why it has been done or what it changes, so other people<br>
can know what's inside before reading the code itself. Human-reading<br>
the historic comments should be there help navigation and borrowing<br>
of the code.<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>