| Date Of Receipt: 12-JUN-1996 18:44:02.18
From: FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE 12-Jun-1996 1843"
To: katz@DEC:.zko.flume
CC: odehelp@DEC:.zko.flume, reynolds@DEC:.zko.flume, metsch@DEC:.zko.flume,
overman@DEC:.zko.flume, tresvik@DEC:.zko.flume
Subj: re: What do I need to do, to get automount to build in v32fsupportos ?
(Tom/Sharon/James - this brings into question the hardware build/patch model)
Charlie, this is a case in which the file you patched was never part
of the original hardware release v3.2F, and automount did not build
as part of v3.2F, and therefore does not build as part of v32fsupport
(it uses a partial or "hardware" build model).
This is an area that both USEG release engineering & development engineering
needs more educating I would guess.
While the source file did go in the pool, if you had done a
findpool -f usr/sbin/automount/auto_look.c
before your submit (which you can also do via the web from the rengweb
home page), you would have found that in order to get the file into
v3.2F, it would should have to be submitted into v32csupportos.
However, since v32fsupportos builds using the partial build list in
src/admin/, as follows:
isl all
usr/sbin/sizer sizer
usr/ccs/bin/ukprofile all
this file is never delivered as part of the v32fsupport kit; its patch
should therefore come from the predecessor build, v32de2supportos.
Unfortunately the answer is as complicated as the question.
The right thing to do, unfortunately, is to back port your fix from
the v32fsupportos pool into the v32csupportos pool, and then have
release engineering "revert" the file and relink it via link_os in
the v32fsupportos pool, and then wait for it to propagate through
v32csupportos -> v32de1supportos -> v32de2supportos, and then take the
patch from that build for the v32f customer.
WAIT WAIT WAIT - I just looked and found you did do your submit to
v32csupportos, so no reverts or resubmits are needed; the patch
just needs to come out of the v32de2supportos build. If it's though
necessary that it should come out of the v32fsupportos build, then
automount needs to be added to the v32fsupportos.bldlist file, and
the whole question of what build model we should be using for support
needs to be raised again.
-josh
p.s. there was one little error in your mail; you said
> while link/src/usr/sbin/automount/auto_look.c had my fix,
this should have not included the 'link/'
------- Forwarded Message
To: [email protected]
Subject: What do I need to do, to get automount to build in v32fsupportos ?
Date: Tue, 11 Jun 96 15:57:03 -0400
From: [email protected]
X-Mts: smtp
I have been asked to make sure my patch to automount gets built
into v32fsupportos AND then do a mkpatch to move the patch to guru.
I got into a sandbox backed by v32fsupportos.nightly and found that
while link/src/usr/sbin/automount/auto_look.c had my fix,
there was no path for the object to be built ???
I wondered if maybe I was in during a build or some such
strangeness.???
Can you do this ?
Check to see if the auto_look.c rev 4.2.20.2
has been built into usr/sbin/automount ???
If so, then I can do a mkpatch, however there's another thing I'm
curious about. Where I never did an srequest for 32f, but somehow
mysteriously the file got there anyway, (if you know how it got
there, please hollar), how can mkpatch know where to get a README
file, and even an srequest to look it up...???
so you see, this is really not an easy question.
Charlie Katz 1-2465
------- End of Forwarded Message
|
| Date Of Receipt: 13-JUN-1996 09:21:07.81
From: WASTED::"[email protected]" "Tom Tresvik"
To: <katz@DEC:.zko.wasted>,
"Joshua M. Friedman, Digital UNIX, 381-1548" <jmf@DEC:.zko.wasted>
CC: <odehelp@DEC:.zko.wasted>, <reynolds@DEC:.zko.wasted>,
<metsch@DEC:.zko.wasted>, <overman@DEC:.zko.wasted>,
<tresvik@DEC:.zko.wasted>
Subj: Re: What do I need to do, to get automount to build in v32fsupportos ?
Josh, [all,]
This is exactly the discussion we had (james, you, me) recently to decide
if we were comfortable with this scenario. We agreed that there would not
be any regressions since the previous pool's output tree is the basis for
the 3.2F build which layers on top. We agreed that we could account for
how patches would deliver through the 3.2D-2 and 3.2F build output trees -
albeit sort of back door. [Remember, my preference would be to do a full
build. I'm still barely tolerating the benefits of this
less-than-scientific partial build.]
Sharon is aware of this scenario as we have discussed it previously in
3.2D-2 and I've since noted that 3.2F will behave the same way. Yes, it
is confusing, but I think we need to yield to Sharon to decide what needs
to be communicated. We can even help with a draft if asked. Sharon also
reserves the right to ask for a full build if that helps her business
model.
Tom
----------
> From: Joshua M. Friedman, Digital UNIX, 381-1548 <jmf>
> To: katz
> Cc: odehelp; reynolds; metsch; overman; tresvik
> Subject: re: What do I need to do, to get automount to build in
v32fsupportos ?
> Date: Wednesday, June 12, 1996 6:43 PM
>
> (Tom/Sharon/James - this brings into question the hardware build/patch
model)
>
> Charlie, this is a case in which the file you patched was never part
> of the original hardware release v3.2F, and automount did not build
> as part of v3.2F, and therefore does not build as part of v32fsupport
> (it uses a partial or "hardware" build model).
>
> This is an area that both USEG release engineering & development
engineering
> needs more educating I would guess.
>
> While the source file did go in the pool, if you had done a
> findpool -f usr/sbin/automount/auto_look.c
> before your submit (which you can also do via the web from the rengweb
> home page), you would have found that in order to get the file into
> v3.2F, it would should have to be submitted into v32csupportos.
>
> However, since v32fsupportos builds using the partial build list in
> src/admin/, as follows:
> isl all
> usr/sbin/sizer sizer
> usr/ccs/bin/ukprofile all
> this file is never delivered as part of the v32fsupport kit; its patch
> should therefore come from the predecessor build, v32de2supportos.
>
> Unfortunately the answer is as complicated as the question.
>
> The right thing to do, unfortunately, is to back port your fix from
> the v32fsupportos pool into the v32csupportos pool, and then have
> release engineering "revert" the file and relink it via link_os in
> the v32fsupportos pool, and then wait for it to propagate through
> v32csupportos -> v32de1supportos -> v32de2supportos, and then take the
> patch from that build for the v32f customer.
>
> WAIT WAIT WAIT - I just looked and found you did do your submit to
> v32csupportos, so no reverts or resubmits are needed; the patch
> just needs to come out of the v32de2supportos build. If it's though
> necessary that it should come out of the v32fsupportos build, then
> automount needs to be added to the v32fsupportos.bldlist file, and
> the whole question of what build model we should be using for support
> needs to be raised again.
>
> -josh
>
>
> p.s. there was one little error in your mail; you said
> > while link/src/usr/sbin/automount/auto_look.c had my fix,
> this should have not included the 'link/'
>
> ------- Forwarded Message
>
> To: [email protected]
> Subject: What do I need to do, to get automount to build in
v32fsupportos ?
> Date: Tue, 11 Jun 96 15:57:03 -0400
> From: [email protected]
> X-Mts: smtp
>
> I have been asked to make sure my patch to automount gets built
> into v32fsupportos AND then do a mkpatch to move the patch to guru.
> I got into a sandbox backed by v32fsupportos.nightly and found that
> while link/src/usr/sbin/automount/auto_look.c had my fix,
> there was no path for the object to be built ???
> I wondered if maybe I was in during a build or some such
> strangeness.???
> Can you do this ?
> Check to see if the auto_look.c rev 4.2.20.2
> has been built into usr/sbin/automount ???
> If so, then I can do a mkpatch, however there's another thing I'm
> curious about. Where I never did an srequest for 32f, but somehow
> mysteriously the file got there anyway, (if you know how it got
> there, please hollar), how can mkpatch know where to get a README
> file, and even an srequest to look it up...???
>
> so you see, this is really not an easy question.
>
> Charlie Katz 1-2465
>
> ------- End of Forwarded Message
>
>
|