incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary <gary.mar...@wandisco.com>
Subject Re: [Trac-dev] Bloodhound / Trac Approach
Date Sun, 08 Jan 2012 00:30:22 GMT
On 06/01/12 22:11, Hyrum K Wright wrote:
> Agreed.  Even with all the ideas being thrown around regarding Trac
> and the ASF and Bloodhound and everything else, I don't yet know what
> the concrete plan is for organizing and distributing Bloodhound.  We
> should hash that out here.
>
> I'll let folks with more technical knowledge than myself chime in
> here, but I'm interested to see what progresses.
>
> -Hyrum

Well, I had best get some of my ideas noted down then :)

Just to be clear, I would like to ensure that changes to core Bloodhound 
are minimised so as to keep close compatibility with Trac. Clearly there 
is an advantage to the plugin developer community if they can expect 
their plugins to work on both systems with little or no changes. It will 
also mean that any improvements made to plugins for use in Bloodhound 
should automatically benefit Trac.

Apache Bloodhound as a whole would therefore be the sum of the 
Bloodhound branch/fork of the Trac code (and so I expect this part to be 
under a BSD license), one or more Apache licensed Bloodhound plugins and 
possibly other pre-existing plugins from track-hacks.

On 06/01/12 16:32, Olemis Lang wrote:
> a decision needs to be made about this .
> IMO start this from 0.12-stable is convenient so as to ensure
> something will be ready in the next few months .
> ;)

Although we do want to be coming up with something soon, I think it 
makes sense to be looking at 0.13. There are two good reasons to do 
this: if Trac are going to take our code then I would expect them to 
want it to be developed against trunk; we probably want all the 
improvements that have gone into the latest code, including the latest 
changes to the Trac API.

Obviously there are some implications for plugins there - I have already 
noted that some existing trac-hacks do not install properly without code 
changes. With luck plugin authors will either be interested in updating 
their work for the latest Trac or perhaps they might welcome a patch 
from us.

On 06/01/12 16:32, Olemis Lang also wrote:
> My last $0.02 is that everything I mentioned before works with a
> central Subversion repository . We have been doing this in
> TracXmlRpcPlugin having :
>
> - central official svn repos @ trac-hacks
> - hg mirror @ Bitbucket
> - patch queue @ Bitbucket as well
>
> in this case workflow (simplified) is as follows :
>
> 1- hg mirror is updated (using hgsvn afaicr ...)
> 2- pending patches are updated to work with tip (optional)
> 3- new patches are created / stacked one of top of another /
>     merged , ...
> 4- if patch is updated , reviewed and ok then it's applied
>     and committed into central svn repos ...
> 5- go to step 1 ... ;)

Yes, I think that we probably want to have an official Bloodhound 
repository for this work and it would be good to be using Bloodhound as 
our issue tracker. Do we want this to be an svn repository? Have we got 
enough voices in favour of the hg patch queue to attempt that on 
bitbucket or has anyone got any opposing views?

Cheers,
     Gary

-- 
Best wishes,

Gary Martin
Lead Developer
WANdisco, Inc.

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion

Subversion community
http://www.svnforum.org

Read our blogs
http://blogs.wandisco.com/

Follow us on Twitter
http://www.twitter.com/wandisco



Mime
View raw message