Hey Justin, I’m supportive of any approach that helps us get the release out the door in good time. Our directory structure certainly does need to be updated, but I think we can leave it until right after we cut the release.
Anastasia, thanks for summarizing the directory structure we had talked about. This is very helpful. A few more thoughts: * If a demo isn’t something we’d want to show our friends, family, and funders, it should be moved to the “manual tests” directory * If a demo is old or out of date, it should be flat out deleted * The only demos in our demos directory should be ones that we think are cool and informative to users of Infusion * We should switch to using Bower for managing third-party dependencies wherever possible * In cases where we have to store a third-party dependency in our repository, we should name the folder “third-party,” instead of “lib,” which most Node.js developers nowadays expect to contain source code Thoughts? Colin On May 29, 2014, at 8:49 AM, Justin Obara <[email protected]> wrote: > Thanks for the feedback Anastasia. > > In the discussion at the meeting yesterday, it came up that lib didn't seem > to fit into the src directory either because it isn't code that was written > by us. In regards to the destruction of the integration demos, I had tried to > do that for the 1.5 release. However, it seems that this is a unique use case > that we need to keep for the pager. Perhaps it could be moved to the manual > tests though. > > Anastasia, could you describe a bit the differences and the purposes of each > type of demo (showcase, instructional, standalone). > > Thanks > Justin > > On May 29, 2014, at 8:41 AM, Cheetham, Anastasia <[email protected]> wrote: > >> >> On 2014-05-28, at 3:48 PM, Justin Obara wrote: >> >> questions arose regarding how best to organize the various demos. Currently >> we have demos, instructional-demos, integration-demos, stand-alone demos, >> and manual tests. It's hard to know the difference between these. >> >> Good questions, Justin. I looked back though past emails and discussions and >> found this email: >> >> http://fluid.2324889.n4.nabble.com/Proposed-folder-hierarchy-for-Infusion-code-td8919.html >> >> Basically, the proposal was: >> >> src >> framework >> components >> lib >> module >> demos >> showcase >> instructional >> integration <- to be destroyed >> standalone >> tests >> >> >> For the demos/instructional folder, the hierarchy would mirror, as much as >> reasonable, the hierarchy of the source folder. In general: >> >> demos/instructional >> framework >> core >> prefs >> renderer >> components >> componentX >> shared >> css >> shared.css >> html >> shared.html >> js >> shared.js >> demoX >> css >> file.css >> html >> file.html >> js >> file.js >> demoY >> css >> file.css >> html >> file.html >> js >> file.js >> componentY >> etc >> >> >> >> -- >> Anastasia Cheetham Inclusive Design Research Centre >> [email protected]<mailto:[email protected]> Inclusive Design >> Institute >> OCAD University >> >> <winmail.dat> > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
