On 6/27/2010 10:22 PM, Itamar O wrote:
regarding the development workflow - I have noticed that discussions of features may take place in (at least) 3 locations - mailing list, ticket comments, wiki (proposals). I must admit this is a little confusing for me, and I am wondering if there are guidelines for what should be discussed where...
Each has its use: the mailing list is usually fine for any kind of topic or scope. A discussion there has a high visibility, but a short attention span in time. Even if you can search in past messages, it's not something you'd do often and so it's sometimes difficult to keep track of good ideas that were once proposed on the list.
In tickets, it's easier to go back to previous arguments and even if there are risks to have "overcrowded" tickets (a few notable ones from memory #454, #6614, #7723), it's usually more preferable for long term work. In practice, the only mails on Trac-dev I go back to after a few weeks or months are those that happen to be referenced by googlegroups: links in the tickets...
The wiki is useful for giving an overview and usually there are many tickets belonging to the scope of one proposal. It combines the "long term" aspect of tickets and the readability of the mails, provided enough editing care was given. It should be used more, for example for summarizing what has been discussed on a topic of interest on the mailing list... The advantage would be that the next time the same topic is brought up on the list, that page could serve as a starting point, avoiding to repeat the same arguments over, and when there are new elements, they can be integrated in the page. For a typical example, see the WhySQLite page, which served this purpose when for some reason the topic of storing the wiki information in the db vs. in a SCM was brought over and over again. Note that this topic is /still/ current ;-)
multi-project support - from a user viewpoint, this would be a giant step forward, but it might be a nightmare for admins. I think that special care should be taken in order to making sure this remains manageable even for complex use-cases. another point is migration from pre-0.13 ad-hoc setups for multi-project to "real-0.13-multi-project". this is probably something to consider, since the main audience for this feature is probably those who already need multi-project and have some setup to achieve that.
We should have a place to collect such existing configurations, but I suppose most (all?) are of the TracMultipleProjects/MultipleEnvironments kind, whereas here we target TracMultipleProjects/SingleEnvironment. But yes, it should eventually be possible for a multiproject aware instance to "swallow" an older single project instance, under a given project name which would behave as a namespace for the resources it contains. Within those swallowed resources, the "context" would be the one of this project, so nothing special should be done in order to keep the existing links working. In fact, it should be possible to consolidate an existing set of instances related between them via InterTrac links into a single multiproject aware instance, with no disruption. From that point, extra steps could eventually be taken to promote some resources to a "parent" level, iff that makes sense for the projects in question.
you mention distributed source control support, which is indeed important, but I think it shouldn't be disconnected from actual "distributed Trac", since many use-cases for distributed source control will probably benefit from distributed issue-tracking.
Well, there's a strong connection: a distributed Trac will most certainly have to use an existing DVCS for its storage backend, and conversely, if you work with a DVCS, having a wiki and issue-tracking that can "follow" the code *can* be useful. But there are plenty of examples showing that a DVCS can work well with a centralized wiki and issue-tracking (witness GitHub and Bitbucket, for example).
So you're actually right, we don't disconnect our interest for better supporting the DVCS from DistributedTrac, as we like to think of this as long term goal (which can happen sooner or later depending on the involvement of dedicated contributors, hint hint ;-) ). But especially given the difficulty of the task, it's more profitable to start working step by step on the little features that we know will be needed (if not absolutely required) for enabling Trac to be distributed, instead of planning full support for distribution up front. Have a look at the http://trac.edgewall.org/wiki/DistributedTrac page for ideas, notably the discussion about merge and conflict resolution features.
I have posted a long email to the dev list about my use-case for distributed Trac& multi-site synchronization a while ago, which sadly caught no interest.
Sorry for that, I've seen the mail but probably got distracted by this 0.12 release ;-) I'll flag it for answering later but at any rate, just go and edit DistributedTrac and integrate your use case and questioning there.
concerning better interaction with plugin-developers, we must not forget that starting 0.12 there's also a 2nd-degree-community (assuming plugin-developers are 1st-degree-community :-) ) of plugin-translators, with workflows quite far from clear in that respect...
Yes, this is in the making, and I suppose it'll take some time until plugins start to integrate i18n support, let alone define a smooth workflow and community of translators (there was a previous mail from Steffen Hoffmann on that topic and the Transifex project he created for this - see http://trac.edgewall.org/wiki/CookBook/PluginL10N#Dotranslatorswork).
Lastly, I was a little disappointed that the issue of interface for user management (http://trac.edgewall.org/ticket/2456) is not part of the near-future roadmap, but I guess I can't have it all... :-)
At the risk of becoming redundant ;-) This is something that has been discussed numerous time on the list, maybe it's time to make a proposal, summarizing what has already been said on the topic, what are the needs / solutions proposed so far, etc.
To sum up- keep up to good work! +1 for>=py2.5 +1 for shorter release cycles
+1 for deprecating mod_python
I suppose this became clear over time, but feel free to edit the wiki in that way. We also need to move the "mapping static resources" section out of TracCgi and more generally promote mod_wsgi, trac.fcgi, and tracd (behind proxy or not) as the preferred ways to host Trac, trac.cgi being really not advised and mod_python as "use at your own risks" (well, for me it works still fine ;-) ).
-- Christian
-- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
