Apple II - Applications [PO] emailer v2.0.0's wrong CRC ?

[chown6471]

Hello TOSECDev.org team !

I collected the Apple II's emailer application from its github public repository located here : https://github.com/bobbimanners/emailler/tree/master/releases.

All the downloaded releases ranging from 0.9.1 to 2.1.9 matched the concerned TOSEC entries except for emailer v2.0.0.

Downloaded disk image file emailler-2.0.0.po has the following CRC value : fee094af, whereas the corresponding TOSEC entry's CRC value for this release is abfe2889.

Is the TOSEC entry's CRC value wrong or does this TOSEC entry refer to another variant of emailer v2.0.0 ?

Kind regards,

Chown

[mictlantecuhtle]

Well, I have to confess to being stumped by this one. I can only assume I downloaded a version which has since been replaced. There's some oddity with the internal file modification dates that I can't quite match up to any existing release though.

For now I've marked this version as [a] but I'm on the case and investigating further to see if I can figure out what's happened here.

[chown6471]

I also have to confess that I only focused on downloading file email-2.0.0.po that belongs to the project's git master branch, (stupidely and non-professionnally) forgetting that author Roberta Bobbi Webber-Manners actually published other branches and tags for this piece of software...

Your answer therefore pushed me to further investigate on my side: for each tag and branch of the emailer project, I downloaded file emailer-2.0.0.po whenever it exists, then I run a crc32 command on the downloaded files, in order to find out whether (by chance) one or several of them may exhibit TOSEC-2021-12-21's referenced CRC value abfe2889.

Here are the results returned by the command :

fee094af   emailler-v2.0.0_tag2.1.0.po
fee094af   emailler-v2.0.0_tag2.1.1.po
fee094af   emailler-v2.0.0_tag2.1.2.po
fee094af   emailler-v2.0.0_tag2.1.3.po
fee094af   emailler-v2.0.0_tag2.1.4.po
fee094af   emailler-v2.0.0_tag2.1.5.po
fee094af   emailler-v2.0.0_tag2.1.6.po
fee094af   emailler-v2.0.0_tag2.1.7.po
fee094af   emailler-v2.0.0_tag2.1.8.po
fee094af   emailler-v2.0.0_tag2.1.9.po
fee094af   emailler-v2.0.0_tag2.1.10.po
fee094af   emailler-v2.0.0_tag2.1.11.po
fee094af   emailler-v2.0.0_tag2.1.12.po
fee094af   emailler-v2.0.0_tag2.1.13.po
fee094af   emailler-v2.0.0_release-develop.po
fee094af   emailler-v2.0.0_release-master.po

Conclusion 1: so far, unless I missed one or several published files, it seems that all the downloaded email-2.0.0.po files have the same  fee094af CRC value, whatever the tag or release they originate from. It would therefore be very interesting to find out where your email-2.0.0.po file version comes from.

Conclusion 2: as you suggested, the initial file you downloaded may have been replaced by the version I downloaded later. Concerning this point, you can notice that author Roberta Bobbi Webber-Manners did not produce an email-2.0.0.po file in published tag "email-2.0.0". I mean: at today's date, this file does not show up in this tag. A possible explanation could be she published this tag with an existing email-2.0.0.po file (the one you downloaded with CRC value abfe2889), then for some (yet) unknown reason, she may have deleted this tag then published it again later, forgetting to include file email-2.0.0.po file; then she would have published file email-2.0.0.po in the next tag (email-2.1.0) with CRC value fee094af.

I am not 100% certain this explanation is THE explanation, but it could be one of those nightmare git-related scenarios that may have happened.

Besides these two conclusions above, I am attracting your atttention on the following point you've probably been deeply thking of before.... just giving my personal viewpoint on this : given the "odd" ways git repos are administered by some software authors, I am really wondering whether such ways are compatible with the TOSEC philosophy, i.e. given the number of temporary tags produced by dev teams (tens or hundreds), does it really make sense for TOSEC to collect all of these temporary tags, most of which are not even even considered by the authors for production purpose? For example, in the case of of the emailer software project, does it make sense to include release 2.0.0 in TOSEC whereas this file only shows up later in published tag 2.1.0?  

