From: Pierre Habouzit <madcoder@debian.org>
To: Yann Dirson <ydirson@altern.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] git integrated bugtracking
Date: Sun, 3 Jun 2007 15:23:55 +0200 [thread overview]
Message-ID: <20070603132355.GC14336@artemis> (raw)
In-Reply-To: <20070603123510.GC6992@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]
On Sun, Jun 03, 2007 at 02:35:10PM +0200, Yann Dirson wrote:
> On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:
> > Hi, I'm currently trying to think about a bug tracking system that
> > would be tightly integrated with git, meaning that it would have to be
> > somehow decentralized.
>
> You may want to look at existing solutions, such as Bugs
> Everywhere[1], which has is modular wrt the backend SCM (supports Arch
> and Bazaar for now).
>
> I'm not sure its storage format is extensible enough, but it at least
> shows some interesting ideas.
I looked at it, the idea is good, implementation quite wrong (too many
files, with too much crancky formats). But it's quite small, so if it's
the good way, it should be easy to adapt.
> > I mean, the immediate idea is to have some .bugs/ directories (or
> > alike). This has many good properties, e.g. for projects like the linux
> > kernel with its many subsystems or driver, it would make sense to have
> > per driver/subsystems/... bug packs, and move bugs from one pack to
> > another would be the way of assigning bugs to different modules.
>
> What about a requirement that .bugs/ is at the project toplevel ?
I don't see why it's necessary, it's just random thoughts and quite
outside the scope of my concerns right now.
> > The other problem I see is that at the time a bug gets reported, the
> > user knows it's found at a commit say 'X'. But it could in fact have
> > been generated at a commit Y, with this pattern:
> >
> > --o---o---Y---o---o---o---o---X---o---o--> master
> > \
> > o---o---o---o---o---o--> branch B
> >
> >
> > Sadly, the bug report has been commited at 'X', hence it does taints
> > branch B. As "inserting" or "moving" 'X' commit before the branch is not
> > an option as it would rewrite history, that becomes also a major no-go
> > for in-tree collecting of bugs.
>
> Maybe "commit annotations" would help here ? I have noticed a thread
> about a git-note tool, though did not open it yet - so I may be
> off-track here.
Hmm, I'll try to search for it then.
> > PS: What I left over, is why I wanted such a tool. Programmers tends (or
> > say I tend to, maybe I'm over-generalizing, but I seem to remember a
> > thread on the lkml where Linus was basically saying the same) to
> > hate bugzillas and such out-of-tree tool because they suck, and do
> > not really fit in the programming cycle. I'd rather see a
> > bugtracking system where the backend is in-tree, basically mboxes so
> > that you can read them easily with your favourite MUA, as well as
> > adding new comments in it the same way. It also accommodates with
> > linux-like workflows where bugs usually are sent on the lkml, a bit
> > like patches and pull requests are handled. That's the reasons why I
> > came with this idea.
>
> I still have mixed feelings towards the idea of implementing a brand
> new defect-tracking system, when there are already so many of them,
> with many features already. Eg., my initial opinion about Bugs
> Everywhere was that it was not complete enough to be used in many
> projects.
>
> I tend to think it would be more productive to do any necessary
> changes in widely-used bug trackers (bugzilla, mantis, rt...), and
> work on glue tools, like scmbug[2].
Well, why writing yet-another-scm like err git ? Because other were
doing things wrong. Bugzilla, or especially rt are not distributed,
hence completely inadequate for use with git, whatever clumsy plumbing
you do to make them work. And I know what I'm talking about, I wrote the
plumbing for the debian bug tracking system, I've looked at a lot of
them. And only bugs everywhere was near what looks the good way, because
when you're able to deal with your code like git allows you to, it makes
absolutely no sense not being able to deal with your bug database the
same way.
And FWIW I'm just asking questions, nothing more, just because I don't
want to rush in yet-another-tool if it appears it will be broken.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-06-03 13:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-03 11:48 [RFC] git integrated bugtracking Pierre Habouzit
2007-06-03 12:35 ` Yann Dirson
2007-06-03 13:23 ` Pierre Habouzit [this message]
2007-06-03 12:59 ` Michael Poole
2007-06-03 13:31 ` Pierre Habouzit
2007-06-03 13:48 ` Johan Herland
2007-06-03 15:19 ` Pierre Habouzit
2007-06-03 15:44 ` Matthieu Moy
2007-06-03 16:07 ` Pierre Habouzit
2007-06-03 17:35 ` david
2007-06-03 18:49 ` Pierre Habouzit
2007-06-03 19:07 ` david
2007-06-03 20:31 ` Yann Dirson
2007-06-03 17:10 ` Yann Dirson
2007-06-03 20:04 ` Yann Dirson
2007-06-03 20:21 ` Pierre Habouzit
2007-06-04 22:03 ` Yann Dirson
2007-06-04 22:25 ` Pierre Habouzit
2007-06-03 19:22 ` Linus Torvalds
2007-06-03 20:16 ` Pierre Habouzit
2007-06-03 23:07 ` Martin Waitz
2007-06-04 9:32 ` Rogan Dawes
[not found] ` <20070604102037.GB7758@.intersec.eu>
2007-06-04 13:29 ` Rogan Dawes
2007-06-03 20:17 ` Yann Dirson
2007-06-03 20:32 ` Pierre Habouzit
2007-06-09 12:12 ` Pierre Habouzit
2007-06-09 16:23 ` Jakub Narebski
2007-06-10 2:44 ` Daniel Barkalow
2007-06-10 7:44 ` Johannes Schindelin
2007-06-10 6:59 ` Martin Langhoff
2007-06-10 7:35 ` Junio C Hamano
2007-06-10 8:38 ` Martin Langhoff
2007-06-10 8:50 ` Jan Hudec
2007-06-11 18:51 ` Jon Loeliger
2007-06-12 8:54 ` Guilhem Bonnefille
2007-06-10 8:37 ` Jan Hudec
2007-06-10 8:55 ` Martin Langhoff
2007-06-10 10:16 ` Pierre Habouzit
2007-06-10 23:14 ` Martin Langhoff
2007-06-11 8:45 ` Pierre Habouzit
2007-06-11 10:00 ` Martin Langhoff
2007-06-10 10:49 ` Jan Hudec
2007-06-10 22:07 ` Matthieu Moy
2007-06-10 13:34 ` Pierre Habouzit
2007-06-10 13:43 ` Pierre Habouzit
2007-06-10 14:02 ` Pierre Habouzit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070603132355.GC14336@artemis \
--to=madcoder@debian.org \
--cc=git@vger.kernel.org \
--cc=ydirson@altern.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).