r5 - 01 Mar 2007 - 17:48:05 - PriscillaChungYou are here: OSAF >  Journal Web  >  ServerMeetingNotes > CosmoMeeting20070227

0.6 Postmortem February 27, 2007

Agenda or topic list

We will be discussing 0.6 in terms of "More of", "Less of", " Same as", and address the following areas:

  • Planning
  • Design
  • Development processes
  • Testing
  • Bug fixing, reporting and triage
  • Build/Release
  • Documentation
  • Community
  • General


Planning

  • The planning seemed fine on the product end.
  • Collection details dialog–things were missing
  • Forgot to implement Preferences–a few features for forgotten
  • spec of collection details were changing–moving target.
  • multiple iterations on the spec
  • let thing's go out and iterative process
  • building iterative design
  • plan forward in our schedule to give more time for the iterative
  • specific time to iterate on the time and to change things dramatically
  • You can't spec out the details in the beginning–See some of it, come together in the code. Dependency we don't realize.
  • Building that into the schedule given a finite time, 'oh I'm trying to do this thing but need more time'
  • Dev to have more time looking at the design spec. --> better feedback on what is possible/difficult
  • Broke down the task at a high level, but did not work through all the --> dev did an okay job this time, can do better, smarter way to understand our stuff better. -bcm
  • here is feature we might need to iterate a lot on, send out to the dev. pick a number, 4 days of iterate, multiply by 3 to do it by 12 days-rules of thumb. - ted
  • some way of gaging the schedule impact. Want the change to iterate.
  • don't want to iterate so much we don't have the time. -ted
  • shorter release cycles not longer.
  • driven by and end user product goal, made it harder to come up with the right estimates–better next time for adding in upgrade process
  • pro-agile development but having it tested w/ putting it in front of customers. -jared
  • driven by a goal rather then a date
  • would like to see much smaller goals for agile programing - jared implement it release it and
  • tenet for the release were too big. less of planning for the full goals.
  • would rather see more
  • tenets for preview, would you like to see them break them up
  • time based release was no use because there was nothing to use. -not a failure to
  • driving towards an end product.
  • what are right sub mile stones?
  • smaller measurable features
  • what is implementable
  • smaller set of features for a sub mile stone
  • define your end goal and suck it up for preview.
  • get to a shorter predictable cycle-not to mess w/ it right now -ted
  • this is where we're going for post preview, 6 weeks mile stones, these are the type of things which are getting fixed.
  • make process and improvements as well.
  • shorter release- more of that hard?
  • more of front loading architectural pieces

Design

  • Allowing design threads to go long without resolution
  • less of agile programing model for design - we did mock ups sooner because Mimi & Priss was trying to be agile
  • when we're tying to do something that is new, agile programing is difficult
  • brainstorming concepts beforehand - mimi
  • clear articulation for the chandler server product even in the end server product issues. Request for server product features.
  • High level understanding of the server product. Need more workflow even though it's not end user request.
  • the design pre-request were not done.
  • every workflow is different, 0.6 that was unusual amount of change. --> work though the details - mimi
  • this didn't feel like iterations - br.
  • getting into design sessions earlier
  • iterative development should be a two way street. As a dev. building UI– need that extra time to build things out. -mde
  • don't want to see unlimited iterations. what's a good design for user w/ out feedback from users. - ted
  • developers sit next to designers?
  • Designer and Dev to work together (check in on each other) on code even when it's not checked it. 10 min review, less costly.
  • they weren't having in the code, it was happening on the list.
  • ie. ticket view workflow stretched into the collection dialog–time upfront spent on planning on prioritizing the workflows, slightly different understanding the user. Dove into creating mock ups/design-listing out the workflows in text and coming into an agreement in the workflows in text.

Development processes

  • the dojo build stuff should be at the beginning of the release
  • very little of time that developers were developing -br
  • just mis-underestimated all the work to be done. First time to use windmill, bugs from before.
  • now that this baseline exists.
  • more of the UI review, feel free to grab design resources
  • Devs to check w/ design before you check things in
  • explicit hand off when dev., not as much during the end
  • explicitly hand of to QA and what is test-able condition, UI review check
  • do it in the cosmo list so ppl will
  • feature creeps, /home /dav thing at the end. –that was scheduled -ted
  • there will be a bugzilla super
  • need to schedule in the beginning of the release.
  • no concerns with the actual changes which were made.
  • rushed panic work
  • earlier is better then later, there was a bit of a panic. -jared
  • make bugs which are dependencies to osaf.us
  • having one planning wiki page for the preview release, that is where the bug list is, features
  • not having to jump through a lot of pages

Testing

  • Devs being able to run the relevant automated tests before checkin
  • Automated test suite coverage
  • Basic acceptance test scripts for Chandler interop
  • Explicit hand-offs of features from devs to QA when features are completed
  • Dev participation in the IRC QA sessions

  • QA - better planning
  • more of testing
  • more dogfooders
  • more cross browsers, more IE6 browsers that came in at the end.
  • make a list of the supported browsers
  • having a test spec. concious decision, this was going to be short 6 wks., but in the end it was more work
  • next release test case documented, and tracking them
  • several RC, 'brown paper bag' RC, pre RC 'smoke test', so bad RC
  • Java Script is prone to introducing those kinds of codes. - it's hard to catch it.
  • Somebody builds it and tests
  • it's about doing a checkpoint then validate it to do a RC
  • having a tinderbox might have helped
  • tinder box does not do cross browser live testing, would not help - bear
  • tinderbox always either orange or red -hekkit
  • not been online for over a month
  • tinderbox only unit tests
  • turned it off for other resources
  • only one OSX tinderbox machine - to run safari, what about firefox?

