Minor cleanup #253

a1346054 commented 2021年08月25日 04:15:59 +02:00 (Migrated from github.com)

No description provided.

smxi commented 2021年08月25日 05:11:42 +02:00 (Migrated from github.com)

You know, I have to give you credit, usually when I get these types of pull requests, I reject them because they are so badly done, but these are all fine. The only error is having the pull request for inxi master, not inxi-perl pinxi branch. inxi master never gets pull requests, everything always goes to the dev branch pinxi. In this case I'll just merge these into the inxi perl branch. Not one silly or dumb fix in the bunch, congratulations, and all good to have fixed, again, I'm impressed, thanks. In this case since they don't touch pinxi or inxi itself, I'll just merge them into inxi master however since that's easier.

You know, I have to give you credit, usually when I get these types of pull requests, I reject them because they are so badly done, but these are all fine. The only error is having the pull request for inxi master, not inxi-perl pinxi branch. inxi master never gets pull requests, everything always goes to the dev branch pinxi. In this case I'll just merge these into the inxi perl branch. Not one silly or dumb fix in the bunch, congratulations, and all good to have fixed, again, I'm impressed, thanks. In this case since they don't touch pinxi or inxi itself, I'll just merge them into inxi master however since that's easier.

smxi commented 2021年08月25日 05:32:28 +02:00 (Migrated from github.com)

There was one error, removing /pty was incorrect, that is/was intended, it's based on a recent change that corrected some tty vs pty behaviors.

There was one error, removing /pty was incorrect, that is/was intended, it's based on a recent change that corrected some tty vs pty behaviors.

smxi commented 2021年08月25日 05:35:13 +02:00 (Migrated from github.com)

Note that I usually don't take pull requests, and technically never for master, so I didn't get this quite right. The changes are now in inxi-perl branch however, I'll double check that since I basically never use git this way. For future reference, inxi is NOT the active development branch, inxi-perl/pinxi is, though it doesn't have some of the files I think. Not sure, as noted, I don't actually use git, github this way so I have to actually think about how to get stuff in.

Note that I usually don't take pull requests, and technically never for master, so I didn't get this quite right. The changes are now in inxi-perl branch however, I'll double check that since I basically never use git this way. For future reference, inxi is NOT the active development branch, inxi-perl/pinxi is, though it doesn't have some of the files I think. Not sure, as noted, I don't actually use git, github this way so I have to actually think about how to get stuff in.

smxi commented 2021年08月25日 05:45:45 +02:00 (Migrated from github.com)

Yeah, basically this should have been one fix to the README.txt on master, one to pinxi and pinxi.1 in inxi-perl, one to the LICENSE.txt in I can't remember where, as noted, I really do not do things this way, I will have to go back and correct some errors I just made.

Yeah, basically this should have been one fix to the README.txt on master, one to pinxi and pinxi.1 in inxi-perl, one to the LICENSE.txt in I can't remember where, as noted, I really do not do things this way, I will have to go back and correct some errors I just made.

smxi commented 2021年08月25日 05:58:36 +02:00 (Migrated from github.com)

Just so you understand it, I don't use github as the master repo, and I definitely do not use git branches for development, it's only a convenience for maintainers who need git / github to be happy and satisfy distro policies, and to make it easier for users to file issue reports.

The actual way inxi development works is not with git branches at all, it started out using real actual svn branches, which are not virtual things like in git, they are real directories with real files in them. I still use that method but it's hidden behind some scripting that pretends that git can do that, which it actually can't. So the inxi-perl/pinxi and pinxi.1 files are the actual real active development branch files for inxi and inxi.1.

In this case, not much work had happened to pinxi or pinxi.1 so it was easy enough to update those, but normally I would have rejected this since it's not practical or possible to actually merge random patches into pinxi using inxi diffs, sometimes there might be a thousand lines difference, or more. Again, any illusion that this is a git standard repo is just that, an illusion, and not created for my benefit since I don't like the way git works at all.

This is why you can run and develop inxi, pinxi, inxi.1, and pinxi.1, totally discreetly, without any interference between the two, ever, changes always migrate from pinxi to inxi, never the other way around. It's also why pinxi has its own configurations, its own updater, and can be run, and is, by me, run as the primary inxi version, I never actually use inxi at all, which is the secret to understand if you work on pinxi ever, but never work on pinxi in general without talking to me about it first because I don't want to deal with tracking changes when I am doing aggressive development.

