incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject cvs commit: incubator-site/src/documentation/content/xdocs/drafts glossary.xml
Date Sun, 10 Nov 2002 03:04:06 GMT
coar        2002/11/09 19:04:06

  Modified:    build/site bylaws.html index.html process.html
                        resolution.html whoweare.html
               build/site/drafts glossary.html glossary.pdf
               src/documentation/content/xdocs book.xml
               src/documentation/content/xdocs/drafts glossary.xml
  Added:       src/documentation/content/xdocs
                        rules-for-revolutionaries.xml
  Log:
  add some more glossary terms, and duncan's rules4revolutionaries
  
  Revision  Changes    Path
  1.4       +10 -3     incubator-site/build/site/bylaws.html
  
  Index: bylaws.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/bylaws.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- bylaws.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ bylaws.html	10 Nov 2002 03:04:05 -0000	1.4
  @@ -133,13 +133,20 @@
   <a href="http://www.apache.org/LICENSE.txt">License</a>
   </li>
       
  -<li>
  -<a href="theapacheway.html">the Apache Way</a>
  -</li>
       
       
   <li>
   <a href="http://www.apache.org/foundation/faq.html">the Apache FAQ</a>
  +</li>
  +  
  +</ul>
  +</li>
  +<li>
  +<font color="#CFDCED">References</font>
  +<ul>
  +    
  +<li>
  +<a href="rules-for-revolutionaries.html">Rules for Revolutionaries</a>
   </li>
     
   </ul>
  
  
  
  1.4       +10 -3     incubator-site/build/site/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/index.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- index.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ index.html	10 Nov 2002 03:04:05 -0000	1.4
  @@ -133,13 +133,20 @@
   <a href="http://www.apache.org/LICENSE.txt">License</a>
   </li>
       
  -<li>
  -<a href="theapacheway.html">the Apache Way</a>
  -</li>
       
       
   <li>
   <a href="http://www.apache.org/foundation/faq.html">the Apache FAQ</a>
  +</li>
  +  
  +</ul>
  +</li>
  +<li>
  +<font color="#CFDCED">References</font>
  +<ul>
  +    
  +<li>
  +<a href="rules-for-revolutionaries.html">Rules for Revolutionaries</a>
   </li>
     
   </ul>
  
  
  
  1.5       +10 -3     incubator-site/build/site/process.html
  
  Index: process.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/process.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -u -r1.4 -r1.5
  --- process.html	8 Nov 2002 20:36:10 -0000	1.4
  +++ process.html	10 Nov 2002 03:04:05 -0000	1.5
  @@ -133,13 +133,20 @@
   <a href="http://www.apache.org/LICENSE.txt">License</a>
   </li>
       
  -<li>
  -<a href="theapacheway.html">the Apache Way</a>
  -</li>
       
       
   <li>
   <a href="http://www.apache.org/foundation/faq.html">the Apache FAQ</a>
  +</li>
  +  
  +</ul>
  +</li>
  +<li>
  +<font color="#CFDCED">References</font>
  +<ul>
  +    
  +<li>
  +<a href="rules-for-revolutionaries.html">Rules for Revolutionaries</a>
   </li>
     
   </ul>
  
  
  
  1.4       +10 -3     incubator-site/build/site/resolution.html
  
  Index: resolution.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/resolution.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- resolution.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ resolution.html	10 Nov 2002 03:04:05 -0000	1.4
  @@ -133,13 +133,20 @@
   <a href="http://www.apache.org/LICENSE.txt">License</a>
   </li>
       
  -<li>
  -<a href="theapacheway.html">the Apache Way</a>
  -</li>
       
       
   <li>
   <a href="http://www.apache.org/foundation/faq.html">the Apache FAQ</a>
  +</li>
  +  
  +</ul>
  +</li>
  +<li>
  +<font color="#CFDCED">References</font>
  +<ul>
  +    
  +<li>
  +<a href="rules-for-revolutionaries.html">Rules for Revolutionaries</a>
   </li>
     
   </ul>
  
  
  
  1.4       +10 -3     incubator-site/build/site/whoweare.html
  
  Index: whoweare.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/whoweare.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- whoweare.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ whoweare.html	10 Nov 2002 03:04:05 -0000	1.4
  @@ -133,13 +133,20 @@
   <a href="http://www.apache.org/LICENSE.txt">License</a>
   </li>
       
  -<li>
  -<a href="theapacheway.html">the Apache Way</a>
  -</li>
       
       
   <li>
   <a href="http://www.apache.org/foundation/faq.html">the Apache FAQ</a>
  +</li>
  +  
  +</ul>
  +</li>
  +<li>
  +<font color="#CFDCED">References</font>
  +<ul>
  +    
  +<li>
  +<a href="rules-for-revolutionaries.html">Rules for Revolutionaries</a>
   </li>
     
   </ul>
  
  
  
  1.5       +61 -0     incubator-site/build/site/drafts/glossary.html
  
  Index: glossary.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/drafts/glossary.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -u -r1.4 -r1.5
  --- glossary.html	8 Nov 2002 20:36:10 -0000	1.4
  +++ glossary.html	10 Nov 2002 03:04:06 -0000	1.5
  @@ -365,6 +365,16 @@
   
           
   <dt>
  +<strong><a name="Darwinism"></a>Darwinism</strong>
  +</dt>
  +        
  +<dd>
  +          See
  +          <em><a href="#SoftwareDarwinism">Software Darwinism</a></em>.
  +        </dd>
  +
  +        
  +<dt>
   <strong><a name="Developer"></a>Developer</strong>
   </dt>
           
  @@ -392,6 +402,15 @@
   
           
   <dt>
  +<strong><a name="Evolution"></a>Evolution</strong>
  +</dt>
  +        
  +<dd>TBD.
  +        Compare
  +        <em><a href="#Revolution">revolution</a></em>.</dd>
  +
  +        
  +<dt>
   <strong><a name="Graveyard"></a>Graveyard</strong>
   </dt>
           
  @@ -651,6 +670,48 @@
           <em><a href="#CommitThenReview">Commit-Then-Review</a></em>,
           and see the description of the
           <a href="voting.html">voting process</a>.</dd>
  +
  +        
  +<dt>
  +<strong><a name="Revolution"></a>Revolution</strong>
  +</dt>
  +        
  +<dd>In the Apache environment, some communities may decide
  +        to permit (or encourage) <em>revolutions</em> as ways of
  +        reconciling differences, particularly code changes which
  +        have been blocked on a particular branch by a veto.
  +        Originally described by James Duncan Davison in his
  +        'Rules for Revolutionaries,' the concept has been
  +        adopted, formally or informally, by at least one Apache
  +        project.  Essentially, a revolution occurs when a group
  +        of committers decides to fork the current main branch
  +        in order to work on problematic code or concepts.  This
  +        permits them to pursue it without disturbing the evolutionary
  +        work on the main branch.  A revolutionary branch may eventually
  +        be merged back into the main branch, die out, split completely
  +        and become a new main branch, or may absorb the current
  +        main branch into itself (essentially no different than
  +        the first option).
  +        See the
  +        '<a href="../rules-for-revolutionaries.html">Rules for Revolutionaries</a>'
  +        and compare
  +        <em><a href="#Evolution">evolution</a></em>.</dd>
  +
  +        
  +<dt>
  +          
  +<strong>
  +            <a name="SoftwareDarwinism"></a>
  +            Software Darwinism
  +          </strong>
  +        
  +</dt>
  +        
  +<dd>A deceptively simple concept, often expressed as
  +        'the best code survives'.  The
  +        <a href="#Evolution">evolutionary</a>
  +        processes inherent in the Apache peer-review environment support
  +        this idea.</dd>
   
           
   <dt>
  
  
  
  1.4       +489 -310  incubator-site/build/site/drafts/glossary.pdf
  
  	<<Binary file>>
  
  
  1.9       +5 -0      incubator-site/src/documentation/content/xdocs/book.xml
  
  Index: book.xml
  ===================================================================
  RCS file: /home/cvs/incubator-site/src/documentation/content/xdocs/book.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -u -r1.8 -r1.9
  --- book.xml	9 Nov 2002 11:26:18 -0000	1.8
  +++ book.xml	10 Nov 2002 03:04:06 -0000	1.9
  @@ -30,6 +30,11 @@
         href="http://www.apache.org/foundation/faq.html"/>
     </menu>
   
  +  <menu label="References">
  +    <menu-item label="Rules for Revolutionaries"
  +      href="rules-for-revolutionaries.html"/>
  +  </menu>
  +
     <menu label="Forms">
       <menu-item label="Contributor's Agreement (PDF)"
         href="forms/ASF_Contributor_License_2_form.pdf"/>
  
  
  
  1.1                  incubator-site/src/documentation/content/xdocs/rules-for-revolutionaries.xml
  
  Index: rules-for-revolutionaries.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC
    "-//APACHE//DTD Documentation V1.1//EN"
    "document-v11.dtd">
  <document>
    <header>
      <title>Apache Archive: Rules for Revolutionaries</title>
  
      <authors>
        <person name="James Duncan Davidson" email="duncan@x180.com" />
      </authors>
  
      <notice>This document is a WIP (Work In Progress).</notice>
  
      <abstract>Archival copy of Duncan's 'Rules for Revolutionaries.'</abstract>
    </header>
  
    <body>
  
      <section>
        <title>rules for revolutionaries</title>
        <note>
          <strong>As Sent on 13 Jan 2000.</strong>
          &copy; 1995-2002, James Duncan Davidson.
          <br/>
          <em>Note: This message was written at a specific place and time
          in response to a specific situtation. It does not address
          several important issues like what happens when revolutions
          do not totally succeed. It also doesn't address the issues of
          responsiblity. The Apache Jakarta PMC has responsiblities 
          that aren't detailed here. With that said...</em>
        </note>
        <source>
  <strong>Date:</strong>    Thu, 13 Jan 2000 15:46:41 -0800
  <strong>Subject:</strong> RESET: Proposal for Revolutionaries and Evolutionaries
  <strong>From:</strong>    James Duncan Davidson &lt;james.davidson@eng.sun.com&gt;
  <strong>To:</strong>      &lt;general@jakarta.apache.org&gt;
  <strong>CC:</strong>      &lt;tomcat-dev@jakarta.apache.org&gt;
  
    Ok, the logical place for this is general@jakarta, but I'm
    including tomcat-dev@jakarta so that the people who are
    there and not on general can see it. Please do not discuss
    on tomcat-dev, please only discuss on general.
  
    In a closed source project where you've got a set team,
    you make decisions about where the entire team goes and
    somebody takes the lead of deciding what gets done
    when. In the discussions about Craig's long term plan,
    this metric was applied by several of us in thoughts about
    where to go next.
  
    After pondering this for a while, it's (re)become obvious
    to me that there's no way that anybody can expect an open
    source organization to work the same way that a team in a
    corporate setting can. Ok, so this is pretty freaking
    obvious, but I've been watching people that are not from
    Sun and who have been doing open source for a while
    talking and proposing things that come from this line of
    thought as well.  Its not just people from Sun or people
    from any particular entity.
  
    So -- in any software development project there is a
    natural tension between revolution and evolution. In a
    closed source environment, you make the call at any
    particular time on whether you are in revolutionay mode or
    evolutionare mode. For example, JSDK was in evolutionary
    mode for years. Then in Nov 98, We made a decision to go
    revolutionary. Of course, at the time the project team was
    composed of 1 person -- me, so it was an easy decision.
    After that revolution was over in Jan 99, Tomcat was in
    evolutionary mode getting JSP bolted in and working with
    J2EE. We (Sun folks) could do that because that was what
    suited the goals best at the time.
  
    However, Open source is chaotic.  With its special magic
    comes a different reality. This is:
  
      1) People work on their own time (even people paid by a
      company can be considered to be working on their own
      time in this situtation as each company is going to have
      different cycles and things they want)
  
      2) People work on what they want to. If you are working
      on your own time, you are going to do what you want or
      you do something else.
  
      3) Some people are evolutionaries, other are
      revolutionaries, and some are both at different times.
  
      4) Both approaches are important and need to be
      cultured.
  
      5) You really can't afford to alienate any part of your
      developer community. Innovation can come from anywhere.
  
    To allow this to happen, to allow revolutionaries to
    co-exist with evolutionaries, I'm proposing the following
    as official Jakarta policy:
  
      1) Any committer has the right to go start a
      revolution. They can establish a branch or seperate
      whiteboard directory in which to go experiment with new
      code seperate from the main trunk. The only
      responsibility a committer has when they do this is to
      inform the developer group what their intent is, to keep
      the group updated on their progress, and allowing others
      who want to help out to do so.  The committer, and the
      group of people who he/she has a attracted are free to
      take any approaches they want too free of interference.
  
      2) When a revolution is ready for prime time, the
      committer proposes a merge to the -dev list. At that
      time, the overall community evaluates whether or not the
      code is ready to become part of, or to potentially
      replace the, trunk. Suggestions may be made, changes may
      be required. Once all issues have been taken care of and
      the merge is approved, the new code becomes the trunk.
  
      3) A revolution branch is unversioned.  It doesn't have
      any official version standing. This allows several
      parallel tracks of development to occur with the final
      authority of what eventually ends up on the trunk laying
      with the entire community of committers.
  
      4) The trunk is the official versioned line of the
      project. All evolutionary minded people are welcome to
      work on it to improve it. Evolutionary work is important
      and should not stop as it is always unclear when any
      particular revolution will be ready for prime time or
      whether it will be officially accepted.
  
    What does this mean?
  
    In practice, this means that Craig and Hans and anybody
    else that wants to run with that revolution is welcome to
    do so. The only change is that it's not called Tomcat.next
    -- it's the RED branch or GOOGLE branch or whatever they
    want to call it.
  
    Whenever Craig (or anybody else working on that codebase)
    wants to bring stuff into the trunk, they propose it here
    and we evaluate it on it's merits.
  
    If somebody disagrees with Craigs approach (for the sake
    of argument here), they are free to create a BLUE
    whiteboard and work out what they think is a good
    solution. At that point, the community will have to
    evaluate both approaches. But since this is a populist
    society, with such a structure it is hoped that it becomes
    clear which is the preferred approach by the community by
    their participation and voting. Or maybe the best solution
    is something in the middle and the two parties work
    together to merge. Irregardless, the point is to allow
    solutions to happen without being stalled out in the
    formative stages.
  
    An important point is that no one revolution is declared
    to be the official .next until it's ready to be accepted
    for that. There is the side effect that we could
    potentially end up with too many revolutions happening,
    but I'd rather rely upon the natural inclination of
    developers to gravitate towards one solution to control
    this than to try to control it through any policy
    statement.
  
    When would this be official?
  
    Well, if this is well recieved, we'd want to word it up
    and make it a bylaw (with approval by the PMC -- this is
    one of the areas in which the PMC has authority).
    Hopefully soon.
  
    Comments? Suggestions?
  
    James Davidson duncan@eng.sun.com
    Java + XML / Portable Code + Portable Data
    !try; do()
        </source>
      </section>
  
    </body>
  </document>
  
  
  
  1.10      +46 -0     incubator-site/src/documentation/content/xdocs/drafts/glossary.xml
  
  Index: glossary.xml
  ===================================================================
  RCS file: /home/cvs/incubator-site/src/documentation/content/xdocs/drafts/glossary.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -u -r1.9 -r1.10
  --- glossary.xml	8 Nov 2002 20:36:11 -0000	1.9
  +++ glossary.xml	10 Nov 2002 03:04:06 -0000	1.10
  @@ -153,6 +153,12 @@
           by many developers.  Almost all of the Foundation's code
           is stored in CVS repositories.</dd>
   
  +        <dt><strong><anchor id="Darwinism"/>Darwinism</strong></dt>
  +        <dd>
  +          See
  +          <em><link href="#SoftwareDarwinism">Software Darwinism</link></em>.
  +        </dd>
  +
           <dt><strong><anchor id="Developer"/>Developer</strong></dt>
           <dd>TBD</dd>
   
  @@ -168,6 +174,11 @@
           may declare itself emeritus.  Emeritus status indicates
           interest but not activity, as opposed to having resigned.</dd>
   
  +        <dt><strong><anchor id="Evolution"/>Evolution</strong></dt>
  +        <dd>TBD.
  +        Compare
  +        <em><link href="#Revolution">revolution</link></em>.</dd>
  +
           <dt><strong><anchor id="Graveyard"/>Graveyard</strong></dt>
           <dd>A location where discontinued, abandoned, and retired
           <link href="#Codebase">codebases</link>
  @@ -348,6 +359,41 @@
           <em><link href="#CommitThenReview">Commit-Then-Review</link></em>,
           and see the description of the
           <link href="voting.html">voting process</link>.</dd>
  +
  +        <dt><strong><anchor id="Revolution"/>Revolution</strong></dt>
  +        <dd>In the Apache environment, some communities may decide
  +        to permit (or encourage) <em>revolutions</em> as ways of
  +        reconciling differences, particularly code changes which
  +        have been blocked on a particular branch by a veto.
  +        Originally described by James Duncan Davison in his
  +        'Rules for Revolutionaries,' the concept has been
  +        adopted, formally or informally, by at least one Apache
  +        project.  Essentially, a revolution occurs when a group
  +        of committers decides to fork the current main branch
  +        in order to work on problematic code or concepts.  This
  +        permits them to pursue it without disturbing the evolutionary
  +        work on the main branch.  A revolutionary branch may eventually
  +        be merged back into the main branch, die out, split completely
  +        and become a new main branch, or may absorb the current
  +        main branch into itself (essentially no different than
  +        the first option).
  +        See the
  +        '<link href="../rules-for-revolutionaries.html"
  +           >Rules for Revolutionaries</link>'
  +        and compare
  +        <em><link href="#Evolution">evolution</link></em>.</dd>
  +
  +        <dt>
  +          <strong>
  +            <anchor id="SoftwareDarwinism"/>
  +            Software Darwinism
  +          </strong>
  +        </dt>
  +        <dd>A deceptively simple concept, often expressed as
  +        'the best code survives'.  The
  +        <link href="#Evolution">evolutionary</link>
  +        processes inherent in the Apache peer-review environment support
  +        this idea.</dd>
   
           <dt><strong><anchor id="Subversion"/>Subversion</strong></dt>
           <dd>TBD</dd>
  
  
  

Mime
View raw message