Bug fixing, reporting and triage

  • more QA related stuff
  • being on all the bug council where they okay w/ the bugs classified as blockers?
  • QA reports it –what's a blocker or not?
  • harmonious group that decides a block or not, not just QA
  • plenty of RCs to do that
  • if we use this process, how do we do a better job at estimating the end date? We don't know how many new blockers, can we doa better ajob at that period at the code freeze and the final phase of the final blocker?
  • there was covering so much stuff in 0.6. -br will eat his words
  • we flushed out a lot of things we may not see that delta again -aparna
  • why the qa cycle lasted so long, when we hit feature complete, it was not feature complete.
  • such as the dojo build stuff - not a feature, it's part of the build -mde
  • after feature freeze to code freeze, philippe's email on the list, design fixes can
  • change the build it has to be a part of that.
  • changes for 0.6.1 is already done. -ted
  • do we need another milestones, for code freeze and code complete?
  • avoid them as far as possible, may not need milestone - aparna
  • contradictory to what philippe's email, though it's for Chandler, we may need to define this for cosmo
  • feature freeze, I fear that is part of the end, and don't want to put more after that -mikeal
  • feature freeze includes - unit tests
  • as for dev. more unit test and windmill test as well! -br
  • All level of unit test
  • More participation in the IRC QA sessions!!! -aparna
  • try out different features
  • help having everyone listening and trying out things
  • once you're feature complete, we'll do a session on that feature
  • ie. settings dialog thing, the way we went in, I appreciate it was working on w/ not iterate it
  • staggered code drops

Build/Release

  • Last minute build system hacking
  • Coordinating non-code deliverables via the public lists
  • Serious cross-browser (e.g., IE6) testing, much earlier
  • Serious cross-browser testing by devs
  • Cross browser smoke tests before we try to cut an RC. We had one brown paper bag RC (the RC was really bad, but a bag over it expression)
  • build changes before rather then after.
  • bear and I it worked well.
  • need more clarity on how tinderbox be used.

Documentation

  • the morse code doc is very good - mikeal
  • going to the 0.6 design spec was hard to find.
  • having all the design listed on one page would be more useful, ted said is going
  • non-code deliverables more coordination in the list
  • point to point, help doc.
  • better coordination two different ppl were assigned to update the URL in the code.
  • redirects on wiki page- because there more then one URL - need to try it out the URLs
  • QA have some automated test for testing the links in the application - problem controlling the page when launching another page
  • if it's click-able link, Pieter documents it in some way. Help link, there were two different links, there was a third link. Identify every screen page/ link w/ the Help link.
  • hard to determine which ones are which. - handled on the manual end.

Community & General

  • Andre (has a posse) has arrived in the Cosmo virtual cosmo space.
  • respond to his feedback as much as you can, has put his feedback
  • need a lot more community activity (be mindful of that)

Upgrade

  • what can we do better w/ upgrade as it had to be rolled back in upgrading osaf.us.
  • documented test cases, never test the /home
  • adam/aparna tested it.
  • ted also swore he tested it- it seemed we should have caught it in testing. Looks like we didn't test it
  • adam tested it w/ the trunk, change /home to /dav. change it in the actual trunk. chandler will not freak out. In the current release chandler, tested on alpha 4
  • great mystery? We did test
  • better matching of the production service. completely replicated on how we do production.
  • Is it the port? weird edge case w/ the port numbers. -mikeal
  • A whole slew bugs in chandler was doing some bizzare stuff. Request the full URL, get http://, hosted service was able to do something with, but clearly broken
  • more coming up, EIM, etc. unit testing, how do we get full unit testing?
  • up manual testing.
  • tried upgrading the cosmo instance, couldn't do w/ out replicating the entire production. -bear
  • coordinately the three different testing environment but not even as closely 'cause of alpha 4
  • once we have morse code, we'll be doing away w/ the proxies, and everyone will be changed to morse code
  • just not have a lot of change in the hosted service
  • what sort of data do we need?
  • not having test plans documented–result. some problems are not going to be able to find things until ppl start using them.
  • we may expect this all the time
  • more documentation for reversion. -jared
  • spec specifically for the upgrade -aparna
  • jared and aparna to work on a migration test plan. let's just get our test plan, automation, part expertise etc.
  • work on test plan
  • more of somebody (sheila) letting the user's know of the implication. Need to be clear w/ the users. If our scenario to tell the restore, sync now and hold off on syncing later.
  • When we need to communicate w/ the customers–nice to send out and warn ppl.
  • minimum, Esther, during that period she didn't realize.
  • even though we don't anticipate, we need to let ppl know. Send out an email.
  • check, general had the most ppl on the mailing list.
  • contacting to list (off line discussion)
  • ppl to check w/ alpha 4.
  • trunk interop is not a goal - so bugs on alpha 5 will not be fixed.

-- PriscillaChung - 22 Feb 2007

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r5 < r4 < r3 < r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.