Return-Path: X-Original-To: apmail-bloodhound-user-archive@www.apache.org Delivered-To: apmail-bloodhound-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CAB66104E3 for ; Tue, 16 Dec 2014 18:57:32 +0000 (UTC) Received: (qmail 37467 invoked by uid 500); 16 Dec 2014 18:57:32 -0000 Delivered-To: apmail-bloodhound-user-archive@bloodhound.apache.org Received: (qmail 37439 invoked by uid 500); 16 Dec 2014 18:57:32 -0000 Mailing-List: contact user-help@bloodhound.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@bloodhound.apache.org Delivered-To: mailing list user@bloodhound.apache.org Received: (qmail 37430 invoked by uid 99); 16 Dec 2014 18:57:32 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Dec 2014 18:57:32 +0000 Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 89F8C1A0041 for ; Tue, 16 Dec 2014 18:57:30 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ij19so6676647vcb.36 for ; Tue, 16 Dec 2014 10:57:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.17.144 with SMTP id s16mr11129276vca.10.1418756247774; Tue, 16 Dec 2014 10:57:27 -0800 (PST) Received: by 10.52.252.136 with HTTP; Tue, 16 Dec 2014 10:57:27 -0800 (PST) In-Reply-To: References: <549067D3.6050603@millcomputing.com> Date: Tue, 16 Dec 2014 10:57:27 -0800 Message-ID: Subject: Re: Broken demo link From: Ryan J Ollos To: user@bloodhound.apache.org Content-Type: multipart/alternative; boundary=001a11c3c76e2bec2e050a59eeaa --001a11c3c76e2bec2e050a59eeaa Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 10:06 AM, Michael Jinks wrote: > > More broadly... What's the QA landscape for this project? I sort of get > the impression that this is one of those projects that works well for the > people creating it, but doesn't get much in the way of formal review on its > way to release. > The changes are peer-reviewed and tested by developers contributing to the project. The release manager is responsible for smoke-testing the project before release, and those voting on the release should do the same. It is important to the success of the project that the community is testing changes and testing the overall project, reporting issues as they arise. One advantage to an open source project is that all reported issues are visible to end users through the mailing list and issue tracker. You can know as much as you like about the project, dependent only on the amount of time you're willing to contribute to reviewing it. > That's great if the releases are frequent and allow those of us at the > endpoint to do our own dev/test/push cycle in the face of incremental > changes each time we see a fresh version, but with infrequent releases > showing major changes that's a tough pattern to maintain. > You are right, it is important that the project do more frequent incremental release if it is to be successful. That is one of the things I have pushed for in the Trac project, and we are on track for a release every 2 months now. The Bloodhound project is suffering from a lack of contributors, but if we can pickup momentum again a 2-4 month release cycle would be ideal. > Sorry to gripe. I like Bloodhound a lot and I'm pushing for its success. > > > > On Tue, Dec 16, 2014 at 11:11 AM, Arthur Kahlich > wrote: >> >> I am sure you already know about this. >> >> I have a couple of older guys looking at bloodhound as part of an >> evaluation of which issue tracker to go with. Naturally, both of them >> within *seconds* of looking at the default local installed home page >> without any prompting went to the bloodhound home page and hit the >> broken demo link. It's a bad first impression, and if not fixed it >> should be removed. I will certainly be removing *any* links to the >> bloodhound home pages that contain the broken link from my installation. >> These 2 guys were my friendly reviewers - some others will not be so >> friendly, with a couple of them that may be downright hostile. >> >> -- >> Arthur Kahlich >> CTO - Hardware >> Mill Computing, Inc. >> Box 1531 >> Palo Alto CA 94302-1531 >> Phone: (408)480-3680 >> -- >> Faster, Cooler, Safer Computing. >> -- >> >> --001a11c3c76e2bec2e050a59eeaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 10:06 AM, Michael Jinks <michael.jinks@gmail.c= om> wrote:
Mor= e broadly... What's the QA landscape for this project? I sort of get th= e impression that this is one of those projects that works well for the peo= ple creating it, but doesn't get much in the way of formal review on it= s way to release.

The changes are pee= r-reviewed and tested by developers contributing to the project. The releas= e manager is responsible for smoke-testing the project before release, and = those voting on the release should do the same.

It is important to t= he success of the project that the community is testing changes and testing= the overall project, reporting issues as they arise. One advantage to an o= pen source project is that all reported issues are visible to end users thr= ough the mailing list and issue tracker. You can know as much as you like a= bout the project, dependent only on the amount of time you're willing t= o contribute to reviewing it.
=C2=A0
That's great if the releases are frequen= t and allow those of us at the endpoint to do our own dev/test/push cycle i= n the face of incremental changes each time we see a fresh version, but wit= h infrequent releases showing major changes that's a tough pattern to m= aintain.

You are right, it= is important that the project do more frequent incremental release if it i= s to be successful. That is one of the things I have pushed for in the Trac= project, and we are on track for a release every 2 months now. The Bloodho= und project is suffering from a lack of contributors, but if we can pickup = momentum again a 2-4 month release cycle would be ideal.
=C2= =A0
Sorry to grip= e. I like Bloodhound a lot and I'm pushing for its success.
<= br>


On Tue, Dec 16, 2014 a= t 11:11 AM, Arthur Kahlich <art@millcomputing.com> wrote= :
I am sure you already know about this.

I have a couple of older guys looking at bloodhound as part of an
evaluation of which issue tracker to go with. Naturally, both of them
within *seconds* of looking at the default local installed home page
without any prompting went to the bloodhound home page and hit the
broken demo link. It's a bad first impression, and if not fixed it
should be removed. I will certainly be removing *any* links to the
bloodhound home pages that contain the broken link from my installation. These 2 guys were my friendly reviewers - some others will not be so
friendly, with a couple of them that may be downright hostile.

--
Arthur Kahlich
CTO - Hardware
Mill Computing, Inc.
Box 1531
Palo Alto CA 94302-1531
Phone: (408)480-3680
--
Faster, Cooler, Safer Computing.
--

--001a11c3c76e2bec2e050a59eeaa--