3.3.06, and, more important, pinxi and pinxi.1, are kind of a stable resting point so that wasn't an issue, but normally it would be. pinxi has only a few small changes right now, which is unusual.

It works like this: pinxi/pinxi.1 from their actual inxi-perl directory are cp to the trunk inxi inxi.1 ONLY at the time of release of next inxi version, never otherwise, which are then copied to inxi git directory master branch, I literally do not touch git, it's all scripted, and invisible to me except for when git breaks or something and I have to fix it. In other words, I never use merge, ever, not for any reason, I actually use cp as a one way update to certain files when I have to handle a github pull request, if it's practical.

It's not really intended to go back the other way, and patches to inxi/inxi.1 would normally be rejected because those are not the development versions of inxi, pinxi and pinxi.1 are. inxi and inxi.1 are dead ends, they don't go backwards, and are not actually ever merged with anything else, they are just static in most cases.

I can't make git be like svn, so I have to work around it, and github is just a frontend for users, I don't use it at all, except rarely to check changes or something. I know this isn't how most people use git, but I never wanted to use git, I wanted svn, which actually fits my work flow exactly. So I made git act like svn as much as practical, which can be confusing to people who have only interacted with git, and like it, which I don't, so I avoid it as much as possible.

Note that while this might seem odd, the fact is, free software isn't a job for me here, it's something I do because I like it, and since I dislike git intensely, and thought, and still think, svn was a far superior development tool for someone with my type of development work flow, using git in the way people are used to would be silly for me to do since jobs are about doing things I don't like doing and getting paid for that, hobbies/fun are about doing things the way I want to do them.

Oh, and github is also one of the ways -U can update either pinxi or inxi, but NEVER using git, lol, which is a silly way to update a file or two, it uses curl/wget, in other words, git is not really in my development process at all, it's just a necessary evil I have to work with/around for other people's sake, not mine.

Just so you understand it, I don't use github as the master repo, and I definitely do not use git branches for development, it's only a convenience for maintainers who need git / github to be happy and satisfy distro policies, and to make it easier for users to file issue reports. The actual way inxi development works is not with git branches at all, it started out using real actual svn branches, which are not virtual things like in git, they are real directories with real files in them. I still use that method but it's hidden behind some scripting that pretends that git can do that, which it actually can't. So the inxi-perl/pinxi and pinxi.1 files are the actual real active development branch files for inxi and inxi.1. In this case, not much work had happened to pinxi or pinxi.1 so it was easy enough to update those, but normally I would have rejected this since it's not practical or possible to actually merge random patches into pinxi using inxi diffs, sometimes there might be a thousand lines difference, or more. Again, any illusion that this is a git standard repo is just that, an illusion, and not created for my benefit since I don't like the way git works at all. This is why you can run and develop inxi, pinxi, inxi.1, and pinxi.1, totally discreetly, without any interference between the two, ever, changes always migrate from pinxi to inxi, never the other way around. It's also why pinxi has its own configurations, its own updater, and can be run, and is, by me, run as the primary inxi version, I never actually use inxi at all, which is the secret to understand if you work on pinxi ever, but never work on pinxi in general without talking to me about it first because I don't want to deal with tracking changes when I am doing aggressive development. 3.3.06, and, more important, pinxi and pinxi.1, are kind of a stable resting point so that wasn't an issue, but normally it would be. pinxi has only a few small changes right now, which is unusual. It works like this: pinxi/pinxi.1 from their actual inxi-perl directory are cp to the trunk inxi inxi.1 ONLY at the time of release of next inxi version, never otherwise, which are then copied to inxi git directory master branch, I literally do not touch git, it's all scripted, and invisible to me except for when git breaks or something and I have to fix it. In other words, I never use merge, ever, not for any reason, I actually use cp as a one way update to certain files when I have to handle a github pull request, if it's practical. It's not really intended to go back the other way, and patches to inxi/inxi.1 would normally be rejected because those are not the development versions of inxi, pinxi and pinxi.1 are. inxi and inxi.1 are dead ends, they don't go backwards, and are not actually ever merged with anything else, they are just static in most cases. I can't make git be like svn, so I have to work around it, and github is just a frontend for users, I don't use it at all, except rarely to check changes or something. I know this isn't how most people use git, but I never wanted to use git, I wanted svn, which actually fits my work flow exactly. So I made git act like svn as much as practical, which can be confusing to people who have only interacted with git, and like it, which I don't, so I avoid it as much as possible. Note that while this might seem odd, the fact is, free software isn't a job for me here, it's something I do because I like it, and since I dislike git intensely, and thought, and still think, svn was a far superior development tool for someone with my type of development work flow, using git in the way people are used to would be silly for me to do since jobs are about doing things I don't like doing and getting paid for that, hobbies/fun are about doing things the way I want to do them. Oh, and github is also one of the ways -U can update either pinxi or inxi, but NEVER using git, lol, which is a silly way to update a file or two, it uses curl/wget, in other words, git is not really in my development process at all, it's just a necessary evil I have to work with/around for other people's sake, not mine.

