[Oberon] [EXT] Re: all in one git tree

[Liam Proven]

On Sat, 26 Dec 2020 at 16:10, Skulski, Wojciech
<skulski at pas.rochester.edu> wrote:
>
> This discussion is funny. We have not agreed what we want to achieve. We did not even pose the question. But we furiously discuss, how.

Up to a point, yes.
>   A new OS?

No

>   Preserving the old one better?

Yes

>   Merging the key distributions which grew slightly different?

Possibly, but it seems to me, more to the point, preventing that from happening.

>   Forcing collaboration among key persons?

Hardly.

> 2. Who will coordinate the effort?
>   Let's not cheat ourselves: any project needs a leader.
>   W/o a leader the project will not even start.
>   Will key persons agree on being managed?
>   If not, then what is going to happen and how?

That's a fair question.

>
> 3. OS is NOT ASCII-based. There are important files which are not pure ASCII.
>   Have you heard of a Procrustean Bed?

Certainly.

>   Can one use the chosen ASCII-mostly tool to manage Oberon non-ASCII files?

Git is perfectly able to handle binary files: you can put them in it,
and you can get them out again. No problem.

But the whole point of Git is that it is a tool for tracking and
managing the changes in files. As I understand it, currently, it can
only do that with plain text files.

There is no benefit at all in using it to manage binary files.

I *think* it would be possible to:
[1] Port Git to Oberon or A2, so that there was a native Git client.
[2] Extend that to understand Oberon "Text" format.
(Although that might not work with hosted repositories such as Github.)

For the Haiku OS project, it was widely seen in the FOSS world as a
significant step when Haiku became self-hosting: when Haiku was mature
enough to host its own development tools and it became possible to
build Haiku _on_ Haiku.

Oberon and A2 are _already_ self-hosting. It would lend them
additional credibility if they were able to run their own native
instance of the FOSS-industry-standard RCS, though.

>   Is cutting off all the non-ASCII files a viable approach?

I don't know. I suspect not.

>   Can we declare all non-ASCII stuff "embellishments" and ban them, so the remaining ASCII can be better managed?

I don't know.

>   Is the OS going to stay ASCII-only from now on simply because we adopted the ASCII-only tool?

I would _guess_ that in terms of its source code alone, that might be
possible, but I suspect it would be undesirable.

>  Saying non-ASCII I do not mean the program texts. I mean all the panels, elements, drawings, documents, etc. The fact that 2013 edition does not include formatted documents does not imply that they do not exist elsewhere, or that they should not get reintroduced.
>
> I somehow feel that w/o even posing these question this discussion is not even academic. Fortunately, it will subside and the status quo will come back. Nothing will change because nobody is seeking an agreement what should change, why, and how. In that sense this discussion will be harmless. Fruitless, but also harmless.
>
> Long live Oberon the way it is now. It will continue!

I very much hope so!


-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053