[Toybox] testing / branching (was Re: [PATCH] Fix the operator precedence in expr.)

[Rob Landley]

On 03/16/2016 03:51 PM, Andy Chu wrote:
>> I often fix the test case before I fix the code, to remind me to fix the
>> code. :)
> 
> Yes I think it's a good idea to add failing tests that are known to be
> good, but not done yet.  I think we could annotate them as follows:
> 
> testing "name" "command" "result" "infile" "stdin"  # good test
> known-fail "name" "command" "result" "infile" "stdin"  # test that
> fails, but is valuable
> 
> If we had a continuous build, we could keep it green, preventing
> regressions of the tests that do actually pass.

Regular testing is nice, but I was convinced that it's no substitute for
regular time-based releases by this video:

http://www.youtube.com/watch?v=IKsQsxubuAA

April 19, 2007 Release Management in Large Free Software Projects -
Martin Michlmayr (Debian)

ABSTRACT: Time based releases are made according to a specific time
interval, instead of making a release when a particular functionality or
set of features have been implemented. This talk argues that time based
release management acts as an effective coordination mechanism in large
volunteer projects and shows examples from seven projects that have
moved to time based releases: Debian, GCC, GNOME, Linux, OpenOffice,
Plone, and X.org.

(That's why "ballpark 3 months after last release, we should have
another one" last message.)

> And then there could be a mode of the test harness that runs the
> known-fail tests.  If they pass, the function can be changed to
> "testing".  Although there is the complication that they could pass in
> one environment but not another.

For 1.0 I want to _fix_ all the known-fail tests. Right now the sad
state of the testing suite is, in part, a way of tracking my todo items. :P

That said, we can rename "blah.tests" to "blah.pending" and have tests
with known failures be in the latter category, moving over to blah.tests
once a test is good and fixed and everything in it runs _and_ we're
pretty happy with the coverage it provides.

>> (I don't always check those in though, because "git diff" showing me a
>> comment or hunk of code is an easy way of keeping track of todo items.)
> 
> How about just working on a branch "rob-todo" ?  And then "git diff
> master.." instead.  And then 'git pull' becomes 'git pull' and 'git
> merge master'.

I don't make very deep use of git. I have multiple working directories
when I really need them, and I try to avoid merge commits in the
history. I know, I should get with the 21st century...

> I noticed you just switched from hg, and so did I.  I liked hg a lot
> better because the commands actually make sense, but git's branching
> is why it's popular. It really is pretty killer and lets me work on
> the test harness while you are reviewing the expr code, etc.

I still use multiple directories instead of branches because of said
history with mercurial. Too busy using the tools to play with the tools
so far. (Also still at the point where when I break it, and oh boy do I
break everything, I don't necessarily know how to fix it and just revert
to a backup instead.)

> The way I think of it is that hg is  for single person projects (most
> of mine were) while git is for collaboration... and that explains why
> git is popular despite being incomprehensible.

No, git won because Linux was using it, and everybody else copied Linux
as usual. Same way the GPL won because it was the Linux license, until
the FSF split it into incompatible factions and set them at war with
each other. (Copying Sun's "CDDL to fracture the GPL" attack from a few
years earlier, Sun didn't have the weight to pull it off, but the FSF
did and destroyed its ecosystem. Pity, I was kind of invested in that at
the time. Oh well, we all move on.)

In theory git and mercurial could each do anything the other could. In
practice mercurial had some very strong ideas about what should be
allowed (they kept trying to dissuade me from using hg rollback, and
would never give me multiple levels of that. In git: "git reset HEAD^1"
and repeat until you're where you want to be, it's all fine if you
haven't pushed yet).

Git has the annoying tick that the way to understand its command line is
to learn how its' on-disk format is implemented. (No really, THAT'S WHAT
THEY EXPECT YOU TO DO. Grumble grumble.) Luckily, there are some
reasonable videos on this. I saw the Linuxcon Japan 2015 presentation of:

https://www.youtube.com/watch?v=I-lGyn3PHP4

> I find it really helps to put the git branch name in your bash prompt
> (if you want a pointer let me know.)

One of my todo items for the post-1.0 roadmap is implementing enough of
my own (0BSD-licensed) git implementation to drive repo in the AOSP
build. (You saw the 2013 ELC talk linked from the left edge of the
toybox page? Making Android a self-hosting development environment?
There are still missing toolchain bits beyond the command line toybox is
doing. A read-only git implementation is actually reasonably
straightforward to implement, the nasty bits mostly seem to be on the
write/merge/repack/gc side.)

So I do intend to do a deep dive into the internals (and learn the
network protocol and everything), but it's several slots down on the
todo list. In the meantime, I'm aware I'm using a wrench to pound in a
screw but it's working.

> Andy

Rob

 1458173932.0