a1346054 commented 2021年08月25日 11:15:42 +02:00 (Migrated from github.com)

Thank you very much for the explanation, I'll take it into account if I spot anything else. I really like what you're doing and wanted to give back in some way I can, and remembered there were various typos in the manpage. So I went ahead with fixing that, and when I was doing that I spotted these other little things.

Thank you very much for the explanation, I'll take it into account if I spot anything else. I really like what you're doing and wanted to give back in some way I can, and remembered there were various typos in the manpage. So I went ahead with fixing that, and when I was doing that I spotted these other little things.

smxi commented 2021年08月25日 20:02:22 +02:00 (Migrated from github.com)

The easiest for me is you work on one file then push that, then I can decide where it goes. man page reviews are particularly welcome because, as you found, it's always got errors in it. The double spacing in man page was particularly annoying to me because I actually tried to get rid of all those recently in an update but obviously missed a lot. Actual work on pinxi should be avoided beyond typos etc unless we talk for a bit about it, because it's'very complicated, and I generally have a faint roadmap in my head for what features might be coming, and various refactors I might do if I get super bored, or hit an issue/feature that just won't work without a refactor. There's only one core refactor I have in mind, but it is not pressing, it's more to make the logic cleaner than due to any actual issues, but it's very difficult to do and does't really solve any real issues so it's on the back burner.

Also note the ongoing issues, those don't get much attention, but all of them are useful additions to pinxi, finding new desktops/wm's that exist in the real world but inxi does not handle, new cpu micro architectures, new distro id/derived distro system base, these are all easy to do but are just tedious because they require in most cases setting up a virtual machine to figure out how to detect and handle those things. Once in a while I will check those, but it's boring and I don't do it very often. CPU microarch I just updated because there was finally some movement in that area after significant delays over past year. Disk vendor ids are tedious to do but require back end scripting and good regular expression ability etc so I can't hand that one to anyone unfortunately

Basically if you push one single file I can either merge it, if appropriate, or just do the changes manually, which is what I did with pinxi and inxi typos.

I know the way I do this stuff is not clear, but the easiest way to understand it is if you understand how svn works, which is actual file/directory based, not virtual like git is. pinxi in particular is important to understand, and pinxi.1 man page to a lesser extent, because those are always by definition next inxi/inxi.1, but are never 'merged' to the master branch, they are totally standalone. To me, nothing is more time wasting and maddening than trying to resolve merge failures or errors in version control, that's why I don't ask version control to do that, and just use cp to overwrite inxi and inxi.1 then commit those changes. If I had realized I would end up using pinxi after the initial rewrite phase to perl was completed as the primary development version, I would probably have set up this source/version control differently, but then people would have gotten more confused I think and thought that pinxi was a fork of inxi or something, which has happened before in terms of people not understanding.

The easy way to understand it is that pinxi is a standalone program that has a standalone man page, which now and then, when stable and complete in terms of fixes, updates, etc, is copied over to the inxi master branch, but never merged. In svn this is how svn works natively, so you don't need to do any contortions to make that happen, in git you really have to bend git in a direction it doesn't like going to make that work in one repo with branches. inxi itself exists mainly for distro packagers and maintainers, and for users to update to latest stable / current using -U if they so chose. To put it another way, as with Debian sid/testing, which now and then are rolled up into next stable, pinxi is rolling release, and inxi is the stable branch. I don't use stable inxi for much of anything beyond checking it has no errors, or just to compare how the changes are working out between pinxi and inxi.

