Release 1.0.9-beta

From Qubit Toolkit

Releases > Release 1.0.9-beta

[edit] Schedule

• Preliminary testing, ongoing
• Feature freeze, 6 April 2010
  • no new features or enhancements, complete existing functionality and fix bugs
• Code freeze, 26 April 2010
  • no new commits after this date until release 1.1 is packaged and posted
• Public release, 17 May 2010
  • post installer, update website, update release history, discussion list announcement

[edit] Checklist

• Release notes
• Critical issues
• Merge translations from translate site
• Merge changes from trunk to stable branches
• Post tarballs
• Post virtual appliances
• Update demo site
• Update translate site
• Public announcement
• Update ICA-AtoM and DCB web sites

[edit] Features

[edit] Must have

• ICA-ISDF functions
• Data-entry form validation [1]
• Duplicate record, issue 411
• Access control [2]
• Print page (e.g. a CSS print stylesheet, print to PDF) [3]
• Usability enhancements
• Installer CSS fix, issue 1169
• Performance testing and optimization (segfaults)

[edit] Retrospective

[edit] Jack

• This was a smoother release with less agonizing : )
• Huge number of commits - almost double the number since the project began!
• Lots of cleanups, to PHP as well as HTML and CSS - at last! : )
• Testing tarballs and virtual appliances in parallel was generally a good move - even if we didn't catch any bugs, we were all warmed up to build tarballs and virtual appliances when the time came. And we did in fact catch some issues with both tarballs and virtual appliances ahead of time, like missing logos, etc.
• Think many of the tarball and virtual appliance versions weren't actually touched - not sure if this is a problem or how to improve? Automated nightly tarballs?
• Keeping release notes up to date reduced pain at release time - let's continue that!
• Started pretty full time testing and bug fixing around April 7th? So about five weeks of almost full time testing and bug fixing? And for the first time we almost had enough testing? Although we ran out of time for "final" tarball and virtual appliance testing at the last minute

Things to do differently next time?

???

[edit] Evelyn

• Testing was more comprehensive this time, due to following Functional testing wiki
• I had more time for testing than expected, but only because there were critical bugs left and we couldn't meet our May 3 release deadline - i.e. catching some critical bugs gave me more time for testing while they got fixed!
• Did not use selenium tests at all this time, I think that was beneficial because constant changes to the software mean that selenium tests need constant updating. However, I'd like to combine a blend of manual and selenium testing next time if it's possible
• As always, great bug fixing by David, Jack and Jesus!

[edit] Peter

• We were better prepared than previous releases to address testing cycles, respecting code freeze, release process tasks, etc.
• There's some concern now about migration from one release to the next which is accounting for the bulk of follow-up release 1.0.9 support. Release migration is one of several scalability issues that need to addressed over the coming months.
• Translations: we did not manage to get a substantial body of application translations into release 1.0.9. In fact, all the parallel translation work was being done on an outdated release 1.0.8 deploy. Release 1.0.9 had a significant number of new translation strings. Many of these are difficult to surface for translators using our existing practice of providing a page that links to active versions of all the application templates. We need to consider an alternative method, namely, passing on the raw XLIFF files directly to the translators (any other suggestions?). This would allow us to update the XLIFF files in advance of a new release and get as many translations in as possible
  • On a related note, we need to coordinate application translations for release 1.1, should we use this method? We need to put a plan in place before the summer so that translators have time to work.

[edit] David

• It seems like 5 weeks of testing was good for a high level of confidence in the release and no major post-release bugs so far - should this be our goal?
• Several major changes were made on or after the code freeze deadline - changing the routing system, scalable tree view and UI changes. The routing system change especially lead to several days of work for Jack, Evelyn, and David after the deadline. Conventional project management recommends minimizing risk by making major changes early in the release cycle. Can we minimize risk and stress in the future by changing how we prioritize features?
  • User:Jablko ^ thoughtful reflection David! Good one

[edit] Retrospective meeting

24 June 2010

• Schedule 5 weeks of testing for Release 1.1 in Sept. - worked well for 1.0.9
• Systematic testing across browsers - IE, Mozilla only?
• Add testing page for installer
• Add testing page for migrations
• Student tester in Sept. for Release 1.1
• Fixing migrations - enable users to migrate their own data
  • Fix Scalability issues
  • Data consistency problems? Data scrubber? Document examples.
• Translations
  • long-term is a re-factor of the whole translation mechanism, i.e. translation server, integration with other translation servers/projects
  • Peter: short-term I am proposing that we ask translators to work directly with XLIFF file to get as much translation coverage as possible in the short window of time before 1.1 release
