incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject svn commit: r920198 - in /incubator/public/trunk: site-author/learn/rules-for-revolutionaries.xml site-publish/learn/rules-for-revolutionaries.html site-publish/sitemap.html
Date Mon, 08 Mar 2010 05:48:19 GMT
Author: jerenkrantz
Date: Mon Mar  8 05:48:19 2010
New Revision: 920198

URL: http://svn.apache.org/viewvc?rev=920198&view=rev
Log:
Clean up rules for revolutionaries page - XML is not a format.

Modified:
    incubator/public/trunk/site-author/learn/rules-for-revolutionaries.xml
    incubator/public/trunk/site-publish/learn/rules-for-revolutionaries.html
    incubator/public/trunk/site-publish/sitemap.html

Modified: incubator/public/trunk/site-author/learn/rules-for-revolutionaries.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/learn/rules-for-revolutionaries.xml?rev=920198&r1=920197&r2=920198&view=diff
==============================================================================
--- incubator/public/trunk/site-author/learn/rules-for-revolutionaries.xml [utf-8] (original)
+++ incubator/public/trunk/site-author/learn/rules-for-revolutionaries.xml [utf-8] Mon Mar
 8 05:48:19 2010
@@ -14,135 +14,149 @@
 -->
 <document>
   <properties>
-    <title>Apache Archive: Rules for Revolutionaries
-</title>
+    <title>Apache Archive: Rules for Revolutionaries</title>
     <authors>
       <person email="duncan@x180.com" name="James Duncan Davidson"/>
     </authors>
-    <notice>This document is a WIP (Work In Progress).
-</notice>
-    <abstract>Archival copy of Duncan's 'Rules for Revolutionaries.'
-</abstract>
+    <notice>This document is a WIP (Work In Progress).</notice>
+    <abstract>Archival copy of Duncan's 'Rules for Revolutionaries.'</abstract>
   </properties>
   <body>
     <section id="rules+for+revolutionaries">
-      <title>rules for revolutionaries
-</title>
+      <title>rules for revolutionaries</title>
       <note>
-        <strong>As Sent on 13 Jan 2000.
-</strong>© 1995-2002, James Duncan Davidson.
-
+        <strong>As Sent on 13 Jan 2000.</strong>&#169; 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>
+Apache Jakarta PMC (and PMCs in general) have responsiblities that
+aren't detailed here.  With that said...</em>
       </note>
-      <source xml:space="preserve">
-        <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 revolutionary mode or evolutionary 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 to 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 Craig's 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()
+      <ul>
+        <li><strong>Date: </strong>Thu, 13 Jan 2000 15:46:41 -0800</li>
+        <li><strong>Subject: </strong>RESET: Proposal for Revolutionaries
and Evolutionaries</li>
+        <li><strong>From: </strong>James Duncan Davidson</li>
+        <li><strong>To: </strong>&lt;general@jakarta.apache.org&gt;</li>
+        <li><strong>Cc: </strong>&lt;tomcat-dev@jakarta.apache.org&gt;</li>
+        <li><a href="http://mail-archives.apache.org/mod_mbox/jakarta-general/200001.mbox/%3cB4A3A3E0.C73%25james.davidson@eng.sun.com%3e">Link
to this message in mod_mbox archive</a></li>
+      </ul>
+
+<pre>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 revolutionary mode or evolutionary
+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 to 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 Craig's 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                                  ...
+Java + XML / Portable Code + Portable Data      !try; do()
+</pre>
 
-      </source>
     </section>
   </body>
 </document>

Modified: incubator/public/trunk/site-publish/learn/rules-for-revolutionaries.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/learn/rules-for-revolutionaries.html?rev=920198&r1=920197&r2=920198&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/learn/rules-for-revolutionaries.html [utf-8] (original)
+++ incubator/public/trunk/site-publish/learn/rules-for-revolutionaries.html [utf-8] Mon Mar
 8 05:48:19 2010
@@ -22,8 +22,7 @@
  <head>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   <link rel="stylesheet" href="../style/style.css" type="text/css" />
-        <title>Apache Archive: Rules for Revolutionaries
- - Apache Incubator</title>
+        <title>Apache Archive: Rules for Revolutionaries - Apache Incubator</title>
   
  </head>
  <body>
@@ -113,123 +112,142 @@
     <!-- CONTENT -->
     <td align="left" valign="top" class="content">
                 <h2><img src="../images/redarrow.gif" />
-   <a name="rules+for+revolutionaries">rules for revolutionaries
-</a>
+   <a name="rules+for+revolutionaries">rules for revolutionaries</a>
 </h2>
 <div class="section-content">
 <div class="note">
 <note>
-        <strong>As Sent on 13 Jan 2000.
-</strong>© 1995-2002, James Duncan Davidson.
-
+        <strong>As Sent on 13 Jan 2000.</strong>© 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>
+Apache Jakarta PMC (and PMCs in general) have responsiblities that
+aren't detailed here.  With that said...</em>
       </note>
 </div>
-<div class="source"><code>
-        Thu, 13 Jan 2000 15:46:41 -0800
+<ul>
+        <li><strong>Date: </strong>Thu, 13 Jan 2000 15:46:41 -0800</li>
+        <li><strong>Subject: </strong>RESET: Proposal for Revolutionaries
and Evolutionaries</li>
+        <li><strong>From: </strong>James Duncan Davidson</li>
+        <li><strong>To: </strong>&lt;general@jakarta.apache.org&gt;</li>
+        <li><strong>Cc: </strong>&lt;tomcat-dev@jakarta.apache.org&gt;</li>
+        <li><a href="http://mail-archives.apache.org/mod_mbox/jakarta-general/200001.mbox/%3cB4A3A3E0.C73%25james.davidson@eng.sun.com%3e">Link
to this message in mod_mbox archive</a></li>
+      </ul>
+<pre>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.
 
-        RESET: Proposal for Revolutionaries and Evolutionaries
+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.
 
-        James Duncan Davidson &lt;james.davidson@eng.sun.com&gt;
+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.
 
-        &lt;general@jakarta.apache.org&gt;
+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 revolutionary mode or evolutionary
+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.
 
-        &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 revolutionary mode or evolutionary 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 to 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 Craig's 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()
+However, Open source is chaotic. With its special magic comes a different
+reality. This is:
 
-      </code>
-</div>
+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 to 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 Craig's 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                                  ...
+Java + XML / Portable Code + Portable Data      !try; do()
+</pre>
 </div>
          </td>
     <!-- RIGHT SIDE NAVIGATION -->

Modified: incubator/public/trunk/site-publish/sitemap.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/sitemap.html?rev=920198&r1=920197&r2=920198&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/sitemap.html [utf-8] (original)
+++ incubator/public/trunk/site-publish/sitemap.html [utf-8] Mon Mar  8 05:48:19 2010
@@ -1728,12 +1728,10 @@
 </ul>
 </li>
 <li>
-<a href="learn/rules-for-revolutionaries.html">Apache Archive: Rules for Revolutionaries
-</a>
+<a href="learn/rules-for-revolutionaries.html">Apache Archive: Rules for Revolutionaries</a>
 <ul>
 <li>
-<a href="learn/rules-for-revolutionaries.html#rules+for+revolutionaries">rules for
revolutionaries
-</a>
+<a href="learn/rules-for-revolutionaries.html#rules+for+revolutionaries">rules for
revolutionaries</a>
 </li>
 </ul>
 </li>



---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message