Also note the recent inxi.changelog upgrades, which made it, finally, the definitive change document for all development, and I finally after too many years now also update it as I add features or fix issues to be much more readable, and to give a much better and more scan-able change history, a very wordy one, lol.

Having a true standalone development branch is absolutely critical for inxi development, in fact, I have absolutely no idea how many projects can even develop new features without having such an option, often new features in inxi may be checked by many, many people on forums, behind the scenes, etc, and it's always run next to, besides, inxi. pinxi can have bugs in it, and often does for brief periods of time, though I try to make it so it's not actually so broken the -U self updater doesn't work, that's how I always update, I never use git for anything beyond its intended role as a version control system, with tagged releases only because distros insist on having a tagged release for a package to point to.

Technically I guess I could have just made one big source repo with all the branch folders included, but I didn't actually know pinxi/pinxi.1 would become standalone programs that would be used for all development when I created them, but technically, pinxi has all the docs in it too, so I didn't do that great a job setting this up in git initially, but the repo was cloned from googlecode svn and that's more or less how it worked if I remember right. Not sure. SVN being actual filesystem/path based, would let you say, give me inxi/trunk, or inxi/branches/one/pinxi, or inxi/docs, or whatever you wanted, and it was nice and clear and non ambiguous about how that all works, and fit perfectly with that type of development work flow.

I didn't really want the docs and other stuff to clutter up the inxi master branch however, but maybe I should have, I don't know, as noted, I liked how svn did it with a trunk and whatever other branches you wanted to add as part of the same repo, and wanted to retain that.

But I still don't think the /docs in inxi-perl should be in inxi, they are more about development etc than a finished master branch, and the docs branch is not really related to inxi at all except it has some of the webpages that document it, that's of no interest to maintainers or packagers.

The easiest for me is you work on one file then push that, then I can decide where it goes. man page reviews are particularly welcome because, as you found, it's always got errors in it. The double spacing in man page was particularly annoying to me because I actually tried to get rid of all those recently in an update but obviously missed a lot. Actual work on pinxi should be avoided beyond typos etc unless we talk for a bit about it, because it's'very complicated, and I generally have a faint roadmap in my head for what features might be coming, and various refactors I might do if I get super bored, or hit an issue/feature that just won't work without a refactor. There's only one core refactor I have in mind, but it is not pressing, it's more to make the logic cleaner than due to any actual issues, but it's very difficult to do and does't really solve any real issues so it's on the back burner. Also note the ongoing issues, those don't get much attention, but all of them are useful additions to pinxi, finding new desktops/wm's that exist in the real world but inxi does not handle, new cpu micro architectures, new distro id/derived distro system base, these are all easy to do but are just tedious because they require in most cases setting up a virtual machine to figure out how to detect and handle those things. Once in a while I will check those, but it's boring and I don't do it very often. CPU microarch I just updated because there was finally some movement in that area after significant delays over past year. Disk vendor ids are tedious to do but require back end scripting and good regular expression ability etc so I can't hand that one to anyone unfortunately Basically if you push one single file I can either merge it, if appropriate, or just do the changes manually, which is what I did with pinxi and inxi typos. I know the way I do this stuff is not clear, but the easiest way to understand it is if you understand how svn works, which is actual file/directory based, not virtual like git is. pinxi in particular is important to understand, and pinxi.1 man page to a lesser extent, because those are always by definition next inxi/inxi.1, but are never 'merged' to the master branch, they are totally standalone. To me, nothing is more time wasting and maddening than trying to resolve merge failures or errors in version control, that's why I don't ask version control to do that, and just use cp to overwrite inxi and inxi.1 then commit those changes. If I had realized I would end up using pinxi after the initial rewrite phase to perl was completed as the primary development version, I would probably have set up this source/version control differently, but then people would have gotten more confused I think and thought that pinxi was a fork of inxi or something, which has happened before in terms of people not understanding. The easy way to understand it is that pinxi is a standalone program that has a standalone man page, which now and then, when stable and complete in terms of fixes, updates, etc, is copied over to the inxi master branch, but never merged. In svn this is how svn works natively, so you don't need to do any contortions to make that happen, in git you really have to bend git in a direction it doesn't like going to make that work in one repo with branches. inxi itself exists mainly for distro packagers and maintainers, and for users to update to latest stable / current using -U if they so chose. To put it another way, as with Debian sid/testing, which now and then are rolled up into next stable, pinxi is rolling release, and inxi is the stable branch. I don't use stable inxi for much of anything beyond checking it has no errors, or just to compare how the changes are working out between pinxi and inxi. Also note the recent inxi.changelog upgrades, which made it, finally, the definitive change document for all development, and I finally after too many years now also update it as I add features or fix issues to be much more readable, and to give a much better and more scan-able change history, a very wordy one, lol. Having a true standalone development branch is absolutely critical for inxi development, in fact, I have absolutely no idea how many projects can even develop new features without having such an option, often new features in inxi may be checked by many, many people on forums, behind the scenes, etc, and it's always run next to, besides, inxi. pinxi can have bugs in it, and often does for brief periods of time, though I try to make it so it's not actually so broken the -U self updater doesn't work, that's how I always update, I never use git for anything beyond its intended role as a version control system, with tagged releases only because distros insist on having a tagged release for a package to point to. Technically I guess I could have just made one big source repo with all the branch folders included, but I didn't actually know pinxi/pinxi.1 would become standalone programs that would be used for all development when I created them, but technically, pinxi has all the docs in it too, so I didn't do that great a job setting this up in git initially, but the repo was cloned from googlecode svn and that's more or less how it worked if I remember right. Not sure. SVN being actual filesystem/path based, would let you say, give me inxi/trunk, or inxi/branches/one/pinxi, or inxi/docs, or whatever you wanted, and it was nice and clear and non ambiguous about how that all works, and fit perfectly with that type of development work flow. I didn't really want the docs and other stuff to clutter up the inxi master branch however, but maybe I should have, I don't know, as noted, I liked how svn did it with a trunk and whatever other branches you wanted to add as part of the same repo, and wanted to retain that. But I still don't think the /docs in inxi-perl should be in inxi, they are more about development etc than a finished master branch, and the docs branch is not really related to inxi at all except it has some of the webpages that document it, that's of no interest to maintainers or packagers.

