[Opinions] Integrated tickets

Hi, many developers rely on ticket systems (githubs issues, trac, bugzilla, etc.). To me a ticket often has a relation to one or more commits.

Hence, even if git is functional in an offline enviroment, I can't work fully since none of the ticket systems above is distributed.

This can be solved with a distributed ticket system. Fossil SCM is one example of an integrated ticket system into a scm (although please don't think about this is something that must be web-based).

So my question is:

what's your opinions on building an integrated ticket system on top of git?

and (maybe mostly for Junio)

Would such system possible be included in git.git?

TL;DR; Is an integrated ticket system something for git?

On Wed, Nov 05, 2014 at 01:44:29PM +0100, Fredrik Gustafsson wrote:

I think it's a nice concept, but there have been several implementations, and AFAIK none of them is incredibly popular. I do not know offhand if the problem is the concept or the implementations (I looked at them long ago but don't remember enough to provide any sort of reasonable critique).

I started to assemble a list of pointers, but I realized that 4 out of 5 of the projects that I had looked at a few years ago no longer exist. ;)

Here's an article from last year with a nice overview of the (non-)state and links to other sources:

  https://www.stationary-traveller.eu/distributed-bug-trackers.html

I am not Junio, but I would have to say: probably not. This seems like something that can very easily sit on _top_ of git and use the git plumbing. In the long-term git may want to grow features to make integration more seamless, but we'd probably want to add them in a more functionality-agnostic way (e.g., don't grow an option to attach bug information to a commit; grow an option to attach arbitrary information to a commit. We already have this part in the form of "git notes", but there are likely other opportunities for integration).

-Peff

Fredrik Gustafsson <iveqy@iveqy.com> writes:

Integrated? Not really, unless we already have a clear winner in the marketplace that we can just ship in contrib/ or something, and even then, the Git ecosystem is now rich enough and the userbase strong enough that having something in contrib/ adds much less value than additional burden of having to keep up with the upstream, and user confusion coming from possible version skew from the upstream. It used to make a lot of sense to ship Git with things like gitweb and gitk when we were trying to gain momentum, but it is no longer 2005 ;-). Even kernel.org does not run gitweb anymore.

This is a tangent, but I personally do not think "ticket" meshes very well with "commit". If you already know which commit was problematic, why are you annotating it with a ticket before reverting it first?

Am 06.11.2014 um 19:45 schrieb Junio C Hamano:

I would expect a ticket to be annotating the commit or version tag where the bug was found, which usually isn't the commit where the bug was introduced.

Holger Hellmuth <hellmuth@ira.uka.de> writes:

You could arrange your "tickets" in such a way, but in general, the way you organize your data should match how the data is expected to commonly be accessed.

If somebody finds a bug when the version he happened to be using was v1.8.5-9-g144d846, do you mean to attach that ticket to that exact commit? Or do you use v1.8.5^0 (i.e. the closest tagged version) after making sure that it is not a commit between these two that introduced it as a new bug?

Either way, I do not see how such an arrangement is the most convenient way to organize the tickets and ask questions such as "what are the known, untriaged, or unresolved issues in v1.8.5?", "what are the issues that didn't exist in v1.7.0 but appear in v1.8.5?", "what are the outstanding issues around refs handling that are the highest priority?", etc. With your arrangement of data, any of the common questions I think of asking would require a linear scan of a commit range, followed by an enumeration and parsing of all the notes attached to the commits to answer.

So I would have to say that your expectation makes even less sense than annotating an exact buggy commit with a note saying what is broken by it.

Am 11.11.2014 um 18:17 schrieb Junio C Hamano:

[...]

Not less sense, because with tickets attached to the exact buggy commit one would have the same problems answering the questions above. I don't dispute that tickets and commits don't mesh, it was the reason that you gave the first time that didn't sound right. Sorry if I have wasted your time, but looking at it from the management side removed any lingering doubts for me that there might be a benefit to an integration, even if some sort of indexing or database was used.

Junio C Hamano <gitster@pobox.com> writes:

Not that annotating the commit as "this commit has this bug" makes much sense, though, of course ;-) But at least it would let us answer "Does this commit introduce a bug?" question, and if the annotated information also records "... and that other commit is a fix that can be cherry-picked (or merged)", that would be even better. That would allow us, when merging down the commit thusly annotated, to stop and consider either not merging (because it is known to introduce a bug) or merging with fixes also merged (because the solution is already known and recorded).