From Van Essen Lab

Jump to: navigation, search

Procedure for Taking a Task

  1. All involved in IT related tasks should add this page to their watch list so that they are alerted to any additional items or changes. Others are encouraged to sign up as well.
  2. When taking a task, put your inititials, an ETC (estimated time of completion), and status for that item (either in-progress or DONE).
  3. Please do not take a task that another developer is working on without following the suggestions below. Additionally, do not start a task before indicating that you are taking it.
  4. If an item's requirements, design, or implementation are unclear or controversial, then create a wiki discussion page, and put a link to it in the particular wiki item.
  5. If the procedure for a group of tasks are un-decided, then a wiki discussion page should be clearly labeled and added as a link to that task. This will facilitate the discussion of design related issues outside of meetings and allow us to better coordinate our efforts.
  6. In general, unless an item is a very large task, one person should perform it, and any concerns about how it is being done should be discussed through the wiki using the discussion page.
  7. If there are issues with an item, discussion is encouraged.
  8. At the beginning of each month, completed tasks should be MOVED to a separate page of tasks for the previous month (i.e. ITTasks092011), and deleted from the "current tasks" list. Tasks started in the previous month(s), but that aren't finished, should be COPIED to the tasks for previous month, but still kept in the "current tasks" list. (Keeping tasks marked in-progress in both the previous month's tasks list and "current tasks" list should make it easier to spot tasks that took more than one month to complete).

Current Tasks

  1. (Tim, Status: DONE) Design and Build two redundant NFS file servers
  2. (Jon, ETC???, Status:In-Progress) Migrate brainvis to the latest version of Ubuntu
  3. Set up LDAP to allow for a single username/password to work for all lab related services (i.e. wiki, RT, email, machine login, vpn, etc.)
  4. Purchase hardware necessary for a dedicated Windows build machine.
  5. Consider purchasing hardware for a dedicated linux build machine (or shared the Windows build machine) (note that all build machines may be best served by using a single, very high-end mac and vmware). Dedicated build machines allow to do intensive configuration of the build environment without interfering with tasks that the owner of a build machine is trying to complete. Our current model of borrowing user workstations for nightly builds causes real problems when we need to troubleshoot, and leaves developers who for example, don't own a mac, stuck trying to troubleshoot on someone else's machine.
  6. Consider purchasing hardware for a dedicated Mac build machine.
  7. (Jon, ETC:???, Status: In-Progress) Create easy-to-use development toolkits for Mac/Windows/Linux. I have spent quite a bit of effort to make setting up caret5/6/7 development easy. Gone are the days when it took hours to set up a build environment. Maintaining and enhancing this is an ongoing effort.
  8. (Jon, ETC:???) Consider, after discussion with others, whether we should distribute "Caret SDK's" to foster 3rd party developer contributions.
  9. (Jon, ETC:???) Consider creating a public/community git repository for 3rd party contributions, with added feature merged into caret at our discretion after careful review.
  10. (Jon, ETC:Oct, Status: In-Progress) Fix issues with windows builds not working when they are executed remotely through an ssh shell. Fixing this will allow us to have nightly builds for windows, which worked great with qmake/caret5, but has been broken using cmake on caret7. A potential fix includes installing Microsoft's Services for UNIX, and it's ssh shell instead of Cygwin
  11. (Jon, ETC: Oct. 15th, Status: In-Progress) Figure out why hippocampus isn't automatically launching nightly builds for Linux/Mac.
  12. (Jon, ETC:???) As Caret7 is still in alpha, it may be premature, but it would still be a good idea to discuss with Michael Hanke what we can do to make caret7 available via neuro-debian's package distribution
  13. Come up with a standard support window for Caret7, so that we aren't stuck supporting caret7 on ancient versions of Linux. On linux, I propose supporting back to the previous LTS version. Ubuntu has two versions. One has a 6 month support window, and LTS versions have a two year support window. When an LTS version is released, it is nearly the same as a standard release, with the main difference being that the support windows is 2 years vs 6 months. i.e.
Version Release date Supported until
8.04 LTS (4, 2008) (4,2014)
8.10 (10, 2008) (4,2014)
9.04 (4, 2009) (4,2014)
9.10 (10, 2009) (4,2014)
10.04 LTS (4, 2010) (4,2016)
10.10 (10, 2010) (4, 2016)
11.04 (4, 2011) (4, 2016)
11.10 (10, 2011) (4, 2016)
12.04 (4, 2012) (4, 2018)

So, if we released caret currently, it would support back to Ubuntu 8.04, released in 2008. Once 12.04 comes out, we would move the support window up to 10.04. Redhat (which is less popular) machines could also run these versions, although we would want to test which versions caret7 worked on prior to release.

Moving to an Ubuntu version support model would allow us to release versions that are very similar to the machines we currently develop on, and having a predictable support window will help our users to avoid surprises.

TSC: proposal: instead of outright dropping support for a system at such a date, why not have it "only if minimal effort", the first time it produces a nontrivial problem not present on more recent releases, drop that environment. While this is a little more work, it is not a commitment to any additional extended support. Further, perhaps we could leave the last release built on each dropped environment available for download indefinitely, with an extra disclaimer that they are unsupported.

  1. There is a wide array of development tools, many of which are currently not used by developers due to lack of time to explore what is out there. Continue to evaluate development, profiling, testing, debugging, and code analysis tools. The most crucial part of this task involves writing wiki pages covering each tool, it's strength and weaknesses, and recommendations for each platform.
  2. Fix issues with NFS mounting on hippocampus that some users are still experiencing.
  3. Write wiki page detailing back-up procedures for all machines and/or important data.
  4. (Jon) Finish implementing upgrade strategy for Ubuntu machines.
Personal tools
Sums Database