| Date Of Receipt: 28-JUN-1993 15:51:06.41
From: MINSRV::"[email protected]" "Michael D. Fairbrother UEG"
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], [email protected],
[email protected]
Subj: Re: restatement/apology Re: X pool inconsistencies, re: check_out_config question
I belive that we as an organization would strive to have similar
environments for development, which allows engineers to be
productive (in both environments).
The two environments are not alike, in fact the differences between the
two is amazing. I feel that some of the primary benefits of ODE, been lost.
I agree with anyone who does not like using bmerge, I do everything I
can to avoid getting pulled into a bmerge when submitting.
|
| Date Of Receipt: 28-JUN-1993 16:35:35.53
From: LOCORE::dutile "Don Dutile WHATHEP"
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <locore::jmf>
CC: locore::dutile, locore::mdf, locore::odehelp, locore::grass,
locore::tresvik, locore::afd, locore::tappan, locore::meyer
Subj: Re: restatement/apology Re: X pool inconsistencies, re: check_out_config question
re: Between the release engineering and workstation groups, we will put
together a Readme file or document of some sort, associated with the
pool, which has appropriate information which a new developer needs in
order to use the pools.
NO, NO, NO, NO, NO, NO, NO!!!!!!!!!!!!!!!!!!!!!!!!!!
Josh,
I didn't find your mail biased, but eye-opening.
If certain individuals want to use the pool in a certain
way, then let them create (and distribute if they like) their
own nifty scripts. Users (new & old) of ode-based pools,
and/or diff. organizationally-based pools, should operate
under the same (basic) rules & expectations.
This "over-customization" is the reason you have
standard tools -- to optimize the larger groups' efforts,
not the minor few who want unique features. If you promote
these non-std. uses, you might as well junk any kind of central,
consistent tool base (ODE). We are drifting back to the old
method(s) of some did it this way, some did it that way, the
result(s) being less predictable.
DO NOT create, encourage, and/or publish a how-to README file
for each pool -- this is pool anarchy. if you want to support
this (extreme) bias -- DON'T USE ODE!
As Mike indicated, if a user wants uniqueness, he creates &
uses environment- and user-specific setups. if release eng.
is spending *any* time customizing pool environments into
non-std. utilization, it is using critical, valuable manpower
resources that should be serving the group in better ways --
like supporting builds, kitting, etc. better (more automation,
less hand tweaking).
The use of ode should not be group determined at this point.
It should be standard for all of USG. If not, then I'd like
to see buy-in from Steve J's staff on this non-std. use and
the extra manpower/hourse to support it (and the lost time when
people have to work in it and "we're not in Kansas any longer...
maybe not even OZ!").
/don
|
| Date Of Receipt: 28-JUN-1993 23:12:29.62
From: FLUME::"[email protected]" "Grant Van Dyck"
To: [email protected] (By the time you make ends meet they move the ends.)
CC: [email protected], [email protected] (Jeff Meyer AUEG),
[email protected] (Alan Delorey), [email protected] (Sarah Tappan AUEG),
[email protected] (Tom Tresvik),
[email protected] (Michael D. Fairbrother UEG), [email protected]
Subj: Re: restatement/apology Re: X pool inconsistencies, re: check_out_config question
Some strong opinions here, but perhaps a bit misleading. This pool, the X11
pool has operated in this manner from it's inception - almost 2 years now.
There is no right and wrong way to handle this, its strictly a matter of
preference, and the inhabitants of this realm PREFER it this way. You go on at
great length about extra overhead, wasted manpower etc ... but in fact none of
this applies. No extra work is required. We're talking about one (1)
environment variable here - which never changes. As far as your statement
regarding "junking ode", this seems to be excessive hyperbole. Everything else
in the X pool is completely consistant with ODE, as much as can be when you
fit a square peg in a round hole. Simply because some of this doesn't mesh
with a notion of the world that you are comfortable with, doesn't make it
wrong. One of the greatest strengths of ODE is its flexibility and it's
ability to be customized to suit the requirements of various user groups. If
we go and impose rigid inflexible "rules" everywhere, you begin to destroy
that beauty and we may as well go back to SCCS.
I think its up to release engineering to decide what is too much overhead.
This pool exists for X11 development and the X11 group overwhelmingly desires
the pool to work in this way. If that is uncomfortable to anyone, it is
reletively easy , as Michael points out, to make your environment work in
another way. Thus the point of the README - to explain what the pool rules are
and how to work differently if that is your wish and allow us all the
FLEXIBILITY to work in the most efficient way for each of us.
-Grant
> re: Between the release engineering and workstation groups, we will put
> together a Readme file or document of some sort, associated with the
> pool, which has appropriate information which a new developer needs in
> order to use the pools.
>
> NO, NO, NO, NO, NO, NO, NO!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> Josh,
> I didn't find your mail biased, but eye-opening.
> If certain individuals want to use the pool in a certain
> way, then let them create (and distribute if they like) their
> own nifty scripts. Users (new & old) of ode-based pools,
> and/or diff. organizationally-based pools, should operate
> under the same (basic) rules & expectations.
>
> This "over-customization" is the reason you have
> standard tools -- to optimize the larger groups' efforts,
> not the minor few who want unique features. If you promote
> these non-std. uses, you might as well junk any kind of central,
> consistent tool base (ODE). We are drifting back to the old
> method(s) of some did it this way, some did it that way, the
> result(s) being less predictable.
>
> DO NOT create, encourage, and/or publish a how-to README file
> for each pool -- this is pool anarchy. if you want to support
> this (extreme) bias -- DON'T USE ODE!
>
> As Mike indicated, if a user wants uniqueness, he creates &
> uses environment- and user-specific setups. if release eng.
> is spending *any* time customizing pool environments into
> non-std. utilization, it is using critical, valuable manpower
> resources that should be serving the group in better ways --
> like supporting builds, kitting, etc. better (more automation,
> less hand tweaking).
>
> The use of ode should not be group determined at this point.
> It should be standard for all of USG. If not, then I'd like
> to see buy-in from Steve J's staff on this non-std. use and
> the extra manpower/hourse to support it (and the lost time when
> people have to work in it and "we're not in Kansas any longer...
> maybe not even OZ!").
>
> /don
>
>
--
Grant Van Dyck enet: [email protected]
Release Engineering
|