• Timing and priority for major features
  • Do big changes (i.e. high possibility of regressive bugs) early in the release cycle, when possible
  • More detailed specification documentation early in the dev cycle
  • Show features to Evelyn earlier to get feedback on usability from archivist's point of view
  • Having a major demo of new release functionality right after release causes much stress, but also puts a hard deadline on features which may be good?
  • Try to stagger Qubit and Archivematica releases?
• Usability was a big win in 1.0.9, success strategies:
  • Having Usability brainstorming meeting, and wiki page to document ideas and goals
  • Better discussion between developers and archivists on building a great UI helped refine final product

[edit] Chat Log

(10:06:17 AM) Jack Bates: so quick retrospective?
(10:07:26 AM) Jack Bates: idea of retrospective is to continue doing what's working
(10:07:31 AM) Jack Bates: and learn from mistakes
(10:07:46 AM) Jack Bates: so identify things that worked in the last release and do more of them!
(10:07:55 AM) Jack Bates: and things that didn't work and not do them again
(10:08:14 AM) epmclellan: For reference, http://qubit-toolkit.org/wiki/index.php?title=Release_1.0.9-beta#Retrospective
(10:08:20 AM) Jack Bates: epmclellan: good one
(10:08:53 AM) Jack Bates: good points in the wiki
(10:09:31 AM) Jack Bates: lets try to keep actual details for later planning -
(10:10:04 AM) Jack Bates: what did work well in 1.0.9?
(10:10:26 AM) Jack Bates: i read that five weeks testing worked well
(10:10:34 AM) Jack Bates: i think lots of us wrote that
(10:10:39 AM) david.juhasz: I was just going to say that :)
(10:10:39 AM) epmclellan: that's quite a lot of testing
(10:10:46 AM) epmclellan: we won't always have that luxury, I think
(10:10:48 AM) david.juhasz: Too much testing?
(10:10:53 AM) epmclellan: no, it was great
(10:10:56 AM) david.juhasz: hehe
(10:11:01 AM) epmclellan: just that we ran over time
(10:11:09 AM) epmclellan: can never get enough of testing :)
(10:11:18 AM) vangarderen.peter: I think we should aim for the same again for the 1.1 release
(10:11:26 AM) vangarderen.peter: i.e. lots of testing
(10:11:33 AM) vangarderen.peter: starting in early Sept
(10:11:34 AM) david.juhasz: I agree, especially since 1.1 is a big release
(10:11:41 AM) ***Jack Bates nods
(10:11:42 AM) epmclellan: yes, it really did feel better than previous releases
(10:11:57 AM) Jack Bates: i think testing the tarballs and virtual appliances early was key
(10:12:00 AM) epmclellan: and no horrible bugs have turned up related to functionality, anyway
(10:12:15 AM) epmclellan: i.e. "app breaks when clicking Add new button" or something
(10:12:24 AM) vangarderen.peter: I think the one *bug* that did slip through is the IE8 installer issue
(10:12:32 AM) vangarderen.peter: fortunately that can be fixed with a patch
(10:12:32 AM) epmclellan: yes, that was pretty serious
(10:12:33 AM) Jack Bates: epmclellan: knock wood!!!
(10:12:57 AM) vangarderen.peter: but it does raise the issue of testing tarballs on multiple OS/browser combos in a systematic way
(10:12:58 AM) epmclellan: I'll create a wiki page for testing installation
(10:13:16 AM) david.juhasz: I feel like the tarball/virtual appliance testing was better this time, but there were a couple of iterations that never got tested because we were still finding so many bugs in the trunk
(10:13:22 AM) epmclellan: not detailed, but saying what we have to do, eg test on IE 8 etc
(10:13:25 AM) Jack Bates: sounds like testing with the funtional testing wiki page was a win?
(10:13:30 AM) epmclellan: yes
(10:13:30 AM) vangarderen.peter: even if that systematic way is to go down a bulleted list of combos like we went through the text-based functional tests
(10:13:36 AM) Sevein: (sorry I am at FCDM)
(10:13:44 AM) epmclellan: Sevein: np
(10:13:59 AM) epmclellan: I would have liked more tarball and vm testing
(10:14:22 AM) Jack Bates: yeah - we talked about posting a pre-release
(10:14:30 AM) Sevein: should we also try to test migrations?
(10:14:30 AM) Jack Bates: for *users*
(10:14:32 AM) vangarderen.peter: now that we have functional tests captured on wiki I wonder if we can rope in a student to start iterating through them in Sept?
(10:14:46 AM) david.juhasz: Sevein: good point, I tested migrations myself
(10:14:46 AM) Jack Bates: that would be a great goal...
(10:14:48 AM) vangarderen.peter: take some of that load of Evelyn but ensure that we are constantly testing
(10:14:50 AM) Sevein: we found some post-release bugs when users started to migrate date
(10:14:51 AM) david.juhasz: but it's not documented
(10:15:04 AM) Sevein: true
(10:15:12 AM) epmclellan: vangarderen.peter: I like the sound of that
(10:15:32 AM) epmclellan: it would be a great experience for a new grad
(10:15:39 AM) epmclellan: but there might be a steep training curve too
(10:16:03 AM) vangarderen.peter: epmclellan: that would be your call as it would fall on you to do that training
(10:16:23 AM) vangarderen.peter: the question would be whether you can free more time with student help vs amount of time spent training student
(10:16:30 AM) epmclellan: hard to say whether the extra testing help would offset the training
(10:16:38 AM) vangarderen.peter: k
(10:16:39 AM) epmclellan: have to think about it
(10:16:44 AM) Jack Bates: sounds good
(10:16:52 AM) Jack Bates: other stuff that went well this release?
(10:16:52 AM) epmclellan: if we could then keep the student for documentation, though...
(10:16:59 AM) Jack Bates: maybe compared to previous releases?
(10:17:22 AM) vangarderen.peter: ^ I think that would take more hand-holding than testing
(10:17:33 AM) epmclellan: hmm, no way out, it seems...
(10:17:37 AM) epmclellan: :)
(10:17:43 AM) vangarderen.peter: anyway, let's discuss offline
(10:17:46 AM) epmclellan: sure
(10:17:56 AM) vangarderen.peter: getting back to migrations...
(10:18:00 AM) david.juhasz: I'm taking some notes:
(10:18:01 AM) david.juhasz: http://qubit-toolkit.org/wiki/index.php?title=Release_1.0.9-beta#Meeting_-_action_items
(10:18:01 AM) vangarderen.peter: need to be tested on two levels?
(10:18:08 AM) vangarderen.peter: one for actual migration functionality
(10:18:10 AM) epmclellan: thanks jack
(10:18:12 AM) vangarderen.peter: second for scalability
(10:18:18 AM) vangarderen.peter: or just for (1)
(10:18:29 AM) vangarderen.peter: (2) is a larger development issue that we are painfully aware of
(10:18:50 AM) vangarderen.peter: I've started this page to begin to deal with it more systematically: http://qubit-toolkit.org/wiki/index.php?title=Scalability
(10:19:10 AM) vangarderen.peter: our hope is that we can postpone migration scalablity until after 1.1 when we can try to tackle it more scientifically
(10:19:11 AM) david.juhasz: Yes, I'm very interested in enabling users to migrate their own data
(10:19:30 AM) vangarderen.peter: i.e. testing options, designing re-factor options, project planning/resourcing for scalability re-factor
(10:19:38 AM) Jack Bates: agree, migrations was a pain point this release
(10:19:44 AM) david.juhasz: Which mostly involves fixing scalability I think - though there are some mysterious data consistency problems cropping up
(10:19:53 AM) vangarderen.peter: right
(10:20:07 AM) vangarderen.peter: we need to capture as much of that info right as we are dealing with it ^
(10:20:16 AM) vangarderen.peter: please use the scalability wiki page to dump info
(10:20:23 AM) Jack Bates: also sounds like we want to improve translations
(10:20:40 AM) Sevein: I'll add what I collected
(10:20:41 AM) vangarderen.peter: yes, I think there too we have to look at short-term vs long-term solution
(10:20:43 AM) Jack Bates: what other things didn't go so well this release?
(10:20:58 AM) vangarderen.peter: long-term is a re-factor of the whole translation mechanism, i.e. translation server, integration with other translation servers/projects
(10:21:27 AM) vangarderen.peter: for short-term I am proposing that we ask translators to work directly with XLIFF file to get as much translation coverage as possible in the short window of time before 1.1 release
(10:21:36 AM) Jack Bates: david mentioned large changes after code freeze -
(10:21:53 AM) Jack Bates: or close to it
(10:21:57 AM) Jack Bates: was a pain point
(10:22:12 AM) vangarderen.peter: yes, I think that has been an ongoing issue
(10:22:25 AM) epmclellan: in general, I think we were aiming for too many enhancements in too short a time
(10:22:33 AM) epmclellan: eg had to abandon permalinks because not enough time
(10:23:04 AM) epmclellan: maybe need to prioritize earlier?
(10:23:14 AM) Jack Bates: are we improving in any respect?
(10:23:16 AM) vangarderen.peter: some we saw coming but just got dragged on past the code freeze (hierarchy tree scalability), the routing change was a surprise to the rest of the team which created some anxiety last minute
(10:23:46 AM) vangarderen.peter: one way to change that is to document design options on wiki page earlier in the dev cycle
(10:24:05 AM) vangarderen.peter: basically to give team a heads-up of proposed changes/options
(10:24:41 AM) epmclellan: yes, to have a list of priorities early on so we know that, say, permalinks is lower than hierarchy treeview optimization, for example
(10:24:42 AM) david.juhasz: I agree that we are packing too much into a release in general - but I'm not sure how to reconcile that with budget considerations
(10:24:56 AM) vangarderen.peter: that said, I think we all agree that app-wide changes (i.e. routing, ORM, theming, etc) should be implemented early in the dev cycle to allow enough testing time to identify and regressions
(10:25:27 AM) vangarderen.peter: we did get theming changes in early in 1.0.9 release which made a big difference in ironing out its implications
(10:25:36 AM) epmclellan: yes, true
(10:25:38 AM) vangarderen.peter: *theming*, i.e. xhtml, css
(10:25:50 AM) Jack Bates: good point
(10:26:12 AM) david.juhasz: ACL also had mostly shaken down by the deadline, because it was started early in the release
(10:26:22 AM) Jack Bates: yes
(10:26:24 AM) epmclellan: yes, you knew it was going to be a huge job
(10:26:28 AM) david.juhasz: (and took until late in the release to complete) :)
(10:26:44 AM) david.juhasz: epmclellan: I didn't realize it was going to be *that* huge a job
(10:26:48 AM) epmclellan: heh
(10:26:54 AM) Jack Bates: so generally we're doing big changes earlier in the release -
(10:26:57 AM) david.juhasz: More detailed specification documentation would have been helpful
(10:26:58 AM) Jack Bates: compared to before
(10:27:01 AM) Jack Bates: which is good
(10:27:02 AM) epmclellan: well, sometimes you're mostly finished and then I say, "why doesn't it do xxx?"
(10:27:12 AM) vangarderen.peter: so what are similar features on the 1.1 roadmap that might cause a similar issue late in the schedule?
(10:27:27 AM) vangarderen.peter: Permalinks?
(10:27:38 AM) Jack Bates: vangarderen.peter: maybe we should leave specifics to the 1.1 planning?
(10:27:45 AM) vangarderen.peter: fair enough
(10:28:01 AM) epmclellan: yes, maybe have a separate meeting next week?
(10:28:08 AM) Sevein: sounds good
(10:28:22 AM) Jack Bates: re: "why doesn't it do xxx?" - good point
(10:28:38 AM) epmclellan: the later I see it, the later I'm going to say "archivists won't like it"
(10:28:51 AM) epmclellan: so interrupt whatever I'm doing to show me new stuff
(10:28:54 AM) epmclellan: I don't mind
(10:28:55 AM) Jack Bates: i felt like we tested features while they were still in development more this release?
(10:29:01 AM) epmclellan: yes, I think so
(10:29:16 AM) Jack Bates: so we identified less big issues late in development?
(10:29:21 AM) Jack Bates: and got feedback sooner?
(10:29:27 AM) epmclellan: except treeview, that was all over the place
(10:29:35 AM) epmclellan: because it took a while to figure out exactly what to do
(10:30:00 AM) Jack Bates: i feel like some of the issues we caught in previous release testing ended up being really big
(10:30:19 AM) Jack Bates: there were a couple really big issues in this release testing period too i guess -
(10:30:23 AM) Jack Bates: but less than before?
(10:30:34 AM) david.juhasz: ++ for early feeback from epmclellan on new features :)
(10:30:40 AM) epmclellan: :)
(10:30:47 AM) epmclellan: there was less pressure this time
(10:30:54 AM) epmclellan: because no major conference coming up
(10:30:56 AM) epmclellan: for example
(10:30:56 AM) Courtney left the room.
(10:31:04 AM) epmclellan: where we had to produce 1500 cds
(10:31:22 AM) epmclellan: so we could delay the release until we were confident in it
(10:31:26 AM) epmclellan: that was great
(10:31:38 AM) Jack Bates: cool
(10:31:44 AM) david.juhasz: Yes, tying release deadlines to a major "unveiling" is definitely a stress point
(10:31:48 AM) Jack Bates: other mistakes to learn from?
(10:31:56 AM) vangarderen.peter: yes, the release deadline did get moved several times actually until we did run into a hard conference deadline
(10:32:02 AM) epmclellan: stagger the ica-atom and archivematica releases a bit more?
(10:32:19 AM) Jack Bates: epmclellan: good thought!
(10:32:35 AM) vangarderen.peter: epmclellan: yes
(10:32:44 AM) epmclellan: k, great
(10:33:06 AM) vangarderen.peter: but again, there are related project deadlines that force those dates
(10:33:13 AM) epmclellan: yes, true
(10:33:19 AM) epmclellan: we can't always control the schedule
(10:34:58 AM) Jack Bates: i think that's awesome reflection -
(10:35:02 AM) Jack Bates: thanks everyone!
(10:35:11 AM) david.juhasz: Notes here, please feel free to add to them:
(10:35:19 AM) david.juhasz: http://qubit-toolkit.org/wiki/index.php?title=Release_1.0.9-beta#Meeting_-_action_items
(10:35:34 AM) Jack Bates: any more 1.0.9 reflections?
(10:35:39 AM) vangarderen.peter: post chat log to wiki page?
(10:35:40 AM) epmclellan: yeah
(10:35:44 AM) epmclellan: 1.0.9 is great
(10:35:45 AM) Jack Bates: here's to even better 1.1!
(10:35:48 AM) epmclellan: people love it!
(10:35:57 AM) david.juhasz: Yay!
(10:36:22 AM) Jack Bates: i think usability was a big deal in 1.0.9
(10:36:43 AM) epmclellan: usability is always a big deal!
(10:36:46 AM) Jack Bates: it's encouraging to hear that it worked?
(10:36:54 AM) epmclellan: yes, lots of good feedback
(10:37:26 AM) david.juhasz: Usability is always a big deal, but this is the first time we've actually had a set of usability goals for a release (that I know of)
(10:37:33 AM) david.juhasz: With a wiki page and everything! :)
(10:37:36 AM) Sevein: I suppose you get feedback from different ways than ica-atom-users?
(10:37:40 AM) epmclellan: I know, that's a really good thing
(10:38:15 AM) epmclellan: verbally from some people at the conference
(10:38:22 AM) epmclellan: like people from LAC
(10:38:44 AM) epmclellan: also, I really like it, so maybe I'm projecting? :)
(10:38:54 AM) Sevein: :)
(10:39:10 AM) david.juhasz: Klaus said some nice things
(10:39:20 AM) david.juhasz: which he certainly did not for 1.0.8 :)
(10:39:22 AM) epmclellan: several people have on the discussion lists
(10:39:28 AM) epmclellan: no, he was quite critical
(10:39:31 AM) david.juhasz: In the discussion lists
(10:39:39 AM) epmclellan: good feedback at the DCB workshop in Ottawa
(10:39:44 AM) vangarderen.peter: i've gotten a lot of informal positive feedback
(10:39:50 AM) epmclellan: some of them had a lot of praise for it
(10:39:51 AM) david.juhasz: Not that we want to please Klaus, but he did have some valid criticisms for 1.0.8
(10:39:59 AM) epmclellan: yes, he did
(10:40:10 AM) vangarderen.peter: including from people like MJ and Richard who had skipped a couple of releases before coming back to 1.0.9
(10:40:12 AM) david.juhasz: Not that we want to *make our goal to* please Klaus, but he did have some valid criticisms for 1.0.8
(10:40:18 AM) Sevein: do you know if Sarah from Whistler Museum updated her installation?
(10:40:25 AM) epmclellan: no, I want to please Klaus!
(10:40:35 AM) epmclellan: haven't heard for Sarah on the list
(10:40:37 AM) Sevein: she was one of the motivation for some important scalability improvemetns
(10:40:52 AM) epmclellan: Victoria Peters in Scotland has given a lot of good feedback
(10:41:12 AM) david.juhasz: I think having a brainstorming meeting with archivist and developer conversation really helped work out some great UI ideas
(10:41:33 AM) david.juhasz: Sometimes hard to harmonize those two different frameworks :)
(10:41:50 AM) epmclellan: yes, archivists always want more
(10:42:46 AM) epmclellan: think we're done?
(10:43:03 AM) david.juhasz: I think archivists just approach the interface differently
(10:43:12 AM) david.juhasz: The events dialog is a good example
(10:43:27 AM) david.juhasz: perfectly reasonable for developers, confusing for archivists :)
(10:43:43 AM) epmclellan: actually, aside from ICA folks there has been pretty good acceptance
(10:43:49 AM) epmclellan: of event dialogue
(10:43:58 AM) epmclellan: it's a powerful tool, they can see that
(10:44:16 AM) david.juhasz: hmm, i thought we'd gotten some mixed reviews from the community - but that was a long time ago
(10:44:29 AM) epmclellan: haven't heard anything recently, I take that as a good sign
(10:44:34 AM) david.juhasz: :)