[116] in Open-Software-Foundation-News
Role of DCE SIG; Next DCE SIG Meeting
daemon@ATHENA.MIT.EDU (Peter_Oleinick@transarc.com)
Tue Jan 31 14:30:29 1995
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.LOCAL
Date: Tue, 31 Jan 1995 08:27:42 -0500 (EST)
From: Peter_Oleinick@transarc.com
To: sig-dce@osf.org
Cc: sww@ch.hp.com
Dear DCE SIG community,
--------------------------
1. Role of the DCE SIG
-------------------------
This last couple of weeks, I've discussed the future role of the DCE SIG with
Scott Wang of HP, the chair of the DCE PSC. Our discussion centered on the
``open-ness issue.'' We both concluded that despite all of the talk and
reassurance voiced about continuing to want input and feedback on shaping
the future contents of the DCE it is still not being perceived as open
a process as it once was. There is a lot of discomfort about this in the
DCE community.
We therefore propose that to really put this issue to rest
requires giving the DCE SIG a formalized role in the process of specifying
DCE requirements and release contents for future releases of the DCE.
The discussion that followed explored how best to do this. Comments and
ideas are welcomed, but as a strawman --- here goes:
Keep in mind that the PSC
would like to move towards a regular release schedule model for upcoming
releases (beyond 1.2) for DCE continuity as well as simplified planning.
In addition, there will likely be two different kinds of releases in
the future: a secure core release, and releases from other PSTs
for non-core additions/features. Once a year there might be a secure
core release and then in between there
might be a release of non-secure core software that works on top of
the current core. This pre-supposes that PSTs could be formed if there is
sufficient interest and funding from those interested in making the non-core
features become widely available. With the ``train model'' of regular
releases, software releases are mostly schedule-driven and if a particular
feature doesn't make this train, it will make the next one.
NOTE: The above paragraph is an oversimplification of and perhaps a bit
premature since not all of the ideas are even well formulated let alone
accepted practice. Scott promises to update us at the next DCE SIG meeting.
However, assuming that something like above is going to happen, a dual
release approach and a regular schedule of planned releases makes it
easier to schedule DCE SIG reviews and requirements proposals so
that they can have a more direct effect on release contents.
The overall schedule needs to be worked out but the idea is something like
the following procedure:
(1) The "Release Content Proposal" is written by the PSC and presented
at a DCE SIG meeting.
(2) It is reviewed by the SIG
(3) Formal response is made by the SIG to the PSC
(review of planned content, prioritizing
other requirements, survey results, suggested PSTs, etc.)
(4) Review of SIG's recommendations by PSC and TPC.
(5) Response from PSC to SIG's recommendations presented at DCE SIG
meeting and subsequent discussions.
NOTE: The process of reviewing and negotiating the release contents proposal
doesn't eliminate the need for detailed working group requirements
specifications to be created. That work will still be essential for planning
the future direction of the DCE. The above review and response process is
meant to more formally address content specification for particular releases.
At the next DCE SIG meeting Scott has agreed to:
1) provide a more detailed description of the Release Content Review
Process described above.
2) present (and hand out) to the DCE SIG the Release 1.3
Content Proposal for the secure core release for SIG
review and comment.
I invite comments and discussion about the above either publicly using sig-dce
or privately to me at pno@transarc.com.
---------------------------
2. About the next meeting
---------------------------
I've looked closely at the upcoming DCI-sponsored DCE Developers conference and
spoken with the people running the conference about our holding the DCE SIG
meeting in conjunction with the conference. The DCE Developers conference
main days are Tues, Weds, Thurs, April 11-13. Monday is for all-day seminars.
Here is what I've determined so far:
1) I like the idea of the SIG meeting being held the same week as the
DCE Developers Conference but don't want it to compete with the
conference, i.e., remember they get paid by conference attendance.
2) If we can conduct the entire (normally two-day) DCE SIG meeting on Monday
they will:
1) find us the rooms we need at the hotel at no charge.
They have 1 large room that can be split into 2 smaller
rooms and 1 additional room making a total of 3 parallel
sessions possible.
2) give all DCE SIG members a $200 discount towards the
purchase of DCI DCE Developers Conference attendance.
3) help promote the DCE SIG meeting -- if we want them to.
3) How can we have the SIG meeting in 1 day?
a) reduce the plenary sessions from 3.5 hrs to 1.5 hr.
< little need for the informational only part of the AM
given the conference covers a lot of this .>
b) have three sets of 90 mins. meetings:
< I observed that most of the 3 hr meetings finish early >
Proposed Agenda:
April 10, 1995 San Jose California (Red Lion Hotel)
8:00 - 8:30 continental breakfast
8:30 -10:00 plenary session
10:00 -10:30 break
10:30 -12:00 Parallel Sessions #1
12:00 - 1:30 lunch
1:30 - 3:00 Parallel Sessions #2
3:00 - 3:30 break
3:30 - 5:00 Parallel Sessions #3
5:00 - 5:30 Wrap Up discussion
4) The main agenda topic for the working group meetings should be requirements
setting for future releases -- in particular the new more formal
process for SIG involvement in release planning, and requiremen
ts
review and discussion. Thus, with the more narrow focus I believe
we can squeeze this meeting into 1 day.
Again, I invite comments, discussion, and suggestions either publicly or
privately.
Regards,
Peter Oleinick
DCE/MAN SIG Chair
412.338.4368
Michael Colby, Chris Erb.
offer a $200 discount on sig
Please advise. Don't be shy,
Peter Oleinick
DCE/MAN SIG Chair
412.338.4368
