Re: Is it alive?

[Oscar Edvardsson]

And we went with Redmine (multi product support was a requirement).
If you don’t need multi product support, I think Trac has the advantage that 
if/when Bloodhound becomes under active development, it is easy to make the 
switch. We never experienced any bugs with Bloodhound (v0.7 and v0.8) during 
the 6-12 months of using it, but we needed something that was regularly 
maintained so any bugs would eventually be resolved.

That aside, I think we as users are sometimes more demanding than fair. It is 
an open source project, and as far as I have understood it, all development 
(now) occurs on the developers' free time and without compensation. The nature 
of open source allows anyone to fix bugs, to their best of their abilities, 
which in turn allows you to patch issues that are important to you, but not 
prioritised by the core development team. (But for us who do not have the 
ability or time to do it - regular maintenance is a big thing)

Sorry for the short rant, keep up the good work!

Regards,

> On 11 Sep 2015, at 08:28, Joseph D. Wagner  wrote:
> 
> I went with Request Tracker.  It has a different set of problems -- every 
> ticket system does -- but it seems more manageable and definitely has active 
> support.
> 
> https://www.bestpractical.com/rt/ 
> 
> In fairness to the BH team, this is a symptom of a systemic problem with 
> Apache projects that aren't considered "hip."
> * James http://james.apache.org/ .  Email server 
> with no active development since 2012.  It died right in the middle of 
> beta-testing it's next major release.
> * SpamAssassin http://spamassassin.apache.org/ 
> .  No active development between 2011 and 
> 2014, but might be picking up again.
> * Geronimo http://geronimo.apache.org/ . Java EE 
> 6 application server with no development since 2013.  However, in Apache's 
> defense, it could be said that Oracle killed Java.
> 
> Joseph D. Wagner
> 
> On 09/10/2015 10:50 PM, Hoiniji Rosonye wrote:
>> I think going to Trac is a good decision.  With all due respect to the BH 
>> team, I think it still has a long way to go.  I first gave BH a try, but it 
>> had too many bugs or configuration limits.  I then decided to try Trac, and 
>> I found that it was very rock solid.
>> 
>> On Sep 10, 2015 9:42 PM, "Torben Lauritzen" > > wrote:
>> Hi.
>> 
>> Thank you for your replies - I will go with the standard Trac for the moment 
>> then. But I will be following Bloodhound.
>> 
>> /Torben
>> 
>> > -Original Message-
>> > From: Olemis Lang [mailto:ole...@gmail.com ]
>> > Sent: 11. september 2015 05:57
>> > To: user@bloodhound.apache.org 
>> > Subject: Re: Is it alive?
>> >
>> > JFTR , I am working on a private fork of Bloodhound that I use for my
>> > deployments . Nonetheless I've had to slow down my dev speed because I'm
>> > contributing with code to the Brython project , and I've not had all the 
>> > time
>> > I'd like these days for BH dev .
>> >
>> >
>> > On 9/10/15, Ryan J Ollos > 
>> > wrote:
>> > > On Thu, Sep 10, 2015 at 6:38 AM, Torben Lauritzen > > > > wrote:
>> > >
>> > >> Hi.
>> > >>
>> > >> I was just about to install Trac, when I found Bloodhound. I have
>> > >> tried installing it, and it seems ok. But at the same time it also
>> > >> looks like the project is more or less dead - last release was
>> > >> 2014-12-11, the documentation has unfinished things, e.g.  the
>> > >> section about git here:
>> > >> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall 
>> > >>  (the page
>> > >> was last edited 7 months ago), there is a warning
>> > >> (SubversionException) at the top of the Wiki pages etc.
>> > >>
>> > >> So, I just wanted to know if the project is still alive? Are anybody
>> > >> working actively on the project?
>> > >>
>> > >
>> > > Yeah there hasn't been much activity lately. I don't have any
>> > > immediate plans or time to work on Bloodhound in the near future, but
>> > > I'd be interested to hear if any other developers will be working on it.
>> > >
>> > > - Ryan
>> > >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Olemis - @olemislc
>> >
>> > Apache™ Bloodhound contributor
>> > http://issues.apache.org/bloodhound 
>> > http://blood-hound.net 
>> >
>> > Brython committer
>> > http://brython.info 
>> > http://github.com/brython-dev/brython 
>> > 
>> >
>> > Blog ES: http://simelo-es.blogspot.com/ 
>> > Blog EN: http://simelo-en.blogspot.com/ 
>> >
>> > Featured 