smxi commented 2021年08月25日 20:54:48 +02:00 (Migrated from github.com)

'branches' review:

• 'docs' - not actual docs, but mostly smxi.org html pages, only inxi-options.htm and inxi-man.htm tend to be up to date because I update those before or during every new inxi release so they match current master inxi options/man info.

• 'inxi-perl' - current development, note that its 'docs' directory is always out of date, and generally only meant for active developers, and much of it is out of date, and irrelevant, some might be things I used for a bit and don't use anymore, it varies, and largely does not matter, it's only a developer reference, which is why it does not belong in the master branch. There are some other backend tools which in theory I should put up too since you can't actually develop some features of inxi without them, but they are better suited for a private, not public, inxi repo, which I don't have, but maybe should make. inxi-perl was the original development branch for next inxi, 3.0, the perl version, which is why pinxi is called pinxi, perl inxi, though I liked the name and kept it, as noted, as dev version since it's easy to remember and tell it apart from inxi.

• inxi-legacy is binxi, and should have been in its own source repo, that's bash/gawk inxi, it's never touched or updated, it's a historical document only.

• inxi-c was an experiment that never went anywhere, a dead end

• one, two - not used anymore, used to be in the old days, I should probably remove those, though leave them just on off chance someone wants to do a branch one/two for a new feature. Note that inxi/pinxi -U support updating from these branches, as well as from smxi.org dev server, which is used sometimes on aggressive development where githubs throttling of many commits in a row makes remote updating a pain. -U 3 updates from smxi.org directly, but should never be used unless you are asked to do so, sometimes extreme changes that may fail are loaded to smxi.org so remote testers can check them, or very active development that doesn't need to be version control tracked since it will change so much. The basic idea is to copy over inxi/inxi.1 there (one/two predate pinxi, which is why I should probably get rid of them, all active stuff should always be done on pinxi as base)

• tarballs, I always forget to update that, the idea is that with each major version update, a tarball of the last committed version of the previous release is stored there. I forget to update that one almost always, so that's mostly for legacy versions of inxi, which are kind of useful to check now and then. Once I started using 'tagging' that became largely unnecessary, so it's mostly useful for earlier versions of inxi.

• xiin - that's the old python debugger, which of course totally failed one day on a python upgrade, which was one of many reasons inxi was moved to perl, well, ok, plus perl debugger is about 10x faster than the python one, and is builtin to inxi/pinxi, not an external part that has to be downloaded. This is also kept only as a historical reference, and as a great example of why python will never be used for anything I do that I want to last over years.

