bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: Commit Ticket Updater With Bloodhound 0.7
Date Wed, 16 Oct 2013 14:36:14 GMT
On 16 October 2013 10:38, Ben Smithers <smithers.ben@googlemail.com> wrote:

> This problem isn't unique to commit messages - #1 is a part of Trac Wiki
> Formatting, so this is also a problem for anything else in global context
> (e.g. global wiki).
>
> Personally I dislike the idea of ticket numbers being re-used across
> projects (to me, it just seems likely to create ambiguity and confusion -
> both in code and for users), but apparently this is a necessary change?
> Assuming this is the case, my thoughts as follows.
>
>
> > I don't believe explicitly linking repos to products explicitly to allow
>> #1
>> > links is the correct approach.
>> I've been thinking twice about it and I do not think that's an option
>> either .
>
>
>  I don't entirely see why it has to be so black-and-white. *If* a
> repository is only linked to one project, #1 is not ambiguous.
>

.. if one repository is linked to one product, but other repos are not, #1
is ambiguous in all of the others. This is obvious logically but not
necessarily at the front of peoples mind when they're committing changes or
switch between products. Using the fully qualified IDs just makes it really
easy.

Why is it important that the non-prefixed syntax is supported? If it never
existed in the first place, would you miss it?


 Why not have the format as #Prod-1 (or perhaps, #Prod:1) but allow the
> product prefix to be dropped where there is only one project linked to the
> repository. Perhaps this could be an option in the configuration.
>
> I mean , if repos R is linked to product P1 & P2 then #P1-3 will update
>> ticket 3 @ P1 , but #P4-8 will
>> be ignored with a warning (error ?) message . Is this convenient ?
>
>
>
>> Difficult to correct for user error like this. I don't think not being
>> able to match something should be a warning or error message - just one to
>> inform the user (ie lower priority). It's easy to fix via the web interface
>> if a change wasn't triggered by a commit.
>
>
> The hook is implemented at post-commit/post-receive so it's not possible
> to reject it anyway (You could add an additional hook before hand, but this
> seems unnecessarily complex to me). I agree with Joe that simply warning
> the user the ticket id was not resolved is appropriate. I imagine that
> forgetting the product prefix entirely will be the more common error though.
>

>From my experience with other ticketing systems this is only a common error
during a brief transition period to prefixed IDs, or permanently if the
system mixes prefixed and non-prefixed IDs. I suggest we should always
prefix ticket IDs.

- Joe


>
>
> Ben
>
> On 16 October 2013 09:56, Joachim Dreimann <joachim.dreimann@wandisco.com>wrote:
>
>>
>>
>>
>> On 15 October 2013 19:33, Olemis Lang <olemis@gmail.com> wrote:
>>
>>> On 10/15/13, Joe Dreimann <joachim.dreimann@wandisco.com> wrote:
>>> >
>>> >
>>> >> On 15 Oct 2013, at 23:03, Olemis Lang <olemis@gmail.com> wrote:
>>> >>
>>> >>> On 10/15/13, Ben Smithers <smithers.ben@googlemail.com> wrote:
>>> >>> Olemis,
>>> >>>
>>> >>> As you suggested, I've created a new ticket for this:
>>> >>> https://issues.apache.org/bloodhound/ticket/695
>>> >>
>>> >> Accepted . Thanks !
>>> >>
>>> >>>> No , because the repositories are global . This means that it
will
>>> be
>>> >>>> necessary to configure which product the vcs ticket updater
will act
>>> >>>> upon .
>>> >>>
>>> >>>
>>> >>> You 'link' repositories to products though?
>>> >>
>>> >> Exactly , if a given repository is bound to several products then what
>>> >> ticket shall be updated if commit message contains refs #1 ?
>>> >>
>>> >> [...]
>>> >
>>> > We can't update a ticket with it, at best we can provide some
>>> disambiguation
>>> > mechanism.
>>> >
>>>
>>> Yes , you are right .
>>>
>>> > Only #PROD-1 can be a valid link in a multi product environment.
>>> >
>>>
>>> Agreed
>>>
>>> > I don't believe explicitly linking repos to products explicitly to
>>> allow #1
>>> > links is the correct approach.
>>>
>>> I've been thinking twice about it and I do not think that's an option
>>> either .
>>>
>>> > Maybe optionally for migrated/merged
>>> > environments.
>>> >
>>>
>>> hmmm ... I do not think so , in those case I'd rather recommend using
>>> RPC or alike .
>>>
>>> Nevertheless , I've been hesitating about whether to allow / disallow
>>> ticket updates based on links .
>>
>>
>> It's optional already so left to the users to decide, right?
>>
>>
>>> I mean , if repos R is linked to
>>> product P1 & P2 then #P1-3 will update ticket 3 @ P1 , but #P4-8 will
>>> be ignored with a warning (error ?) message . Is this convenient ?
>>>
>>
>> Difficult to correct for user error like this. I don't think not being
>> able to match something should be a warning or error message - just one to
>> inform the user (ie lower priority). It's easy to fix via the web interface
>> if a change wasn't triggered by a commit.
>>
>> - Joe
>>
>>
>>>
>>> --
>>> Regards,
>>>
>>> Olemis - @olemislc
>>>
>>
>>
>>
>


-- 
Joachim Dreimann | *User Experience Manager*

WANdisco // *Non-Stop Data*

e. joachim.dreimann@wandisco.com
twitter @jdreimann <https://twitter.com/jdreimann>

Mime
View raw message