Re: Splitting off core: where we stand

Jim forgot Edgar Schwarz and Preston Bannister's messages (both dated
2/3/2001), both of whom voted for submitting the combined document to
the IESG.  Also, Jim Amsden left me phone mail saying that he was in
favor of submitting a combined document to the IESG (JimA, please do
send email to the list, to make it official).

Greg and Juergen expressed their desire to split the document before
we cleanly separated out the core and options sections.  So I'd
be interested in hearing whether they still believe it should be
split, especially since one of the prime motivations for doing the
split is to defer the submission of the options to the IESG.

So with the addition of JimA, Eric, and Ron, that makes it:
JimW, Larry, Mark, Lisa, Chris in favor of splitting
Greg, Juergen possibly in favor of splitting
Geoff, Tim, James, Edgar, Preston, Eric, Ron, JimA in favor of keeping together

So that makes the straw poll:
5 for splitting
2 maybe for splitting
8 for keeping together

So depending on how we count the "maybe"s, that would make it
either 8-7 in favor of keeping together or 8-5 in favor of
keeping it together.

So as Jim said, "Not entirely rough consensus, but it certainly
shows a leaning in one direction."  (:-).

Cheers,
Geoff

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>
   Date: Wed, 7 Feb 2001 11:50:35 -0800

   Back on December 1, 2000, I opined that splitting off core versioning from
   the options seemed like a good idea, giving reasons both for and against the
   split [1].

   At the time, Greg Stein [2] and Juergen Reuter both favored a split, though
   Juergen suggested that the split criteria should be to include all
   versioning features in one document, and configuration management features
   in another [3]. Geoff Clemm stated that he would be willing to make such a
   split, but indicated that he was concerned that this might delay core [4].

   On February 2, 2001, the issue resurfaced, with Larry Masinter favoring
   splitting off core, adding a new rationale [5]:

      "Everything outside of core versioning is much less
      likely to progress along standards track at the same
      rate as core versioning (more time to get independent
      interoperable implementations of every feature); by
      linking "core versioning" with "non-core" in the
      initial spec, you're setting yourself up for having
      to split the documents later. Much of non-core is
      controversial."

   On this same date, Mark Hale began a thread titled, "Complexity and Core
   Considerations", where he polls working group members on whether they think
   the specification should be split along core/non-core lines [6]. I replied,
   stating that I felt the specification should be split [7], to which Chris
   Kaler [8] and Lisa Dusseault [9] agreed. Geoff Clemm [10], Tim Ellison
   [11],and James Hunt [12] all disagreed, and want the protocol specification
   unsplit.

   So, at present we have six in favor of a split, three against. Not entirely
   rough consensus, but it certainly shows a leaning in one direction.

   - Jim

Received on Wednesday, 7 February 2001 18:27:43 UTC