Edgewall Software

Changes between Version 4 and Version 5 of SeaChange/DevelopmentProcess


Ignore:
Timestamp:
May 2, 2015, 11:54:49 PM (9 years ago)
Author:
figaro
Comment:

Further preliminary cleanup

Legend:

Unmodified
Added
Removed
Modified

  • SeaChange/DevelopmentProcess

    v4 v5  
    11= The Trac development process
    22
    3 == High Level Observations ==
     3== High Level Observations
    44
    5 These are observations only, no judgement is implied. We're just trying to collect data.
     5These are observations only on the current development process on Trac. No judgement is implied.
    66
    7  1. Trac core development has stagnated to a certain degree.
    8  2. A lot of the current core developers do not or cannot commit a lot of time to the project.
    9  3. Frequently requested features do not get implemented. eg. multi-project support.
    10  4. Release cycle is ''way'' too slow.
    11  5. Historically, there's effectively zero chance of a plugin getting into the core.   
    12  6. Features that users think should be "core" are not (''this is '''very''' subjective'').
    13  7. Many Trac tickets age in a limbo of sorts when they could probably be closed.
     7 1. A lot of the current core developers do not or cannot commit a lot of time to the project.
     8 1. Frequently requested features do not get implemented. eg. multi-project support.
     9 1. Release cycle is ''way'' too slow.
     10 1. Historically, there's effectively zero chance of a plugin getting into the core.   
     11 1. Features that users think should be "core" are not.
     12 1. Many Trac tickets have gone stale and they could probably be closed.
    1413
     14=== 1. Core developers do not or cannot commit a lot of time to the project
    1515
    16 We'll develop each of these questions, which are or were all valid at some point.
     16        {{{#!div style="background:#efe"
     17        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.
     18        }}}
    1719
    18 === 1. Core development has stagnated
     20    We need more people to actively care about the project.
    1921
    20     Probably true, we need more people to actively care about the project.
    21     How?
    2222        {{{#!div style="background:#efe"
    23         Comment: Just look at the history of #2456. People cared, wrote patches, discussed the issue. But in the end nothing changed despite the fact that trac doesnt adhere to its design principles in that area (Users not managed via pluggable !Components/Relations) The ticket is '''4 years old'''. There are few comments from team members and virtually no information what problems prevent this to move forward. People got frustrated, wrote competing implementations/plugins or gave up and moved on. I think it's worth analyzing what went wrong here.
     23        Comment: Just look at the history of #2456. People cared, wrote patches, discussed the issue. But in the end nothing changed despite the fact that trac doesnt adhere to its design principles in that area (Users not managed via pluggable !Components/Relations) The ticket is '''9 years old'''. There are few comments from team members and virtually no information what problems prevent this to move forward. People got frustrated, wrote competing implementations/plugins or gave up and moved on. I think it's worth analyzing what went wrong here.
    2424        }}}       
    2525     a. lowering the barrier to entry [[br]]
    … …  
    4242         - Google summer of code mentoring (requires time though)
    4343
    44 === 2. Core developers do not or cannot commit a lot of time to the project
    45 
    46     See also the points made under point 1: Core development has stagnated.
    47         {{{#!div style="background:#efe"
    48         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.
    49         }}}
    50         Aggregating random changes is not going to work. We need a plan, a global vision.
    51 
    52 === 3. Frequently requested features do not get implemented
     44=== 2. Frequently requested features do not get implemented
    5345
    5446    Big features (e.g. MultipleProjectSupport) first need to have a developer really   
    5547    needing the feature, as it can't be done without some kind of deep involvement.
    5648
    57 === 4. Release cycle is way too slow
     49=== 3. Release cycle is too slow
    5850
    5951    [[Image(wiki:SeaChange/WhatDevelopersWant:trac_release_statistics.jpg)]] [[br]]
    … …  
    6355      We're actually going to do it, right after 1.0, see [gdiscussion:trac-dev:17DO_N1MM-A the whole discussion] and the [gmessage:trac-dev:17DO_N1MM-A/nbhupXw0NAIJ decision to go with  1.0] directly and from that point, have regular 1.0.x stable releases and 1.1.x development releases, until the cycle repeats.
    6456
    65 === 5. Zero chance of a plugin getting into the core
     57=== 4. Zero chance of a plugin getting into the core
    6658
    6759    WebAdmin was integrated. There was some attempt to do the same for
    … …  
    8072           Another option to make git and mercurial stand on a more equal footing than svn would be to //extract// the svn support in a plugin, or at the very least move it to `tracopt.versioncontrol.svn_fs.*` (`svn_fs` because having one day a `.svn.*` backend based on the command line would be an option) //-- cboos//
    8173
    82 === 6. Features that users think should be "core" are not
    83     Since 0.12, there's a new [source:trunk/tracopt tracopt.] package hierarchy,
    84     for bundling components that are not enabled by default.
    85     This makes it possible to have some room between
    86     ''strictly necessary for almost anyone using Trac (`trac.`)'' and
    87     ''optional, must be 3rd party.''
     74=== 5. Features that users think should be "core" are not
    8875
    89 === 7. Many Trac tickets have gone stale and they could probably be closed.
    90     The 1000+ active tickets, often old and with inflated severity, give a false impression of the state of the project. See for instance the history of scary #11174 'blocker', an InstallationIssue that should probably be closed as invalid. Some very old tickets relevant to points 3. and 6. above could be closed as 'wontfix', perhaps with a note suggesting interested parties could write a patch and reopen the ticket if it is still relevant. Many others could be set to low priority and moved to the 'unscheduled' milestone to help reduce the clutter.
     76Since 0.12, there's a new [source:trunk/tracopt tracopt.] package hierarchy, for bundling components that are not enabled by default. This makes it possible to have some room between ''strictly necessary for almost anyone using Trac (`trac.`)'' and ''optional, must be 3rd party.''
     77
     78=== 6. Many Trac tickets have gone stale and they could probably be closed
     79
     80The 1000+ active tickets, often old and with inflated severity, give a false impression of the state of the project. See for instance the history of scary #11174 'blocker', an InstallationIssue that should probably be closed as invalid. Some very old tickets relevant to points 3. and 6. above could be closed as 'wontfix', perhaps with a note suggesting interested parties could write a patch and reopen the ticket if it is still relevant. Many others could be set to low priority and moved to the 'unscheduled' milestone to help reduce the clutter.