Product / Version strategies

[Oscar Edvardsson]

Hi all,

I am about to set up a new Bloodhound server. I have a structure issue though.
We aim at using the wiki and ticket system to manage three different parts of 
our system. Each part may involve software/firmware, hardware and/or mechanics, 
and each of these have different versions. It may look like below.
I am aware that Bloodhound is primarily intended for software development, but 
I think it would fit our issue management neatly.

 System A 
 +-- Part A
 | +-- Software
 | |  + Version 1
 | |  + Version 2
 | +-- Hardware
 | |  + Version 1
 | +-- Mechanical
 |+ Version 2
 +-- Part B
   +-- Software
 . +--- Version 1
 .
 .


My initial, and most intuitive, way of structuring this was to have one product 
for each part. Each part/product would then have the components Software, 
Hardware and Mechanics.
The issue arrived when I realised the version numbering for the components does 
not match. I.e. Software Version 2 may run on Hardware Version 1. One 
workaround would have to list all versions, but then Version 2 for Software 
does not correspond to Version 2 for Hardware. This means that, e.g. version 
description is not really applicable, as a version is actually two (or three) 
different versions. This also matches our directory structure most closely.

The next idea was to separate Software, Hardware and Mechanics into different 
products, but I find this less intuitive and there will be an even greater 
issue with versions existing in one of the parts, but not the others (i.e. Part 
A, Version 2 vs. Part B, Version 1.5).

Third idea was to separate the parts into different projects, but then the 
parts are not “grouped”, so if we add a new system there is no way of telling 
which projects belong to which system.

Are there any good approach to fulfil the following:
 - Separate the three parts
 - Separate the three different disciplines (Software, Hardware, Mechanics)
 - Versions are tied to the discipline

Very off-topic: Maybe Order deny,allow Allow from all in the Bloodhound 
installation instructions should be changed to Require all granted? I had to do 
that to get the setup to work, thought I’d let you know anyway.

Thanks in advance,

Re: Product / Version strategies

[Oscar Edvardsson]

Thank you both for yor kind answers!

I would like to tinker as little as possible to avoid disaster (often happens 
when I tinker) and help maintenance.

I can now really appreciate the idea of separating by discipline. I will 
definetly have to think about that.

Off-topic: I never saw what Apache version it was for, I just assumed it was 
the latest and greatest. :) My bad.

 26 aug 2015 kl. 23:10 skrev Olemis Lang ole...@gmail.com:
 
 On 8/26/15, Oscar Edvardsson os...@monivent.se wrote:
 Hi all,
 
 Hi !
 :)
 
 I am about to set up a new Bloodhound server. I have a structure issue
 though.
 We aim at using the wiki and ticket system to manage three different parts
 of our system. Each part may involve software/firmware, hardware and/or
 mechanics, and each of these have different versions. It may look like
 below.
 
 In my experience sometimes the best way to structure issue tracking is
 by discipline , instead of system's organisation . In a real world
 similarly complex deployment what I did was the following :
 
 Two BH instances , one for each intl branch .
 
 Six domains (mapped 2 to 4 onto BH instances) for each discipline
 (mechatronic , soft eng , automatic control , 3D design ,
 manufacturing , sales/customer support/strategy) . Products names in
 those instances were mapped onto domains by prefix e.g. mech_sensor1
 = mech_sensor1.mech.domain.tld , swe_app1 = swe_app1.swe.domain.tld
 , ...
 
 The separation of domains helped us to deal with authentication ,
 cookies , and alike ... In each case , components + milestones +
 versions .
 
 HTH
 
 [...]
 
 -- 
 Regards,
 
 Olemis - @olemislc
 
 Apache™ Bloodhound contributor
 http://issues.apache.org/bloodhound
 http://blood-hound.net
 
 Brython committer
 http://brython.info
 http://github.com/brython-dev/brython
 
 Blog ES: http://simelo-es.blogspot.com/
 Blog EN: http://simelo-en.blogspot.com/
 
 Featured article:

Re: upgrading to 0.8

[Oscar Edvardsson]

Not an expert at all, but what database backend are you using? I successfully 
upgraded from Version 0.7 to 0.8 using MySQL.

I also have the mentioned base_url-warning, but it hasn't affected me, afaik.

Can you create another (empty) install?

 16 mar 2015 kl. 21:49 skrev Tim Tisdall tisd...@gmail.com:
 
 I'm kind of stuck with a useless install here...  Is there nothing I
 can do to fix this?
 
 On Mon, Mar 9, 2015 at 3:47 PM, Tim Tisdall tisd...@gmail.com wrote:
 Any debugging commands (ie inserting of logging statements, etc) I
 could run to give you some additional information on this?
 
 On Fri, Mar 6, 2015 at 2:28 PM, Tim Tisdall tisd...@gmail.com wrote:
 On Fri, Mar 6, 2015 at 2:27 PM, Ryan J Ollos rjol...@apache.org wrote:
 What version are you upgrading from?
 
 I'm upgrading from 0.7

Link to Wiki page in base wiki from product wiki

[Oscar Edvardsson]

Hi,

I'm sure there is an answer to this, but I can not find it. I am trying 
to create a wiki link between a page in a product and the main wiki. I.e.


Project/products/ProductA/wiki/PageA - Project/wiki/PageB

If I simply type PageB in PageA, this would not create a link working, 
persumably because it will try to link to a wiki page in the same 
product (i.e. to Project/products/ProductA/wiki/PageB). So, how would 
you create a link to a page in the main wiki (i.e. no product). I tried 
creating server relative links, but didn't get that to work for some reason.


I can see the rationale (if there is one) that you can not link between 
two products (as these should be independent, in my thinking), but to 
the base wiki I believe should be possible (project related info can be 
good to have available in product pages).


Regards,

Re: Link to Wiki page in base wiki from product wiki

[Oscar Edvardsson]

Thanks,

Works as you said. Didn't work for referencing across products though 
(e.g. [product:ProductB:PageB]), but doesn't really matter for me right now.


Regards,

On 2014-12-16 16:02, Eric Jouffrey wrote:

Hello,
I think I can help you on that because I recently find it out myself...
In your PageA you can have a link :
[product::PageB]
that will do the job.

From the same idea, you can link to PageB if it's another product by 
/[product:ProductB:PageB]/
And you should use /[product:ProductB://WikiStart]/ for link to the 
home page of the ProductB or [product::WikiStart] for link to the main 
homepage from any product.


The only problem is that give a name to the cross-products links 
doesn't seems to work.. For any of [product::PageB link name], 
[product::PageB|link name], [[product::WikiStart|Home]], It's always 
the wiki page label wich is displayed ('PageB', 'WikiStart').




On 12/16/2014 12:45 PM, Oscar Edvardsson wrote:

Hi,

I'm sure there is an answer to this, but I can not find it. I am 
trying to create a wiki link between a page in a product and the main 
wiki. I.e.


Project/products/ProductA/wiki/PageA - Project/wiki/PageB

If I simply type PageB in PageA, this would not create a link 
working, persumably because it will try to link to a wiki page in the 
same product (i.e. to Project/products/ProductA/wiki/PageB). So, how 
would you create a link to a page in the main wiki (i.e. no product). 
I tried creating server relative links, but didn't get that to work 
for some reason.


I can see the rationale (if there is one) that you can not link 
between two products (as these should be independent, in my 
thinking), but to the base wiki I believe should be possible (project 
related info can be good to have available in product pages).


Regards,

New release?

[Oscar Edvardsson]

Hi all,

There is well over a year since the latest release and the latest mention of a 
new release was in the dev mailing list 2014-09-14, after which nothing 
happened.
http://mail-archives.apache.org/mod_mbox/bloodhound-dev/201409.mbox/%3c5410e8f8.5040...@wandisco.com%3e

Is there any reason to expect there will be a new release anytime soon?
We love Bloodhound, but we can not use a system that is not actively maintained.

Kind regards