[4634] in Release_7.7_team
Re: Meeting tomorrow, 1pm
daemon@ATHENA.MIT.EDU (Bill Cattey)
Tue Jun 29 16:06:09 2004
From: Bill Cattey <wdc@MIT.EDU>
To: Jonathon Weiss <jweiss@mit.edu>
Cc: Greg Hudson <ghudson@mit.edu>, release-team@mit.edu
In-Reply-To: <200406291843.i5TIhsu6003685@distraction.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1088539564.9642.79.camel@tokata.mit.edu>
Mime-Version: 1.0
Date: Tue, 29 Jun 2004 16:06:04 -0400
I'll remind y'all that last August, Mitch Berger kicked off a
conversation in source-developers (starting at transaction 604) on this
topic.
I've always been in favor of an architecture like what Mitch suggested
of a quick required phase, and a slow background phase for verification.
I too believe we should NOT omit verification, that we should add
instrumentation, that we should enable the ability to abort the
time-consuming verify, but I'm also speaking in favor of trying out
the two phased verify.
-wdc
On Tue, 2004-06-29 at 14:43, Jonathon Weiss wrote:
> > We will meet tomorrow to discuss our status report and what to do with
> > Linux public workstation verification, as well as any other topics
> > people have.
> >
> > The Linux public workstation verification is: as the amount of
> > material in the Linux-Athena release has gone up, the public
> > workstation verification has started to take a long time. Lou claims
> > the long delay is an impediment to service. Unfortunately, we have no
> > data on how often public workstation verification actually cleans
> > anything up. Our options are:
> >
> > 1. Omit public workstation verification
> > 2. Run verification in the background
> > 3. Add a thing where you can press a key to manually suppress
> > verification before it starts. (Lou said this would be an
> > acceptable compromise, but not his preference.) Or a thing where
> > you can manually terminate verification after it starts, which
> > might be more acceptable.
> > 4. Start collecting data (via syslog, probably) on how often
> > verification does anything, and in the meantime do (a) nothing,
> > (b) option #2 above, or (c) option #3 above.
> >
> > Andrew won't be around, but is willing to implement any of these
> > things.
>
> I'll also miss the meeting (USENIX, in my case). I'm opposed to
> number one. I think I prefer 3 to 2, but it's a weak preference. 3b
> is definately better than 3a. I actually like #4, mostly becasue it
> will make it easire for us to detect issues where the verification
> always re-installs certain rpms, but this is probably the wrong
> reason.
>
> Jonathon
>
