[Toybox] Proposal for TODO items and progress tracking

[Rob Landley]

Sorry for the delay replying. See a couple emails back about my house
flooding _again_. (Once chance, twice coincidence, third time we're on
the waiting list for professional landscapers with backhoes and maps of
where all the underground pipes and wires are and such. I do not enjoy
being on the receiving end of climate change.)

On 06/06/2015 01:30 AM, Conroy, Bradley Quentin wrote:
> For the remaining unimplemented commands, would it be desirable to create
> a separate folder with basic stubs for each command

I have toys/pending, although it's more for other people than for me.

> with the following:
>   * URL of the applicable standard and/or man page

http://landley.net/toybox/status.html

>   * toybox'ed short and long options to be implemented

The design work for figuring out what a command should look like is more
work than actually implementing the command. (And then testing is more
than those two combined.)

>   * any applicable notes; such as possibly useful toybox functions

http://landley.net/toybox/code.html

>   * stubs of functions in toybox coding format standards

I don't understand that bullet point?

> This could go a long way toward lowering the entry barrier to competent
> C programmers who are simply unfamiliar with the toybox specifics.

The bottleneck is actually cleanup, and I keep trying to do something to
help other people work on that:

http://elcabs2015.sched.org/event/f19ec107950abfefa61c14f0e49e82ba
http://landley.net/toybox/cleanup.html
https://www.youtube.com/watch?v=iI7vlTXJbiI

The thing is, I just spent several hours analyzing my own ls code to fix
two bugs, and https://github.com/landley/toybox/commit/28727ba7cddb and
https://github.com/landley/toybox/commit/9acbbafefafb already _had_
patches, they just weren't quite the _right_ patches, and it took me
hours of staring at and analyzing my own code to understand why. (And
coming up with test cases, when I mentioned in the checkin comment but I
have a whole blog entry about design issues with upgrading the test
infrastructure that I need to finish and post...)

Along the way I found some cleanups I can do to ls, and did some of
them, but the pending issue there is that ls takes a fairly naieve
approach to internationalization, specifically utf8 fontmetrics. For
example, the time the Fake AP Stylebook twitter feed pretended to get
taken over by the Demon of Typos for a while:

https://twitter.com/FakeAPStylebook/status/415263262629171201

You can stick an arbitrary amount of bling onto characters and it all
counts as one character for width purposes, and with the ls -C and ls -l
code caring that much about spacing...

The current ls fontmetrics stuff is tied into the "blot out unprintable
characters" code by the way, which may nor may not be specified by posix
(it's been long enough I have to look it up again). Possibly there
should be a version more like the hexedit fontmetrics counter. I'm
collecting use cases like that and then genericizing them into
lib/interestingtimes.c as I work out what the right behavior _is_...

I mostly punted the first time because for ls -l all the filenames are
at the right edge so spacing is no longer an issue, but user and group
names can _also_ be sorlac, and -C mode cares...

(And yes, I still owe people human_readable() changes. Again, the hard
part isn't implementation but working out what the right behavior _is_.)

> While I am on the issue of _adding_ a folder, let it be known that it is
> not my intention that toybox go the way of busybox with commands
> divided up into so many categories that it makes them difficult to
> locate.  I'd like to see something more like ./toys/todo, ./toys/pending
> and ./toys/complete with the use cases handled by simply adding a
> special line in the config section such as:

There already is a toys/pending, and everything in it should be cleaned
up and moved into other directories. Spreading it out doesn't make it go
faster.

> USED_BY LSB DEVELOPMENT KLIBC DEFCONFIG ...

It's section annotations in the roadmap.html file which
scripts/mkstatus.py parses to form groups it then outputs into
status.gen which is sourced by status.html using a server side include.
I just updated... rather a lot of stale web pages files actually, but
http://landley.net/toybox/status.html should be up to date as of an hour
or so back now.

> or
> select gunzip if LSB || DEVELOPMENT || KLIBC || DEFCONFIG ...

No. "select" means "switch this on even though they didn't select it in
kconfig". That's now how I use kconfig: you switch on your prerequisites
and your options when chosoing what you want, the default is everything
_off_. If it's a problem, then there are too many kconfig options and we
should probably remove some.

> Using this type of directory structure based on completion would not
> only help would-be contributors to get right to coding, but also ease
> progress tracking.

Ease it for who?

> Contributors wanting to code something from scratch could go straight to
> ./toys/todo or ./toys/pending for major cleanup or ./toys/complete to
> optimise/improve an existing toy.

Why would there be a toys/complete that _isn't_ toys/posix or toys/lsb
or toys/other or toys/android and so on?

> Progress tracking could be automatically generated based on the
> directory it is in, as well as any USED_BY or //TODO lines.

Or it could be automatically generated by scripts/mkstatus.py.

I've had a chronic problem keeping up with submissions for _years_. Ask
poor Georgi about that:
http://lists.landley.net/pipermail/toybox-landley.net/2012-March/000288.html

This month has been exceptionally bad due to travel, a work crunch, and
natural disasters. (All in the same month!) And I've never had toybox as
my fulltime job. (It's been half-time a couple times, which was very
nice. The first of those paid for last year's flooding. :)

But my problem with delegating is I have obsessively high standards for
what counts as "done" for a toybox command, and my attempts to teach
other people to do this kind of coding have been... well, see the
cleanup.html stuff above...

> R,
> Brad Conroy

Rob

 1435095110.0