RE: Splitting off core: where we stand

Lisa,

  I don't know what makes you think we're doing source code control.
We're focusing on web content management.  I think source code control
is already done pretty well by other vendors.

  I also don't see how the categorization is that helpful.  First of
all, it is clear from the mailing list that the correct category is #2
(core & options both useful).  Some people just want to implement Core.
However, a large group of people (probably somewhat more than half),
will implement at least one option.  I also don't see how the conclusion
for your category #2, "we should be able to publish core but since there's
significant demand for the options they ought to be standardized
relatively quickly" follows.  You are just asserting that if 
core & options are both useful, they should be split, without stating
a reason for this conclusion.

  There are many valid reasons that a separate DeltaV options standard
would proceed more slowly down the standards track other than lack of
interest.  First of all, now there will be a second spec for options
reviewers to examine, which will replicate much of the same introductory
informationin the options spec.  Second, there will be a loss of context
caused by removing forward references from Core to the options.  Two-way
links are generally more useful than one-way links.  Third, there is the
cost that both of the split documents would pay while we are waiting for
the splitting.  I could go on...

  As far as the politics of this goes, the issue is not "pork-barreling"
the IESG, but in fracturing the consensus of the working group.  If you
peel off the support of those folks interested only in Core from the
options stuff, and make the folks who think that Core is useless by itself
unhappy because the stuff that they care about got throw out of the "fast
track" spec, I think everyone interested in DeltaV will lose.

--Eric

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Thursday, February 08, 2001 10:11 AM
> To: Greg Stein; ietf-dav-versioning@w3.org
> Subject: RE: Splitting off core: where we stand
> 
> 
> > Subversion: bunch o' options
> > Oracle: requires workspaces and baselines
> > Rational: nothing stated publicly :-), but they're doing a
> > bunch of options
> > Xythos: core
> >
> > So... there is certainly support for saying that core by
> > itself is pretty useless and not the focus of most
> > implementors. And if that is the case, then why bother to
> > break it out (with the hope that it gets standardized
> > sooner rather than later).
> 
> Greg, I think your data supports my point.  Xythos is the only WebDAV
> server that is not doing source code control, that is planning to
> implement any part of DeltaV.  I think I'm the only person designing a
> versioning server that isn't for source control, that has bothered to
> read the entire spec, but then I'm used to daunting technical documents.
> 
> Let's take a step back. Originally we had a single document without any
> distinction between core and options. In response to complaints that it
> was too complicated, and massive overkill for simple scenarios, we
> labelled some of the material core and the rest options. Now, there are
> essentially four situations:
> 
> (1) Core useful, options useless.
> (2) Core useful alone, options useful.
> (3) Core useless, core + options useful.
> (4) All of DeltaV useless.
> 
> In case (1) our best move is to simply throw away the options and
> publish core.
> In case (2) we should be able to publish core but since there's
> significant demand for the options they ought to be standardized
> relatively quickly.
> In case (3) we should throw away the distinction between core and
> options and publish one monolithic document.
> In case (4) we should all go home.
> 
> Keeping core separate but in the same document is a half-measure that in
> my view serves no real purpose. I'm particularly unimpressed by the
> argument that standardizing core alone will hold up standardization of
> the options. If the options aren't interesting enough to stand on their
> own then we should throw them away, not glue them to core so that the
> IESG has to take all-or-nothing. We're trying to design a broadly
> implementable technical standard, not pork-barrelling in Congress.
> 
> Lisa
> 
>

Received on Thursday, 8 February 2001 13:58:16 UTC