Open equilet opened 9 years ago
Fodder for our meeting
There are lots of issues embedded in this that need breaking down. The first one I am troubled by relates to support/maintenance and the notion of backwards compatibility. If we change or improve something in the depot what responsibility do we owe to users of it? Do we freeze everything that goes in so people can trust it to be there and add new ideas to new objects or do we design trusted stable API's (OSC message sets) that can be interpreted in flexible ways? Maybe you should take a stab at a best practices style guide that contributors can be inspired to follow?
A style/best practices guideline needs to be agreed upon and put in the wiki. The freezing issue can be somewhat alleviated by tagged releases, which I've annotated for specific use cases. One example issue that this doesn't necessarily address is which odot release a given tag pertains to. Maybe this could also be annotated?
On Dec 5, 2014, at 2:11 PM, Jeffrey Lubow notifications@github.com wrote:
A style/best practices guideline needs to be agreed upon and put in the wiki. The freezing issue can be somewhat alleviated by tagged releases, which I've taken time to annotate for specific use cases. One example issue that this doesn't necessarily address directly is which odot release a given tag pertains to. Maybe this could also be annotated? it's all about testing. We need to know what works and what depends on what to make it work. This isn't easy and until we have a practice of nightly build style automated testing I don't think we will be able to deliver the quality people might hope for.
we should discuss the jamoma/nils' testing suite in our meeting to see if it can help us in any way...
Amanda Chaudhary did an OSC-based one before Nils.
I have been discussing this on and off for years and David has advertised the importance of this at a NIME keynote. I don't have much left to discuss other than the usual - someone has to own the problem for long enough to make it work and teach others how it can be part of regular development practice. This is the difference between programming and software engineering. There are very few software engineers in the music tech space.
On Dec 5, 2014, at 8:27 PM, Jeffrey Lubow notifications@github.com wrote:
we should discuss the jamoma/nils' testing suite in our meeting to see if it can help us in any way...
— Reply to this email directly or view it on GitHub.
In the spirit of keeping these issues focussed:
A QA Engineer walks into a bar: Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
As we work through various cases here and elsewhere, there will be opportunities to update older modules (patchers), js files, tutors, and tutorials. We need to have a protocol in place for updating these to practices that are sanctioned and discussed upon. Do we try to move these patches into the odot example world? Keep them here? A new space, perhaps?
An example of this was issue #34. My goal here would be to know in advance what we should consider for upgrades, if odot should be involved, etc. We need to sort this out ASAP so that we can build stable robust tools that are useful beyond the context of a single project.
@adrianfreed @EdmundCampion