[aprssig] APRS tocalls.txt - practical steps

[Heikki Hannikainen]

On Fri, 11 Feb 2022, Steve Dimse wrote:

> I have no problem with you taking over allocating the IDs for now, if 
> you agree to yield in the future should a protocol group emerge.

Sure, like I wrote already: If an APRS standards committee / organisation 
develops later on, I'll be happy to pass on the responsibilty of 
maintaining the list to such a group. This is a fairly boring task that 
I'm more than happy to let someone else do. Which is one reason why I'd 
prefer to invite a couple of other people (preferably people with some 
prior experience with git and github) to help out and have commit 
privileges so that allocations could be made even if I'm away for a few 
weeks. Which is one reason why I'd like to do it on github.

In practical terms, I can set up an organisation/team in github, and pass 
that on to a suitable group when the time comes. For me, it does not 
matter if the group emerges in 1, 3 or 18 months; I can promise to do it 
at any time. I'd sure like to see it being an open organisation with a 
Code of Conduct, like Randy Hall and Scott Howard described, where people 
developing new things currently could have an impact.

If that group does not publish a machine-readable list (available in YAML 
and/or JSON), then I'll still have to maintain my duplicate copy, like I 
have done for the past 8 years, as I need the file for my software, so 
that it can detect the devices and show the make & model. I will still 
publish the list like before so that other developers can use it too, but 
I'll just stop accepting new allocations diretly and manually track 
changes from the upstream organisation, like I tracked Bob's file until 
now.

If that group publishes the list in machine-readable format, great, then I 
can just make my software download and use it automatically! This would be 
my favourite outcome.

There needs to be a single primary document, it'd be totally silly to have 
multiple diverging allocation lists.

The allocations list on github can be made visible on aprs.org in an 
automated fashion, so that it always shows the current list without manual 
work. It would be best if the team maintaining the allocations could 
publish updates independently, without a requirement that any single 
specific person is available to publish changes (like, myself, or Steve).

I'm volunteering to work on the allocations list because I've had to 
maintain a copy of the list *anyway* to make automated detection possible, 
and I will have to keep maintaining it unless someone else does it *and* 
publishes a machine-readable version.

  - Hessu, OH7LZB/AF5QT


>> On Feb 11, 2022, at 10:23 AM, Heikki Hannikainen <hessu at hes.iki.fi> wrote:
>>
>>
>> Hello,
>>
>> Sad news indeed, and I guess some practical things need to be sorted out soon. Here's one: tocalls and Mic-E identifiers for new apps and devices.
>>
>> I've been meaning to propose publicly that the APRS unique identifiers allocation (device identifiers / tocalls / mic-e IDs, and additional secondary symbol table extensions) tables would be maintained on Github, where a team of few people could maintain the master list, instead of having just one person do it. The machine-readable aprs-deviceid list [1], which I've been maintaining since 2013, which tracks tocalls.txt and is currently in sync with it, could serve as the new primary list for tocalls/mic-e. I'd just move it to a github organization and add a couple of additional maintainers there.
>>
>> Bob seemed happy with me maintaining the list (we discussed this a few times over email during the course of a couple years, and he said last March in an email about an additional symbol identifier that "Lets see if Hessu agrees. He is taking over assignments."), but I'd rather have a couple of others with permission to update, and a documented criteria for good additions, so that it wouldn't depend on my availability.
>>
>> The benefits of the git approach are:
>>
>> * There is a clear record of all changes and change requests
>> * The machine-readable database can be used directly in APRS applications to identify other apps based on packet contents, and the database can be updated automatically by just downloading the file in the app or during a build process
>> * Github supports multiple maintainers nicely, as it is a distributed development platform
>> * Git repositories, with complete revision history, can be easily backed up (by anyone, including yourself, from this public github repository) and moved from Github to some other place if necessary later on.
>>
>> Until now I have only added devices there only after they appeared in Bob's text file, and if someone tried requesting an entry directly to aprs-deviceid, I bounced them to Bob first.  The first request ticket to add new allocations already came in yesterday, but I've put it on hold for a bit.
>>
>> I can volunteer to set the github organisation up. If an APRS standards committee / organisation develops later on, I'll be happy to pass on the responsibilty of maintaining the list to such a group. I've licensed the files under the CC BY-SA 2.0 open source license, so technically it wouldn't need my permission anyway, if someone wanted to fork the database, and people would rather use the forked list instead. I chose the license so that other APRS developers could use the files freely in their applications, but it allows forks just as well.
>>
>> I propose that this shall be discussed over the weekend, and if there is some sort of consensus that I should do this, I'll start adding new allocations and setting up the other things some time next week.  If there isn't consensus and someone else would rather maintain tocalls.txt, then I'll refrain from allocating new identifiers for now.
>>
>> [1] https://github.com/hessu/aprs-deviceid
>>
>> The master list is edited in YAML (a machine-readable format itself):
>>
>> https://github.com/hessu/aprs-deviceid/blob/master/tocalls.yaml
>>
>> Which is then converted to JSON and XML with a script, and developers using this
>> data in their applications can then choose to read in one of the three formats,
>> depending on their preferences:
>>
>> https://github.com/hessu/aprs-deviceid/tree/master/generated
>>
>> In addition to these I'd write a script to automatically publish a pretty (well, at least less ugly) HTML table with the current allocations for humans to browse, updated every time the master list is changed.
>>
>> Changes are archived, like git does, and you can see some 3rd-party
>> contributions coming in as well already in the past:
>>
>> https://github.com/hessu/aprs-deviceid/commits/master
>>
>> All the changes and revisions are archived, so everyone can see what exactly was changed, and how. This is how most open source software is maintained these days (and a lot of closed source, as well).
>>
>> https://github.com/hessu/aprs-deviceid/commit/ac6c0436f85579b7b8e6ef345f41d771a2621213
>>
>> People have mostly submitted update requests as Github Issue tickets, and occasionally over direct email. Tickets are nice as there's a public track of change requests, and their resolutions.
>>
>> https://github.com/hessu/aprs-deviceid/issues?q=is%3Aissue+is%3Aclosed
>>
>>  - Hessu, OH7LZB / AF5QT, aprs.fi
>>