Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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
  • Incremental testing?
  • 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.
  • Anthony wants to scrape the logs and compare 2.7.x and 2.6.x, and 2.7.x would include only the master project that would point via externals to other projects.
  • Should branch trunk as 2.7.x branch now
  • But what that means is that fixes need to be merged across other branches
  • 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 a point of comparison. A snapshot of trunk so that we see what's there.
  • What about doing it the other way? Ask people to branch if they're not going to be ready.
  • Levels of oversight on 2.7 branch ... branch manager will be putting stuff in there?
  • 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
  • Address committer holes
  • How good are we at having JIRAs associated with commits? Not bad right now
  • 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? Put trust in branch managers.
  • Need a charter so that we don't need a lot of discussion about what should go in there.
  • Want to keep revision releases a community affair, dialogue about issues
  • Maintenance releases make the lives of production people easier.
  • Entity Broker, Polls, and ResetPassword.

Next Steps

  • No labels