[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 |
369.0. "priority of zk s new ODE 3.0 Work Items" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Wed Oct 06 1993 17:53
Date Of Receipt: 6-OCT-1993 16:20:11.13
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 06-Oct-1993 1620"
To: decwet::snow, decwet::anderson
CC: decwet::ode, d_angel@wasted:zko.dec, meyer@wasted:zko.dec,
tresvik@wasted:zko.dec, reng@wasted:zko.dec, hantman@wasted:zko.dec,
demers@wasted:zko.dec, ring@wasted:zko.dec, jproj@wasted:zko.dec,
grass@wasted:zko.dec, odehelp@wasted:zko.dec
Subj: priority of zk's new ODE 3.0 Work Items
Tina & I just got off the phone going over priorities of the extra
work items which ZK came up with. Here is my record of that, with the
priorities we discussed marked as follows:
>MED> ...
------- Forwarded Message
Return-Path: jmf
Delivery-Date: Fri, 10 Sep 93 20:19:18 -0400
Return-Path: jmf
Received: by flambe.zk3.dec.com; id AA22245; Fri, 10 Sep 1993 20:19:14 -0400
Received: by wasted.zk3.dec.com; id AA05584; Fri, 10 Sep 1993 20:17:26 -0400
Received: by longbow.zk3.dec.com; id AA12285; Fri, 10 Sep 1993 20:17:26 -0400
Message-Id: <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], d_angel, meyer, tresvik, reng, hantman, demers,
ring, jproj, grass, odehelp
Subject: zk review of "DECode-II Version 3.0 Work Items"
Date: Fri, 10 Sep 93 20:17:25 -0400
From: "Joshua Friedman, OSF/UNIX SDE 381-1548" <jmf>
X-Mts: smtp
Dave (ODE Eng. Manager) & Tina (ODE V3.0 Project Leader),
This review of the document "DECode-II Version 3.0 Work Items"
represents the combined review input of the ZK3 release engineering,
project management, and documentation groups.
The original work items list as provided by you is presented in its
original form with ">" markers, and any comments we had are included
after each section. Additional items have been added at the end.
Thank you very much... --josh
> DECode II Version 3.0
> Work Items
>
> Change history
> --------------
>
> 5/19/93 MT Initial version for review by DECode II development
> group.
>
> 6/16/93 MT To DEC OSF/1 team for review.
>
> Notes for Reviewers
> -------------------
>
> The work estimates in this plan are rough estimates.
> The actual scheduling will be done using estimates
> agreed upon with the responsible engineer(s).
>
> The work items are listed in decreasing order of
> priority. Your comments on the priorities of these work
> items are welcomed. Those comments, along with the
> dates on which the DEC OSF/1 team will be ready to
> accept new revisions, will be used to determine the
> actual project schedule. In order to meet the DEC OSF/1
> team's date requirements, some of the work items toward
> the bottom of the priority list (except the items that
> are associated with each release of the project) may be
> removed or postponed until a future release.
>
>
> Introduction
> ------------
>
> This document details the work items for release 3.0 of
> DECode II. Each item has a label of the form "3.0-nnn"
> where nnn is a three-digit numeric with leading zeroes.
> The schedule will have corresponding entries with the
> same task numbers. Additionally, the schedule will also
> have tasks of the form "ODE-nnnnn" where nnnnn is a
> five-digit numeric with leading zeroes. These are
> scheduled PTT (Problem Tracking Tool) fixes,
> corresponding to the PTT number. The strings "3.0-nnn",
> "ODE-nnnnn", and "admin" will be used as the defect
> numbers for submissions.
>
> The work items for version 3.0 were derived from the
> results of a Contextual Inquiry (CI) performed in
> February 1993 and the subsequent Quality Function
> Deployment (QFD) process, and requests for
> functionality from the DEC OSF/1 team.
>
> In each CI session, an interviewer and a note-taker
> observed a user as he/she performed everyday
> operations, in his/her own environment, using the tool
> which was the subject of the CI (in this case DECode II
> version 1.5). After the CI was completed, the
> interviewer and note-taker produced a list of
> customers' needs, based on observations during the CI.
>
> The QFD involved all members of the development group.
> The customers' needs were grouped, using a technique
> called Affinity Diagramming. From this, a list of
> features was derived, with each feature meeting at
> least one of the customers' needs. The customers' needs
> were weighted, using input from the users and the
> developers, and then the final portion of the QFD
> determined the relative priority of each feature, based
> on the weighted importance of all the customers' needs
> that it would solve.
When is this work planned to be done? There is some concern about
disruption to Gold if this update comes near the end of the Gold
development timeframe.
> Work Items
> ----------
>
> Work items are listed in order of priority. The
> priorities were determined in part by the results of
> the QFD, and in part from an overall review of the
> items, to make sure that items believed to be of high
> priority were not overlooked in the QFD results.
>
> 3.0-037 PTT fixes (16 person-weeks)
> Fixes for yet-to-be-submitted PTTs.
- - This "highest priority" item should only refer to PTT reports of
high priority (1 and 2); a reference to other PTT reports of lower
priorities should be lower on the list.
- - Is there any cut off date for when PTT reports will be reflected in
ODE V3 relative to the intended ship time?
> 3.0-038 Integration Test (4 person-weeks)
> Integration test after code freeze.
- - What about regression testing?
> 3.0-039 Release Notes (4 person-weeks.)
>
> 3.0-040 Release Engineering (2 person-weeks)
>
> 3.0-001 Post-processing support in bcreate, bco, bci, and bsubmit
> (13 person-weeks)
> This will allow pool managers and individual users
> to automate certain actions that are currently
> performed manually. For example, mailing of the
> hh:mm.Tlog file at the end of a bsubmit. Post-
> processing actions on the client will be tailorable
> by the individual user, those on the server by the
> administrator. This will permit interface with a
> project-wide submit review process.
- - This is very non-specific as it appears here - more information?
- - This should be a much lower priority, certainly lower than much of the
bmerge related work.
- - For example, the automated mailling of the bsubmit log is very low on
our list because from day 1 we had a solution to this through crontab.
> 3.0-002 Rework bsubmit merge (2 person-weeks)
> The merge feature within bsubmit will be improved in
> the following ways :
> co/rco and diff/rdiff menu options will be more meaningful
> diff markers will be more meaningful
> add option to not submit a file which has merge overlaps
- - Other things we feel are important related to this:
>HI> . bco -j bugs (in the ptt system)
>MED-HI>. make bco -j handle headers separately like bmerge, or roll
bco -j functionality into bmerge.
>MED> . rcs keyword ptt report
>HI> . ability for 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.
> 3.0-003 Flexible configurable merge tool (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), during a bsubmit.
- - Will this be accessible from bdiff, and all the other times diff is
called during bci, bmerge, and bsubmit?
- - Will there be a user-settable DIFF variable of some sort to allow any
diff tool?
- - A 3-way visual diff of some sort would be very valuable to look at
diffs from a common ancestor.
> 3.0-004 Change bmerge to conform to bsubmit changes
> (4 person-weeks)
> Changes to the merge feature within bsubmit will be
> shadowed in bmerge.
>
> 3.0-005 Turn off merging in bsubmit (1 person-week)
> This will be an option to bsubmit. When enabled, and
> if 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.
- - What about the "atomicity" of the submit - it's not always desirable
to get in part of a submit and leave part for another time.
- - Will the bsubmit.hold file be modified in the case that part of the
submit is left for later to only include the remaining files?
> 3.0-006 Pre-processing support in bcreate, bco, bci,
> and bsubmit (13 person-weeks)
> This will allow pool managers and individual users
> to automate certain actions that are currently
> performed manually. For example, checking that the
> user is allowed to submit files with a certain
> defect number on a bsubmit.
- - This is somewhat vague - please supply more details.
- - We "hope" this includes call-out points during the commands in which
local functions can be called to perform local operations and return
status which would control whether or not the function continues.
This would eliminate the need we have for the "bsubmit wrapper".
- - Some examples are as follows:
. 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
presented for the user how to get added to the acl list.
. inform the user who else has a lock when file is bco'd
. inform other users who have the file checked out of the bco
. inform "file owner" (taken from some admin list) that the person
has done a check out
> 3.0-007 -local switch for bci -defunct (3 person-
> weeks)
> This new switch for bci would indicate to bsubmit
> that the file is to be defuncted only in the shared
> sandbox immediately backing the sandbox. The file
> will be removed, the shared sandbox set label will
> be removed from it, and the end of the branch will
> be set to state "Defunct".
- - Is the intent of this like the "revert" operation we've asked about,
indicating a shared sb no longer needs a special copy, and to
revert to the version from the backing tree? If so, additional
operations would include: removing file from SNAPSHOT file,
removing file from DEFUNCT file, and replacing file with link if
it's a linked src tree.
> 3.0-008 Optional exclusive lock (6 person-weeks)
> DECode II administrators will have the option of
> permitting only one user to have a lock on any given
> file at one time. Optional exclusive locking, if
> enabled, will apply to the whole pool, not to any
> individual user.
- - Is this on a pool/project basis, or possibly on a file by file
basis? Both would be useful. The "whole pool" single-user-lock
should be easy to turn on (i.e. not requiring a list of all
files). This is needed for some projects like the doc pools.
> 3.0-009 Ship CEMENT (13 person-weeks)
> CEMENT is a change management tracking tool. It
> maintains information about the relationships
> between changed files and :
> change requests for bug fixes or enhancements
> released software files
> files in development versions of software
- - We need more detailed information on this. Is it in the advanced
development category? It is a very large block of time, and,
depending on what benefit it will provide us, it seems it is
potentially listed at a higher priority than items which we
consider much more important.
> 3.0-010 Update videotape (3 person-weeks)
> The DECode II training videotape will be updated as
> necessary to reflect version 3.0.
- - This should be a much lower priority.
> 3.0-011 Compatibility with automount (3 person-weeks)
> We will investigate the use of automount as a
> complement to or replacement of the odemount
> command, and solicit comments on the odemount
> command. Use of automount will reduce the load on
> system administrators, especially when multiple
> levels of nested shared sandboxes are in use in a
> project. This work item may generate additional work
> items not yet in this plan.
- - This should be a lower priority. We don't think there's a problem
here. 3 weeks sounds like alot.
- - Make sure this is an optional addition to the environment, i.e.
Do not scrap "odemount".
- - Please contact Jim McGinness, [email protected], for work he has done
to automatically update automount maps from the ode_fstab file.
> 3.0-012 Prevent checkin of file with merge overlap
> markers (2 person-weeks)
> A check will be added to both bci and bsubmit, to
> prevent checkin of a file whose comment leader is
> not BIN and which contains merge overlap markers. A
> mechanism will be provided to allow an over-ride for
> files that legitimately contain such markers.
- - Great! This should be a MUCH HIGHER priority, however.
- - This check should also apply to BIN files which are ascii files
(there's a ptt report in related to allowing bmerge/bdiff for
BIN files which are really ascii text "nolog" files.)
> 3.0-013 -undefunct switch (3 person-weeks)
> This switch will allow an individual user to
> undefunct a file defuncted by the user. This will
> apply to files defuncted on the user's branch, and
> files submitted as defunct.
- - Any user should be able to undefunct, via a submit, a file submitted
defunct by another user, not just the same user. (Submit approval
is assumed and a project function, not a tool function.)
- - Be sure to also handle removing the entry from the DEFUNCT file when
it is added to the SNAPSHOT file.
> 3.0-014 Mechanism for parallel builds across multiple
> platforms (4 person-weeks)
> DECode II will provide a mechanism where builds on
> multiple platforms can be initiated from a single
> machine.
- - This should be much lower priority. It's a fairly good time chunk, and,
frankly, we don't care about this functionality at all. Currently
we only support one architecture, and when we supported more than
one it was no big deal to kick of builds on multiple machines.
> 3.0-015 Non-atomic bsubmit command option (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
> submission 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 some projects this may be useful, but, for the osf/1 project, the
atomicity of submits is very important. Having not atomic submits
can be a problem if two submittors overlap files, and each get part
of their submit in. There may be a merge "deadlock" and both sets
of functionality may be broken in the build. We're concerned more
individual submittors which problems will break the build rather
than just delaying their functionality.
- - Is there a performance implication here (slower or faster submit?)
- - Make this lower priority
> 3.0-016 Enhanced branch tracking of files in RCS pool
> (10 person-weeks)
> This will provide the user with the capability of
> obtaining more information about the state of a file
> (who has it locked on what branches, etc.).
- - What exactly is planned here? It's a nebulous description and a
large block of time.
- - See these other related ideas also listed after 3.0-006:
. inform the user who else has a lock when file is bco'd
. inform other users who have the file checked out of the bco
. inform "file owner" (taken from some admin list) that the person
has done a check out
> 3.0-017 Add intelligence to build_list (defunct
> trees) (4 person-weeks)
> The build_list file and the tools that manipulate it
> will be modified so that defunct trees can be
> recognized, along with a pointer to the replacement
> tree.
- - Make this lower priority
- - Will this make the "check_out_config" section of the build_list entry
functional?
> 3.0-018 Project optional relink/copy of file on
> bsubmit (4 person-weeks)
> On a project-wide basis, it will be possible to have
> bsubmit restore the link or copy (with updated
> contents) of the submitted file that was present
> before the bco of that file. This will be useful for
> pools that rely on copies or links in order to build
> in a sandbox.
- - This can be done now by having the user put the "-local_co backing"
switch in their .sandboxrc bsubmit customization (according to the
documentation.) 4 weeks sounds like a lot a time to provide
existing functionality.
- - Make this a very low priority
> 3.0-019 Flexible type of authentication (3 person-
> weeks)
> Different levels of authentication will be
> supported, configurable on a per-pool basis. They
> are :
> No authentication
> Simple authentication (node & user name)
> Principal authentication (via Kerberos)
- - Who is the target audience for this functionality?
- - Is there any way now to "fake out" the authentication by dummying
the kxct.conf files?
> 3.0-020 FUSE prototype (13 person-weeks)
> DECode II will be incorporated into FUSE as a
> prototype, to investigate putting a Graphical User
> Interface on DECode II.
- - Who is the target audience for this functionality? We'd be very
interested in the outcome of a USG-wide survey on who uses or would
like to use FUSE, and the perceived value of integration with ODE.
- - This does not sound like ODE V3 functionality per se but the
beginning of an advanced development prototype project, independent
of active osf/1 development needs.
- - Do you know FUSE is working with integrating Atria's ClearCase?
- - This should be a much lower priority, since the implication is that
anything lower than an investigation item is expendable.
> 3.0-021 Analyze alpha tweaking method (1 person-
> week.)
> We will analyze the method currently used to tweak
> pools, and determine what features could be provided
> by DECode II. This work item may generate other work
> items not accounted for in this plan.
- - The "alpha tweaking method" we use is exactly that outlined in
the admin section of the "Using ODE" overheads.
> 3.0-022 Cache what files in sets are locked/unlocked
> (3 person-weeks)
> 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.
- - Does this relate to the "owner" and "notify" items we listed
following 3.0-006 and 3.0-016?
> 3.0-023 Sup collections optionally created by
> mksb/mksharedsb (2 person-weeks)
> For users that need shadow sandboxes for themselves
> and other sites, mksb and mksharedsb will be
> modified to create a sup collection to propagate
> themselves.
>
> 3.0-024 Scripts take arguments in any order (3
> person-weeks)
> All DECode II scripts will be modified to accept
> arguments in any order.
>
> 3.0-025 Defuncting replaces file with zero-length
> file (2 person-weeks)
> When a file is checked in with -defunct (and without
> -local), and then submitted to a shared sandbox, the
> file in the user sandbox will be replaced by an
> empty file. This will then cause build errors if
> dependencies are incorrect.
- - This is useful in the user's sandbox after the bci, but we don't
think it should be done in the submit tree (which will accumlate
old garbage and have misleading file lists.)
- - If this is done is should be an option for each project to choose in
the rc_files.
> 3.0-026 Undo a sub-tree (3 person-weeks)
> This will allow easy undoing of a sub-tree created
> by mksb in an existing sandbox.
- - What is this? Low priority
> 3.0-027 Make mksb independent of default sandbox (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.
- - Good! Make this a MUCH higher priority. People bump into and
complain about this every day. Often a user's default sandbox
is the first one they created a year ago and is no longer valid.
> 3.0-028 Make build_list work for mksb (2 person-
> weeks)
> mksb will be modified to use the contents of the
> build_list file under all circumstances.
- - It appeared that this was fixed already (with respect to the
directory lookup)
> 3.0-029 Monitor user command use (3 person-weeks)
> Version 3.0 will include functionality to optionally
> log command line arguments are entered by the user,
> how the user responds to prompts, etc. The log will
> be useful for debugging problems.
- - This needs to be mandatory (on a per-project basis perhaps) if it is
to be useful. I.e. if the user needs to decide to log a command
before running it, s/he might as well just use "script." When
problems which you'd want to be logged are encountered, they are
never anticipated.
> 3.0-030 Remove references to RCS in man pages (2
> person-weeks)
> Since many DECode II users are not familiar with
> RCS, references to RCS will be removed from the
> DECode II documentation. Note - this depends on
> availability of a writer. Currently we do not have a
> writer assigned to this group.
>
> 3.0-031 Provide method submit to multiple trees (4
> person-weeks)
> DECode II version 3.0 will provide a mechanism by
> which users can submit to multiple trees.
- - It would be useful if this supported both submits at the same time as
well as an indefinite delay between the two.
- - This is related to item 3.0-021
> 3.0-032 Remove -nosh (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.
>
> 3.0-033 Refined build granularity using Makeconf (3
> person-weeks)
> The Makeconf file will be modified to allow greater
> build granularity. For example, to allow for
> building on two different versions of the same
> Operating System, without the build results from the
> two interfering with each other. The export
> directories may present a problem here.
>
> 3.0-034 Change sandboxes by cd'ing (3 person-weeks)
> Users will be able to change sandboxes by moving
> from one directory to another.
- - We need more inforamation on this. It could cause inadvertent errors.
- - If a user cd's to another directory which causes ODE to switch context
to another sandbox, it should output an information message to the user.
> 3.0-035 Documentation (16 person-weeks)
> Update User's Guide and reference pages to match 3.0
> functionality. Revert to "MU" macros for ease of
> maintenance. Note - this depends on availability of
> a writer. Currently we do not have a writer assigned
> to this group.
- - Please make a distinction between the release notes, reference pages,
the user documentation, and the administration documentation.
- - At least the release notes and reference pages need to be a MUCH
higher priority. The fact that there's no current writer assigned
is not a reason for this to be a low priority.
- - If no writer is available, engineers can be used, again, at least
for the release notes and reference pages, both of which should be
available in both ascii and bookreader.
> 3.0-036 Merge in OSF's latest interface (13 person-
> weeks)
> In order to remain in synch with the Open Software
> Foundation, the latest version of their ODE sources
> will be merged into the DECode II source pool.
- - Does this refer to just internals, or user interface as well?
Any changes to user interface should be described in detail.
- - This integration has a potential of having major impact, and if
it is to be done, it should not have such a low priority.
- - !!Careful not to lose previously fixed bugs, as has happened in the
past when new osf versions of ode have been incorporated!!
>
>
> Architectures Supported
> -----------------------
>
> In versions greater than 2.0, DECode II provides
> three levels of platform support :
> - Build support - only enough DECode II tools to
> enable building of a product. No source control or
> sandbox making features will be provided.
> - Client support - enough support to run as a DECode II
> client. This level is a super-set of build support.
> - Server support - full DECode II support. This
> level is a super-set of client support.
>
> DECode II version 3.0 will support the following
> platforms at the specified levels :
> Hardware OS Level
> -------- -- -----
>
> AXP DEC OSF/1 Server/Client/Build
- - Please continue to check and ensure binary compatibility between
1.2, 1.3, 2.0, 3.0, etc. Having non-shared images would help.
> MIPS ULTRIX Server/Client/Build
> Sun4 SunOs Build
> VAX ULTRIX None 1
- - This needs to at least continue to be supported as a client and
maybe for build; we still have quite a few production machines in
zk which are vaxen and which are used by developers for
bco/bci/bsubmit. The doc group does builds on vax machines, in
addition to the other platforms.
> MIPS DEC OSF/1 None 2
- - Please do a survey on the need for MIPS client & build support.
> 1 Support withdrawn due to this architecture's reduced use.
>
> 2 Support withdrawn due to lack of support of this Hardware by
> the Operating System.
>
- --------------------------------
Additional Items Not in the Plan
- --------------------------------
>HI> expiration feature
>LOW> mapping feature
o Tools to help manage kerberos database (eg. reports of who will
expire when, mapping between kerberos account and mail address) and acl
lists (though we've got acl support pretty well covered)
>MED>
o 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.
>MED>
o mksb should create a "custom" file which includes ./local, just like
mksharedsb, so users have an obvious place to put their
customizations which are immune from resb. It could perhaps have a
comment about putting your customizations here.
>MED-LO> (investigation)
o Make ODE able to track files which have moved or been renamed.
>ZERO if merge easy/complete; MED otherwise>
o Allow user to automatically override merge during bsubmit.
Sometimes users know they've merged files independent of the bmerge
facility, 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.
>HIGH> (osf's done this)
o Commands should use common interface, without exception. Currently
there are many inconsistencies (eg. bci/bsubmit using -m""/-m "",
eg. some commands using -r for rev, others putting rev next to -p
or -u or -o without using the -r.)
>HIGH>
o The -defunct switch should require and use user comments, and not
automatically fill in "file is defunct"
>LO-MED>
o bcreate -undo should remove the ,v file in the rcs tree, and remove
any empty directories.
>LO-MED> (investigation)
o Tracking of sandboxes - it would be real useful if mksb and resb
could track in a central place who has trees backed to what, for
purposes of informing users of changes and availability.
======================================================================
------- End of Forwarded Message
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|