On Tue, May 31, 2011 at 15:07, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
>>
>> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>>>
>>> One of the conclusions the study group came to was that there should
>>> be good integration between the tracker system and the SCM. That was
>>> in the days before distributed SCMs were common, and in a commercial
>>> context, so I'm not sure how well our reasoning would stand up for the
>>> current context, but I see it's been mentioned elsewhere and I think
>>> it's a significant consideration, at least.
>>
>> What kind of functionality would (good) SCM integration provide?
>>
>
>
> Well, the most obvious one is that when a commit (or merge or push) is made
> that fixes a bug, the bug is annotated and its status updated. I know I've
> wasted plenty of time in the past first hunting for bugs and then hunting
> for the fixes, which aren't always clear from the commit messages.
As long as we properly track email, we don't actually need a direct
integration with the SCM for this - since we send the commit message
out to the -committers list anyway, we just need to pick it up there.
> In a more centralized system you can also have fairly tightly integrated
> workflow (e.g. you can have the tracker open a branch when a bug is
> assigned, and you can prevent one being created without an issue being
> assigned) but that doesn't seem like such a good fit for us, nor for anyone
> using a distributed system like git. You could also argue that it's a bad
> thing for commercial organizations, but that's a debate for another place.
> The reason we wanted such a thing is that we were spending significant time
> managing the workflow issues, and doing tidy up.
Yeah, that does sound like a very bad idea *for us*.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
