Release/1.0

[dankessler]

This pull request should serve to get us started towards Release 1.0. The diff is not too dramatic, but it'd be great if we could actually get everyone to check this out, poke around, and make sure that it contains everything that they want in the release, and nothing more.

@shijiaguo has effectively been testing this for a week or two now since the only real things introduced in this change used to be only in spm8Batch_alpha, and that's what she's been using.

I know there a couple of open issues (e.g. #93, #94) but I'm not sure whether those are show-stoppers that should hold back release.

This release is currently slated to "go live" on Wednesday, August 1, 2012, so let's hop to it in doing some testing!

-Daniel

[dankessler]

If you want to test this, do the following, where github/dankessler should be replaced with whatever alias you used for my repository git@github.com:dankessler/MethodsCore

git fetch github/dankessler
git checkout github/dankessler/release/1.0 -b release/1.0

then go to work.

Also, kind of cool that release 1.0 pull request ended up being issue 100 :)

[mangstad]

I would say it would be nice if #93 and #94 could be addressed, but they are definitely not requirements for release 1.0, so it should go ahead whether they are addressed or not.

---

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

[dankessler]

Stuff left to do (to wit)

• Update README file in mcRoot
• Quietly setup repositories on cluster, psyche, Zubieta cluster, and Heitzeg cluster. Set them to track public so that once we go live we can just run the self-update script.

[mangstad]

What's the best way to get this into a deployment? I was going to update the MethodsCoreTest on dysthymia to this because Yanni needs to preprocess some data so I figured if she started today that would be some additional testing. I'm currently tracking spm8Batch_alpha, but wanted to adjust it to track the actual release candidate, but I don't think I can set it to track something that's not in universe?

[dankessler]

I back-propagated the release candidate to spm8Batch_alpha, so for now they're equivalent, and you can keep tracking that branch.

[dankessler]

@mangstad also makes me realize maybe I should tweak the workflow for preparing a release so that there is actually a release branch, in universe, where I can quickly put the release candidate. Then the pull request can be universe@release -> universe@public

[mangstad]

Yeah, I think that makes sense. And it makes it easier for us to do final testing before release.

---

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

[dankessler]

Alright, I'll go ahead and quickly do that right now, though documentation
will be out of date until I update it

On Tue, Jul 31, 2012 at 10:28 AM, Mike Angstadt <
reply@reply.github.com

wrote:

Yeah, I think that makes sense. And it makes it easier for us to do final
testing before release.

---

Electronic Mail is not secure, may not be read every day, and should not
be used for urgent or sensitive issues

---

Reply to this email directly or view it on GitHub:

#100 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[dankessler]

Ok, going to go ahead and close this pull request. Discussion can move over to #102

[mangstad]

Okay, /net/dysthymia/MethodsCoreTest on the cluster is now set up to track the release branch, so should provide a good testbed on the cluster.

---

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

[dankessler]

Sweet, thanks!

On Tue, Jul 31, 2012 at 10:42 AM, Mike Angstadt <
reply@reply.github.com

wrote:

Okay, /net/dysthymia/MethodsCoreTest on the cluster is now set up to track
the release branch, so should provide a good testbed on the cluster.

---

Electronic Mail is not secure, may not be read every day, and should not
be used for urgent or sensitive issues

---

Reply to this email directly or view it on GitHub:

#100 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[rcwelsh]

I'll be updating spm8Batch to have the correction for the "feature" in warpfMRI about logging that @mangstad pointed out. Also I've modified sliceTime to have options for TR and TGLOBAL. Finally, I've added a new flag that allows all commands run in the foreground. This will facilitate daisy-chaining the processing. Daisy chaining is mainly a feature to be used at the imaging center for pre-processing of data for investigators, however, it will become available also as a tool at a later date. Presently it's possible to daisy chain by hand.

@shijiaguo : did you find any issues with help that is displayed at each command? I want to make sure it all is correct.

[mangstad]

If you didn't, I also would suggest adding an option for different slice acquisition order (there are several options in slicetimer dealing with this including --down, --odd, and --ocustom and possibly some more). However, given our proposed release date of tomorrow I don't think it's wise to integrate any of these into that release -- with the possible exception of the bug fix.

[rcwelsh]