As far as I am concerned as a software developer and as a git casual practicioner, I tend to create public tags only for temporary dev or test purpose, naming them using nicknames and/or dates, whereas once a tag is "stable" for prod, I then create a branch and name it using the usual release naming conventions (1.2.0, 2.2.3, etc.). IMHO, only such branches should be realistically considered to be included in TOSEC's database. Otherwise, the risk for TOSEC with such ongoing software projects like project emailer is that on the medium/long term TOSEC may become a overcroweded Git annex that references every temporary tags of such projects.... Would it make sense?? Is it really TOSEC's purpose to behave as a SCMS ?


Hope this investigation and my rhetoric questions above will help your own investigations of this "weird" case


Btw, I forgot to tell you something I really wanted to tell TOSEC's hardworkers since all those years I've been following this project: thanks for your great work !

Kind regards,

Chown

[mictlantecuhtle]

Wow, thank you for the very comprehensive investigation there, that's certainly helped me out! I'd definitely still like to do some more checks on my own just to make sure I haven't missed anything, but I'm coming to one of two conclusions here:

1) I managed to grab a file that was published in haste or in error by the author and swiftly deleted/replaced, thus one which was probably never intended for public release
2) I myself have managed to accidentally alter the file in some way prior to including it in the database

I'd like to think I'm generally careful enough to avoid (2) as an option but it's possible I've slipped up somewhere in my process.

As far as your wider philosophical point, I tend to agree and personally wouldn't go to the effort to grab every individual tag in the way you describe. When I'm getting files from github projects I would generally focus only on the releases page (in this case https://github.com/bobbimanners/emailler/releases). As I understand it, these would usually be the proper, "official" releases of the project files rather than WIP / test builds.

I mean ultimately collecting those sorts of builds is technically in scope for TOSEC as a project, but in terms of where I'd like to direct my efforts that doesn't seem worthwhile. In a similar fashion, I wouldn't like to begin thinking about how many possible variant ROMs of A Link to the Past one could produce using https://alttpr.com/en/customizer#home, but I certainly have no intention of trying to generate all possible combinations and DATting them.

ETA: Thanks for the kind words and thank you for all your contributions over the past days! It's great to know that someone else is looking at what we produce. If you've any interest in becoming more formally involved in the project we have more work to do than can be done in a lifetime so more help is always welcome!

[chown6471]

I totally agree with your vision of collecting new items.

Actually before starting this "wider philosophical point" I should have mentioned first that I started getting interested in and making use of TOSEC's database some year back between 2007 and 2010 (cannot exactly remember when, as I am getting old now...). What I do remember is that 10 or 15 years ago, collecting artefacts for retro-platforms mainly consisted of collecting old (i.e. already finalized, produced, and published) software items. Although items such as "homebrew" games and stuff already existed at that time, one would generally notice that in many cases, their developers used to make them available for downloads as a finite count of releases for which you could find simple corresponding download links on the developer's home pages or in some dedicated forums where they were active. Therefore, as I undertsand it, even homebrew artefacts could be reasonably considered and collected as regular retro-roms. This (and I am coming to the above discussion), may differ from nowadays' situation where it seems (am I wrong?) that a  growing number of individuals are getting interested in retrogaming (and in retrocomputing), some of them now starting to produce not only homebrew stuff but new pieces of software, using modern SCMS to manage, maintain their source codes and/or publish versioned artefacts. Therefore, going a little bit beyond the sole scope of github repos used to maintain such code, I was simply poiting out that concerning such pieces of software, TOSEC workers maybe now be facing a growing number of situations where they have to collect WIP artefacts, and that collecting such items may require different (or modified) principles in order to avoid a situation where TOSEC would somehow become a registration annex of the (Git, CVS, SVN, etc.) used to manage such pieces of software.

From your explanation, I could read you have a clear and neat vision of the collecting principles to be applied. 

Concerning a more formal involvment in the project, I am affraid this is not possible at this time, as I am the slave of my own ongoing projects. Nevertheless, since you seem to appreciate my contributions for the dats, you can count on my future contributions anytime some information should be reported to you and if required, on any technical investigation I may be in a position to perform to accelerate the correction process.

Kind regards,

Chown