Add a bugzilla website

Add a bugzilla website

[ycollette.nospam]

Hello,

I just wanted to ask a question: why is there no bugzilla website for git ?
It's better to put bugs into such a tool to follow there evolution than to manage bugs via a developpment mailing list ...

Best regards,

YC

Re: Add a bugzilla website

[Damien Wyart]

* ycollette.nospam@free.fr <ycollette.nospam@free.fr> [2013-11-15 08:44]:
> I just wanted to ask a question: why is there no bugzilla website for
> git ? It's better to put bugs into such a tool to follow there
> evolution than to manage bugs via a developpment mailing list ...

http://thread.gmane.org/gmane.comp.version-control.git/191835/focus=192464

-- 
Damien Wyart

Re: Add a bugzilla website

[ycollette.nospam]

And the conclusion is ? No bugzilla tool installed because somebody want to build a gitbased bugzilla thing ?

YC

----- Mail original -----
De: "Damien Wyart" <damien.wyart@gmail.com>
À: "ycollette nospam" <ycollette.nospam@free.fr>
Cc: git@vger.kernel.org
Envoyé: Vendredi 15 Novembre 2013 09:53:26
Objet: Re: Add a bugzilla website

* ycollette.nospam@free.fr <ycollette.nospam@free.fr> [2013-11-15 08:44]:
> I just wanted to ask a question: why is there no bugzilla website for
> git ? It's better to put bugs into such a tool to follow there
> evolution than to manage bugs via a developpment mailing list ...

http://thread.gmane.org/gmane.comp.version-control.git/191835/focus=192464

-- 
Damien Wyart

Re: Add a bugzilla website

[Konstantin Khomoutov]

On Fri, 15 Nov 2013 10:40:47 +0100 (CET)
ycollette.nospam@free.fr wrote:

> And the conclusion is ? No bugzilla tool installed because somebody
> want to build a gitbased bugzilla thing ?

Well, no, the real answer is that for those who actually write code and
apply patches, an e-mail based workflow is simpler: Git has tools to
apply patches right from Unix mailboxes, so one is able to just save a
thread with the final patch series to a file and apply it.  Some people
also prefer discussing patches inline -- in the same e-mail thread
the patch series being discussed had started.

I'm aware of at least one big project sporting the same approach
to handling bugs -- PostgreSQL.

But there was an announcement that an experimental JIRA instance has
been set up for Git [1].  I'm not sure what its current status is, but
you could look at it.

Also Git's mirror on github [2] supposedly provides for pull requests.
Again, not sure whether/how they're handled.

1. http://git-blame.blogspot.ru/2012/02/experimental-git-bug-tracker.html
2. https://github.com/git/git/

Re: Add a bugzilla website

[ycollette.nospam]

OK, thanks for these informations.
From a user perspective, having this volume of devel mails flooding all the bugs mail is very annoying.
And following the status of a bug and the history of this bug is very hard too.
The bugzilla approach is really useful for the user who is reporting bugs: all the bugs are tracked, you can see if a bug has been already filled and put some additional informations if necessary.

I will have a look at the JIRA thing.

YC

----- Mail original -----
De: "Konstantin Khomoutov" <flatworm@users.sourceforge.net>
À: "ycollette nospam" <ycollette.nospam@free.fr>
Cc: git@vger.kernel.org
Envoyé: Vendredi 15 Novembre 2013 10:51:32
Objet: Re: Add a bugzilla website

On Fri, 15 Nov 2013 10:40:47 +0100 (CET)
ycollette.nospam@free.fr wrote:

> And the conclusion is ? No bugzilla tool installed because somebody
> want to build a gitbased bugzilla thing ?

Well, no, the real answer is that for those who actually write code and
apply patches, an e-mail based workflow is simpler: Git has tools to
apply patches right from Unix mailboxes, so one is able to just save a
thread with the final patch series to a file and apply it.  Some people
also prefer discussing patches inline -- in the same e-mail thread
the patch series being discussed had started.

I'm aware of at least one big project sporting the same approach
to handling bugs -- PostgreSQL.

But there was an announcement that an experimental JIRA instance has
been set up for Git [1].  I'm not sure what its current status is, but
you could look at it.

Also Git's mirror on github [2] supposedly provides for pull requests.
Again, not sure whether/how they're handled.

1. http://git-blame.blogspot.ru/2012/02/experimental-git-bug-tracker.html
2. https://github.com/git/git/

Re: Add a bugzilla website

[Matthieu Moy]

ycollette.nospam@free.fr writes:

> The bugzilla approach is really useful for the user who is reporting
> bugs: all the bugs are tracked, you can see if a bug has been already
> filled and put some additional informations if necessary.

As a user, the most important thing is that the bug is eventually fixed.
I had a lot of experiences with projects using bugtrackers, where
I filed bugs, and the bugs were burried forever in the bugtracker. Not
all projects are like this, but the danger of using a bugtracker to have
long-standing bugs forgotten is high. It is especially high when there's
no one paid to maintain the list of open bugs low.

