trac for xml3k

[Uche Ogbuji]

Luis set up Trac for the xml3k projects at trac.xml3k.org. For now it's
tied to the Amara trunk Mercurial repository. We're discussing how to
reuse the trac instance for Bright Content and Akara as well. Obviously
one approach would be to have 3 separate trac instances, say:
trac.amara.xml3k.org, trac.akara.xml3k.org , etc. The problem with that
is that it offers no connection between the instances unless we develop
something to tie them together. Probably a nicer option would be if a
single instance of Trac could organize several subprojects, binding to
several Hg repositories. Luis is not sure the Mercurial plugin for Trac
supports this, though.

It would be nice to get Trac properly into service, so if anyone has
ideas, or experience dealing with Trac and Hg, we'd appreciate any input.

Thanks.

--
Uche Ogbuji http://uche.ogbuji.net
Founding Partner, Zepheira http://zepheira.com
Linked-in profile: http://www.linkedin.com/in/ucheogbuji
Articles: http://uche.ogbuji.net/tech/publications/

[Eric Larson]

Hi All,

On Thu, Apr 10, 2008 at 9:00 AM, Uche Ogbuji <uc...@ogbuji.net> wrote:
>
> Luis set up Trac for the xml3k projects at trac.xml3k.org. For now it's
> tied to the Amara trunk Mercurial repository. We're discussing how to
> reuse the trac instance for Bright Content and Akara as well. Obviously
> one approach would be to have 3 separate trac instances, say:
> trac.amara.xml3k.org, trac.akara.xml3k.org , etc. The problem with that
> is that it offers no connection between the instances unless we develop
> something to tie them together. Probably a nicer option would be if a
> single instance of Trac could organize several subprojects, binding to
> several Hg repositories. Luis is not sure the Mercurial plugin for Trac
> supports this, though.
>
> It would be nice to get Trac properly into service, so if anyone has
> ideas, or experience dealing with Trac and Hg, we'd appreciate any input.
>
> Thanks.
>

When talking with Luis in the channel about it I pointed out the
Mercurial Repo plugin[1] along side the Multiple Repo[2] plugin. My
thought was that we could simply use trac's component feature to help
utilize things like the roadmap and timelines. Uche, you made the
point that it is probably better to avoid specific conventions in
organizing trac so people don't have to learn *our* version of trac. I
think this also makes sense.

If someone sees a good way to manage a set of projects in trac without
any sort of conventions, then that seems like a good way to reduce the
addition of multiple systems. If not and we need to have more
instances setup, I'm happy to help with the cost in terms of any extra
webfaction accounts or anything.

I'm not really adding anything new here, except the potential
requirement to *not* simply use conventions as a means of managing
subprojects in trac.

Eric

[1] http://trac.edgewall.org/wiki/TracMercurial
[2] http://trac.edgewall.org/ticket/2086

[Luis Miguel Morillas]

I'm writing here my work with trac:
http://wiki.xml3k.org/Managing_the_projects . I'm reading that it's
posible to manage three projects with a single trac, but I don't now
how to configure it. Not yet almost. ;-)

2008/4/10, Eric Larson <ion...@gmail.com>:

--
Saludos,

--

Luis Miguel