overture-workshop-notes

1.1.1 04Dec/31Jan/10Mar/01Apr/20May/13Jun

1.1.2 Average around 1.5 months between releases

1.1.3 New version 2.x features

1. Eclipse 4.2 base
   
2. ASTv2 integration
   
3. New AST-based pog
   
4. New code generation module
   
5. ProB use
   
6. Smaller interface improvements (quickfixes, etc) (probably)
   

1.2.1 Started trialling May 2012

1.2.2 Really started transition October 2013

1.2.3 Issue tracker 21 Nov 2013 (the day I generated 1000+ emails…)

1.2.4 Better integration between issues, code, etc

1.2.5 Easier to work with — we're actually using this

1.3.1 Briefly: experimental OS X-based VM (machine was overprovisioned; system performance sucked)

1.3.2 Now: new beefy Linux-based VM at overture.au.dk

1.3.3 Travis-CI — lightweight, live feedback on buildstatus of all commits

1. No extra configuration on the buildserver
   
2. (still a bit buggy, due to build complexity)
   

1.4.1 Shinier!

1.4.2 GitHub hosted, static site — essentially zero attack surface aside from GitHub itself

1.4.3 More flexible than the old

1.4.4 Has a issue tracker for website bugs!

1. Still need to link it on the site
   

1.4.5 Rewriting (slowly) to sound less like an academic paper

1.4.6 Download numbers (somebody is downloading, at least)

2.1.1 GitHub "Releases" used for the standalone files

2.1.2 We still use SourceForge.net for (some of) stuff

1. To be phased out
   
2. Standalone files are posted
   
3. Eclipse update site posted
   

2.1.3 Eclipse update site

1. No good public+free solution
   
2. Will soon use the AU buildserver (temporarily?)
   

2.2.1 all in maven

2.2.2 no doc yet

2.2.3 developement branch should always build

2.3.1 Release procedure documentation incomplete

1. But some exists
   

2.3.2 There are many little tasks, distributed everywhere

2.3.3 Next release will be done by Kenneth

1. I will sit beside and document what's missing
   

2.3.4 Native installers

1. Value of this? (unzipping files isn't that difficult)
   
2. Windows: Not a huge effort, just not prioritised
   
3. OS X: configuration wrestling with tycho/maven
   
4. Linux: zip is the only real option (or tar.gz)
   

2.4.1 Backed by a git repository

2.4.2 Easier to keep "clean"

1. Dead content is removed by just deleting files
   

2.4.3 Development wiki already on GitHub

1. i.e. the one we actually use (AU devs, at least)
   

2.4.4 General wiki currently on an old IHA host

1. Should be moved; I'd like to put it on GitHub
   
2. Test migration soon
   
3. Cleanup in the process
   

2.5.1 Limited file attachments to bug reports

1. Code can be inlined between ``` or ~
   
2. Images may be attached
   
3. No real possibility for anything else
   

2.5.2 Encourages reporters to make minimal examples

2.5.3 Small examples make bugs easier to find

1. Hidden advantage?
   

2.5.4 We actively use the GitHub Issues tools

1. Stark contrast against the sf.net bug tracker
   

2.6.1 We should have these under version control somewhere

1. I will set up a private AU repository
   

2.6.2 Occasional small changes (recently from Nick in bug #304)

3.1.1 adoption why?

1. solves new, real problem
   
2. community
   
3. best-in-class
   
4. artifacts
   

3.1.2 adoption context

1. teaching (student's interest) > artifacts for instruction > robustness > community
   
2. research: impact > bootstrapping > community
   
3. commercial: paying > future opportunities > community
   

3.1.3 noted

1. strengths: history, age, foundations, community, artifacts
   
2. neutral: size, communication, artifacts, quality, source, motivation, uniqueness, momentum
   
3. weaknesses: nationality, history, age, foundations, impact, wealth, influence, memes
   

3.1.4 Recommendations: age, impact, influence, nationality, memes

3.2.1 I've not done anything to address these directly, to my amusement

3.2.2 Memes — if you take GitHub, StackOverflow to be a meme

3.2.3 Eclipse?

1. You'll note I use Emacs
   
2. Can we do better? and,
   
3. We claim a strong border between core/ and ide/
   

3.3.1 The move the GitHub aims (partially) to reduce friction

1. For curious onlookers, it's now easy to look at and search the code
   
2. For potential developers, GitHub directly supports forking and contribution mechanisms, without requiring permission
   

3.3.2 Website update is intended to make the project look live (a site design that visually dated us to 2002 wasn't helping)

3.3.3 StackOverflow tag

3.4.1 Kiniry's "prove that VDM is applicable"

3.4.2 Overture doesn't (yet) support the refinement/reificiation chains that are so popular on paper

1. POG-TP would help mitigate this
   

3.4.3 Overture doesn't do the strong inferential typechecking seen in FP Langs (union types are no help!)

3.4.4 Overture/VDM is not a great language to implement in

3.4.5 What an awkward niche!

1. Is there a good story for all of our tradeoffs?
   

3.4.6 What's our compelling advantage?