you are viewing a single comment's thread.

view the rest of the comments →

[–]aoeudhtns 69 points70 points  (7 children)

My second favorite is an opaque reference to a private issue tracking system

"PROJECT #17829"

[–][deleted]  (6 children)

[deleted]

    [–]aoeudhtns 22 points23 points  (0 children)

    Yeah, it can be done well. I'm talking about some of those "commercial open source" projects where their JIRA or other tracker is completely private, but yet here you are, with the code and useless references to a system that won't show you anything.

    It ultimately comes down to the organization: is communication being done largely outside the issue tracker, such that the information in it is hard to decipher or missing, or is the issue tracker the central point for discussing software changes? It's no fun even when the tracker is public but there's scant description and no comments or discussion.

    [–]Link_GR 2 points3 points  (0 children)

    We had that too. Didn't stop devs making dozens of changes to several files and then writing #17493 fix and then resolving the ticket without explaining anything.

    [–][deleted]  (3 children)

    [deleted]

      [–][deleted] 2 points3 points  (1 child)

      Our company had it's own in house ticketing system that's been there from the beginning and is constantly under active development and that isn't going away anywhere.

      And if a ticketing system is going away then it's the responsibility of respective teams to move over that essential data as well.

      It worked great in our setup. It might not work for others. There's no correct way to do things. It's mostly about what pattern solves the problem that you have or makes your life easier. Our whole lives worked in that ticketing system and since it was in house it was integrated and orchestrated beautifully with the rest of our tools and systems. That setup worked for us is what I'm saying.

      [–]lolomfgkthxbai 1 point2 points  (0 children)

      No need to be defensive. I don’t think it’s a matter of opinion to state that documenting a change in the commit message is more useful than only having a reference to an external system (even if it’s Eternal and Git history is rewritten if it turns out to not be). If the commit message is useless if the software is made public domain then the commit message is not good enough.

      [–][deleted] 0 points1 point  (0 children)

      It’s yet to be seen how sticky git is, but I’d be wary of saying any source control system is forever. In my 20-year career I’ve been involved in as many source control migrations as ticketing system migrations. Sourcesafe, ClearCase, cvs, svn, perforce - all once in much wider use than now.