As opposed to this, most bug reports on this list are followed by a
lively discussion and a patch.

Sure, a bugtracker could complement this, but someone would have to
volunteer to set up and maintain one, and to get developpers interested
in fixing bugs reported there. There have been attempts, but AFAIK no
success.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Add a bugzilla website

[Andrew Ardill]

On 15 November 2013 01:51, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
> But there was an announcement that an experimental JIRA instance has
> been set up for Git [1].  I'm not sure what its current status is, but
> you could look at it.

So!

The biggest concern has always been that any bug tracking system needs
to complement the existing workflow of many developers. For bugs and
feature requests, they are raised, discussed, and fixed on the list.
Replacing this process is not in scope for a bug tracker.

In that framework the main value a bug tracker has is keeping track of
what bugs exist, what versions they affect, and when they are fixed.
Unfortunately, at the moment, collecting and curating this information
is entirely manual.

The JIRA attempt [1] looks to pull in every conversation and thread it
for us (adding replies as comments to existing tickets), but hasn't
tried to anything beyond that. Automation may be possible, to do
things like parse What's Cooking and the release notes, but that is a
harder problem :)

The tools are there, and you should be able to log in and add/update
issues. Feel free! (Definite value would be derived from a dedicated
curator who updated the bug tracker manually)

I had a look over the set up (I hadn't in a while) and realised we
were dropping some emails, so I'll try and fix that, but the bigger
problem is that simply creating tickets to track conversations is not
enough.

We need to then identify those conversations that we care about and
capture some metadata about them - did they resolve the reported
issue, and when did that happen? Junio is the source of truth for
this, and so ideally we would use his communications to understand it,
but that just shifts the problem to linking the issues he writes about
to the conversations that started them.

In any case, adding value to the existing process is hard (because it
works quite well!) and probably requires significantly more work to
even understand what that value might look like. This, I think, is the
key reason it is hard to truly get started with any bug tracking
solution; the solution is not obvious, and the current (very
customised) workflow is not supported directly by any tool.

Regards,

Andrew Ardill

[1] https://git-scm.atlassian.net

Re: Add a bugzilla website

[Jonathan Nieder]

Hi,

Andrew Ardill wrote:
> On 15 November 2013 01:51, Konstantin Khomoutov
> <flatworm@users.sourceforge.net> wrote:

>> But there was an announcement that an experimental JIRA instance has
>> been set up for Git [1].  I'm not sure what its current status is, but
>> you could look at it.
>
> So!
>
> The biggest concern has always been that any bug tracking system needs
> to complement the existing workflow of many developers. For bugs and
> feature requests, they are raised, discussed, and fixed on the list.
> Replacing this process is not in scope for a bug tracker.

I always thought the biggest concern was that someone has to have a
sense of what bugs are a priority to track and do the curation to keep
the list of bugs useful.  In the mailing list it's easy to prioritize
based on what people are actually working on; on a bug tracker, which
is mainly about what people are *not* working on, that's harder work.

One way to address that problem is to decentralize: maybe everyone has
a different idea of what bugs are important, but if each person or
project makes their own idea of that public, you get most of the
benefit of a bugtracker.  Bonus points if different project's
bugtrackers link to each other to avoid duplication of information.

In this vein, there are a few active bugtrackers for git already:

 * the mailing list archive is the canonical source of truth
 * the JIRA experiment: https://git-scm.atlassian.net
 * the Debian project maintains http://bugs.debian.org/src:git
 * the Ubuntu project maintains
   https://bugs.launchpad.net/ubuntu/+source/git

I don't think the Ubuntu bugtracker wants reports for upstream issues
that were not discovered on Ubuntu.  By contrast, the maintainers of the
Debian bugtracker have made it clear that they are happy to receive
reports for the git package even when they do not affect Debian at all
(e.g., Windows-specific issues).

In other words: if you report a bug by sending an email to
submit@bugs.debian.org with body text starting with

	Package: git
	Version: 1:1.8.5~rc2-1
	Tags: upstream

	... description of the bug here ...

then I am happy to keep track of it, link to the corresponding
upstream conversation, and let you know when I notice it's fixed.  Of
course I won't fix your bug for you, unless it's a priority to me for
other reasons. :)

More details on reporting bugs through the Debian BTS are at [1].

Maybe other people provide the same service as well.

Thanks and hope that helps,
Jonathan

[1] http://www.debian.org/Bugs/Reporting

Re: Add a bugzilla website

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Fri, Nov 15, 2013 at 10:40:47AM +0100, ycollette.nospam@free.fr wrote:
> And the conclusion is ? No bugzilla tool installed because somebody
> want to build a gitbased bugzilla thing ?

