On 6/10/07, Pierre Habouzit <madcoder@xxxxxxxxxx> wrote:
On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote: > > Call me a fool, but writing a <new> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
