Version 2
Created by jbalunas on Sep 8, 2010 11:31 AM. Last modified by jbalunas on Sep 8, 2010 12:54 PM.
    We had our Milestone2 post-mortem meeting today.  In these minutes I'll outline major topics and items.  I'll then open a forum thread to discuss open items.
    The Good
    *Build updates
    behaving as expected.
    One source control root for co, build, and release simplifies
    Still able to break into modules in the future.
    Build should not be a significant time drain any longer.
    Moving the docs out of primary build help speed up build, and allows Sean greater flexibility
    *Core/CDK both stabilized quite a bit
    Review of CDK/core should be done by senior team
    * Mock release
    Helped work out build kinks, and QE verify issues
    * Jira process and usage was much better
    Component jira process worked well
    * Scope creep was limited, and no large scale redesigns except for final build updates
    * Cloud support and showcase demo
    Great item for project, and community usage
    ** The Bad **
    * Archetypes were still not right, even after fixing.  They still used snapshot versions of 4.0.0 in the generated project
    Need to have integration/functional tests that verify the generated archetype
    * Only completed 4 components
    Need to review on to streamline component development so that we can release quicker
    Part of this was unavoidable items like holidays, vacations, etc…
    * Initial quality of components was lacking
    Developer testing is critical here, to catch the obvious issues
    Developer samples are not optional and should exercise all attributes
    More complete set of unit/integration tests needed for each component
    QE could only focus on the low handgun fruit - because stuck with basic issues
    It's not good that half of rich components has "Chrome not supported" issue risen right after moving to ui.. that has to be catched by dev
    * Components that are developed late in release may not get updated in QE's metamer test application
    Not too much to be done here, as this fits the milestone release structure
    Just need to be aware
    * Checkstyle/Testcase failures after checking
    Locally disabled checkstyle and testcases cause hudson builds to fail, and other issues.
    Development branch process should help with this
    But developers still responsible for their commits
    * Checkstyle issues revealed during build updates
    Copies of checkstyle suppressions needed, plugin location config issues
    Alex K is going to look into updating this
    * Hudson not trusted
    After build updates a full review of hudson builds not fully completed
    In order to dev branches, and trunk to be stable hudson must be trusted
    * Dev branch usage from Minsk are taking a VERY long time, and then JBoss svn has issues
    Hours spent fixing conflicts and merging to trunk
    If minsk team can't use dev branches efficiently need to find alternative
    * Validation in Eclipse workspace shows errors for valid files
    This is caused by several things: outdated CDK schemas, old config files, some generated files contain errors
    Nick to create jira's as needed to cover these items as critical for M3
    * No generated taglib documentation
    * Wiki/Jira not kept in sync so docs, engineering, qe, have a hard time tracking what should and should not work.
    For example component names changes, but not really clear where was "right", made it hard to document correctly.
    * Migration process wiki pages started, but not completed
    Updates need to be made and then process followed
    * Not enough time to update example ( showcase ) before tagging with latest components
    Do we want to think about having the examples be a separate module - like docs?
    * Still lacking team wide participation in online design/requirement discussions
    * Build Update took longer than expected, and caused 1 week shift in code freeze
    Better to take the week so that M2 was stable.
    ** Changes for M3 **
    * Development branch usage and work flow example
    developer to complete component, dev sampe, and basic dev testing prior to merge back to trunk.
    * JBoss svn is at older version, and have various issues
    Team will investigate more, and Jay will contact helpdesk
    May want to review using git?
    * Investigate having a core demo that unifies dev samples into a single app to testing
    Not styled or anything
    Debate on need, priority, and complexity, but could cut down on some duplication across examples.
    Jay will create a jira, but not high priority
    * Component jira process updates
    Perhaps dev and QA could have something like checklist of component features/attributes which should be implemented at the end of development phase
    This would be new steps in the process
    * Cross linking and updating wiki pages
    Jira's should be linked to related wiki pages
    Wiki pages should link to jira's covering requirements
    Wiki's need to be updated if functionality, plans change
    Perhaps additional tasks should be tracked for example after the component moved to ui and marked complete - to review and update wiki with info about postponed features
    * Reliable access to crucible/sonar servers for hudson
    Various pings have been made, but TODO list for .org is too long atm.
    * QE should not create jira's with "fix for" - leave them unscheduled
    * Add release branches into plan for release so we can option trunk to development quicker.
    * Developer sample and testing of components in not optional
    Basic functionality of component should be verified by developer ( all attributes, common use cases )
    QE is best used to test the integration, and complex use of components, environments, etc...
    * More automated integration/functional tests for the components needed
    * Release dates/process update
    Component code freeze one week before final code freeze for each release
    * The whole team should do a better job at keeping jira up to date
    * Fresh review of CDK/core in M3
    * Finalize component development/migration process/wiki
    ** Build Updates **
    * In general everyone happy with updates.
    ** Planning, prep, jiras **
    * Continuing the jira process from M2
    Not blinding shifting items to next release
    * Final release planning needed
    Mostly completed, wiki updates, and blog required

    We had our Milestone2 post-mortem meeting today.  In these minutes I'll outline major topics and items.  I'll then open a forum thread to discuss open items.

     

    Original thread: http://community.jboss.org/message/560275#560275

     

    The Good

    • Build updates
      • Behaving as expected.
      • One source control root for co, build, and release simplifies
      • Still able to break into modules in the future.
      • Build should not be a significant time drain any longer.
      • Moving the docs out of primary build help speed up build, and allows Sean greater flexibility
    • Core/CDK both stabilized quite a bit
      • Review of CDK/core should be done by senior team
    • Mock release
      • Helped work out build kinks, and QE verify issues
    • Jira process and usage was much better
      • Component jira process worked well
    • Scope creep was limited, and no large scale redesigns except for final build updates
    • Cloud support and showcase demo
      • Great item for project, and community usage

    The Bad

    • Archetypes were still not right, even after "fixing". 
        • RF-9266 - They still used snapshot versions of 4.0.0 in the generated project
        • RF-8949 - Need to have integration/functional tests that verify the generated archetype
      • Only completed 4 components
      • RFPL-801 - Initial quality of components was lacking
        • Developer testing is critical here, to catch the obvious issues
        • Developer samples are not optional and should exercise all attributes
        • More complete set of unit/integration tests needed for each component
        • QE could only focus on the low hanging fruit - because stuck with basic issues
        • It's not good that half of rich components has "Chrome not supported" issue risen right after moving to ui.. that has to be catched by dev
      • Dev branch usage from Minsk are taking a VERY long time, and then JBoss svn has issues
      • Components that are developed late in release may not get updated in QE's metamer test application, or showcase demo
        • Not too much to be done here, as this fits the milestone release structure
        • Do we want to think about having the examples be a separate module - like docs?
        • Just need to be aware, and update early in next cycle.
      • RFPL-801 - Checkstyle/Testcase failures after checking in code
        • Locally disabled checkstyle and testcases cause hudson builds to fail, and other issues.
        • Development branch process should help with this
        • But developers still responsible for their commits
        • FULL TEST SUITE SHOULD BE RUN BEFORE CHECKIN OR MERGE
      • RFPL-595, RFPL-677 Checkstyle issues revealed during build updates
        • Copies of checkstyle suppressions needed, plugin location config issues
        • Alex K is going to look into updating this
      • RFPL-802 - Hudson not trusted
        • After build updates a full review of hudson builds not fully completed
        • In order to dev branches, and trunk to be stable hudson must be trusted
      • RFPL-803 - Validation in Eclipse workspace shows errors for valid files
        • This is caused by several things: outdated CDK schemas, old config files, some generated files contain errors
        • Nick to create jira's as needed to cover these items as critical for M3
      • RF-7840, RF-8227 - No generated taglib documentation
      • RFPL-804 - Wiki/Jira not kept in sync so docs, engineering, qe, have a hard time tracking what should and should not work.
        • For example component names changes, but not really clear where was "right", made it hard to document correctly.
      • RFPL-437 - Migration process wiki pages started, but not completed
        • Updates need to be made and then process followed
      • Still lacking team wide participation in online design/requirement discussions
      • Build Update took longer than expected, and caused 1 week shift in code freeze
        • Better to take the week so that M2 was stable.

      Changes for M3

      • RFPL-805 - Development branch usage and work flow example
        • Developer to complete component, dev sample, and basic dev testing prior to merge back to trunk.
      • JBoss svn is at older version, and have various issues
      • RFPL-807 - Investigate having a core demo that unifies dev samples into a single app to testing
        • Not styled or anything, just for centralizing developer samples.
        • Debate on need, priority, and complexity, but could cut down on some duplication across examples.
        • Jay will create a jira, but not high priority
      • RFPL-804 -Component jira process updates
        • Perhaps dev and QA could have something like checklist of component features/attributes which should be implemented at the end of development phase
        • This would be new steps in the process
      • RFPL-804 -Cross linking and updating wiki pages
        • Jira's should be linked to related wiki pages
        • Wiki pages should link to jira's covering requirements
        • Wiki's need to be updated if functionality, plans change
        • Perhaps additional tasks should be tracked for example after the component moved to ui and marked complete - to review and update wiki with info about postponed features
      • ORG-439 - Reliable access to crucible/sonar servers for hudson
        • Various pings have been made, but TODO list for .org is too long atm.
      • QE should not create jira's with "fix for" - leave them unscheduled
      • RFPL-445 - Add release branches into plan for release so we can option trunk to development quicker.
      • RFPL-801 - Developer sample and testing of components in not optional
        • Basic functionality of component should be verified by developer ( all attributes, common use cases )
        • QE is best used to test the integration, and complex use of components, environments, etc...
      • More automated integration/functional tests for the components needed
      • RFPL-808 - Release dates/process update
        • Component code freeze one week before final code freeze for each release
      • The whole team should do a better job at keeping jira up to date
      • RFPL-809 - Fresh review of CDK/core in M3
      • RFPL-437 - Finalize component development/migration process/wiki

      Build Updates

      • In general everyone happy with updates.

      Planning, prep, jiras

      • Continuing the jira process from M2
        • Not blinding shifting items to next release
      • Final release planning needed
        • Mostly completed, wiki updates, and blog required