BIRCH/Meeting/Aug112011

From Bioinformatics.Org Wiki

Contents 1 Topics 2 Goals 3 Tentative Roadmap for Me 4 Brian's comments 5 Results

Topics

The topics of todays meeting are:

1. Winbirch - I want to see what's happening with Winbirch.

• Status: take a look at the git.cc.umanitoba.ca repos
  • Currently there is a stable version of winbirch, but it is rather old. The remainder of the development on winbirch involves modifying the framework in birchdev, as well as creating the binaries so that users can actually use biolegato.
• What I've been up to this lately:
  • I have been working on documenting the development environment, and am refactoring getbirch's winbirch functionality.
    • Currently, winbirch is in unstable development, and I am waiting for the birchdev repository to get online before I can finish features that will require me to make changes to the framework, in particular:
      • Getting biolegato to work with winbirch will require modifying a .blproperties file
      • Getting launchers to work on windows will involve writing a batch script to launch biolegato into BIRCH. This script will need to be modified by birchhome.
  • Once we have the framework (and preferable biolegato) on the repository, we can start developing binaries to make a full winbirch release.
  • Updating the wiki in various places:
    • Winbirch, added development section, summarized how development works, will be reviewed below. The goal is to make it easy to onboard new developers to winbirch
    • Updated the python API section of the wiki to be more relevant
    • General cleaning up of the wiki.
  • Refactoring getbirch
    • Currently, getbirch is being refactored to integrate a number of winbirch changes more cleanly, as well as to consolidate the useful portions of the jython API. When the refactor is complete, getbirch will be easily useable to test winbirch using git.
  • Current development:
    • I am currently developing a single regular expression that will allow for windows paths to be safely converted in all cases. This is refining a method that I used to create the "cygwin java wrapper". This is a much more elegant and catch-all approach than the previous string.replace methods I had been using.
• What needs to happen:
  • See goals below.

2. Ruming will be rewriting his oligo scripts as a Java application. I'd like your advice on implementing this through Netbeans/Git so that he and I can easily collaborate.

• I spoke to him about this last night, and what this will amount to is the following:
  • Rhuming creating his program, and then importing it into netbeans.
  • Creating a submodule somewhere in the birch framework for it
  • When rhuming has stable code, he will simply commit this to his submodule. He will not have full write access on the framework, just his module.
• I will be creating a page on Git/netbeans usage (with screenshots etc) that will allow him to easily work with the repository. This will prevent having to give him write access to psgendb.

Until he starts using netbeans, I can show him the basic git commands he needs to use, basically just:

• git add * && git commit -a -m "new iteration" && git push # is all he will have to do each day when he is done developing.

Goals

1. Go over submodule documentation here, essentially this will allow everyone to work on what the need to.
   1. The main consideration is that anyone working on a submodule in the framework must push that submodule before birchdev.
2. Recreate the birchdev repository, and make the bin/lib directories into appropriate submodules. (For the time being, there isn't enough space for the binaries on git.cc.umanitoba.ca)
   1. Create a .gitignore file to exclude bin* and lib* from the birchdev repository until there is more space
3. Make biolegato into a submodule of the birch framework, and any other appropriate submodules ( i suggest creating a "doc" module)
4. By end of day, update getbirch to use git.cc.umanitoba.ca, and winbirch development will be facilitated.
   1. It will now work by fetching each submodule that it needs (everything but the binaries that it doesn't need)
5. Get Brian/Graham setup with winbirch development BIRCH/Winbirch/Development so that we can eventually collaborate on binary development.

Tentative Roadmap for Me

1. Finish putting birchdev on git
   1. Submodularize birchdev, and add metastore to the hooks.
   2. Make "unbirchhome" run before a commit, and "birchhome" run on a pull
2. Make changes to birchdev for winbirch (I already have some sitting on a local repository, they will just need to be merged in)
   1. Getting biolegato to work with .blproperties writer in getbirch
3. Create winbirch binaries
4. Prototype/test winbirch
5. Release winbirch beta
6. Start refactoring python API, working on "birch server" using existing jython code that is currently being refactored.

Brian's comments

Winbirch

1. I didn't realize I has holding anything up. I did a push of BIRCHDEV on Aug. 4, so what else needs to be done to get BIRCHDEV integrated into the repo? Let's do that today.

• Yes, the only issue here is the current size of the repo. I have outlined a plan to reduce the size.

2. I remain to be convinced of the advantage of having Getbirch obtain its downloads from the Git repo, rather than creating a stable archive file and simply downloading it. Certainly, the latter capability is needed if we have a DVD release.

• The benefit here is that we will not need to continuously generate frameworks manually when doing development (in other words, this feature is mainly for developers to cut out the "make a development framework" step. This should keep us from stepping on each other's toes, as getbirch can only have one path hardcoded at a time, but can select from as many tags as are available.
• I agree completely that the tarball method is best for stable releases.

Oligomaker/Netbeans/Git - my main question is with regard to the best way to collaborate on Oligomaker.

Presumably , anyone could check out the current Oligomaker, work on it locally, and push the changes up to the repo. The potential problem arises with the fact that Netbeans stores file paths in its configuration files. Those paths, or course, would be different on different computers.

• It stores full paths? I would like to see one of these configuration files to verify this.

One potential solution is that we all work on the copy of the Netbeans project, to be located somwhere within BIRCHDEV.

However, my intuition tells me that most developers don't work that way, and that there is another way to get around the file path issue. Where we put the Netbeans project for Oligomaker may in part be decided by the answer to these questions.

• Yes, let's discuss this further when you arrive.

Results

Put the results of the meeting, any ideas/feedback during the meeting here, as well as any meeting TO DO's.