From: Martin Langhoff Date: Sun, 10 Jun 2007 23:14:03 GMT Subject: Re: [RFC] git integrated bugtracking Message-ID: <46a038f90706101614h48112deel70d848f4312c88d7@mail.gmail.com> In-Reply-To: <20070610101616.GF2951@artemis> On 6/10/07, Pierre Habouzit wrote: > On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote: > > > > Call me a fool, but writing a bugtracker looks like a > > boil-the-oceans scheme. > > Sure, what if I like it anyway ? Be my guest. It might turn out to be a beautiful project, but has low chances of helping GIT-BTS integration in general. > > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is > > what is going to make the difference. Most of those have already the > > ability to "link" to one or more commits -- after the commits are done > > and in GIT. > > Sure, you can do that and still inherit from the many downsides of > those tools: central, needs another separate tool to work with, and a > tool that nowadays tends to eat 500Mb of your memory if you take the > most hype implementation of it (Yes I'm describing a web browser), that > is slow like hell (because yes, there is many clients at the same time > on the central server, that is overloaded like hell), and so on. Most usable BTSs work on lighter webbrowsers, and can be tuned to work reasonably. That's not a dead-end per se. > You can like central web UIs, your choice. And I suppose if grit works > well, there will be one at some point. Bugtrackers are communication tools between developers and users. In many spaces, they are _teaching tools_, teaching the users about info developers need. That's why BTSs have explicit fields asking for important variables like OS, Arch, and version you are reporting a bug against. That's also why the BTS gains a lot from being web-based: extreme portability, reachability, zero-install for users. > > So you can tell your bugtracker > > - which commit fixed it -- usually auto-linked if you include the > > bugnumber in the commit message > > - which commit added the test -- auto linked as above > > - which commit introduced the bug -- if such thing exists and someone > > digs it up > > yeah, that is what bugtrackers already do. Though, that's of no use > for release managers. What is useful is what people call "milestones" in > trac e.g., meaning a set of bugs that has been flagged as needing to be > fixed. And what a release manager need is a tool to deal with this set > of bugs as a whole. Hmmm. Most BTSs have milestones, and the integration of the above with milestones is useful for release managers. How about the _rest_ of the BTS-using populace? > That's the same argument that Linus has against per-file tracking. > Also atm when you e.g. backport a patch that fixes this or this bug, > you're no BTS helps you tagging the bug as fixed in that branch as well. > Not to mention that BTS I know do not make any use of the commits DAG. > And for a very good reason, there is no real DAG in many existing tools > (svn, cvs, ...). Making the BTS DAG-aware is overkill. The BTS can ask for every update on every branch "what commits does it bring into branch X?" and that's all you need. If you backport a patch and mention the original patch SHA1 the BTS can do its job. And all of that can be done SCM-agnostic - except for the regex to spot a commitid. > > And definitely, if you use git as an alibi to write a new bugtracker, > > don't use the "works only with git" as a feature. It should work with > > as many SCMs as possible. > > No it should not, because it can't. I want the distributed and > Bug status spanning-DAGS be a central feature. But you lose portability. And gain... what that you can't do portably? > You're a lucky guy. All bug trackers I've used suck a way or another, > that impedes my workflow a lot. Let's cite a couple: Ok - but BTSs are a compromise, something that must work for users, and developers. > > Bugtrackers are co-owned by developers, users and (where they exist) > > project managers. > > That's exactly why distributed rock. Because everyone could _really_ > own _his_ bugtracker. This solves the same range of ACLish issues git > solves with respect to the code. Don't think I've seen politics over who owns the bugtracker ;-) but I _have_ seen politics over specific bugs (developers close unfixed bugs, flamefests ensue). I guess with a DBTS everyone can have their own status for the bug... but does that help the user? Or the developer? > > Well - hmmm. Git's database is great at tracking _content identity_. > > But a bug's content identity (description+comments+status) changes all > > the time. I don't think it's naturally a good match. > > Oh, because the code never changes. Doh, how stupid I am :) > No, really, you name your bug after the sha hash of the first report, > I think that's pretty obvious. That gives you a bug name. Then you ask > git for "what's the current sha for this bug in the tip of the BTS > branch", then you ask "so now what this new sha is pointing to in the > code". That's a small indirection that I suppose is bearable. Of course, you _can_ map the DBTS storage on git's storage. But git's storage has been designed to match the task. While I'm sure there are some good tricks to reuse, I don't think that it's a good fit. > > And at git's end we can get the smooth integration using/abusing that > > loose coupling strategy. So if git-log/gitk/qgit grow some hooks that > > can be used to perform a lookup... I can think of a perl script that > > gets events for each SHA1 that git-rev-list produces and returns one > > bug number, url and title (or more than one) that then git-log / gitk > > / qgit / annotate can use to further "decorate" the commit info in a > > similar style to what gitk is doing now with head names in each > > commit. > > > > Would that fit your vision of a nicely integrated tracker? > > Honestly ? No, because that would be horribly slow (but I'd love to be > proven wrong). What part would be slow? cheers martin