[175] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Meeting minutes 10/14/94

daemon@ATHENA.MIT.EDU (Dorothy Bowe)
Mon Oct 17 10:36:34 1994

To: release-team@MIT.EDU
Date: Mon, 17 Oct 1994 10:36:11 EDT
From: Dorothy Bowe <dot@MIT.EDU>


[Thanks to JJ for the notes.  Any inaccuracies are mine.  -- dot]

In attendance:	Kevin, Anne S., Craig, Matt, Mark, Carla, Dot, Gary,
		Mike

Handouts:	(4 sides) Suggestion list thus far, description of items
		from software-suggestions

Pre-agenda item

0.1 What should we call ourselves?

    We reached the decision to create a mailing list called
    release-team@mit for all release-related email activity.  For the
    present time, this mailing list includes the current release discuss
    meeting, menelaus:/usr/spool/discuss/release-77, but at some point
    in the future we'll switch over to a new discuss meeting explicitly
    for the next major release, presumably release 7.8.  

	Email:   release-team@mit.edu	(release team members only)
	Discuss: menelaus:/usr/spool/discuss/release-77	(public)

Agenda

1.1 Tentative Schedule for the Release

    First Field Release		early June 1995
    Staff Test			~ May
    Friendly/Beta Test		~ April
    Code Cut			it depends

    This schedule led into a discussion of how proposed changes in
    development and release engineering would affect what we think of as
    the release cycle.  Many of the details of these changes are still
    being worked out and are beyond the scope of the release team
    itself, but the general points which are pertinent to the team are:

	* Source tree builds occurring on a regular basis.  This should
	  eliminate some amount of time in past release schedules
	  between code cut and first round of testing.

	* Regular releases of new system packs for front line testers.
	  This should allow integration of new features and/or fixes on
	  a regular basis instead of a crunch at "code cut".  It would
	  also get some features out for earlier testing and encourage a
	  year-round development cycle.

    Thus, the code cut date we talk about is strictly for inclusion in a
    particular release;  code which misses that date can still, in
    theory, be incorporated for inclusion in the next or a later
    release.  ** All of this is still subject to change as the details
    of these processes are worked out.  **

    Code cut for "Release 7.8" translates roughly to

	Operating System upgrades	February
	"Major" pieces/changes		mid March
	Other				mid April

[A discussion ensued about the release team, controlling/accessing
 resources and how it relates to what we put into the release.  For more
 details, see me.]

1.2 Possibility of a release in January

    We have a window of opportunity to have some kind of release in
    January on one or more platforms.  Whether or not we take advantage
    of this window depends on whether there are sufficient items for
    such a release.  

    We throw the terms "patch", "release", and "minor release" around
    without precise meanings, making it difficult to differentiate
    between the window of opportunity in January and the recent patch
    for Solaris.  One difference is that a complete (major) release
    involves a rebuild of the source tree, while a patch such as the one
    we put out recently involves only specific programs and files.  

    >> Proposed items for January "release" will come from call for
       release suggestions.

1.3 What do we have to do?
   
    First task for the release team is to come up with a proposed list
    of items for the next release(s).  This should be completed by
    mid-November for approval by the release teams sponsor.  Other tasks
    are tentatively:

	Dec/Jan 	possible release of some sort
	by February	"What Should Run" list update
		 	Detailed list for next release
	(ongoing)	consider additional input
	March-June	usual release activity
	June/July	updates to release

2.X Input for next release(s)
   
    The seed list for suggestion items was included in the handouts and
    consisted of:

	* Items which did not make it into Release 7.7
	* Items from software-suggestions
	* Items from dcns-dev (thanks mike!)

    Dot will send out a request for input for this list.  Suggestions
    may be sent to release-team@mit.edu and should include a description
    of the item as well as some indication of why it should be included
    in a release.

3.X Next steps

    * Get input for suggestion list
    * Next meeting:

	Thursday, Oct 27 10:30 AM in E40-357

    * Anne S. suggested an additional item for the next meeting:  Taking
      things *out* of the release.

Action Items:

   Carla:	create mailing list	(done)
   Dot:		send out request for input


home help back first fref pref prev next nref lref last post