Wednesday, May 18, 2011
A person who's not a committer, and who's made a change on their (say) Github fork of a project, with a consequential 'pull request' for the originator to consume the change as a contribution, could sign each commit.
Whether the CLA is as I penned it, or one like Apache's or Google's for accepting back contributions, the contributor could a line detailing the hash of the contribution they have made.
It gets merged in too, along with the actual change, and consequentially has a lasting presence in the bottom of a "contributions.txt" file that has the CLA as the first few paragraphs in "we, the undersigned" style.
Source control gets to prove that the contribution is correlated with the CLA signing. Such contributors have to keep re-signing subsequent contributions to cover for the eventuality that they are one day going to change employers.
Full blown committers should be exempt from this process of course, but then they are likely to not do business in nom-de-plume style, be be known to the other developers.
Note also that committers could reject pull requests until the contributor had completed the workflow of adding to the contributions.txt file.
Maybe Github could add some workflow/automation around this....
A question from an OSS buddy: Is that "sign" as in "cryptographically sign" or some other sense?
The hashes of changes are irrefutable an part of git's way of working. The follow-up addition of that hash to the contributions.txt file would be committed by the same user (by convention), and also hashed as a change in the same way.
Now the person COULD effect both of those without PKI being involved, but they are authenticated as far as Github is concerned, but virtue of other their id/password. Its as good as cryptographic signing to all intents and purposes. Provided Github has no XSS issues (etc) where someone can commit in the name of another.
Wednesday, December 22, 2010
WebDriver started at ThoughtWorks a few years ago. Its lead, Simon Stewart, and his now Google colleagues have spent a lot of time on it since. The Selenium-1.x team (Jason Huggins, Pat Lightbody, Dan Fabulich, & many more) and new committers and friends have helped production harden WebDriver to the extent where its an admirable replacement for Selenium-RC (1.x).
There is a little brand confusion as to whether this is Selenium 2.0 or WebDriver that will resolve in time, but it is true however that Selenium 1.x will have no more major releases. That means no more Selenium-Core or Selenium-RC (other than bug fix releases). The reverse takeover that is WebDriver emulating the old Selenium is good enough for prime-time usage. Actually it has probably been good enough for some time.
Good work Simon and all involved!
Watch http://seleniumhq.org/download/ for updates.
Tuesday, August 31, 2010
Read the announcement and release notes.
Summarizing the release notes a little: 7 bugs, 45 improvements, and 11 new features later, JBehave 3.0 is now happily a Git citizen, with repos mirrored from Codehaus to Github.
If thought of as a JUnit plugin (which is an over-simplification) JBehave 3.0 is perfect for "in the box" enterprise development now. Note also there are now plugins for Guice, Spring and PicoContainer to allow Dependency Injection to play a part in the composition of Behavior Driven Development (BDD) tests.
Sunday, July 25, 2010
Announcing Frank, a lightweight UI automation framework for iPhone and iPad applications.
Frank sews together several open source tools, notably UISpec, cocoahttpserver, and Cucumber. The goal is to automate basic UI-level acceptance testing of an iPhone or iPad application, integrated into a Continuous Integration system.
You can read more about Frank here.
Tuesday, July 20, 2010
Image from http://www.osnews.com/story/19266/WTFs_m
WTF implies lack of clarity. Clear code is easier to understand, easier to maintain and easier to extend.
Announcing saikuro_treemap -- an easy to setup tool to generate complexity treemaps of ruby code.
See a demo for yourself.