Changes between Version 18 and Version 19 of SeaChange/WhatDevelopersWant
- Timestamp:
- Mar 15, 2012, 11:50:22 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SeaChange/WhatDevelopersWant
v18 v19 19 19 == Development Process Issues == 20 20 21 Regarding [../#HighLevelObservations High Level Observations] points raised on the SeaChange page: 22 1. '''Core development has stagnated''' [[br]] 21 We'll develop the [../#HighLevelObservations High Level Observations] points raised on the SeaChange page. 22 23 === 1. Core development has stagnated 24 23 25 Probably true, we need more people to actively care about the project. 24 26 How? … … 32 34 Comment: When I started looking into Trac it kinda felt like development documentation is somewhere between minimal and completely missing for some areas, but I personally find the source code quite useful (its well documented and I found everything I needed so far). Yet I do think that setting-up API documentation can really help developing for Trac, while it shouldn't take too much effort - there must be plenty of API documentation generators for Python - shesek 33 35 }}} 34 see TracDev/ApiDocs... 36 See TracDev/ApiDocs and TracDev/PluginDevelopment/ExtensionPoints. 37 35 38 A practical course of a computer science student could be to analyze the sources and create an UML model and some UML diagrams of the whole project. This can highly increase the chance that people realize the architecture and are able to extend it with features like e.g. user management. There are some good community versions of UML tools around for free. - falkb 36 a. motivating people to jump over the barrier [[br]]39 b. motivating people to jump over the barrier 37 40 - the great new feature! 38 41 - nice stuff that really makes Trac stand out of the competition … … 43 46 - see [query:?status=!closed&keywords=~bitesized] 44 47 - ?? Google summer of code mentoring (requires time though) 45 2. '''Core developers do not or cannot commit a lot of time to the project''' [[br]] 48 49 === 2. Core developers do not or cannot commit a lot of time to the project 50 46 51 Whip them? Otherwise, see 1. 47 52 {{{#!div style="background:#efe" … … 49 54 }}} 50 55 Aggregating random changes is not going to work. We need a plan, a global vision. 51 3. '''Frequently requested features do not get implemented''' [[br]] 56 57 === 3. Frequently requested features do not get implemented 58 52 59 Big features (e.g. MultipleProjectSupport) first need to have a developer really 53 60 needing the feature, as it can't be done without some kind of deep involvement. 54 4. '''Release cycle is way too slow''' [[br]] 61 62 === 4. Release cycle is way too slow 63 55 64 [[Image(trac_release_statistics.jpg)]] [[br]] 56 I proposed something with intermediate point releases, 57 see googlegroups:trac-dev:7f875005134cd355. 58 We should actually do it. 59 Current idea is to shorten the development cycle of major 60 releases, see googlegroups:trac-dev:6823a7fa94bb0392. 61 This is still somewhat complementary to first idea exposed above: 62 if a big feature doesn't make it for a release, it should simply 63 wait for the next one instead of delaying it further. 64 This implies merging a feature ''late'', once we're sure it 65 can be finished. Late merging has its own drawbacks, which 66 could perhaps be mitigated by the use of temporary integration 67 branches. 68 5. '''Zero chance of a plugin getting into the core''' [[br]] 65 66 (cboos) proposed something with intermediate point releases, 67 see googlegroups:trac-dev:7f875005134cd355. 68 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. 69 70 === 5. Zero chance of a plugin getting into the core 71 69 72 Well, WebAdmin was integrated. There was some attempt to do the same for 70 73 [TH:AccountManagerPlugin] (see also [../WhatUsersWant]), but see 3. … … 74 77 [[br]] 75 78 Can someone explain the licensing issues here? I used to be a Trac user, and for me, the main reason I don't think of using it now is that my default option is Github. And I wouldn't think of using a SCM that wasn't distributed. For Trac to remain relevant to me, it needs to support Git or Mercurial as natively as it supports SVN. (Ie. not need me to install and manage a plugin). 76 As I understand it, we can't integrate the TracMercurial plugin because we're using its internal API ("linking to it"). Doing that would force us to distribute Trac as GPL as well, something we don't want to. The git plugin could be different story, as it uses git via its command line interface, so if HvR was to relicense his git plugin under a BSD like license, we might consider it for inclusion (probably below `tracopt.versioncontrol.git.`). Same thing could happen with a rewrite of the Mercurial plugin to use its command line interface, but that would be silly, of course ;-) The other 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// 77 6. '''Features that users think should be "core" are not''' [[br]] 79 As I understand it, we can't integrate the TracMercurial plugin because we're using its internal API ("linking to it"). Doing that would force us to distribute Trac as GPL as well, something we don't want to. The git plugin could be different story, as it uses git via its command line interface, so if HvR was to relicense his git plugin under a BSD like license, we might consider it for inclusion (probably below `tracopt.versioncontrol.git.`). 80 Actually, the integration of Git support happened recently (see gdiscussion:trac-dev:hCwTylvQ_FU and #10594), just like described above. 81 82 Same thing could happen with a rewrite of the Mercurial plugin to use its command line interface, but that would be silly, of course ;-) \\ 83 See #10411 for a reasonable alternative. 84 85 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// 86 87 === 6. Features that users think should be "core" are not 78 88 Since 0.12, there's a new [source:trunk/tracopt tracopt.] package hierarchy, 79 89 for bundling components that are not enabled by default.
