On Thursday, March 14th, 2024 at 12:04, enh <e...@google.com> wrote: > at a high level, it does seem like many/most people interpret "pending" as > "almost done" (he says, being part of the problem himself, having several > pending things building and shipping on all Android devices) whereas in > actual fact it can mean anything from "yeah, actually pretty much done" to > "will be completely rewritten" via "still just trying random experiments > trying to work out _how_ this should be rewritten". > sadly i don't have a better suggestion...
pending/experimental and pending/functional maybe, or something along that gist? Then again it'd make it harder to track the history of pending commands, adding only new ones to those 2 directories would fix that, but would make the organizational problem for the old ones worse. > a branch would be the usual git option, but that would probably mean "no > pending stuff in the main branch" Also a problem if you want to switch Version Control systems or distribute tarballs without a .git/ directory. It'd hide these commands too, For the first time I checked if there were any special branches in the repo because I didn't bother to think about that in the months I spent working on it. > i still struggle between "other" and "lsb" in particular. Same here, I can remember the posix commands. But I don't care about LSB enough to memorize everything in wants. And keeping all completed commands that aren't in poisx, lsb, networking or android in a massive "other" folder sorta defeats the purpose of these directories which are supposed to reduce clutter. > `vi toys/foo.c` would save me a lot of thinking/calls to find. Eh, keeping all the commands in a massive toys/ directory makes it harder to tell what we have. A possible solution is to organize commands by their purpose. Like "net/", One directory for text-processing commands like head and grep and sort, one for programming languages like awk or bc (This becomes a lot more sensible if you want a compiler in toybox post-1.0), etc. This would mean that you could find a command by just knowing it's name and general purpose. Then again, it would take away from our ability to manage commands based on standards, And there are edge cases (Not like we are completely free of it with our current model: Does git.c go into net/ or other/ once it's done? Network access is a pretty key part of a read only git implementation). Does this outweigh the organizational usefulness of organizing commands on purpose? I realized this has probably already been discussed before back in 2012/2013 (When the commands were moved into posix/ and lsb/ and other/ and such), But haven't read the discussion on it if there was one. In any event, a complete reorganization of the commands would make the history of them a lot harder to keep track of. So it's probably not very viable until post-1.0. I don't know though, what does the project manager think? - Oliver Webb <aquahobby...@proton.me> _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
