Changes between Version 7 and Version 8 of SeaChange/WhatDevelopersWant

Timestamp:

May 3, 2010, 2:41:55 PM (14 years ago)

Author:

Christian Boos

Comment:

some updates relative to discussion about milestones

SeaChange/WhatDevelopersWant

@@ -1 +1 @@
 = Developers' Corner =
- '' A blackboard for ideas related to future directions'' ,,(or: ''How do we bribe the aliens so that we can reach milestone:2.0?''),,
+ '' A blackboard for ideas related to future directions'' 
 
 More seriously, this page is for drafting long term ideas and share the vision the Trac developers have.
@@ -11 +11 @@
 == Development Process Issues ==
 
-Regarding [../#HighLevelObservations]:
+Regarding [../#HighLevelObservations High Level Observations] points raised on the SeaChange page:
  1. '''Core development has stagnated''' [[br]]
     Probably true, we need more people to actively care about the project.
@@ -38 +38 @@
         Comment: In theory they don't need to, if the community can write patches and test them, then all the core developers need to do is commit to svn.
         }}}
+        Aggregating random changes is not going to work. We need a plan, a global vision.
  3. '''Frequently requested features do not get implemented''' [[br]] 
     Big features (e.g. MultipleProjectSupport) first need to have a developer really   
     needing the feature, as it can't be done without some kind of deep involvement.
-    See 1.2.
  4. '''Release cycle is way too slow''' [[br]]
     (need a picture showing Release History) [[br]]
     I proposed something with intermediate point releases, 
-    see googlegroups:trac-dev:7f875005134cd355. We should actually do it.
+    see googlegroups:trac-dev:7f875005134cd355. 
+    We should actually do it.
+    Current idea is to shorten the development cycle of major 
+    releases, see googlegroups:trac-dev:6823a7fa94bb0392. 
+    This is still somewhat complementary to first idea exposed above:
+    if a big feature doesn't make it for a release, it should simply
+    wait for the next one instead of delaying it further.
+    This implies merging a feature ''late'', once we're sure it
+    can be finished. Late merging has its own drawbacks, which
+    could perhaps be mitigated by the use of temporary integration 
+    branches.
  5. '''Zero chance of a plugin getting into the core''' [[br]]
     Well, WebAdmin was integrated. There was some attempt to do the same for 
@@ -57 +67 @@
     ''strictly necessary for almost anyone using Trac (`trac.`)'' and
     ''optional, must be 3^rd^ party.''
-