• wiki - I can't remember, I think it's the one page of the github wiki, or maybe it's the original googlecode one, another reason I don't put actual doc pages on github, each one of these uses its own documentation syntax, and html or .txt are better than all of them and don't require redoing it all the time, or if source repo is changed, for example, if inxi moves to gitlab etc. Note that all inxi docs are done either in real html using the template and css in 'docs' branch, or are straight .txt files. no other formats are ever used, particularly not .md, because I don't need to have a third and largely useless documentation format to track and maintain.

A key concept to understand about pinxi/inxi development is just how much testing on multiple systems matters, all computer data is random and cannot be relied on in terms of syntax or structure or location or consistency, therefore multiple tests on a wide variety of systems are required for initial alpha testing of new features, and retesting on updates or refactors. BSD stuff I think was tested on maybe 20 different bsds over the process, and in the past, a similar number were used, on various remote systems and different testers running various systems on their end, all shooting non stop --debugger datasets, which are the primary development tool used for inxi features.

'branches' review: * 'docs' - not actual docs, but mostly smxi.org html pages, only inxi-options.htm and inxi-man.htm tend to be up to date because I update those before or during every new inxi release so they match current master inxi options/man info. * 'inxi-perl' - current development, note that its 'docs' directory is always out of date, and generally only meant for active developers, and much of it is out of date, and irrelevant, some might be things I used for a bit and don't use anymore, it varies, and largely does not matter, it's only a developer reference, which is why it does not belong in the master branch. There are some other backend tools which in theory I should put up too since you can't actually develop some features of inxi without them, but they are better suited for a private, not public, inxi repo, which I don't have, but maybe should make. inxi-perl was the original development branch for next inxi, 3.0, the perl version, which is why pinxi is called pinxi, perl inxi, though I liked the name and kept it, as noted, as dev version since it's easy to remember and tell it apart from inxi. * inxi-legacy is binxi, and should have been in its own source repo, that's bash/gawk inxi, it's never touched or updated, it's a historical document only. * inxi-c was an experiment that never went anywhere, a dead end * one, two - not used anymore, used to be in the old days, I should probably remove those, though leave them just on off chance someone wants to do a branch one/two for a new feature. Note that inxi/pinxi -U support updating from these branches, as well as from smxi.org dev server, which is used sometimes on aggressive development where githubs throttling of many commits in a row makes remote updating a pain. -U 3 updates from smxi.org directly, but should never be used unless you are asked to do so, sometimes extreme changes that may fail are loaded to smxi.org so remote testers can check them, or very active development that doesn't need to be version control tracked since it will change so much. The basic idea is to copy over inxi/inxi.1 there (one/two predate pinxi, which is why I should probably get rid of them, all active stuff should always be done on pinxi as base) * tarballs, I always forget to update that, the idea is that with each major version update, a tarball of the last committed version of the previous release is stored there. I forget to update that one almost always, so that's mostly for legacy versions of inxi, which are kind of useful to check now and then. Once I started using 'tagging' that became largely unnecessary, so it's mostly useful for earlier versions of inxi. * xiin - that's the old python debugger, which of course totally failed one day on a python upgrade, which was one of many reasons inxi was moved to perl, well, ok, plus perl debugger is about 10x faster than the python one, and is builtin to inxi/pinxi, not an external part that has to be downloaded. This is also kept only as a historical reference, and as a great example of why python will never be used for anything I do that I want to last over years. * wiki - I can't remember, I think it's the one page of the github wiki, or maybe it's the original googlecode one, another reason I don't put actual doc pages on github, each one of these uses its own documentation syntax, and html or .txt are better than all of them and don't require redoing it all the time, or if source repo is changed, for example, if inxi moves to gitlab etc. Note that all inxi docs are done either in real html using the template and css in 'docs' branch, or are straight .txt files. no other formats are ever used, particularly not .md, because I don't need to have a third and largely useless documentation format to track and maintain. A key concept to understand about pinxi/inxi development is just how much testing on multiple systems matters, all computer data is random and cannot be relied on in terms of syntax or structure or location or consistency, therefore multiple tests on a wide variety of systems are required for initial alpha testing of new features, and retesting on updates or refactors. BSD stuff I think was tested on maybe 20 different bsds over the process, and in the past, a similar number were used, on various remote systems and different testers running various systems on their end, all shooting non stop --debugger datasets, which are the primary development tool used for inxi features.

