I think, seven years later, we can safely say that git has taken off without distributed bug tracking.
There are some good reasons why you don’t want distributed bug tracking. When you fix the bug on the plane, customers don’t get that fix. Their reality has not changed. Ok, sure, the status change will get merged with the code change, but then… Which bug tracker do you check when you show up each morning? Yours or theirs? If the fix has not been delivered, then the bug is not done. I can easily imagine the trouble that can arise seeing that ones own tracker says zarro boogs when nothing has been pushed. I’ve already seen this happen when code changes don’t propagate, but the open bug serves as a safeguard reminder. Ultimately, the focus needs to be on the deliverable. Keeping everybody’s understanding of a bug’s status in the same reality helps.
I think, seven years later, we can safely say that git has taken off without distributed bug tracking.
There are some good reasons why you don’t want distributed bug tracking. When you fix the bug on the plane, customers don’t get that fix. Their reality has not changed. Ok, sure, the status change will get merged with the code change, but then… Which bug tracker do you check when you show up each morning? Yours or theirs? If the fix has not been delivered, then the bug is not done. I can easily imagine the trouble that can arise seeing that ones own tracker says zarro boogs when nothing has been pushed. I’ve already seen this happen when code changes don’t propagate, but the open bug serves as a safeguard reminder. Ultimately, the focus needs to be on the deliverable. Keeping everybody’s understanding of a bug’s status in the same reality helps.
Link back to previous fossil post: https://lobste.rs/s/p2fpgn/fossil_not_so_new_dvcs_from_sqlite_author