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