a1346054 commented 2021年08月26日 11:50:20 +02:00 (Migrated from github.com)

Thank you so much for this information, it is fascinating to read. It would definitely be worth it including this, or linking to it, in some CONTRIBUTING file in all the relevant repositories, so that everyone knows this for the future.

Thank you so much for this information, it is fascinating to read. It would definitely be worth it including this, or linking to it, in some CONTRIBUTING file in all the relevant repositories, so that everyone knows this for the future.

smxi commented 2021年08月26日 20:55:09 +02:00 (Migrated from github.com)

For me, sometimes when I find something is very difficult to explain, it also suggests that the underlying issues maybe should be revisited. However, sadly, as with your quite good fixes, the number of people who will actually read such things is so tiny that it largely doesn't matter. Even you, who clearly have good reading/proofreading skills, missed that the readme clearly says use pinxi, not inxi for all pull requests.

I was thinking about this this morning, and may do some very conservative changes, splitting binxi [legacy inxi] into its own branch would not be a bad idea for example since that doesn't need to maintain anything in terms of urls, though in theory, users can update binxi from binxi repos if they so chose, though ti's pointless, unless someone had a pre 2.3.56 inxi and wants to update to the last release of that legacy branch.

I've tried writing contributor stuff, coding standards, etc, but nobody ever looks at it, and I don't keep it current, every piece of documentation requires work over years to keep current, and it's just more stuff people don't read, sad to say.

But for your own interest, the inxi-perl/docs has some very useful stuff in it, those are my actual developer notes, and do NOT require proofreading since it doesn't matter, and is more work that doesn't realy help anyone. But they provide a lot of valuable resources, some of which used to be in inxi comments, but that got so cluttered I moved almost all of those things to various doc files. Those doc files are the actual contributor notes, for example, invaluable data on desktop syntax/detections, hundreds of links for different feature data sources, and so on.

Note that in general nobody reads the README to discover that fact from what I can see so adding one more thing nobody will read, lol, is largely pointless.

But I was thinking about this, and just reviewing and posting the branch real info was a nice reminder of what is really there, and moving binxi to its own repo, and moving docs to its own repo, were the ones that jumped out at me, so I may do that. I don't know how to handle legacy features like xiin, inxi-c, and wiki however, maybe a separate repo that is just inxi-misc? Actually maybe that is how to handle the various irrelevant branches?

At least that would require less explanation and lean up the core branches to only active stuff?

Thanks for reading and responding, I haven't revisited this stuff in a long time, but have been working on docs, inxi.changelog in particular got a lot of work when I decided to make that to a really more serious and consistent and formatted change document, before it was sort of randomly formatted, and hard to scan.

Feel free to keep the conversation going, anytime anyone actually reads these explanations I'm somewhat impressed, because they are largely me, here, now, rethinking these things in real time, lol.

Things that should not change:

inxi-perl/pinxi / pinxi.1 - this is used by people who know that if they want current dev inxi, they should run pinxi and skip inxi, and use pinxi -U to keep their pinxi up to date, and pinxi -U works as expected always, so that's an actual living used branch, and is the only branch I actually use beyond double checking changes and making sure features are the same between inxi / pinxi when core logic has changed, etc, or checking that inxi bugs or issues are fixed in pinxi.

And if that were split it would be virtually impossible to get people to grasp that pinxi is the development branch of inxi, so that one has to stay.

but the other non dev branches maybe could be moved, maybe I'll look into how to make git do that, it doesn't sound too hard, but probably will end up being hard anyway since git rarely works easily for difficult situations.

inxi-misc could have for example:

README.txt
binxi/binxi
binxi/binxi.1
xiin/xiin.py
inxi-c/inxi or whatever that has in it
wiki/wiki stuff

I'll think about this.

