Hi Michelle, On Jan 29, 2014, at 4:02 PM, Michelle D'Souza <[email protected]> wrote:
> 1. We have been wanting to move to using Jenkins for the nightly builds for a > long time now, but haven't been able to fit in the cycles to do the actual > move. Instead of upgrading Continuum, let's make that move now. Justin, Avtar > and I will do the work for this over the next couple of weeks. We have just > deployed a new and improved page on the build site: > http://build.fluidproject.org/ with links to static demos. Once the move to > Jenkins happens, the links from that page will once again be built regularly. > Instead of having them happen 'nightly' we plan to use github service hooks > to have the build happen on every push to the project repository. Can someone outline the features and benefits that Jenkins will provide us in comparison to a simple script that listens for Github hooks? I’m sure there are good ones, I’d just like to hear them enumerated. > 2. We have recently discovered a bug in our current Infusion build which > causes our minified builds not to work in IE8. > http://issues.fluidproject.org/browse/FLUID-5260 This is another piece of > infrastructure that we have been planning to replace. Now is a good time to > replace our current Ant builds with the Grunt builds that we have been > working on. +1. If we are in a bind, I suggest we simply replace the “minify” target in buildutils.xml to invoke Uglify instead of YUI Compressor. But we’re going to need to move to Grunt before we ship 1.5, I think. > 3. We have been directing users to the Infusion Builder to create special > builds of Infusion, however, the builder often becomes out of date and has > breakages that we tend not to notice immediately. With the move to Grunt, > creating a special package of Infusion should be easier. Let's consider not > putting the builder back up, and instead provide several commonly used > packages for download and instructions on creating unique packages using > Grunt. +1. Graphical UIs are really nice, but developers are very comfortable with Grunt these days. And given that I hope we will consider splitting out the components from the framework post-1.5, we’d have to rethink what a “distributed builder” would look like anyway. So ditching it sounds like a great idea to me. > 4. We have been hosting an instance of TestSwarm for a long time now and yet > it has not become part of the community practise to actually use it. Let's > not put it back online until we see a clear need for it in our community. I think there is a clear need for TestSwarm or something similar in our community already. The problem is that we need to have sufficient critical mass of cross-browser test agents, which really requires us to have VMs dedicated to the task of testing. And it needs to be tightly integrated into our workflow, sending emails or IRC bot messages when failures occur. Given these requirements, I think we’re best to live without Test Swarm long enough to get our cloud infrastructure running and then revisit the issue. We do need it, though. We’ve had subtle breakages in IE that went unnoticed because developers weren’t testing manually on it. Test Swarm would have caught these kinds of issues, but we’re just not in a position to be able to maintain it right now. > 5. We have been maintaining our own fork of JSLint for a long time now. It's > becoming clear that a move to JSHint would be a better fit for our community > and would mean less infrastructure for us to host. There is a JSHint plugin > for Grunt, which will actually improve our ability to run our tests > regularly. We will need to determine which setting to use in JSHint and > likely do a pass through of all our files. +1. I have switched to JSHint for Flocking and it’s been a pleasure to use with Grunt. And it doesn’t insult users with insane Crockford-isms like the “stupidity” checkbox. Let’s definitely update our comment blocks (or use a .jshintrc file in the project) and switch to JSHint. Colin _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
