On Wed, Mar 16, 2016 at 5:18 PM, Rob Landley <[email protected]> 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 > [email protected] > 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