For me, sometimes when I find something is very difficult to explain, it also suggests that the underlying issues maybe should be revisited. However, sadly, as with your quite good fixes, the number of people who will actually read such things is so tiny that it largely doesn't matter. Even you, who clearly have good reading/proofreading skills, missed that the readme clearly says use pinxi, not inxi for all pull requests. I was thinking about this this morning, and may do some very conservative changes, splitting binxi [legacy inxi] into its own branch would not be a bad idea for example since that doesn't need to maintain anything in terms of urls, though in theory, users can update binxi from binxi repos if they so chose, though ti's pointless, unless someone had a pre 2.3.56 inxi and wants to update to the last release of that legacy branch. I've tried writing contributor stuff, coding standards, etc, but nobody ever looks at it, and I don't keep it current, every piece of documentation requires work over years to keep current, and it's just more stuff people don't read, sad to say. But for your own interest, the inxi-perl/docs has some very useful stuff in it, those are my actual developer notes, and do NOT require proofreading since it doesn't matter, and is more work that doesn't realy help anyone. But they provide a lot of valuable resources, some of which used to be in inxi comments, but that got so cluttered I moved almost all of those things to various doc files. Those doc files are the actual contributor notes, for example, invaluable data on desktop syntax/detections, hundreds of links for different feature data sources, and so on. Note that in general nobody reads the README to discover that fact from what I can see so adding one more thing nobody will read, lol, is largely pointless. But I was thinking about this, and just reviewing and posting the branch real info was a nice reminder of what is really there, and moving binxi to its own repo, and moving docs to its own repo, were the ones that jumped out at me, so I may do that. I don't know how to handle legacy features like xiin, inxi-c, and wiki however, maybe a separate repo that is just inxi-misc? Actually maybe that is how to handle the various irrelevant branches? At least that would require less explanation and lean up the core branches to only active stuff? Thanks for reading and responding, I haven't revisited this stuff in a long time, but have been working on docs, inxi.changelog in particular got a lot of work when I decided to make that to a really more serious and consistent and formatted change document, before it was sort of randomly formatted, and hard to scan. Feel free to keep the conversation going, anytime anyone actually reads these explanations I'm somewhat impressed, because they are largely me, here, now, rethinking these things in real time, lol. Things that should not change: inxi-perl/pinxi / pinxi.1 - this is used by people who know that if they want current dev inxi, they should run pinxi and skip inxi, and use pinxi -U to keep their pinxi up to date, and pinxi -U works as expected always, so that's an actual living used branch, and is the only branch I actually use beyond double checking changes and making sure features are the same between inxi / pinxi when core logic has changed, etc, or checking that inxi bugs or issues are fixed in pinxi. And if that were split it would be virtually impossible to get people to grasp that pinxi is the development branch of inxi, so that one has to stay. but the other non dev branches maybe could be moved, maybe I'll look into how to make git do that, it doesn't sound too hard, but probably will end up being hard anyway since git rarely works easily for difficult situations. inxi-misc could have for example: README.txt binxi/binxi binxi/binxi.1 xiin/xiin.py inxi-c/inxi or whatever that has in it wiki/wiki stuff I'll think about this.

smxi commented 2021年08月26日 22:56:25 +02:00 (Migrated from github.com)

Also, smxi.org is the actual documentation location for inxi, by design, I don't want to use github's junky wiki markup language, and don't want to rely on a version control repo for the site documentation. So the two documentation locations are smxi.org [also found in inxi docs branch], and in inxi-perl/docs. The README.txt per branch are always out of date as a rule, because I forget to update them. Adding more just makes it less likely that a user will find one of those and that I will maintain it. Documentation is like code, it has to be maintained over time to be useful, and that's just more work, so the more documentation that is added, the more it will go out of date and get filled with errors. Nobody ever steps up to maintain that over years, so I don't pretend that will happen, if I add documentation, I will have to also maintain that over years, and that's how it goes. I did over the past 2 years update some core docs for inxi, along with the inxi.changelog upgrade, which removed some silly and totally obsolete doc stuff.

Also, smxi.org is the actual documentation location for inxi, by design, I don't want to use github's junky wiki markup language, and don't want to rely on a version control repo for the site documentation. So the two documentation locations are smxi.org [also found in inxi docs branch], and in inxi-perl/docs. The README.txt per branch are always out of date as a rule, because I forget to update them. Adding more just makes it less likely that a user will find one of those and that I will maintain it. Documentation is like code, it has to be maintained over time to be useful, and that's just more work, so the more documentation that is added, the more it will go out of date and get filled with errors. Nobody ever steps up to maintain that over years, so I don't pretend that will happen, if I add documentation, I will have to also maintain that over years, and that's how it goes. I did over the past 2 years update some core docs for inxi, along with the inxi.changelog upgrade, which removed some silly and totally obsolete doc stuff.