On 18/03/13 10:55, Andrej Golcov wrote:
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
Well, I don't think I want to see a particular distinction between small
changes and larger (sets of) changes. I would argue that it is unlikely
for anyone to be spending all their time doing lots of small commits in
disparate areas of the code with no relationship between them over
extended periods. Where changes are related, a single ticket could be
raised to cover many such changes. Otherwise, for one-offs, the
associated overhead should not really be a significant part of a
committer's overall time.
Cheers,
Gary