| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 170.1 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 16:00 | 16 |
| Date Of Receipt: 24-JUN-1993 14:06:24.16
From: MINSRV::"[email protected]"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
CC: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subj: Re: X pool inconsistencies, re: check_out_config question
I couldn't have said it any better. It was particularly frustrating
since this affected one developer in that she was convinced she was
doing something wrong and wasted an entire day.
I hope this issue gets resolved.
-Rich
|
| 170.2 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 16:00 | 113 |
| Date Of Receipt: 24-JUN-1993 14:13:47.10
From: QUARRY::pderr "Peter Derr AUEG 24-Jun-1993 1413"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@DEC:.zko.quarry>
CC: [email protected], ws@DEC:.zko.quarry, odehelp@DEC:.zko.quarry,
grass@DEC:.zko.quarry, tresvik@DEC:.zko.quarry, afd@DEC:.zko.quarry,
tappan@DEC:.zko.quarry, meyer@DEC:.zko.quarry
Subj: Re: X pool inconsistencies, re: check_out_config question
NO! Please don't break this! When I check something out, I want the latest
version that has been checked in, whether or not it has yet made it into the
nightly backing tree. Otherwise, it is quite possible to miss previous changes
and lose previous work, especially since it seems to happen relatively often
that the nightly tree fails to get updated daily (nightly). Changing this
would the cause needless confusing merges when submitting. If you check out
the latest from the submit tree and find that is not the same as the nightly
tree, it is extremely simple and obvious to see what has been changed by
reading the modification history.
This check out config has worked very well this way for a very long time,
and just because a single new user of the X pool found this confusing is
not a valid reason for changing this.
Peter
----------------------------------------------------------------------------
To: [email protected]
cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: X pool inconsistencies, re: check_out_config question
Rich, you are right to have been telling people that when they do a
check out they should get the same thing as in the tree, such that
a build before the bco and a build after are identical, and I feel
strongly that this should be the case, *always*...
EXCEPT
the x11 development community has "required" us to have it this way;
they "want" it such that a check out always gets the latest code, even
if its inconsistent with its backing tree. (at least for the .nightly's)
(In my opinion this is broken.)
I think, however, its time to revisit this, since the x11 development is
no longer just 5 people who are in tight coordination, but it's part of
a larger product development environment which has more global processes
which are in place to allow everyone to work from the same assumptions.
In her mail, Madeline commented that:
> If there are engineers on your side are working in the X pool, they should
> feel free to discuss these decisions with them.
My feeling is that the community using the x11 pool should have all the
same expectations etc., and this community has grown. People submitting
into the pool also include the security group, the hardware group, the ootb
group in New Jersey, and perhaps miscellaneous parts of the base development
group like presto support for example.
Maintenance is coming to a close, so we shouldn't interfere with its
process, but I recommend we make this change to sterling, gold and aghw.
Thanks for bringing this up...
-josh
------- Forwarded Message
Return-Path: [email protected]
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
Received: by lars.unx.dec.com (5.65/MS-070792);
id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: check_out_config question
Date: Wed, 23 Jun 93 16:59:29 -0400
From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
<[email protected]>
X-Mts: smtp
When a sandbox is backed against agxminor.nightly the variable
check_out_config is set to:
AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
So if I check out a file from agxminor.nightly I will get the latest version
in the submit pool instead of the version in agxminor.nightly. Is that right??
I then backed my sandbox against agosminor.nightly, check_out_config is:
AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
I have been telling the developers here that when you check out a file
you get the version that is in the tree you are backed to.
There seems to be an inconsistency here. This has frustrated the hell out
of some of the developers here who are expecting to get the version in
the agxminor.nightly tree when they bco.
Please help.
Rich
- ----------------------------------------------------------------
Rich Larsen, M/S: UNX TCP/IP: [email protected]
USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
Digital Equipment Corporation FAX: 908-577-6003
200 Route 9 North Voice: 908-577-6083
Manalapan, New Jersey 07726 DTN: 462
------- End of Forwarded Message
|
| 170.3 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 16:01 | 124 |
| Date Of Receipt: 24-JUN-1993 14:17:21.73
From: QUARRY::snider "Peter Snider AUEG 24-Jun-1993 1417"
To: "Peter Derr" <pderr@DEC:.zko.quarry>
CC: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@DEC:.zko.quarry>,
[email protected], ws@DEC:.zko.quarry, odehelp@DEC:.zko.quarry,
grass@DEC:.zko.quarry, tresvik@DEC:.zko.quarry, afd@DEC:.zko.quarry,
tappan@DEC:.zko.quarry, meyer@DEC:.zko.quarry
Subj: Re: X pool inconsistencies, re: check_out_config question
I strongly agree with peter derr. There was a couple of times I started
to work on a problem and found the fix had NOT made it into the nightly
tree due to build problems.
-pete
In email from "Peter Derr" <pderr>:
>
>NO! Please don't break this! When I check something out, I want the latest
>version that has been checked in, whether or not it has yet made it into the
>nightly backing tree. Otherwise, it is quite possible to miss previous change
>s
>and lose previous work, especially since it seems to happen relatively often
>that the nightly tree fails to get updated daily (nightly). Changing this
>would the cause needless confusing merges when submitting. If you check out
>the latest from the submit tree and find that is not the same as the nightly
>tree, it is extremely simple and obvious to see what has been changed by
>reading the modification history.
>
>This check out config has worked very well this way for a very long time,
>and just because a single new user of the X pool found this confusing is
>not a valid reason for changing this.
>
>Peter
>
>----------------------------------------------------------------------------
>To: [email protected]
>cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
>Subject: X pool inconsistencies, re: check_out_config question
>
>Rich, you are right to have been telling people that when they do a
>check out they should get the same thing as in the tree, such that
>a build before the bco and a build after are identical, and I feel
>strongly that this should be the case, *always*...
>
>EXCEPT
>
>the x11 development community has "required" us to have it this way;
>they "want" it such that a check out always gets the latest code, even
>if its inconsistent with its backing tree. (at least for the .nightly's)
>(In my opinion this is broken.)
>
>I think, however, its time to revisit this, since the x11 development is
>no longer just 5 people who are in tight coordination, but it's part of
>a larger product development environment which has more global processes
>which are in place to allow everyone to work from the same assumptions.
>
>In her mail, Madeline commented that:
>> If there are engineers on your side are working in the X pool, they should
>> feel free to discuss these decisions with them.
>
>My feeling is that the community using the x11 pool should have all the
>same expectations etc., and this community has grown. People submitting
>into the pool also include the security group, the hardware group, the ootb
>group in New Jersey, and perhaps miscellaneous parts of the base development
>group like presto support for example.
>
>Maintenance is coming to a close, so we shouldn't interfere with its
>process, but I recommend we make this change to sterling, gold and aghw.
>
>Thanks for bringing this up...
>
>-josh
>
>
>------- Forwarded Message
>
>Return-Path: [email protected]
>Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
> id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
>Received: by lars.unx.dec.com (5.65/MS-070792);
> id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
>Message-Id: <[email protected]>
>To: [email protected]
>Subject: check_out_config question
>Date: Wed, 23 Jun 93 16:59:29 -0400
>From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
><[email protected]>
>X-Mts: smtp
>
>
>When a sandbox is backed against agxminor.nightly the variable
>check_out_config is set to:
>
>AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
>
>So if I check out a file from agxminor.nightly I will get the latest version
>in the submit pool instead of the version in agxminor.nightly. Is that right??
>
>I then backed my sandbox against agosminor.nightly, check_out_config is:
>
>AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
>
>I have been telling the developers here that when you check out a file
>you get the version that is in the tree you are backed to.
>
>There seems to be an inconsistency here. This has frustrated the hell out
>of some of the developers here who are expecting to get the version in
>the agxminor.nightly tree when they bco.
>
>Please help.
>
>
>Rich
>- ----------------------------------------------------------------
>Rich Larsen, M/S: UNX TCP/IP: [email protected]
>USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
>Digital Equipment Corporation FAX: 908-577-6003
>200 Route 9 North Voice: 908-577-6083
>Manalapan, New Jersey 07726 DTN: 462
>
>------- End of Forwarded Message
>
>
|
| 170.4 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 16:02 | 120 |
| Date Of Receipt: 24-JUN-1993 14:20:45.86
From: QUARRY::haney "Don Haney USG 24-Jun-1993 1420"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@DEC:.zko.quarry>
CC: ws@DEC:.zko.quarry, odehelp@DEC:.zko.quarry, grass@DEC:.zko.quarry,
tresvik@DEC:.zko.quarry, afd@DEC:.zko.quarry, tappan@DEC:.zko.quarry,
meyer@DEC:.zko.quarry, [email protected]
Subj: Re: X pool inconsistencies, re: check_out_config question
Hi all the world ....
As one who feels reasonably strongly that we are doing it the right way in the
X pool, I can't understand why anyone would want to be checking out anything
OTHER than a file which reflected the latest check-ins within a given stream.
Especially when one considers that it is QUITE easy for the foo.nightly backing
tree to be a couple (or a few) days out of date; remember, it reflects yesterday's
submits ONLY if last night's build was successful. Otherwise, who knows how
many intervening submits are in there which might effect your change.
Very specifically .... agxminor.nightly was not built last night at the direction
of project management. So any changes which were bci'd yesterday are not in the
agxminor.nightly tree today.
The basic reason a bco from the X pool has always been from the main tree, and
not from foo.nightly or any other subsidiary tree, is to drastically reduce the
need to merge changes coming from different people or on subsequent days.
It is indeed unfortunate that whoever told Rich how the pools work failed to
tell him that bco's in the X pool operate in this manner. And then he passed
on what he thought to be correct. Now is the time to correct the misconceptions.
Don
-------------------------------------------------------------------------
> Rich, you are right to have been telling people that when they do a
> check out they should get the same thing as in the tree, such that
> a build before the bco and a build after are identical, and I feel
> strongly that this should be the case, *always*...
>
> EXCEPT
>
> the x11 development community has "required" us to have it this way;
> they "want" it such that a check out always gets the latest code, even
> if its inconsistent with its backing tree. (at least for the .nightly's)
> (In my opinion this is broken.)
>
> I think, however, its time to revisit this, since the x11 development is
> no longer just 5 people who are in tight coordination, but it's part of
> a larger product development environment which has more global processes
> which are in place to allow everyone to work from the same assumptions.
>
> In her mail, Madeline commented that:
> > If there are engineers on your side are working in the X pool, they should
> > feel free to discuss these decisions with them.
>
> My feeling is that the community using the x11 pool should have all the
> same expectations etc., and this community has grown. People submitting
> into the pool also include the security group, the hardware group, the ootb
> group in New Jersey, and perhaps miscellaneous parts of the base development
> group like presto support for example.
>
> Maintenance is coming to a close, so we shouldn't interfere with its
> process, but I recommend we make this change to sterling, gold and aghw.
>
> Thanks for bringing this up...
>
> -josh
>
>
> ------- Forwarded Message
>
> Return-Path: [email protected]
> Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
> id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
> Received: by lars.unx.dec.com (5.65/MS-070792);
> id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
> Message-Id: <[email protected]>
> To: [email protected]
> Subject: check_out_config question
> Date: Wed, 23 Jun 93 16:59:29 -0400
> From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
> <[email protected]>
> X-Mts: smtp
>
>
> When a sandbox is backed against agxminor.nightly the variable
> check_out_config is set to:
>
> AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
>
> So if I check out a file from agxminor.nightly I will get the latest version
> in the submit pool instead of the version in agxminor.nightly. Is that right??
>
> I then backed my sandbox against agosminor.nightly, check_out_config is:
>
> AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
>
> I have been telling the developers here that when you check out a file
> you get the version that is in the tree you are backed to.
>
> There seems to be an inconsistency here. This has frustrated the hell out
> of some of the developers here who are expecting to get the version in
> the agxminor.nightly tree when they bco.
>
> Please help.
>
>
> Rich
> - ----------------------------------------------------------------
> Rich Larsen, M/S: UNX TCP/IP: [email protected]
> USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
> Digital Equipment Corporation FAX: 908-577-6003
> 200 Route 9 North Voice: 908-577-6083
> Manalapan, New Jersey 07726 DTN: 462
>
> ------- End of Forwarded Message
>
>
|
| 170.5 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 16:04 | 21 |
| Date Of Receipt: 24-JUN-1993 14:40:59.54
From: ABYSS::decwet::peterson
To: QUARRY::haney
CC: abyss::odehelp, abyss::tresvik, abyss::afd, abyss::tappan, abyss::meyer,
abyss::"[email protected]"
Subj: Re: X pool inconsistencies, re: check_out_config question
There are two issues:
1. the de facto policy of the X pool is to check out the latest revision,
but this is not documented anywhere. Consequently new users can waste
a lot of time dealing with this (which is a real problem). If more than
a small group of people are working on the X pool, there should be a document
describing this and other X pool policies (note that the X pool builds
differently from the OS pool, and I'm sure there's other gotchas
that need explaining as well).
2. A proposal has been made to change the way check outs work in the X pool.
That should be formally brought before whoever is responsible for setting
X pool policy, and have it taken care of there inbstead of via mail.
--Kim
|
| 170.6 | Re: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 24 1993 17:08 | 142 |
| Date Of Receipt: 24-JUN-1993 15:01:09.27
From: FLUME::"[email protected]" "Madeline Barcia-Asmus USG"
To: [email protected], [email protected], [email protected]
CC: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subj: Re: X pool inconsistencies, re: check_out_config question
As much as I can appreciate a good debate , I'd like to propose a suggestion.
(how on earth did I become the voice of reason !).
Before I make my suggestion, just some history.
I believe in allowing developers to have input in their work environment. Basically
if one is comfortable , you work better. So, I left this decision up to the 'X' engineers
of GSF when 'X' joined the real world of ODE sandboxes. They "ALL" wanted
to be able to check out the most recent version and not the version in the backing
tree. There is NO RIGHT WAY OR WRONG WAY, its a way of preference.
So , it seems the real problem here is the lack of communication of how to you
work when you back to an X tree.
My suggestion:
Perhaps a README or some sort of online information concerning the
X work and build environment is needed. This doesn't mean I'm going to run
off and put on in place by 5:00 pm. BUT perhaps we can all work together and
pull the different important pieces together into one central online doc.
This will help new comers and even the old comers who just simply forget
how to do something.
Glad to see no one's sleeping out there ! : )
-Madeline
-------------------------------------------------
NO! Please don't break this! When I check something out, I want the latest
version that has been checked in, whether or not it has yet made it into the
nightly backing tree. Otherwise, it is quite possible to miss previous changes
and lose previous work, especially since it seems to happen relatively often
that the nightly tree fails to get updated daily (nightly). Changing this
would the cause needless confusing merges when submitting. If you check out
the latest from the submit tree and find that is not the same as the nightly
tree, it is extremely simple and obvious to see what has been changed by
reading the modification history.
Peter (pderr)
I strongly agree with peter derr. There was a couple of times I started
to work on a problem and found the fix had NOT made it into the nightly
tree due to build problems.
-pete Snider
Hi all the world ....
As one who feels reasonably strongly that we are doing it the right way in the
X pool, I can't understand why anyone would want to be checking out anything
OTHER than a file which reflected the latest check-ins within a given stream.
>>> EXCEPT
>>>
>>> the x11 development community has "required" us to have it this way;
>>> they "want" it such that a check out always gets the latest code, even
>>> if its inconsistent with its backing tree. (at least for the .nightly's)
>>> (In my opinion this is broken.)
>>>
>>> I think, however, its time to revisit this, since the x11 development is
>>> no longer just 5 people who are in tight coordination, but it's part of
>>> a larger product development environment which has more global processes
>>> which are in place to allow everyone to work from the same assumptions.
>>>
>>> In her mail, Madeline commented that:
>>> > If there are engineers on your side are working in the X pool, they shou
ld
>>> > feel free to discuss these decisions with them.
>>>
>>> My feeling is that the community using the x11 pool should have all the
>>> same expectations etc., and this community has grown. People submitting
>>> into the pool also include the security group, the hardware group, the oot
b
>>> group in New Jersey, and perhaps miscellaneous parts of the base developme
nt
>>> group like presto support for example.
>>>
>>> Maintenance is coming to a close, so we shouldn't interfere with its
>>> process, but I recommend we make this change to sterling, gold and aghw.
>>>
>>> Thanks for bringing this up...
>>>
>>> -josh
>>>
>>>
>>> ------- Forwarded Message
>>>
>>> Return-Path: [email protected]
>>> Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
>>> id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
>>> Received: by lars.unx.dec.com (5.65/MS-070792);
>>> id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
>>> Message-Id: <[email protected]>
>>> To: [email protected]
>>> Subject: check_out_config question
>>> Date: Wed, 23 Jun 93 16:59:29 -0400
>>> From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
>>> <[email protected]>
>>> X-Mts: smtp
>>>
>>>
>>> When a sandbox is backed against agxminor.nightly the variable
>>> check_out_config is set to:
>>>
>>> AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CON
FIG
>>>
>>> So if I check out a file from agxminor.nightly I will get the latest versi
on
>>> in the submit pool instead of the version in agxminor.nightly. Is that rig
ht??
>>>
>>> I then backed my sandbox against agosminor.nightly, check_out_config is:
>>>
>>> AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
>>>
>>> I have been telling the developers here that when you check out a file
>>> you get the version that is in the tree you are backed to.
>>>
>>> There seems to be an inconsistency here. This has frustrated the hell out
>>> of some of the developers here who are expecting to get the version in
>>> the agxminor.nightly tree when they bco.
>>>
>>> Please help.
>>>
>>>
>>> Rich
>>> - ----------------------------------------------------------------
>>> Rich Larsen, M/S: UNX TCP/IP: [email protected]
>>> USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
>>> Digital Equipment Corporation FAX: 908-577-6003
>>> 200 Route 9 North Voice: 908-577-6083
>>> Manalapan, New Jersey 07726 DTN: 462
>>>
>>> ------- End of Forwarded Message
>>>
>>>
>>
|
| 170.7 | | AOSG::TAPPAN | | Mon Jun 28 1993 10:38 | 30 |
| <<< SYS$SYSDEVICE:[NOTES$LIBRARY]BUILDHELP.NOTE;1 >>>
-< USG buildhelp questions/answers >-
================================================================================
Note 171.0 Correction - Re: X pool inconsistencies, re: check_out_c No replies
SMURF::FILTER "Automatic Posting Software - mail to" 23 lines 24-JUN-1993 15:03
--------------------------------------------------------------------------------
Date Of Receipt: 24-JUN-1993 14:25:27.22
From: QUARRY::haney "Don Haney USG 24-Jun-1993 1425"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@DEC:.zko.quarry>
CC: ws@DEC:.zko.quarry, odehelp@DEC:.zko.quarry, grass@DEC:.zko.quarry,
tresvik@DEC:.zko.quarry, afd@DEC:.zko.quarry, tappan@DEC:.zko.quarry,
meyer@DEC:.zko.quarry, [email protected]
Subj: Correction - Re: X pool inconsistencies, re: check_out_config question
------- Forwarded Message
Sorry - a corretion in my recent note:
> Very specifically .... agxminor.nightly was not built last night at the direction
> of project management. So any changes which were bci'd yesterday are not in the
> agxminor.nightly tree today.
Should say "bsubmit'd" instead of "bci'd" ------------^
Don
------- End of Forwarded Message
|
| 170.8 | | AOSG::TAPPAN | | Mon Jun 28 1993 10:38 | 164 |
| <<< SYS$SYSDEVICE:[NOTES$LIBRARY]BUILDHELP.NOTE;1 >>>
-< USG buildhelp questions/answers >-
================================================================================
Note 172.0 Peter Wolfe in UNX agrees, don t change it 1 reply
SMURF::FILTER "Automatic Posting Software - mail t" 157 lines 24-JUN-1993 15:03
--------------------------------------------------------------------------------
Date Of Receipt: 24-JUN-1993 14:35:51.26
From: QUARRY::pderr "Peter Derr AUEG 24-Jun-1993 1435"
To: jmf@DEC:.zko.quarry
CC: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subj: Peter Wolfe in UNX agrees, don't change it
The problem that occurred in UNX was not caused by the checkout config. Peter
Wolfe says, "It's fine that bco gives you the latest for the X tree."
Peter
------- Forwarded Message
Return-Path: [email protected]
Received: by quarry.zk3.dec.com; id AA12897; Thu, 24 Jun 1993 14:24:14 -0400
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA11598; Thu, 24 Jun 1993 14:24:13 -0400
Received: by peewee.unx.dec.com (5.57/MS-070792);
id AA16635; Thu, 24 Jun 93 14:26:41 -0400
Date: Thu, 24 Jun 93 14:26:41 -0400
Message-Id: <[email protected]>
From: [email protected] (Peter Wolfe, Desktop Devel., DTN 462-6010)
To: "[email protected]"@SYSV.ENET.dec.com
Subject: FWD: Re: X pool inconsistencies, re: check_out_config question
Whoooaaa! What you have described below has nothing to with the
actual problem - which is a REAL problem. It's fine that bco gives
you the latest for the X tree. The problem is that the last
change to a particular file was over a month yet it's not
in the backing tree! What actually happened to Linda was that the
bco file already had her changes in it!!!! IOW, someone had checked it
in already but that version was not int he backing tree nor the submit tree
for over a month!
Pete
From: UNXA::UNXA::SYSV::"[email protected]" 24-JUN-1993 14:08:32.12
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
CC: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subj: Re: X pool inconsistencies, re: check_out_config question
NO! Please don't break this! When I check something out, I want the latest
version that has been checked in, whether or not it has yet made it into the
nightly backing tree. Otherwise, it is quite possible to miss previous changes
and lose previous work, especially since it seems to happen relatively often
that the nightly tree fails to get updated daily (nightly). Changing this
would the cause needless confusing merges when submitting. If you check out
the latest from the submit tree and find that is not the same as the nightly
tree, it is extremely simple and obvious to see what has been changed by
reading the modification history.
This check out config has worked very well this way for a very long time,
and just because a single new user of the X pool found this confusing is
not a valid reason for changing this.
Peter
- ----------------------------------------------------------------------------
To: [email protected]
cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: X pool inconsistencies, re: check_out_config question
Rich, you are right to have been telling people that when they do a
check out they should get the same thing as in the tree, such that
a build before the bco and a build after are identical, and I feel
strongly that this should be the case, *always*...
EXCEPT
the x11 development community has "required" us to have it this way;
they "want" it such that a check out always gets the latest code, even
if its inconsistent with its backing tree. (at least for the .nightly's)
(In my opinion this is broken.)
I think, however, its time to revisit this, since the x11 development is
no longer just 5 people who are in tight coordination, but it's part of
a larger product development environment which has more global processes
which are in place to allow everyone to work from the same assumptions.
In her mail, Madeline commented that:
> If there are engineers on your side are working in the X pool, they should
> feel free to discuss these decisions with them.
My feeling is that the community using the x11 pool should have all the
same expectations etc., and this community has grown. People submitting
into the pool also include the security group, the hardware group, the ootb
group in New Jersey, and perhaps miscellaneous parts of the base development
group like presto support for example.
Maintenance is coming to a close, so we shouldn't interfere with its
process, but I recommend we make this change to sterling, gold and aghw.
Thanks for bringing this up...
- -josh
- ------- Forwarded Message
Return-Path: [email protected]
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
Received: by lars.unx.dec.com (5.65/MS-070792);
id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: check_out_config question
Date: Wed, 23 Jun 93 16:59:29 -0400
From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
<[email protected]>
X-Mts: smtp
When a sandbox is backed against agxminor.nightly the variable
check_out_config is set to:
AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
So if I check out a file from agxminor.nightly I will get the latest version
in the submit pool instead of the version in agxminor.nightly. Is that right??
I then backed my sandbox against agosminor.nightly, check_out_config is:
AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
I have been telling the developers here that when you check out a file
you get the version that is in the tree you are backed to.
There seems to be an inconsistency here. This has frustrated the hell out
of some of the developers here who are expecting to get the version in
the agxminor.nightly tree when they bco.
Please help.
Rich
- - ----------------------------------------------------------------
Rich Larsen, M/S: UNX TCP/IP: [email protected]
USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
Digital Equipment Corporation FAX: 908-577-6003
200 Route 9 North Voice: 908-577-6083
Manalapan, New Jersey 07726 DTN: 462
- ------- End of Forwarded Message
------- End of Forwarded Message
|
| 170.9 | | AOSG::TAPPAN | | Mon Jun 28 1993 10:39 | 31 |
| <<< SYS$SYSDEVICE:[NOTES$LIBRARY]BUILDHELP.NOTE;1 >>>
-< USG buildhelp questions/answers >-
================================================================================
Note 172.1 Peter Wolfe in UNX agrees, don t change it 1 of 1
SMURF::FILTER "Automatic Posting Software - mail to" 23 lines 24-JUN-1993 15:05
-< Re: Peter Wolfe in UNX agrees, don t change it >-
--------------------------------------------------------------------------------
Date Of Receipt: 24-JUN-1993 14:42:25.90
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 24-Jun-1993 1442"
To: "Peter Derr" <pderr@wasted:zko.dec>
CC: jmf@wasted:zko.dec, [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected]
Subj: Re: Peter Wolfe in UNX agrees, don't change it
As I responded to Rich earlier, the problem with the inconsistency
in the tree with dxdiff/parsediffl.c (is that the case in question?)
is being investigated.
We'll let you know the details soon, but there was a problem with
the way that much of the x code was "put" into "the pool" without
the use of bsubmit -- this caused inconsistencies; we're investigating
this now...
-josh
(I still feel strongly about the check-out-config, but if everyone
using the pool agrees, AND EDUCATES ANY GROUP WHO MAY BE USING THE
POOL TOO, then... well...)
|
| 170.10 | fwd: X pool inconsistencies, re: check_out_config question | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Mon Jun 28 1993 15:29 | 299 |
| Date Of Receipt: 28-JUN-1993 13:37:57.08
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 28-Jun-1993 1337"
To: alphapc@wasted:zko.dec, bossec@wasted:zko.dec
CC: ws@wasted:zko.dec, odehelp@wasted:zko.dec, grass@wasted:zko.dec,
tresvik@wasted:zko.dec, afd@wasted:zko.dec, tappan@wasted:zko.dec,
meyer@wasted:zko.dec
Subj: fwd: X pool inconsistencies, re: check_out_config question
Alpha-PC and Security groups, fyi, I know that you are or will be
working with the "X" pool some, and thought you should be aware of the
following, and have a chance to input, as part of the development team.
Attached are 6 pieces of mail debating the following issue: in all the
x nightly pools, the x developers have had us structure the rc_files
such that when you're backed by nightly, a bco doesn't give you the
version from nightly, but from the submit tree, which may be more
recent, and therefore inconsistent with the backing tree, but it
reduces the need to do extra merges prior to submitting.
You should know about this structure, and if you have any arguments you
feel strongly about, please feel free to respond to the group...
Thanks...
-josh
------- Forwarded Messages
------- Message 1
Return-Path: jmf
Message-Id: <[email protected]>
To: [email protected]
Cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: X pool inconsistencies, re: check_out_config question
Date: Thu, 24 Jun 93 13:58:44 +28716
From: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>
X-Mts: smtp
Status: RO
Rich, you are right to have been telling people that when they do a
check out they should get the same thing as in the tree, such that
a build before the bco and a build after are identical, and I feel
strongly that this should be the case, *always*...
EXCEPT
the x11 development community has "required" us to have it this way;
they "want" it such that a check out always gets the latest code, even
if its inconsistent with its backing tree. (at least for the .nightly's)
(In my opinion this is broken.)
I think, however, its time to revisit this, since the x11 development is
no longer just 5 people who are in tight coordination, but it's part of
a larger product development environment which has more global processes
which are in place to allow everyone to work from the same assumptions.
In her mail, Madeline commented that:
> If there are engineers on your side are working in the X pool, they should
> feel free to discuss these decisions with them.
My feeling is that the community using the x11 pool should have all the
same expectations etc., and this community has grown. People submitting
into the pool also include the security group, the hardware group, the ootb
group in New Jersey, and perhaps miscellaneous parts of the base development
group like presto support for example.
Maintenance is coming to a close, so we shouldn't interfere with its
process, but I recommend we make this change to sterling, gold and aghw.
Thanks for bringing this up...
- -josh
- ------- Forwarded Message
Return-Path: [email protected]
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA23543; Wed, 23 Jun 1993 16:59:49 -0400
Received: by lars.unx.dec.com (5.65/MS-070792);
id AA14880; Wed, 23 Jun 1993 16:59:30 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: check_out_config question
Date: Wed, 23 Jun 93 16:59:29 -0400
From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
<[email protected]>
X-Mts: smtp
When a sandbox is backed against agxminor.nightly the variable
check_out_config is set to:
AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
So if I check out a file from agxminor.nightly I will get the latest version
in the submit pool instead of the version in agxminor.nightly. Is that right??
I then backed my sandbox against agosminor.nightly, check_out_config is:
AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32
I have been telling the developers here that when you check out a file
you get the version that is in the tree you are backed to.
There seems to be an inconsistency here. This has frustrated the hell out
of some of the developers here who are expecting to get the version in
the agxminor.nightly tree when they bco.
Please help.
Rich
- - ----------------------------------------------------------------
Rich Larsen, M/S: UNX TCP/IP: [email protected]
USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
Digital Equipment Corporation FAX: 908-577-6003
200 Route 9 North Voice: 908-577-6083
Manalapan, New Jersey 07726 DTN: 462
- ------- End of Forwarded Message
------- Message 2
Return-Path: [email protected]
Received: by minsrv.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA24206; Thu, 24 Jun 1993 14:06:40 -0400
Received: by lars.unx.dec.com (5.65/MS-070792);
id AA17273; Thu, 24 Jun 1993 14:06:20 -0400
Message-Id: <[email protected]>
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
Cc: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subject: Re: X pool inconsistencies, re: check_out_config question
In-Reply-To: Your message of "Thu, 24 Jun 93 13:58:44."
<[email protected]>
Date: Thu, 24 Jun 93 14:06:20 -0400
From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
<[email protected]>
X-Mts: smtp
Status: RO
I couldn't have said it any better. It was particularly frustrating
since this affected one developer in that she was convinced she was
doing something wrong and wasted an entire day.
I hope this issue gets resolved.
- -Rich
------- Message 3
Return-Path: pderr
Received: by quarry.zk3.dec.com; id AA12202; Thu, 24 Jun 1993 14:13:28 -0400
Message-Id: <[email protected]>
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>
Cc: [email protected], ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: Re: X pool inconsistencies, re: check_out_config question
In-Reply-To: Your message of "Thu, 24 Jun 93 13:58:44."
<[email protected]>
Date: Thu, 24 Jun 93 14:13:28 -0400
From: "Peter Derr" <pderr>
X-Mts: smtp
NO! Please don't break this! When I check something out, I want the latest
version that has been checked in, whether or not it has yet made it into the
nightly backing tree. Otherwise, it is quite possible to miss previous changes
and lose previous work, especially since it seems to happen relatively often
that the nightly tree fails to get updated daily (nightly). Changing this
would the cause needless confusing merges when submitting. If you check out
the latest from the submit tree and find that is not the same as the nightly
tree, it is extremely simple and obvious to see what has been changed by
reading the modification history.
This check out config has worked very well this way for a very long time,
and just because a single new user of the X pool found this confusing is
not a valid reason for changing this.
Peter
------- Message 4
Return-Path: snider
Received: by quarry.zk3.dec.com; id AA12505; Thu, 24 Jun 1993 14:17:08 -0400
Message-Id: <[email protected]>
To: "Peter Derr" <pderr>
Cc: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>, [email protected], ws,
odehelp, grass, tresvik, afd, tappan, meyer
Subject: Re: X pool inconsistencies, re: check_out_config question
In-Reply-To: Your message of "Thu, 24 Jun 93 14:13:28 EDT."
<[email protected]>
Date: Thu, 24 Jun 93 14:17:03 -0400
From: Pete Snider <snider>
X-Mts: smtp
I strongly agree with peter derr. There was a couple of times I started
to work on a problem and found the fix had NOT made it into the nightly
tree due to build problems.
- -pete
------- Message 5
Return-Path: haney
Received: by quarry.zk3.dec.com; id AA12645; Thu, 24 Jun 1993 14:20:04 -0400
Message-Id: <[email protected]>
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>
Cc: ws, odehelp, grass, tresvik, afd, tappan, meyer, [email protected]
Subject: Re: X pool inconsistencies, re: check_out_config question
In-Reply-To: Your message of "Thu, 24 Jun 93 13:58:44."
<[email protected]>
Date: Thu, 24 Jun 93 14:20:04 -0400
From: haney
X-Mts: smtp
Hi all the world ....
As one who feels reasonably strongly that we are doing it the right way in the
X pool, I can't understand why anyone would want to be checking out anything
OTHER than a file which reflected the latest check-ins within a given stream.
Especially when one considers that it is QUITE easy for the foo.nightly backing
tree to be a couple (or a few) days out of date; remember, it reflects
yesterday's
submits ONLY if last night's build was successful. Otherwise, who knows how
many intervening submits are in there which might effect your change.
Very specifically .... agxminor.nightly was not built last night at the
direction
of project management. So any changes which were bci'd yesterday are not in the
agxminor.nightly tree today.
The basic reason a bco from the X pool has always been from the main tree, and
not from foo.nightly or any other subsidiary tree, is to drastically reduce the
need to merge changes coming from different people or on subsequent days.
It is indeed unfortunate that whoever told Rich how the pools work failed to
tell him that bco's in the X pool operate in this manner. And then he passed
on what he thought to be correct. Now is the time to correct the
misconceptions.
Don
------- Message 6
Return-Path: mad
Received: by malcolm.zk3.dec.com; id AA07395; Thu, 24 Jun 1993 15:01:07 -0400
Message-Id: <[email protected]>
To: haney, jmf, [email protected]
Cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: Re: X pool inconsistencies, re: check_out_config question
In-Reply-To: Your message of "Thu, 24 Jun 93 14:20:04 EDT."
<[email protected]>
Date: Thu, 24 Jun 93 15:01:07 +28716
From: ""Madeline T. Asmus"" <mad>
X-Mts: smtp
As much as I can appreciate a good debate , I'd like to propose a suggestion.
(how on earth did I become the voice of reason !).
Before I make my suggestion, just some history.
I believe in allowing developers to have input in their work environment.
Basically
if one is comfortable , you work better. So, I left this decision up to the
'X' engineers
of GSF when 'X' joined the real world of ODE sandboxes. They "ALL" wanted
to be able to check out the most recent version and not the version in the
backing
tree. There is NO RIGHT WAY OR WRONG WAY, its a way of preference.
So , it seems the real problem here is the lack of communication of how to you
work when you back to an X tree.
My suggestion:
Perhaps a README or some sort of online information concerning the
X work and build environment is needed. This doesn't mean I'm going to run
off and put on in place by 5:00 pm. BUT perhaps we can all work together and
pull the different important pieces together into one central online doc.
This will help new comers and even the old comers who just simply forget
how to do something.
Glad to see no one's sleeping out there ! : )
- -Madeline
------- End of Forwarded Messages
|