2009-08-13

Owned by Former user (Deleted)
Last updated: Aug 13, 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 high impact items, esp. open questions about them. (see Proposed Sakai 2.7 Changes)
  2. Discuss Documentation template (see New Feature Documentation)
  3. Set freeze date(s)

Proposed Sakai 2.7 Changes

New Feature Documentation

Attendees

  • Seth Theriault
  • Steve Smail
  • Megan May
  • Pete Peterson
  • Charles Hedrick
  • Clay Fenlason
  • David Haines

Discussion Outline

  • New Feature Documentation looks pretty good overall (Megan, David and Clay contributed), but coding practices not clear, and so it's hard to make this something that we could insist on
    • Still, it's important long-term, and we might make a simple start. David H will continue to try to develop this
  • Clay will try to rearrange our list of features around these questions, both documenting what we know and revealing to developers what they need to fill in for us.
  • Freeze dates: what lessons have we learned about this?
    • They can work if you're strict about sticking to them
    • They can be counterproductive as a global divide, where they're just a pressure point for people to dump things in before they're ready
    • Separate freeze dates (e.g. feature freeze, code freeze, doc freeze) helpful to a developer who's trying to organize and prepare
    • Don't really want a documentation freeze later in the game this time - want documentation to be produced before or during, and not an afterthought
  • What if we brought in projects as they were ready rather than the same hard freeze for everyone?
    • Would bring new emphasis to developing a release plan ahead of time. Some projects are ready to go now, others needn't be rushed.
  • A general maintenance team would be a big help (aside: Anthony is going to try to pull this together when he gets back)
  • Debate about how risky it was to try and do two releases: no clear consensus, but there was at least the point made that API changes could require a lot of regression testing that would leave the current 2.7 release plan unrealistic.
    • alternative proposal: a 2.6.x maintenance release, and a 2.7 that would come out in March.
  • Our charge is to come up with a good plan, and the current proposal is open to revision, so long as the general goals are still kept in view.