bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Smithers <smithers....@googlemail.com>
Subject Re: Commit Ticket Updater With Bloodhound 0.7
Date Wed, 16 Oct 2013 09:38:10 GMT
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. 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.

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
>>
>
>
>

Mime
View raw message