RE: Splitting off core: where we stand

# Stand up and applaud vigourously #

I agree with everything that Eric has written below.  He expressed it very
eloquently.

The goal is not to get through the IESG process and get an RFC number as
quickly as possible, rather it is to get a stable basis for interoperable
implementations.  The Proposed Standard track is the psychological
milestone for authors, reviewers, and implementers to raise the maturity
level of the spec.  I believe that we meet the criteria for doing so.

As I've said before, I believe that the document is well presented, and
that developers capable of implementing to it will not be confused by which
sections they must understand to implement the functionality they require.

Tim

-----------------------------------
Eric wrote:

I think the reason that the working group is so divided on this is
that we all have our own reasons for supporting DeltaV.  Frankly,
the fact that we have a standard document in the first place is
completely amazing, given the major differences in versioning models
in use right now.  The way the spec deals with change set vs. branching,
client vs. server workspaces, document management and source code
configuration management issues, and resolves the tradeoffs, is a
major accomplishment.

To me, splitting the document upsets the delicate balance that has
been developed by Geoff Clemm & Jim Amsden over the past few years,
and the reason for the proposed split is procedural, not technical.

Splitting the document would require enough rework to probably delay
submission by a month, as we remove all of the forward references from
Core into the option stuff, and then go through a round of nitpicking
on errors in that process.

While it is clear that Larry & others are right, that Core would go
through the standards process faster alone, it is also clear that
the options would go through much slower.  So, the time benefit of
splitting depends on the relative value assigned to the MOST important
option for each implementor, vs. the value assigned to Core.  Naturally
the people who only plan to implement Core are in favor of splitting,
since they assign a very small (if not zero) value to the options.
Plus, the cost of splitting the document must be added to the time
cost/benefit of the split standard.

Successful standards are all about the implementations (and how
interoperable they are), not the IESG.  If we have a bunch of people
out there doing implementations, with a spec that is stable, that
achieve interoperability, that is the important part.  If the content
of the spec is basically done, isn't it better to have the people on
this working group focusing more on implementation of the spec than
on rehashing its format for another month?

Finally, to Lisa's point, I don't see how splitting
the document helps people who just want to implement Core.  I actually
think it hurts them, because they will want to interoperate with
people implementing many of the options, and if they have no clue as
to where those folks are coming from, they will have a harder time
debugging interoperability problems.  It's like trying to implement
a mail server and only understanding RFC822, without having any clue
as to what MIME is.  Yeah you can do it, but you aren't going to get
much interoperability.

Received on Thursday, 8 February 2001 05:05:44 UTC