fluid-work IRC Logs-2010-04-22

Owned by Fluid IRC Log Bot
Last updated: Apr 22, 2010Version comment
11 min read

[09:05:27 EDT(-0400)] * jhung (~Jon@H37.C193.cci.switchworks.net) has joined #fluid-work
[09:22:21 EDT(-0400)] * jameswy (~jameswy@142.150.154.115) has joined #fluid-work
[09:27:32 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[09:34:03 EDT(-0400)] <jhung> joost, you there?
[09:37:56 EDT(-0400)] * clown (~clown@142.150.154.101) has joined #fluid-work
[09:44:49 EDT(-0400)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[09:56:16 EDT(-0400)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:00:32 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[10:23:00 EDT(-0400)] <joost> jhung: yes
[10:25:15 EDT(-0400)] <jhung> joost, I'm just about to reboot. Can you take a look at DECA-102 (http://issues.fluidproject.org/browse/DECA-102) and see how this is possible?
[10:27:39 EDT(-0400)] <joost> jhung: greyascale and binarization are two different steps that can be split. do you just need both output images or do you want to call just the method that is needed?
[10:29:44 EDT(-0400)] * jhung1 (~Jon@H37.C193.cci.switchworks.net) has joined #fluid-work
[10:34:20 EDT(-0400)] <joost> link to the dataset for decapod-pdfgen evaluation: http://iupr1.cs.uni-kl.de/~joost/dataset/
[10:57:29 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[11:24:01 EDT(-0400)] * michelled_ (~michelled@142.150.154.141) has joined #fluid-work
[11:48:56 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:48:29 EDT(-0400)] <jhung1> jameswy - are you editing the Threshold page?
[12:48:59 EDT(-0400)] <jameswy> jhung1: nope--was just stealing markup. No worries about edit conflicts.
[12:49:04 EDT(-0400)] <jhung1> ok
[12:56:45 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[13:25:36 EDT(-0400)] <jhung1> jessm, tmb, jameswy: found this interesting blog while searching for unpaper thresholding examples. http://ssdigit.nothingisreal.com/2010/03/final-results-with-unpaper.html
[13:26:03 EDT(-0400)] <jhung1> has a bit about auto-cropping which is what we're looking for as well.
[13:26:04 EDT(-0400)] <jessm> jhung1: our peeps!
[13:34:50 EDT(-0400)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[13:57:51 EDT(-0400)] <jameswy> jhung1: you mentioned Joost or Michael gave us a 700 MB package of book pages--where can I find that?
[13:58:00 EDT(-0400)] <jameswy> Is that in the repo?
[13:58:37 EDT(-0400)] * elicochran (~elicochra@dhcp-169-229-212-35.LIPS.Berkeley.EDU) has joined #fluid-work
[14:04:00 EDT(-0400)] <jhung1> jameswy: http://iupr1.cs.uni-kl.de/~joost/dataset/
[14:04:07 EDT(-0400)] * jhung1 (~Jon@H37.C193.cci.switchworks.net) has left #fluid-work
[14:04:15 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[14:05:24 EDT(-0400)] * jhung1 (~Jon@H37.C193.cci.switchworks.net) has joined #fluid-work
[14:05:33 EDT(-0400)] * elicochran_ (~elicochra@dhcp-169-229-212-35.LIPS.Berkeley.EDU) has joined #fluid-work
[16:07:24 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[16:35:55 EDT(-0400)] * jhung1 (~Jon@H37.C193.cci.switchworks.net) has left #fluid-work
[17:16:52 EDT(-0400)] * clown (~clown@142.150.154.101) has left #fluid-work
[17:23:22 EDT(-0400)] * elicochran (~elicochra@dhcp-169-229-212-35.LIPS.Berkeley.EDU) has joined #fluid-work
[18:16:51 EDT(-0400)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[02:59:53 EDT(-0400)] * joost (~joost@dfki-113.dfki.uni-kl.de) has joined #fluid-work
[03:13:47 EDT(-0400)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[05:21:36 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[07:07:55 EDT(-0400)] * 45PAAFMTP (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[08:01:26 EDT(-0400)] * yura_ (~yura@142.150.154.114) has joined #fluid-work
[08:56:01 EDT(-0400)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[08:56:39 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[08:56:45 EDT(-0400)] * colinclark (~colin@bas2-toronto09-1176131665.dsl.bell.ca) has joined #fluid-work
[08:59:48 EDT(-0400)] <kasper> justin_o: got time for a few questions?
[09:00:20 EDT(-0400)] <Justin_o> kasper: sure...
[09:01:14 EDT(-0400)] <kasper> great!
[09:02:22 EDT(-0400)] <kasper> ok.. some background: We're attempting to release cspace 0.5.1, and are getting closer and closer.. I have not have time for writing detailed testplans for very much of it, nor had time for created automatic acceptance testing
[09:03:05 EDT(-0400)] <kasper> Therefore the testing so far has been very ad-hoc, and while doing them i've been filing bugs, and writing notes (as a basis for writing more detailed testplans)
[09:04:06 EDT(-0400)] <kasper> ok: my problem is I have a hard time prioritizing between: automatic acceptance testing, doing the needed testing for current release/functionality, and writing detailed testplans
[09:04:19 EDT(-0400)] <kasper> All three of those take quite a lot of time
[09:04:29 EDT(-0400)] <kasper> and all of them have their advantages
[09:05:13 EDT(-0400)] <Justin_o> kasper: i totally understand those issues... when is the release scheduled for?
[09:05:24 EDT(-0400)] <kasper> 2 weeks ago
[09:05:26 EDT(-0400)] <kasper> (big grin)
[09:05:51 EDT(-0400)] <kasper> well.. it was supposed to be released (be the original plan) approx. two weeks ago
[09:06:13 EDT(-0400)] <kasper> problem is that it is not untill now (i think) that cspace is being thoroughly tested
[09:06:28 EDT(-0400)] <kasper> so there are a lot of rather serious bugs appearing
[09:07:27 EDT(-0400)] <kasper> But even after 0.5.1 I think I will be in the same situation, as we got an "Integration release" coming up just a few weeks after that, at the most
[09:08:17 EDT(-0400)] <kasper> ... So in general, I think from now on, until release 1.0 I will be faced with the issue of not having enough time to do those three things satisfactory
[09:08:42 EDT(-0400)] <kasper> which i guess means i have to prioritize, or compromize for that matter
[09:09:24 EDT(-0400)] <kasper> .. I guess my question would be; what would you consider the most important?
[09:09:35 EDT(-0400)] <kasper> Or what would be your priority of those?
[09:09:55 EDT(-0400)] <kasper> jesus.. sorry for spilling a full novel on you
[09:11:05 EDT(-0400)] <Justin_o> kasper: (smile)
[09:11:08 EDT(-0400)] <Justin_o> no problem...
[09:11:34 EDT(-0400)] <Justin_o> okay... so i think you have some pressing needs to get the testing done... i think that you will probably have to do this incrementally
[09:11:49 EDT(-0400)] <Justin_o> for this current release i think you are probably stuck
[09:12:01 EDT(-0400)] <Justin_o> unless you have time while you are waiting for bug fixes to get a test plan or two written
[09:12:09 EDT(-0400)] <kasper> yeah ok
[09:12:28 EDT(-0400)] <Justin_o> in between releases i would write as many test plans as possible and continue to do so until you have coverage for the system
[09:12:36 EDT(-0400)] <Justin_o> then you can start converting those to automated tests
[09:12:50 EDT(-0400)] <kasper> that makes a lot of sense
[09:14:37 EDT(-0400)] <Justin_o> kasper: the good thing is that as you start to develop test plans and then move into automated testing... each step of the way should make your testing more thorough and easier.. as well as making it possible to get more help
[09:14:56 EDT(-0400)] <Justin_o> so hopefully by 1.0 you will have been able to free up more time
[09:15:36 EDT(-0400)] <kasper> ahh .. "more time" sounds very good (big grin)
[09:16:22 EDT(-0400)] <Justin_o> (smile)
[09:16:25 EDT(-0400)] <kasper> but yea.. that sounds very true
[09:16:29 EDT(-0400)] <kasper> justin_o: Another i bumped into is that the release has been dragging out, mainly due to bugs being found and having to be fixed
[09:16:53 EDT(-0400)] <kasper> But it aint really possible to do the testing untill stuff has been implemented
[09:17:02 EDT(-0400)] <kasper> How do you go about this?
[09:17:19 EDT(-0400)] <kasper> simply allowing enough time for bugfixing after code stop.. or?
[09:17:28 EDT(-0400)] <kasper> or take smaller "steps"
[09:17:53 EDT(-0400)] <kasper> eg. add a single feature, then test, debug, retest, etc.... Then add another?
[09:18:05 EDT(-0400)] <Justin_o> kasper: so there are a few ways... this is something that will be easier once there are automated tests and more unit tests available of course...
[09:18:48 EDT(-0400)] <Justin_o> kasper: 1) you should make sure that the developers are accountable for doing testing before they commit. This won't catch everything of course, but hopefully will knock off alot of obvious mistakes
[09:19:05 EDT(-0400)] <kasper> yeah... I think this release is probably gonna be one of the worse in terms of this problem, since we havent tested very thoroughly before
[09:19:07 EDT(-0400)] <kasper> yeah
[09:20:56 EDT(-0400)] <Justin_o> yes that does make it much more difficult
[09:21:23 EDT(-0400)] <Justin_o> 2) would be to test after each commit, this probably won't be practical if the scale is too large, which i suspect it is
[09:22:16 EDT(-0400)] <kasper> yeah.. i suspect that too.. But i guess we might be able to do a partial testsuite that has to be run after each commit
[09:22:22 EDT(-0400)] <kasper> to take the worst
[09:22:23 EDT(-0400)] * jhung (~Jon@H37.C193.cci.switchworks.net) has joined #fluid-work
[09:22:27 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:22:29 EDT(-0400)] <Justin_o> 3) I think cSpace has a nightly build, if this is the case you should probably be doing a quick run through each morning to make sure things haven't broken ( this will also become tough as scale increase before the automated and unit tests)
[09:23:03 EDT(-0400)] <Justin_o> kasper: yep... just to clarify was this a question for whenever or during these particular fixes
[09:24:01 EDT(-0400)] <kasper> Mostly in terms of the time up to a release
[09:24:13 EDT(-0400)] <kasper> which is what has messed us up right now
[09:24:22 EDT(-0400)] <kasper> but i guess it holds in general too
[09:24:42 EDT(-0400)] <Justin_o> oh okay.. i think i'm clear now...
[09:25:32 EDT(-0400)] <Justin_o> something that I would like and have tried to suggest with some of the fluid projects is for the designers to regularly check in and to do a walkthrough of the system before feature freeze. You should do this as well...
[09:25:54 EDT(-0400)] <Justin_o> then you should have a good idea of what needs to get fixed and you can prioritize this during your feature freeze period
[09:26:45 EDT(-0400)] <Justin_o> that way hopefully you will be taking care of all the blockers at the feature freeze time..
[09:27:04 EDT(-0400)] <Justin_o> although there may be surprises from time to time in the final qa push, but hopefully these will be rare
[09:27:24 EDT(-0400)] <kasper> thats a good idea
[09:30:16 EDT(-0400)] <kasper> Do you have any place with an overview of the progress of the individual parts for the next release; reason I'm asking is that we work across 3 teams (backend, app, UI), and it's very hard to keep track of when a feature is 'fully' implemented, and ready for testing
[09:30:37 EDT(-0400)] <kasper> Not having this, makes it more difficult for the designers and me to know what we can expect to work
[09:31:41 EDT(-0400)] <kasper> I talked to megan about updating our roadmap to something like this: http://wiki.collectionspace.org/display/collectionspace/rm2 ... but that requires quite a bit of extra bookkeeping from all times
[09:31:58 EDT(-0400)] <kasper> times = teams (smile)
[09:33:35 EDT(-0400)] <Justin_o> kasper: hmm... here is something that we did for engage to try to keep things focused
[09:33:36 EDT(-0400)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Engage+0.3+beta+Development+Phases
[09:34:23 EDT(-0400)] <Justin_o> you'll probably have to modify this for cSpace since the teams are more split in what parts they work on, but there are, I'm guessing, dependencies from one to the other
[09:34:53 EDT(-0400)] <Justin_o> michelle helped a lot in making this, so you may want to chat with her about how to do iteration planning and tasking
[09:35:59 EDT(-0400)] <kasper> that looks very nice
[09:36:28 EDT(-0400)] <kasper> ok.. I'll try to ping her later
[09:36:46 EDT(-0400)] <kasper> but i think you're right, that we might have some heavy dependency problems
[09:38:25 EDT(-0400)] <kasper> On the other hand, I think generally there is a: QA testing -> depends on UI -> depends on application -> depends on service -> depends on design
[09:38:27 EDT(-0400)] <kasper> pattern
[09:39:05 EDT(-0400)] * clown (~clown@142.150.154.101) has joined #fluid-work
[09:39:26 EDT(-0400)] <Justin_o> hmm interesting...
[09:39:35 EDT(-0400)] <Justin_o> how are the layers about unit tests
[09:40:03 EDT(-0400)] <kasper> I think all the teams unit test fairly thoroughly, if that's what you mean?
[09:41:32 EDT(-0400)] <kasper> oh... i guess i should meantion, in my world "team" == "layer" (smile)
[09:50:20 EDT(-0400)] <Justin_o> kasper: yep got it...
[09:50:38 EDT(-0400)] <Justin_o> okay... so you are more concerned with the integration then
[09:50:38 EDT(-0400)] <kasper> about the dependencies; I'm actually not really sure that is the case.. I guess the different teams can develop their parts independently
[09:51:34 EDT(-0400)] <Justin_o> okay... i guess the dependency would be if one layer needed a feature from the other
[09:51:44 EDT(-0400)] <kasper> yeah, exactly
[09:52:32 EDT(-0400)] <kasper> and in general: Ui only speaks to app which only speaks to service
[09:52:59 EDT(-0400)] <kasper> but i do think, the integration is where all the bugs have appeared
[09:53:48 EDT(-0400)] <kasper> and what i would like is to avoid having a bomb dropped as soon as the a functionality is integrated across the layers
[09:54:04 EDT(-0400)] <kasper> because individually (according to unit tests), the layers work
[09:54:20 EDT(-0400)] <kasper> but as soon as you put it all together, bugs starts appearing
[09:54:54 EDT(-0400)] <kasper> .. it would be nice to spread out the bugs instead
[09:55:02 EDT(-0400)] <Justin_o> kasper: (smile)
[09:55:02 EDT(-0400)] <kasper> but i guess that's a common problem
[09:55:29 EDT(-0400)] <Justin_o> a bit yes... can the individual layers do integration testing or does it have to wait till the end
[09:55:54 EDT(-0400)] <kasper> hmm.. yeah.. that's a good question, which i'm not really capable of answering
[09:56:19 EDT(-0400)] <Justin_o> ah okay...
[09:56:23 EDT(-0400)] <kasper> I think the service and app layer can do integration testing
[09:56:54 EDT(-0400)] <kasper> but i doubt UI and app would be able to do any sensible integration testing without involving the service layer
[09:57:18 EDT(-0400)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[09:57:18 EDT(-0400)] <kasper> which i guess is why i tend to think of the dependency hierarchy described above
[09:58:20 EDT(-0400)] <Justin_o> kasper: okay... is there a nightly build that incorporates all layers?
[09:59:09 EDT(-0400)] <kasper> justin_o: yeah.. I'm pretty sure.. but i have to check
[09:59:11 EDT(-0400)] <kasper> one sec
[10:02:24 EDT(-0400)] <kasper> justin_o: well.. doesn't look like it
[10:02:36 EDT(-0400)] <kasper> apparently it has been started, but never finished
[10:02:47 EDT(-0400)] <Justin_o> (sad)
[10:03:38 EDT(-0400)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:05:42 EDT(-0400)] <kasper> justin_o: btw, according to the plan you linked, when would the testing be done
[10:16:15 EDT(-0400)] <Justin_o> kasper: yes.. so for this one we were actually testing as we went and the designer was pretty much on top of it daily, even several times a day
[10:17:13 EDT(-0400)] <Justin_o> then of course qa testing for the release would have happened... although this was a special case in that it was originally supposed to be 0.3 and then we switched our focus mid way do to some other constraints
[10:18:44 EDT(-0400)] <kasper> Are you working in layers too, or do you have a 'single layer' that can be tested as soon as it is implemented?
[10:18:48 EDT(-0400)] <kasper> justin_o
[10:23:26 EDT(-0400)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[10:29:04 EDT(-0400)] <Justin_o> kasper: for infusion we pretty much had a single layer... for engage we had a server side and a client side
[10:29:34 EDT(-0400)] <Justin_o> for decapod we will have probably 3 layers
[10:30:54 EDT(-0400)] <Justin_o> kasper: for engage we basically worked on both of them together and didn't really treat them as seperate entities too much, since the client side was do a lot of interaction with the server
[10:31:28 EDT(-0400)] <kasper> justin_o: ok
[10:31:37 EDT(-0400)] <kasper> justin_o: so.. are you planning to stick to your current way of doing the testing/QA, or are you also looking towards some automation, etc for decapod?
[10:32:56 EDT(-0400)] <Justin_o> kasper: yes.. definitely we want to move towards more automation wherever possible
[10:40:30 EDT(-0400)] <kasper> ok
[10:41:29 EDT(-0400)] <kasper> justin_o: Thanks a lot for taking time to for this chat.. Its been very helpful!
[10:43:03 EDT(-0400)] <Justin_o> kasper: glad i could help... and please let me know how it all works for you... i think it was anastasia or michelle who noticed how you link to the test plans from the task itself, so i'm probably going to start doing that for my task lists too (smile)
[10:43:37 EDT(-0400)] <kasper> hehe great
[10:51:49 EDT(-0400)] * justin_o_ (~jmo@142.150.154.101) has joined #fluid-work
[10:52:08 EDT(-0400)] <Justin_o> jhung: what was the link to the decapod google code page?
[10:52:50 EDT(-0400)] <jhung> http://code.google.com/p/decapod/
[10:54:10 EDT(-0400)] <jhung> jessm, justin_o, jameswy, joost, tmb_ : the Decapod release schedule has been updated.
[10:54:35 EDT(-0400)] <Justin_o> jhung: thanks
[10:54:55 EDT(-0400)] <jessm> jhung: it looks great
[10:54:58 EDT(-0400)] <jessm> just checking it out
[10:55:15 EDT(-0400)] <jessm> jhung: and yes, it'll be great to have folks look at this in advance and then talk about it at the next mtg.
[11:31:46 EDT(-0400)] * sgithens (~sgithens@2001:18e8:3:443:221:9bff:fedb:d729) has joined #fluid-work
[12:04:54 EDT(-0400)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[12:21:08 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:24:34 EDT(-0400)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[13:48:38 EDT(-0400)] <Justin_o> jhung: hello, quick question... do you know what ide joost and michael use. Also how they interact with mercurial?
[13:49:05 EDT(-0400)] <jhung> Nope. No idea. Best to ping them via email.
[14:12:39 EDT(-0400)] <Justin_o> jhung: thanks
[15:48:00 EDT(-0400)] <jessm> so, Justin_o i just asked you a bunch of questions regarding HG in IM – and you gave a bunch of answers
[15:48:04 EDT(-0400)] <jessm> i should have asked in the channel
[15:48:20 EDT(-0400)] <jessm> can you put your thoughts in here for others to see where we are on deciding to use HG or not?
[15:48:35 EDT(-0400)] <Justin_o> jessm: i should have answered in the channel (smile), i can restate those here
[15:48:54 EDT(-0400)] <jessm> michelled: and I'm also hoping you'll be able to tune in and give Justin_o a hand in making a final decision
[15:49:27 EDT(-0400)] <Justin_o> So i've tried using the mercurial eclipse plugin, but i don't think it is particularly well designed in terms of usability
[15:49:39 EDT(-0400)] <Justin_o> not as good as the svn plugin at least
[15:50:59 EDT(-0400)] <Justin_o> I also spent some time talking to colleague here about GIT and the work flow they went with was to have one person pull from the various people's remote repositories on the server and then merging them into trunk. Instead of everyone merging their branches into trunk
[15:51:36 EDT(-0400)] <Justin_o> their release scheduling is quite different from ours though, but they felt it would be easier that way to manage the code
[15:52:11 EDT(-0400)] <Justin_o> they also switched to SVN because the GIT eclipse plugin wasn't good, but it was missing GIT commands.