Re: [RFC] git integrated bugtracking
On Sun, Jun 03, 2007 at 02:35:10PM +0200, Yann Dirson wrote:
Show 11 quoted lines
> 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.
Show 7 quoted lines
> > 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.
Show 17 quoted lines
> > 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.
Show 21 quoted lines
> > 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
Pierre Habouzit <madcoder@debian.org>