Constructing master lists of data types hga@xxxxxx (30 Sep 2019 14:51 UTC)
Re: Constructing master lists of data types Lassi Kortela (30 Sep 2019 15:09 UTC)
Re: Constructing master lists of data types hga@xxxxxx (30 Sep 2019 18:00 UTC)
Re: Constructing master lists of data types John Cowan (02 Oct 2019 17:15 UTC)
How to store the master lists of data types hga@xxxxxx (02 Oct 2019 17:52 UTC)
Re: How to store the master lists of data types Arthur A. Gleckler (02 Oct 2019 21:10 UTC)
Re: How to store the master lists of data types Lassi Kortela (02 Oct 2019 21:31 UTC)
Re: How to store the master lists of data types hga@xxxxxx (02 Oct 2019 21:54 UTC)
Re: How to store the master lists of data types hga@xxxxxx (02 Oct 2019 21:42 UTC)
Re: How to store the master lists of data types Arthur A. Gleckler (03 Oct 2019 04:11 UTC)
Re: How to store the master lists of data types hga@xxxxxx (03 Oct 2019 12:27 UTC)
Re: How to store the master lists of data types Lassi Kortela (03 Oct 2019 14:55 UTC)
Re: How to store the master lists of data types Arthur A. Gleckler (03 Oct 2019 15:07 UTC)
Re: Constructing master lists of data types Alaric Snell-Pym (01 Oct 2019 09:11 UTC)
Re: Constructing master lists of data types John Cowan (30 Sep 2019 21:59 UTC)
Re: Constructing master lists of data types hga@xxxxxx (30 Sep 2019 22:14 UTC)
Re: Constructing master lists of data types John Cowan (01 Oct 2019 20:05 UTC)
Re: Constructing master lists of data types Alaric Snell-Pym (02 Oct 2019 16:15 UTC)
Re: Constructing master lists of data types Alaric Snell-Pym (01 Oct 2019 09:33 UTC)

Re: How to store the master lists of data types Lassi Kortela 02 Oct 2019 21:30 UTC

> I'm afraid that I don't understand.  Based on the subject line, it sounds
> like this would be for storing a registry of data types supported by the
> proposed serialization mechanism.  Do we really need more than a simple
> text file, or perhaps a Git repo, for that?

I have to agree with this. Git is ubiquitous, free, vendor-neutral,
simple and fundamentally decentralized: every time people make changes,
they effectively make distributed backups of the whole change history.

Storing the master list in a database is admirable from a dogfooding
perspective, but my confidence in our abilities and available
person-hours is not quite that high :) Storing the ground-truth for any
assets in Git is a good default unless there are some exotic
requirements - whether those assets are code, specs, websites,
documentation or configuration.

If we store it in Git we can also store it as S-expressions from the
get-go. It's really easy to generate reports and tools from that.

No strong opinion either way on Google Sheets.