[169] in Release_7.7_team
More release ?!?
daemon@ATHENA.MIT.EDU (Dorothy Bowe)
Thu Sep 29 15:34:52 1994
To: release-77@MIT.EDU
In-Reply-To:
Date: Thu, 29 Sep 1994 15:34:33 EDT
From: Dorothy Bowe <dot@MIT.EDU>
Hi everyone!
As I promised, September was a release-free month for most of us.
However, it's almost October, and time to start thinking about release
issues again. To bring you up to date, I'm including the draft schedule
I sent to the ppt for approval. While the details of any minor or patch
release process are still being worked out (*do not* necessarily believe
any details I included in my message) , I haven't heard any objections
to the overall schedule for a next major release.
Working on this premise, I'm thinking about having a release team
kickoff meeting during the first two weeks of October. The purpose of
this meeting will be to start thinking about and generating a list of
items for a next big release. (X11R5/6 ? etc. and no, I don't have the
agenda ready yet...) This meeting is not mandatory, but if you do not
attend, please follow through on reading any meeting notes, or ask me
about the meeting as we need input from all areas for this part of the
release process.
Now the fun part. Can you all please get back to me and let me know 1)
if you plan to or want to attend, and 2) what times are okay for you. I
would prefer something from
Tuesday mornings
Wednesday afternoons
Thursday any time
Friday any time
This is not a weekly meeting time; just a one-time deal between Oct. 3
and Oct. 14.
Thanks,
./dot
Note: replace 'weekly' with 'monthly'. If you're interested in the
follow-up discussion to this message, check out the ppt meeting on
menelaus.
> To: ppt
>
> Well, it's almost October, and therefore time (for some of us, anyway)
> to start thinking about releases again. If I recall correctly, at the
> Aug 17 PPT meeting, we agreed that I would propose a schedule and here
> it is. This schedule is far from final or detailed, but since I
> want/need to start something in October, I thought I'd see if there are
> any major objections.
>
> As it turns out, there are actually two schedules, one for the next
> "major" release, and one for what might be called "minor" releases.
> Craig Fields is still working out the plans for release engineering
> which affect everything with regards to a "minor" or "bug fix" release.
> Again, the details of how this will work are still vague, but since it
> affects any "major" release, I've included the general outline here.
>
> The basic idea concerns three kinds of "releases":
>
> 1. More frequent (weekly or bi-weekly) test pack releases containing
> a) bugs fixes
> b) Other changes as approved by release team or necessitated for
> some **good** reason or other. Yes, this is vague.
>
> 2. Periodic staff/field releases from test packs. In other words,
> when there are fixes or features that need to get to the field, we
> have a channel for them.
>
> 3. Regular (yearly or bi-yearly) 'major' releases. The same old thing
> we've done for years now.
>
> Tentative Schedule
> ==================
>
> (Star'd items indicate part of "major" release cycle)
> October
> Begin "weekly" builds of the source tree
> * Establish some procedure for dealing with suggestions and/or input for
> the release.
> * Call for suggestions for next major release
>
> November
> * Come up with initial list for including in next release. (This
> should be a somewhat rolling process, but here is where we
> identify a list of items which need development resources and/or
> lots of testing and documentation.)
> * Request development resources
> Review weekly build procedure, adjust as necessary
> Determine if we need a January 'bug-fix' release
>
> December
> Possible testing for January release
>
> January
> Possible release
>
> February
> * Review status of major release development
> * Modify release inclusion list as necessary (possibly adding new
> features here, or deleting things which won't be ready)
>
> March
>
> April
> * Major release to staff some time around mid-April
> * Begin work on all other pieces of the release
> Release notes
> Installation procedure(s)
> Stock answers
> etc.
>
> May
> * Staff test continues
> * Possible update(s) to staff test from test packs
>
> June
> * First field release
>
> July
>
> August
> * Last field release with bug fixes
>
> Details:
> =======
>
> * Weekly builds of the source tree incorporating any bug fixes and
> release-approved changes that are ready. These packs go to anyone
> who volunteers to be on the cutting edge.
>
> * Periodically, when there are enough changes or reasons to propagate
> fixes to the field, we go through a staff and field release cycle.
> These releases should not include any major user-visible changes
> which have been incorporated into the test packs. (In other words,
> even if clients built with Motif 1.2 are in test, they would not got
> out in a 'minor' release like this. The details of how this would
> occur still need to be worked out; we might have to do something
> different.)
>
> While there may be occasional need to update a stock answer or
> change documentation, for the most part these releases should be
> invisible to support folks and the user community.
>
> * (The 'usual' release) Whenever we reach an established deadline for
> incorporation into a major release, whatever new fixes and new
> features are ready got through a staff-field release cycle. If
> something has been approved for the release but is not ready in
> time, it can get incorporated into the source tree and released with
> the next major release.
>
> ./dot
>
