[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | USG buildhelp questions/answers |
|
| Moderator: | SMURF::FILTER |
|
| Created: | Mon Apr 26 1993 |
| Last Modified: | Mon Jan 20 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2763 |
| Total number of notes: | 5802 |
429.0. "most recent ode project plan" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Fri Nov 12 1993 16:20
Date Of Receipt: 10-NOV-1993 18:50:35.61
From: US2RMC::"[email protected]" "Tina Salley is decwet::salley, Brian is quarry::anderson, Mark is decwet::markk"
To: flambe::odehelp
CC:
Subj: most recent ode project plan
Here is the latest project plan. It takes what Mike
gave me and also the comments I got back from Josh.
I also grouped tasks, to make it easier on me and
how I keep track of the various tasks and correlations.
If you want a postscript version, I'll put one into
abyss::~tea/odeplan.ps in about 10 minutes. Enjoy, Tina
******************* cut here ****************************
Digital Equipment Corporation - Confidential and Proprietary
For Internal Use Only
10-November-1993
Development Plan for
DECode II V3.0
Issued by: Tina Anderson
For Internal Use Only
Digital Equipment Corporation -DECwest
Confidential and Proprietary
Preface
This is an description of the development project to design, build,
test, evaluate, and deliver DECode II V3.0.
Associated Documents
1. Automated Dependency Generation Project Plan (5/7/93) that
describes
the goals, deliverables, and cross-project considerations for the
automatic dependencies.
2. Automatic Dependency Generation in the DEC/OSF1 Build Specifica-
tion (9/14/93) that describes the mechanism for automatic gener-
ation for DEC/OSF1.
3. Change Management Tracking System (CEMENT) Design Specification -
Prototype Version (5/21/93)
Change_History_____________________________________________________
Description/Summary of
Date_________Issue_#__Person____________Changes____________________
5/19/93 Mike Thomas Initial version for review by
DECode II development group
6/16/93 Mike Thomas To DEC OSF/1 team for review
9/19/93 Tina Anderson Return from DEC OSF/1 team
10/6/93 Tina Anderson Return from DEC OSF/1 team
with
prioritizations
10/11/93 Tina Anderson Update with DEC OSF/1 teams
in-
________________________________________put________________________
Preface v
Digital Equipment Corporation-DECwest
Confidential and Proprietary
1 Development Strategy
The goals for DECode II V3.0 were derived from interviewing a diverse
group of DECode-II users using a method called contextual inquiry.
The
interviewing was done in February 1993. These users included devel-
opers, release engineers and project leaders at 5 Digital sites. The
data obtained from these interviews plus from user requirements and
wish lists were used to generate a list of "needs". The "needs" were
then weighted, using input from both the DECode-II group and from the
DEC/OSF1 group. Out of these "needs", a list of "work items" were
gen-
erated. Both the DECode-II group and the DEC/OSF1 generated "work
items"
for DECode II V3.0.
2 Work Items and Estimates
The "work items" are grouped around goals for DECode II V3.0.
Each work item is attached a priority of high, medium, or low. The
pri-
orities were determined in part by the results of the QFD, and in
part
from an overall review of the items by the DECode II group and the
DEC/OSF1
group.
In order to meet the DEC OSF/1 team's date requirements, some of the
medium and low work items may be removed or postponed until a future
release.
The work estimates in this plan are rough estimates. The actual
schedul-
ing will be done using estimates agreed upon with the responsible en-
gineer(s).
2.1 merging - improve the "how" of merging.
Users find the bsubmit/bmerge merge menu confusing. Users hesitate to
use bmerge, due to being poisoned by past experiences with merge
tools.
For some merge work users need to use an optional pick and choose
method
to merge, such as vdiff. Users start a submit and in the process dis-
cover they need to do a merge as well. GUI merge enchancements in un-
derstanding differences between files.
The following tasks below will make the merge process easier.
o flexible configurable merge tool (High\13 person-weeks)
This will provide the optional feature of being able to merge
files
that have merge overlaps, using a visual tool (like vdiff). This
effort to include early prototype, followed by a formal design
pro-
cess. prototype to include investigating a user-settable DIFF
vari-
able of some sort to allow any diff tool.
o rework bsubmit merge (High\2 person-weeks)
The merge features within bsubmit will be improved in the follow-
ing ways:
co/rco and diff/rdiff menu options will be more meaningful
DECode II V3.0 Development Plan 1
Digital Equipment Corporation-DECwest
Confidential and Proprietary
diff markers will be more meaningful
add option to not submit a file which has merge overlaps.
o merge -info (High\2 person-week)
Provide a bmerge -info or "bmerge as-needed" to list which files
actually need to be merged, similar to what happens now at the
start
of a bsubmit\2 person-week)
o prevent check in of file with merge overlap markers (High\3 weeks)
o change bmerge to conform to bsubmit changes (High/4 person-weeks)
Changes to the merge feature within bsubmit will be shadowed in
bmerge.
o PTT Problem - bco -j bug (High\1 person-week) fix diff3 bug
o turn off merging in bsubmit - optional (High\1 person-week)
When bsubmit detects that a merge will be necessary, bsubmit will
produce an informational message telling the user how to manually
merge the file, and will then proceed to the next (if any) file.
o roll bco -j into bmerge (Medium-High\2 person-week)
roll bco -j functionality into bmerge\1 person-week)
o PTT Problem - rcs keywork (Medium\2 person-weeks)
don't expand rcs keywords when merging\2 person-week.
o 3-way visual diff (Low\13 person-weeks)
Provide tool of some sort to look visually at diffs from a common
ancestor
2.2 customization of commands on project or user level
Provide ability whereby user-created code could be integrated into
the
execution of the commands, as a way to allow per-project and per-user
customization. Work would include a design of the above model. Given
the design, provision would be added for pre- and post-processing
call-
out points for an initial set of commands. That set would be the "b"
commands. Pre-processing would include a continue/don't continue sta-
tus in order to control subsequence processing by the DECode II com-
mand. By providing this model, projects can obtain such information
as the following:
. checks that an approved submit is being done
. check that user has been approved by the project team
. if there is an acl denied message local information could be pre-
sented for the user how to get added to the acl list.
. track who has sandboxes backed by a specific backing tree
Customization of commands include the following work items:
o pre-processing support in bcreate, bco, bci, and bsubmit (High\13
person-weeks)
This would provide a call-out point for individual "b" commands so
user-created code could be integrated into the pre-processing of
an individual "b"-command
2 DECode II V3.0 Development Plan
Digital Equipment Corporation-DECwest
Confidential and Proprietary
o post-processing support in bcreate, bco, bci, and bsubmit (High\13
person-weeks) This would provide a call-out point for individual
"b" commands so user-created code could be integrated into the
post-
processing of an individual "b"-command.
Note: We have this one high because we ourselves need this. In
that
we may use this functionality to design some other tasks.
o pre-processing support in non-"b" commands (Low\5 person-weeks)
This would provide a call-out point for individual non-"b"
commands
so user-created code could be integrated into the pre-processing
of an individual non-"b"-command.
o post-processing support in non-"b" commands (Low\5 person-weeks)
This would provide a call-out point for individual non-"b"
commands
so user-created code could be integrated into the post-processing
of an individual non-"b"-command.
2.3 authentication
The goal is to provide a more flexible authentication level that can
be supported and configurable on a per-pool basis.
DEC/OSF1 has a need as well to address kerberos passwords expiring,
which is very annoying when you have a deadline to submit a file.
o fix password expirations/bold (high/ 30 minutes)
It is frustrating to have your password expire, and then wait to
have your expiration date fixed. The database on merge.zso.dec.com
will have all passwords set to expire at a future date, so that
this
will not be a problem any longer.
o no authentication (low/3 weeks)
o simple authentication (node & user name) (low/3 weeks)
o principal authentication (via Kerberos) (high/ this is current
model-
no work)
2.4 automount
The goal is to test and make all DECode II commands compatable with
automount. Work includes investigating the use of automount since use
of autmount will reduce the load on system administrators, especially
when multiple levels of nested shared sandboxes are in use in a
project.
o make DECode II compatable with automount (low/3 person-weeks)
2.5 bcreate
bcreate -undo needs to remove the ,v file in the rcs tree, and remove
any empty directories.
o bcreate -undo remove ,v file (Low-Medium/ 2 person-week).
DECode II V3.0 Development Plan 3
Digital Equipment Corporation-DECwest
Confidential and Proprietary
2.6 bsubmit
Tasks to enhance bsubmit includes the following:
o take defunct comments (High-2 person-weeks)
The -defunct switch should require and use user comments, and not
automatically fill in "file is defunct"
o automatically override merge during bsubmit (ZERO if merge
easy/complete;
MED otherwise\? person-weeks)
Allow user to automatically override merge during bsubmit. Some-
times users know they've merged files independent of the bmerge
fa-
cility, and that bsubmit will flag a file as requiring a merge.
The
user intends to use the "rco" option to override the merge and
just
"force" in their own version of the file. If there are many files
involved, it is very keyboard-intensive to do this on every file,
and it would be nice if this could be automated, like an "-auto_
rco" switch to bsubmit.
There is a risk, however, that if this feature is too convenient,
people may get sloppy and start losing other peoples' work.
o project optional relink/copy of file on bsubmit (Low-Medium/4
person-
weeks) On a project-wide basis, it will be possible to have bsub-
mit restore the link or copy (with updated contents) of the indi-
vidual submitted file that was present before the bco of that
file.
This will be useful for pools that rely on copies or links in or-
der to build in a sandbox. Currently -local_co checks out the
file,
and doesn't provide just a link.
Note: This came from the X group requesting an automatic relink
for
each file they submit.
o bsubmit - Non-atomic bsubmit command option (non-goal for
DEC/OSF1\5
person-weeks) The bsubmit command will be modified so that each
file
goes through the full submission process before the next file is
processed. This will reduce the frequency with which users' files
get put in the hold queue. Instead of all files involved in the
sub-
mission being held when a submission error occurs, only the one
file
with the problem will be held. bsubmit will then go on to the next
file.
For so projects this may be useful, but, for the osf/1 project,
the
atomicity of submits is very important. Having not atomic submits
can blem problem if two submittors overlap files, and each get
part
of tmit submit in. There may be a merge "deadlock" and both sets
of flityionality may be broken in the build. We're concerned more
individual submittors which problems will break the build rather
than just delaying their functionality.
Thus this feature is a non-goal for DEC/OSF1 and will not be
planned.
4 DECode II V3.0 Development Plan
Digital Equipment Corporation-DECwest
Confidential and Proprietary
2.7 bug fixes
Closing all high priority bugs and 50% of medium bugs is the goal. As
in past releases, bug fixes to ode2.1 will be not only incoorporated
into V3.0, but will also be made available via sup.
o High priority Bugs (High\16 person-weeks). Fix current priority 1
and 2 problems Fix yet-to-be-submitted PTT's.
o Medium priority Bugs (Medium\? person-weeks). Fix current prior-
ity 3 problems. Fix yet-to-be-submitted PTT's.
o Low priority Bugs (Low\? person-weeks). Fix current priority 4
prob-
lems; Fix yet-to-be submitted PTT's.
2.8 build enhancements
Provide enhancements for multiplatforms builds. Tasks to enhance
build-
ing includes the following:
o provide mechanism for parallel builds across multiple platforms
(Low/
4 person-weeks)
DECode II will provide a mechanism where builds on multiple plat-
forms can be initiated from a single machine.
o provide refined build granularity using Makeconf (Low/3
person-weeks)
The Makeconf file will be modified to allow greater build granu-
larity. For example, to allow for building on two different ver-
sions of the same Operating System, without the build results from
the two interfering with each other. The export directories may
present
a problem here.
2.9 common interface
The goal is for commands to use a common interface, without
exception.
The goal will be met by the following:
o merging in OSF's ode V2.3 common interface. (High/13 person-weeks)
2.10 customer involvement
The goal is to obtain useful data in the wide spectrum from immedi-
ate current problems a user is solving to data obtaining for future
releases.
o monitor user command use (Low\3 person-weeks) Version 3.0 will in-
clude functionality to optionally log command line arguments that
are entered by the user, how the user responds to prompts, etc.
The
log will be useful for debugging problems. Since problems needing
to be logged are usually not anticipated, this function needs to
be able to be turned off or on at a granularity to catch what was
not anticipated. The granularity may be per-project.
DECode II V3.0 Development Plan 5
Digital Equipment Corporation-DECwest
Confidential and Proprietary
2.11 documentation
Work includes the following:
o 3.0 Release Notes (High\4 person-weeks)
o 3.0 Manpages (High \8 person-weeks) Manpages will be updated to
re-
flect new or modified functionality in V3.0.
o 3.0 Installation Guide (Medium \2 person-weeks)
o finish Admin Guide (Medium\8 person-weeks)
o update User's Guide (Low\8 person-weeks)
Work includes reverting guide to use "mu" macros for ease of main-
tenance. Also included updating to V3.0 functionality.
o remove references to RCS in man pages (Low\2 person-weeks)
Many DECode II users are not familiar with RCS. Thus, references
to RCS will be removed from the DECode II documentation.
2.12 flexible locking
Provide a flexible locking model to use in tracking of locking and
also
in taking out a lock.
o enhanced branch tracking of files in the RCS pool. (Medium \
person-
weeks 10)
This will provide the user with the capability of obtaining more
information about the state of a file such as who else has a lock
when the file is checked out. Using the pre and post processing,
this extra tracking could also inform other users who has the
files
checked out that another person is doing a bco, and also inform
"file
owner" that a person has done a check out.
Note: This is a prereq to providing optional exclusive locking
which
has high priority.
o provide optional exclusive lock. (High \ person-weeks 6)
DECode II administrators will have the option of permitting only
one user to have a lock on any given file at one time. Optional
ex-
clusive locking, if enabled, will apply to the whole pool, not to
any individual user.
2.13 FUSE prototype
o integrating DECode II into FUSE (investigation) (low\13
person-weeks
)
Investigate the use of FUSE and the integration of DECode II into
FUSE. This investigation included a survey on who uses or would
like
to use FUSE. This would be an investigation.
6 DECode II V3.0 Development Plan
Digital Equipment Corporation-DECwest
Confidential and Proprietary
2.14 multiple-backed sandboxes
Work involves adding functionality to easily undo backing to an sec-
ondary tree. Currently many files need to be modified, and several
di-
rectories need to be removed to undo a sub-tree manually.
o automatic undo of sub-tree (low/2 person-week)
2.15 OSF ode 2.3 merge (Medium/ person-weeks unknown)
Summer of 1993 OSF came out with a new release of ode.
o evaluate what new functionality/bug fixes are in OSF ode2.3
(Medium/3
person-weeks)
o merge in necessary functionality/bug fixes (Depending on changes
range from Low to High/unknown person-weeks)
2.16 parallel Development
o analyze alpha tweaking method (low/no-need at writing)
Currently the "alpha tweaking method" is exactly that outlined in
the admin section of the "Using ODE" overheads. We don't need to
analyze this. If the method should change, we would want to under-
stand where DECode II's weakness's are in the "tweaking". By un-
derstanding the weakness's, we can determine what future features
we could provide for DEC/OSF1.
o provide method submit to multiple trees (Medium/4 person-weeks)
Provide a mechanism by which uses can submit to multiple trees.
De-
sign includes addressing the feasibility of submitting to both
trees
at the same time as well as an indefinite delay between the two.
2.17 remove/replace files
Allowing users to remove and replace their own files is the goal.
Cur-
rently release engineering has to undefunct a file. Also currently
re-
lease engineering has to revert a file that is no longer desirable in
a shared sandbox.
Tasks to provide easy removal/replacement of files includes the fol-
lowing:
o undefunct tool (High\3 person-weeks)
Provide mechanism for a user to undefunct a submit branch, Work
would
include putting file back into submit tree, and updating the DE-
FUNCT file and SNAPSHOT file.
o revert tool (High\3 person-weeks)
Provide a revert option for a shared sandbox so that an user can
remove a file out of a shared sandbox to revert to the version
from
the backing tree. Work includes removing file from SNAPSHOT file
and replacing file with a link if have information that it'sd a
linked
src tree.
DECode II V3.0 Development Plan 7
Digital Equipment Corporation-DECwest
Confidential and Proprietary
o defuncting replaces file with zero-length file - optional (Low\2
person-weeks)
When a file is checked in with -defunct (and without reverting,
and
then submitted to a shared sandbox, the file in the user sandbox
will be replaced by an empty file. The file in the shared sandbox
will be removed. This will then cause build errors if dependencies
are incorrect. The file will be 0 filled only in the user's pri-
vate sandbox and not in the shared sandbox.
2.18 sandboxes
"workon without the pain" is the goal.
To accomplish the task of improving the use of sandboxes, the follow-
ing work items are planned.
o make build_list work for mksb (high\2 person-weeks)
mksb will be modified to use the contents of the build_list file
under all circumstances. (Note: maybe fixed already)
o allow resb an "orphaned" sandbox (Medium/2 person-weeks )
Make resb work for a sandbox which cannot be "worked on" anymore,
i.e. a "-force" option which just removes the link and makes a new
link, and then does a regular resb.
o allow mksb create a "custom" file as default (Medium/2
person-weeks)
mksb should create a "custom" file which includes ./local, just
like
mksharedsb, so users have an obvious place to put their customiza-
tions which are immune from resb. It could perhaps have a comment
about putting your customizations here.
o make mksb independent of default sandbox (High\1 person-week)
mksb will no longer require information from the default sandbox,
for the situations where the default sandbox does not exist or is
inaccessible. (Note: people bump into this problem every day)
o change sandbox by cd'ing (Low\4 person-weeks) Users will b Chile
to change sandboxes by moving from one directory to another.
Note: This could cause inadvertent errors. If a user cd's to an-
other directory which causes ODE to switch context to another
sand-
box, should output an information message to the user.
o add intelligence to build_list (defunct trees) (Medium\4 person-
weeks)
The build_list file and the tools that manipulate it will be mod-
ified so that defunct trees can be recognized, along with a
pointer
to the replacement tree.
o cache what files in sets are locked/unlocked (Medium\3
person-weeks)
Currently a user needs to to a blog -all on files in his set to
de-
termine if others have the file checked out as well, or if since
he has checked out the file, another person has checked it out
later.
In order for a user to quickly determine the state of a file
(checked
out, checked in, submitted), information about the state of each
file will be cached.
8 DECode II V3.0 Development Plan
Digital Equipment Corporation-DECwest
Confidential and Proprietary
o create sup collections automatically (optional) (Medium\2 person-
weeks) For users that need shadow sandboxes for themselves and
other
sites, mksb and mksharedsb wilut/l be modified to create a sup
col-
lection to propagate themselves.
o remove -nosh (low\2 person-weeks)
The mksb command will no longer use the workon command, which is
the only reason for the -nosh switch. The switch will be removed
from workon and the documentation.
2.19 scripts
All DECode II scripts will be modified to accept arguments in any or-
der.
o Script arguments taken in any order (Medium\3 person-weeks)
2.20 track correlations
Users need to track the relationships between source files and the
files
they kit. Users need to track the relationships between where a file
currently is and where is was moved from in the past. Release engi-
neering needs to track relationships between kerberos names and users
names.
o transfer autodependency capability to zk3 (high/(depends on able
to take - ? person-weeks)
o ship CEMENT prototype (13 person-weeks).
CEMENT is a change management tracking tool. It maintains infor-
mation about the relationships between changed files and : change
requests for bug fixes or enhancements released software files
files
in development versions of software
Work here includes finishing correlation between released files
and
their location on the kit. Time is also calculated to work with
DEC/OSF1
in installing CEMENT at zk3 and getting the first set of dependen-
cies loaded into CEMENT.
o track moving files (investigation) (Medium/? person-weeks).
As a part of a life of a pool, directories are moved and files are
moved in the RCS pool. A model is needed to track these moved
files
and who the correlations between 3rd party sources and also older
baselevels that are out of synch with the RCS pool. The investi-
gation will include understanding further the need and also inves-
tigating how the need could be provided through CEMENT.
o map between kerberos names and users name (Low/4 weeks)
This would be provided in CEMENT.
DECode II V3.0 Development Plan 9
Digital Equipment Corporation-DECwest
Confidential and Proprietary
2.21 video for training
o Update the Training Video.
2.22 closing Release
To close a release the baselevel is created, integration testing is
done, the kit created and soaked, and the final kits mailed out.
o Integration Test (High\4 person-weeks)
o Release Engineering (High\2 person-weeks)
10 DECode II V3.0 Development Plan
% Received: by us2rmc.bb.dec.com; id AA24096; Wed, 10 Nov 93 18:47:49 -0500
from DECnet-Mail11.flambe.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/01Nov93-1038AM) id AA27217; Wed, 10 Nov 1993 18:49:01 -050
% Date: Wed, 10 Nov 1993 18:49:01 -0500
% Message-Id: <[email protected]>
% From: [email protected] (Tina (Salley is decwet::salley, Brian is quarry::anderson, Mark is decwet::mark))
% To: flambe::odehelp
% Subject: most recent ode project plan
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|