Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <514477AA.5010602@wandisco.com>
References: <058.69e42561dfc157c4cef849d58629a3e1@incubator.apache.org>
	<CABD8fLVtH7OtYFPtAQLmrhX26Em6Ka+wQ3KV36vy1Npa+6n1Qw@mail.gmail.com>
	<CAPt9QwQPaiWdDg=Oja2ApgdGD2FKQecd_YvE5mGRNg3hLpQ7Ag@mail.gmail.com>
	<514477AA.5010602@wandisco.com>
Date: Mon, 18 Mar 2013 11:55:47 +0100
Message-ID: 
 <CAHM0gniHH4t_ukmtN27uuiif5i1P=LeYGxoKK9MgoQ3p_1sq8A@mail.gmail.com>
Subject: Re: [Apache Bloodhound] #467: About page should include a link to
 Apache Bloodhound
From: Andrej Golcov <andrej@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf3074d222d4095304d830d46f

--20cf3074d222d4095304d830d46f
Content-Type: text/plain; charset=ISO-8859-1

I agree with Gary and just want to add my opinion where I found usage of
issue tracker useful during BH development.

BH project is quite young and often commits include a lot of code and it
can be hard to follow in-code TODOs for other developers. In such case,
adding a ticket with TODO task is more obvious to me. Using tickets for
planning of new features is also looks more convenient to me

IMHO, where we can avoid unnecessary overhead is not using issue tracker
for small-to-medium obvious changes. IOW, if we see obvious problem or
improvement - just fix it and don't spend time for creating-closing
tickets. That also means that not all commit messages should contain
#ticket number.

Cheers, Andrej


On 16 March 2013 14:46, Gary Martin <gary.martin@wandisco.com> wrote:

> On 16/03/13 12:36, Ryan Ollos wrote:
>
>> On Sat, Mar 16, 2013 at 1:44 AM, Greg Stein <gstein@gmail.com> wrote:
>>
>>  How about leaving some TODO markers in the page via commit? Maybe
>>> somebody will follow up on that commit, and actually make the changes.
>>>
>>>  Joe filled this ticket and he's primarily a designer rather than a
>> developer. It doesn't make sense for him to checkout and edit the codebase
>> in order to ask for something to be implemented.
>>
>>
>>  Why should the marker be within a ticket, instead of the codebase
>>> itself? Again, if somebody goes to fix this, then they have
>>> double-work: make some commits, and make some ticket changes.
>>>
>>>  Maybe you don't think that an issue tracker should exist at all? You
>> continue to suggest that we not use the issue tracker for anything as far
>> as I can tell. You seem to feel that Subversion and the mailing list are
>> entirely adequate, and an issue tracker would then be used for what? I
>> disagree, and I can't speak for others, but I get the impression that I'm
>> not alone in disagreeing.
>>
>>
>>  The ticket system is entirely divorced from the codebase. Consider:
>>> community members can spend the next month handling tickets. Does that
>>> accomplish anything? Nope. Alternative: work within the actual
>>> product, making changes/notes as they are discovered.
>>>
>>>  I'd suggest that we aim to improve the integration of the ticket system
>> with the code base and correct the flaws here, rather than giving up and
>> not using the ticket system.
>>
>> I'm not going to repeat any of my arguments of why I think the ticket
>> system is better and more valuable than a mailing list, but you can read
>> them in (1) if you like.
>>
>> On Sat, Mar 16, 2013 at 1:40 AM, Greg Stein <gstein@gmail.com> wrote:
>>
>>  This is better discussed on the mailing list, rather than moving the
>>> discussion over to a ticket.
>>>
>>> The majority of the community is on the dev@ list. By placing this
>>> question into a ticket, you're dividing the set of people who may want
>>> to discuss this item. You're also attempting to flow the discussion
>>> into the ticket, rather than here on the dev@ list, where the larger
>>> community resides.
>>>
>>>  We are building an issue tracker and we'd like users to use that issue
>> tracker. Discussing issues may be the first interaction they have with
>> Bloodhound and it would be nice to expose them to our product.
>>
>> I'm willing to change how we do things for Bloodhound if there is *a
>> consensus among the community* that things should be done differently. I'd
>> like to hear if others agree with the viewpoint of our mentor. I
>> respectfully disagree.
>>
>> (1)
>> http://markmail.org/search/?q=**bloodhound%20#query:**
>> bloodhound%20list%3Aorg.**apache.incubator.bloodhound-**
>> dev%20order%3Adate-backward+**page:2+mid:3uuwhkztmtipdchw+**state:results<http://markmail.org/search/?q=bloodhound%20#query:bloodhound%20list%3Aorg.apache.incubator.bloodhound-dev%20order%3Adate-backward+page:2+mid:3uuwhkztmtipdchw+state:results>
>>
>>
> I have to agree with Ryan to a large extent. I don't see it as a
> particular hardship to be using the issue tracker to track our work and
> share it out. Using svn for this purpose seems like a poor substitute and
> could certainly be considered as being more difficult to use when we want
> note that a piece of work is to be done, see whether the work is in
> progress or if the work can be done by someone else. The idea that
> switching context is a particular hardship is a bit strange as there is
> already a switch of context to commit work.
>
> Where I agree with our mentors is that we are getting too much commenting
> on issues in the issue tracker if we assume that the larger developer
> audience is on the dev mailing list.
>
> So, I suggest that we
>
>  * continue to raise tickets for all our work,
>  * redirect discussion and request for clarifications to the dev
>    mailing list as much as possible,
>  * continue to use ticket comments to record revision numbers for that
>    ticket - note that it can be appropriate to list multiple revisions
>    in a single comment depending on the period over which work is done
>
> Cheers,
>     Gary
>
>

--20cf3074d222d4095304d830d46f--