equilet
commented
9 years ago Fodder for our meeting
Open equilet opened 9 years ago
equilet
commented
9 years ago Fodder for our meeting
adrianfreed
commented
9 years ago 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?
equilet
commented
9 years ago 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?
adrianfreed
commented
9 years ago 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.
equilet
commented
9 years ago we should discuss the jamoma/nils' testing suite in our meeting to see if it can help us in any way...
adrianfreed
commented
9 years ago 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.
adrianfreed
commented
9 years ago 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.
equilet
commented
9 years ago
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