2009-08-20

Owned by Former user (Deleted)
Last updated: Aug 22, 2009Version comment
3 min read

Connection Info

Telephone: +1 812 856 7060
Internet: 156.56.240.9

Sakai001

  • Conference Code: 348#
  • PIN: 72524#

Agenda

  1. Implications of a new release proposal
    • Tool inclusion criteria
  2. Maintenance team?
  3. Maintenance releases for 2.5 and 2.6

Release Proposal 2009

Google Spreadsheet of new features

New Feature Documentation

Attendees

  • Charles Hedrick
  • Seth Theriault
  • David Horwitz
  • Pete Peterson
  • Megan May
  • David Haines

Minutes

  • General QA needs to start early; this stuff about "by end of 2009" is worrisome
  • QA servers: how to move them from tag to tag. Need them running 2.6.x right away.
  • Seth's QA server proposal.
  • Rutgers is willing to commit 1 FTE for QA. (applause)
  • A lot of the blockers in 2.6 were also in 2.5, we should look at blockers now.
  • We should scrape the svn logs and compare 2.7.x and 2.6.x, to find out what's really there.  JIRA issues alone can't tell us everything we may need to know, and we can't really get anywhere without having a clear understanding of what's in our codebase.  We should branch trunk now.
  • But that means fixes need to be merged across other branches, and it could be a confusing chore. Also, we don't yet have a branch manager for 2.7, and should have more than one anyway.
  • Even without a branch manager, it would give us an important point of comparison, which we can't do well just from trunk itself, which continues to be a moving target.
  • What about doing it the other way? Ask people to branch if they're still doing work and think they might not be ready.
  • That relies on development teams making judgment calls about things they can't know the answer to yet.
  • Levels of oversight on 2.7 branch ... will it be the branch manager putting everything in there?
  • That's not the main point atm - just really need to get a handle on what's in there now. Can't QA something if you don't know what's in it.
  • Anthony will branch trunk, serve as interim branch manager while we build up a team, cut a milestone candidate to bind to a 1.1 kernel over next week. Develop a rhythm of cutting 2.7 tags and having people to look at it.
  • Should also get a known revision point of 2.6.x
  • Our committer lists are not up to date, and that also needs some cleanup.
  • How good are we at having JIRAs associated with commits? Analysis suggests it's not bad.
  • Should put 2.6.1 out somewhere mid-September, and a 2.6.2 somewhere mid-November, cut straight from 2.6.x
    • assumption is that they've been tested before getting into the branch
  • Need to link this to having QA refresh 2.6.x on the servers.
  • How can we be confident of what's going into 2.6.x? It depends on trust in branch managers.
  • Need a clear charter so that we don't have a lot of discussion about what should go in there.
  • Want to keep revision releases a community affair, dialogue about issues.
  • Maintenance releases should be viewed as a kind of service designed to make the lives of production people easier.  When we cut one will depend mostly on when people in production could really benefit from one.
  • Entity Broker, Polls, and ResetPassword are already in shape for independent releases.

Next Steps

  • Anthony will cut a branch from trunk and compare it with 2.6.x starting early next week.
  • Pete, Anthony and Seth will develop a QA server plan that incorporates Seth's proposal from July, and will work to get a revision of 2.6.x on test servers straight away.
  • Clay will work to recruit resource to pull together a Forums tool release that will be tested against either 2.6.x or the new branch Anthony is going to cut, depending on how that analysis goes.