History of CMatrix? about cmatrix

[abishekvashok]

I don't actually remember the dates however lets collect information. It will be nice!

[livibetter]

I just read #1 and #6, it seems this repo was originally a mirror by @wyntau , that should be part of history as well if there was any development took place at the time ~2015(?)–2017.

However, the big issue for me is where were the historical commits? Since the copyright year in code indicated that CMatrix started in 1999.

I don't know how many released the original author Chris Allegretta had released, and if he also provided any VCS access. But if there is any commits that made by Chris, not just single tarball, then they should be included in this repo. Actually, even only with tarballs, they should also be manually imported with corresponding released dates as commit dates.

It might be too late to put them into master branch, as it will wreck all the forks, but we can always have a branch with the historical codes. Or the very least, creating release entries in GitHub releases tab for those old tarballs.

---

Aside (no need to read further, just some sentimental stuff)

To me history is important—as you can see why I created this issue—as well as in-repo/tarball docs, I have noticed many CAPSFILES have become/are dummy files, which pointing to this GitHub repo. I understand why we still have those, because otherwise autotools would complain.

Frankly, I wish more would understand GitHub doesn't last forever, at least not the biggest coding hub. Look at SoruceForge, it was the hub, but since GitHub became GitHub (probably before that), even Google abandoned their own Google Code, whose issue tracker was/is still better than GitHub's. And not just Google.

So, one day, GitHub would be overthrown by a new kid on the block. Issues aside, those releases notes you spent time to write in releases tab, they would not be carried over to new hub easily. And yes, we can relies on new hub's automatically generated Contribution/Contributer page, but it's not as good as a simple AUTHORS, because who are listed in that file means something. All those CAPSFILES are self-contained, and requiring no modern computer technology, they can be read on a three-decade-old computer without problems, a simple pager does the job.

A couple of years ago, I have transfered one repo to someone, in short time, those well-documented CHANGES by me was git rm'd, like I say, history is important, and I have no idea what's going on in that such said repo.

Some people consider CHANGES and CHANGELOG == git log, which is not true as many well-written CHANGELOG could attest. By the way, whoever has rewritten helper scripts to format git log into CHANGELOG should be *beep* *beeeep* *beeeeeeeeep*!

There are more one occasion that I want to find out when an option or feature is added, I looked for CHANGES or NEWS or RELEASENOTES or the likes, and I could always find the answer, with simple grep command. Conversely, more than once, after clicking lots of buttons and still couldn't find the answer, sometimes not even in commit logs, I've to resolve with git blame after I located the relevant piece in source code.

These days, many developers ain't taking any value out of documenting efforts, more often, a commit message is unnecessary as it says nothing.

Web, sometimes I really hate it, all those fancy HTML, people have forgot that the most informative knowledge can be conveyed with basics, and with ease and less painful when changes arise. But it's not like many of us are actually seeking for knowledge.

[abishekvashok]

I don't know how many released the original author Chris Allegretta had released, and if he also provided any VCS access. But if there is any commits that made by Chris, not just single tarball, then they should be included in this repo. Actually, even only with tarballs, they should also be manually imported with corresponding released dates as commit dates.

The tarball was provided. Hence i couldnt extra ct any commit data.

[abishekvashok]

Lets keep this we will do this.

[livibetter]

It's been a month, I'm closing this again, I'll appreciate if this would not get reopened.

---

@abishekvashok

I like to keep my PR and Issue (top bar of GitHub) clean, from my experience, this type of minor issue, if it doesn't get resolved in a week or two, it'd mysteriously take a long time, and I don't like ping someone when I am just passing by.

You probably are caught up in something, but I have lost the interest last time I closed. If this was something I could contribute, I'd have already submitted a PR than just closing it up.

I'd suggest that you (a) open your own, (b) make a ToDo (issue/file/wiki), or (c) make a Project and put this closed issue under ToDo column. Personally, I will go for last.