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
