[Opinions] Integrated tickets

[Opinions] Integrated tickets

[Fredrik Gustafsson]

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?
-- 
Med vänlig hälsning
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

Re: [Opinions] Integrated tickets

[Jeff King]

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

> So my question is:
> 
> what's your opinions on building an integrated ticket system on top of git?

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

> and (maybe mostly for Junio)
> 
> Would such system possible be included in git.git?

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

Re: [Opinions] Integrated tickets

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> 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?

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?

Re: [Opinions] Integrated tickets

[Holger Hellmuth]

Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
> 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?

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.

Re: [Opinions] Integrated tickets

[Junio C Hamano]

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

> Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
>> 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?
>
> 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.

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.

Re: [Opinions] Integrated tickets

[Holger Hellmuth]

Am 11.11.2014 um 18:17 schrieb Junio C Hamano:
> Holger Hellmuth <hellmuth@ira.uka.de> writes:
>
>> Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
>>> 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?
>>
>> 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.

[...]

> 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.

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.

Re: [Opinions] Integrated tickets

[Junio C Hamano]

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

> 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.

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).