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

[enh]

On Wed, Mar 16, 2016 at 5:18 PM, Rob Landley <rob at landley.net> wrote:
> 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:

continuous testing is a tool that enables you to have regular
time-based releases that work.

you always want to know if your change broke something, regardless of
whether you're doing feature- or time-based releases.

> 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1458184176.0