{"action":"created","issue":{"url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/153","repository_url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool","labels_url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/153/labels{/name}","comments_url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/153/comments","events_url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/153/events","html_url":"https://github.com/BrechtDeMan/WebAudioEvaluationTool/issues/153","id":178438503,"number":153,"title":"More rigorous master branch review","user":{"login":"BrechtDeMan","id":4103243,"avatar_url":"https://avatars.githubusercontent.com/u/4103243?v=3","gravatar_id":"","url":"https://api.github.com/users/BrechtDeMan","html_url":"https://github.com/BrechtDeMan","followers_url":"https://api.github.com/users/BrechtDeMan/followers","following_url":"https://api.github.com/users/BrechtDeMan/following{/other_user}","gists_url":"https://api.github.com/users/BrechtDeMan/gists{/gist_id}","starred_url":"https://api.github.com/users/BrechtDeMan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BrechtDeMan/subscriptions","organizations_url":"https://api.github.com/users/BrechtDeMan/orgs","repos_url":"https://api.github.com/users/BrechtDeMan/repos","events_url":"https://api.github.com/users/BrechtDeMan/events{/privacy}","received_events_url":"https://api.github.com/users/BrechtDeMan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-09-21T19:18:48Z","updated_at":"2016-09-22T12:18:53Z","closed_at":null,"body":"In light of a few bugs that were not there before, I've been wondering if master branch commits should be subject to a more rigorous process to reduce the risk of breaking existing functionality. I think we are coming quite close to getting the basic functionality just right, at which point it should really not be touched unless we are more or less certain the improved code or extra features don't introduce bugs. \r\n\r\nI don't think code reviews are necessary or even possible, but perhaps hot fixes and merges with the master branch should only be made after testing a few example projects. \r\nI would quite gladly volunteer to run a few of these on a few browsers and log any issues, e.g. every time a milestone is almost reached on the dev_main branch. \r\n\r\nThis might mean rethinking and improving a couple of example projects so that a wide range of functionality is effectively tested. These should also make it easy for the developer to quickly test their latest changes. \r\n\r\nPerhaps a viable process is to establish who has which platforms available, then open a 'sprint' issue here every time a set of new changes are to be tested, so we can log what problems we're seeing. \r\nI could also set up a server where I can pull the latest version of WAET every now and then, for demos and testing. Scripting a 'git hook' for this would be ideal though I don't have the time myself to look into how to do this. \r\n\r\nUnit tests (#113) would also still be great, but I don't think they could easily prevent this type of problems. \r\n\r\nThoughts? @nickjillings @djmoffat @giuliomoro "},"comment":{"url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/comments/248887429","html_url":"https://github.com/BrechtDeMan/WebAudioEvaluationTool/issues/153#issuecomment-248887429","issue_url":"https://api.github.com/repos/BrechtDeMan/WebAudioEvaluationTool/issues/153","id":248887429,"user":{"login":"BrechtDeMan","id":4103243,"avatar_url":"https://avatars.githubusercontent.com/u/4103243?v=3","gravatar_id":"","url":"https://api.github.com/users/BrechtDeMan","html_url":"https://github.com/BrechtDeMan","followers_url":"https://api.github.com/users/BrechtDeMan/followers","following_url":"https://api.github.com/users/BrechtDeMan/following{/other_user}","gists_url":"https://api.github.com/users/BrechtDeMan/gists{/gist_id}","starred_url":"https://api.github.com/users/BrechtDeMan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BrechtDeMan/subscriptions","organizations_url":"https://api.github.com/users/BrechtDeMan/orgs","repos_url":"https://api.github.com/users/BrechtDeMan/repos","events_url":"https://api.github.com/users/BrechtDeMan/events{/privacy}","received_events_url":"https://api.github.com/users/BrechtDeMan/received_events","type":"User","site_admin":false},"created_at":"2016-09-22T12:18:53Z","updated_at":"2016-09-22T12:18:53Z","body":"Yes, agreed. Let's focus on \r\n\r\n1. keeping the master branch free from anything but thoroughly tested new versions and important (and ideally also relatively well-tested) hotfixes - i.e. make a new, less stable 'next version' branch.\r\n2. testing using example projects after each significant update, and if necessary improving the example projects (so that we don't need 20, but we've got a handful that cover most or all functionality). Could do a quick diff of XMLs I guess, and produce 'canonical' XML outputs to compare against. "}}
{"actor":{"display_login":"BrechtDeMan"}}