Personally, I do not want Yet Another Bugzilla Account.  A project is
significantly less likely to get a patch from me if I have to create an
account to report a bug.  Most of the patches I send to various projects
are for bugs I've experienced and want to provide a fix for, so I send a
small number of patches to many projects.

I feel that the mailing list workflow ends up working very well for Git
and it provides a low barrier to entry for those that want to send just
one or two patches for problems that they're experiencing.  It also
allows me to see and comment on virtually every patch on the list, while
ignoring threads I am not interested in, a combination which is
difficult to achieve with a web-based bug tracker.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Add a bugzilla website

[ycollette.nospam]

On most linux distro bugzilla website, there are some people dedicated to triaging bugs (finding duplicated bugs, asking for more informations, closing old and / or resolved bugs).
To have an efficient bugtracking tool needs to have some people dedicated to this.
But for the user, it's a better approach. For example, I do not need to register to the devel list and I do not have to watch all mails to locate the one which concerns my bug.
It works nicely with fedora, magieia and other distro / tools, so I don't know why this shouldn't work fine with git ?
But as far as I can read, most people here are very reluctant to use a bugtracking tool ...

YC

----- Mail original -----
De: "brian m. carlson" <sandals@crustytoothpaste.net>
À: "ycollette nospam" <ycollette.nospam@free.fr>
Cc: git@vger.kernel.org
Envoyé: Vendredi 15 Novembre 2013 23:57:09
Objet: Re: Add a bugzilla website

On Fri, Nov 15, 2013 at 10:40:47AM +0100, ycollette.nospam@free.fr wrote:
> And the conclusion is ? No bugzilla tool installed because somebody
> want to build a gitbased bugzilla thing ?

Personally, I do not want Yet Another Bugzilla Account.  A project is
significantly less likely to get a patch from me if I have to create an
account to report a bug.  Most of the patches I send to various projects
are for bugs I've experienced and want to provide a fix for, so I send a
small number of patches to many projects.

I feel that the mailing list workflow ends up working very well for Git
and it provides a low barrier to entry for those that want to send just
one or two patches for problems that they're experiencing.  It also
allows me to see and comment on virtually every patch on the list, while
ignoring threads I am not interested in, a combination which is
difficult to achieve with a web-based bug tracker.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Re: Add a bugzilla website

[Matthieu Moy]

[ Please, don't top-post, and set your mailer correctly so that the To:
  header points to the person you're replying to. ]

ycollette.nospam@free.fr writes:

> On most linux distro bugzilla website, there are some people dedicated
> to triaging bugs (finding duplicated bugs, asking for more
> informations, closing old and / or resolved bugs).
> To have an efficient bugtracking tool needs to have some people dedicated to this.

On this list, proposals like "I would like to volunteer to do XYZ" are
usually more welcome than "someone should volunteer to do XYZ"...

> But for the user, it's a better approach. For example, I do not need
> to register to the devel list and I do not have to watch all mails to
> locate the one which concerns my bug.

You don't need to register to post, and people will Cc-you in their
replies by default.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Add a bugzilla website

[David Aguilar]

On Fri, Nov 15, 2013 at 2:34 AM,  <ycollette.nospam@free.fr> wrote:
> OK, thanks for these informations.
> From a user perspective, having this volume of devel mails flooding all the bugs mail is very annoying.
> And following the status of a bug and the history of this bug is very hard too.
> The bugzilla approach is really useful for the user who is reporting bugs: all the bugs are tracked, you can see if a bug has been already filled and put some additional informations if necessary.
>
> I will have a look at the JIRA thing.

FWIW Debian and Fedora (and possibly others) have "git" components in
their bugtrackers.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=git

https://bugzilla.redhat.com/buglist.cgi?component=git&product=Fedora

It might be worth working along with one of the distros to avoid
duplicating effort.

cheers,
-- 
David

Fwd: Add a bugzilla website

[Stefan Saasen]

> In any case, adding value to the existing process is hard (because it
> works quite well!) and probably requires significantly more work to
> even understand what that value might look like. This, I think, is the
> key reason it is hard to truly get started with any bug tracking
> solution; the solution is not obvious, and the current (very
> customised) workflow is not supported directly by any tool.
>
> Regards,
>
> Andrew Ardill
>
> [1] https://git-scm.atlassian.net


I think you summarised the challenges very well and I don’t think there is an
obvious answer to that.

I’d just like to offer any help that I or we (Atlassian) could give you. Given
your experience with JIRA I’m sure that you’ve got everything covered, but if
you need anything, please ping me.

Re-reading the old discussions there was a concern that the issue data was not
available, I just wanted to chime in and mention that if you are using a JIRA
OnDemand (e.g. the https://git-scm.atlassian.net) instance you can get the full
backup of your data (including any attachments, data available as XML) and
there is a JIRA REST API as well.

I know that this is just a very tangential concern given the challenges of
making an issue tracker work with an email based workflow that has proven quite
successful but I at least wanted to address that and offer any help you might
need.


Cheers,
Stefan