2009-09-03

Owned by Former user (Deleted)
Last updated: Sept 03, 2009Version comment
2 min read

Connection Info

Telephone: +1 812 856 7060
Internet: 156.56.240.9

Sakai001

  • Conference Code: 348#
  • PIN: 72524#

Agenda

  1. Review of branch comparisons (2.6.x against 2.6.0 and 2.7.x against 2.6.0)

Release Proposal 2009

Google Spreadsheet of new features

New Feature Documentation

Attendees

  • Seth Theriault
  • Pete Peterson
  • Clay Fenlason
  • David Horwitz
  • David Haines
  • Chuck Hedrick
  • Adam Hocek
  • Steve Smail
  • Anthony Whyte

Minutes

  • Anthony talking to us about branch comparisons
  • laptop disaster leaves numbers a little ad hoc (from memory)
  • what's in 2.6.x as of Aug 30 vs. 2.6.0
    • some 232 merges in 2.6.x not in 2.6.0
    • of those over 100 involved translation updates
    • others for help documentation, some 20+ commits or so
    • another half-dozen or so i18n commits
    • leaving 75 or so fixes to code
      • osp has the largest portion
      • osp will now merge their own fixes into 2.6.x (ie broadening branch management)
      • a dozen or so chat fixes
      • 8 or so assignment fixes
        • another dozen or so fixes in trunk not yet merged in, but probably should be
      • site-manage has another dozen or so recent merges
      • Beth added about 25 i18n updates just in the last few days
    • analysis hasn't provided a qualitative picture, but a sense of the volume of changes, and what 2.6.1 would be about if we cut it today.
    • about 40 issues ready to be merged to 2.6.x, verified and closed.
    • another healthy chunk of resolved issues that need testing and verification.
    • Anthony would like to see a 2.6.1 by the second half of September, and a 2.6.2 before the Thanksgiving break.
  • DH: assignments SAK-16921 blocker he wants to flag
  • site-manage also has some issues
  • should be more proactive with these project teams on their issues
  • haven't had people running osp involved in branch management, which has made it harder to see appropriate and timely merges
  • Anthony has script for branch comparisons
  • Seth and UCT both will have 2.6.x branches running on QA server.
  • important to distinguish known revision from the one running on nightly
  • still need some documentation on what's changed
  • Anthony feels fairly comfortable with his grasp of what's in 2.6.x. Still needs some JIRA cleanup, but can use svn logs to help do that.
  • Looking at trunk vs. 2.6.x
    • Over 800 issues closed, overlap with 2.6.x (since merged across)
    • issues specific to 2.7, about 350-ish
    • looks better to move ahead with 2.7 based on trunk rather than 2.6.x
    • merges get a little more complicated
  • If we don't have a branch manager for 2.7, might want to hold off on branching
  • pick known revisions, wait until we get to a point that 2.7 is ready for its own branch
  • call it trunk QA
  • the one thing you don't get out of that approach is that you're not constraining work
  • better for us for general QA if we have a better idea of the things that are going through on a regular basis. Can't do gatekeeping without branch manager.
  • a lot of changes in 2.6.x also in 2.7
  • 2.6.x a priority over 2.7?
  • would be wise to focus QA efforts on 2.6.x
  • Disadvantages with work we've done so far is that things get pushed off to last minute
  • Does it make sense to have a single date? Can depend on project?

Next Steps