mike, good point, i can probably do that, though the custom etc will be a pain in the butt, i'll need to think of a solution for that. presently for realignfMRI i use a global option capability so i made be able to work off that.

[shijiaguo]

@rcwelsh , except for the issues @mangstad brought up, I think everything else looks fine until now.

[shijiaguo]

@rcwelsh one thing is in vbm8 or warp I don't remember exactly, if you append a 'w' for the output image, the process will be terminated for some reason (I believe the reason is it skips a loop if it finds a w* img in the directory). If you could check that it will be good. @mangstad could you remind us about that?

[rcwelsh]

thanks scarlet, that is one of the fixes to be merged today.

[shijiaguo]

@rcwelsh I just talked to Yanni, we took a look at your help files, some of them doesn't make sense.

1. in sliceTime, there's no explaination about the -s flag
2. the examples made are not very typical
3. in coregHires, there's an typo, you used the old command coregSPGR

If in the release we can put something like the documentation @heffjos talked about in a previous issue, but not just push the users to the help, that will be better.

[dankessler]

@shijiaguo to clarify about 3, that's a typo in the help right, not a bug
in the code?

On Tue, Jul 31, 2012 at 4:03 PM, Shijia Guo <
reply@reply.github.com

wrote:

@rcwelsh I just talked to Yanni, we took a look at your help files, some
of them doesn't make sense.

1. in sliceTime, there's no explaination about the -s flag
2. the examples made are not very typical
3. in coregHires, there's an typo, you used the old command coregSPGR

If in the release we can put something like the documentation @heffjos
talked about in a previous issue, but not just push the users to the help,
that will be better.

---

Reply to this email directly or view it on GitHub:

#100 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[shijiaguo]

Yeah that's a typo in the help file

[rcwelsh]

okay, I'll fix those, but they are not super critical.

1. if the "-s" flag shows no help, then the flag is not supported, the
   help file is just erroneous with the example.

2. the examples are really old, and they are examples

3. that is also a typo in the help file which I can update.

As for not pushing the help files, that is not recommended and indeed will
break the whole thing, the help files are integral in a way, if they were
there and if a command was issued either with no parameters or the wrong
parameters it would then fail when trying to print out help and just cause
more confusion.

indeed that is one of the nice things about the commands is that they have
built-in help

anyway, the help files do need a little bit of tending, but not critical
for the release.

On 7/31/12 4:03 PM, "Shijia Guo"
<reply+i-5922836-91a08f4f8d89a2ee3f897359a63d77c2f066ff1f-1485912@reply.git
hub.com> wrote:

@rcwelsh I just talked to Yanni, we took a look at your help files, some
of them doesn't make sense.

1. in sliceTime, there's no explaination about the -s flag
2. the examples made are not very typical
3. in coregHires, there's an typo, you used the old command coregSPGR

If in the release we can put something like the documentation @heffjos
talked about in a previous issue, but not just push the users to the help,
that will be better.

---

Reply to this email directly or view it on GitHub:
#100 (comment)
9807

---

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

[shijiaguo]

@rcwelsh You are right the help is not critical. The point is that we prob should give some instructions to the users. Otherwise they will have problem running the program.

I took a look at the spm8Batch/SPM8Batch_Supplement.pdf and SPM*BATCH.pdf, they talk about the structure but not the flags. If the user can be pointed to those two files and also look at the help, they prob will have less problem.

[rcwelsh]

the flags are listed on page 7 of "SPM8BATCH.pdf", though slightly out of
date as they don't include the latest I added today.

however, these are minor and can be fixed and pushed out next week as a
minor update that people won't be effected by operationally.

-robert

On 7/31/12 4:28 PM, "Shijia Guo"
<reply+i-5922836-91a08f4f8d89a2ee3f897359a63d77c2f066ff1f-1485912@reply.git
hub.com> wrote:

@rcwelsh You are right the help is not critical. The point is that we prob
should give some instructions to the users. Otherwise they will have
problem running the program.

I took a look at the spm8Batch/SPM8Batch_Supplement.pdf and SPM*BATCH.pdf,
they talk about the structure but not the flags. If the user can be
pointed to those two files and also look at the help, they prob will have
less problem.

---

Reply to this email directly or view it on GitHub:
#100 (comment)
0394

---

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues