On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
On 6/10/07, Pierre Habouzit [off-list ref] wrote:
quoted
FWIW I've begun to work on this (for real). I've called the tool
"grit". You can follow the developpement on:
* gitweb: http://git.madism.org/?p=grit.git;a=summary
* git: git://git.madism.org/grit.git/
Call me a fool, but writing a <new> bugtracker looks like a
boil-the-oceans scheme.
Sure, what if I like it anyway ?
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.
You can like central web UIs, your choice. And I suppose if grit works
well, there will be one at some point.
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.
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, ...).
If the bugtracker can also auto-link things that look committish in
text entered by users (someone might write "bisect sez that f345e is
to blame"), with tooltips indicating in which heads those commits
resides (like gitk does), then it's just gorgeous.
that's not up to the BTS tool to do that, it's way to high level. It's
up to the importing filters/hooks that will parse the associated ML, and
that would translate that to useful low level BTS commands.
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. So that means that this
tool can only work on top of SCMs that support that. ttbomk git, hg,
_maybe_ bzr fit the description. I only know the former, but I really
plan to write the tool in a way that the underlying SCM does not matters
_too_ much. Maybe I'll fail. Honestly, I don't really care (yet ?).
OTOH, that's just me, I'm lazy and like to work on already-successful
projects that are 99% there for my needs (and where I can add that
1%).
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:
* bugzilla: takes more from the -zilla than from the BTS side. It's
huge, monstruous, slow (have ever used glibc's bugzilla ? it has
maybe 5k bugs, it's slow like if it ran on an Atari ST), complex,
the mail gateway suck hard, it's completely unusable for me. Believe
me, I've packaged KDE for 2 years in Debian, now am in the glibc
team. Every single day I have to work on this horrible tool is a
PITA.
* flyspray: I've been upstream for a short time. Visually nice, good
to work with, UI is great. Integration totally suck, worthless.
Can't use mails either, needs a Web Browser -> useless. The same
holds for mantis, roundup and a lot of other friends.
* debbugs: oh yeah there is a mail interface. So slow that you have to
wait up to 15 minutes to see your command be taken into account. And
when you have to deal with dozens of bugs (Yes I've done that on a
regular basis) you _have_ sometimes to wait for the answer to come
back (because you need an ID that will be in there e.g.) to continue
your work. That is unacceptable, you pass most of your time waiting.
Moreover sometimes you made an error in your commands, so you also
need to parse the anwer ... one day later because "immediateley when
you still remembered what this was about" is not an option.
Unacceptable again. The plus: it uses mboxes, hence is worthwile in
a hacking environment, it fits the workflow well.
* trac: very very very nice tool. I mean it. We use it at work, where
I have to suffer svn (through git-svn though). It's really nice (did
I repeat myself ?). THough, it's on top of svn, and you can't use
the Bugs informations from your repository. You can't say: I'm
backporting that patch into that branch. Now what affects this
branch please ? Trac can't answer that (and ttbomk now BTS really
can anyway, except Debian's debbugs instance, and it's somehow
limited). That is a question a release manager takes 80% of his time
to ask. I hope grit can take back to the 0.01% of his time, which is
still too much.
On Sun, Jun 10, 2007 at 08:55:21PM +1200, Martin Langhoff wrote:On 6/10/07, Jan Hudec [off-list ref] wrote:
quoted
I don't know about any *distributed* bug tracker, which is the point
here.
As an end user, I suspect I _don't_ want to have to report a bug in a
distributed bug tracker ;-)
I trol^Wdiscuss everyday on debian's channel with friends that tell
that svn is the best tool ever, and that they would never ever use a
distributed SCM because it's too hard to understand. Your call.
quoted
We have several distributed version control tools, but no other
distributed tools for the other tasks in configuration management.
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.
quoted
- Distributed version control is designed to decrease the workload of
the central maintainer(s) while keeping him in control. But with
centralized
And to provide a single place for users to report a problem and track
its status.
Why wouldn't it exist a "public reporting interface"-branch ? that
would be the same purpose as the mainline ~linus/linux2.6.git tree. And
you can build/instanciate your beloved web UI on top of that, and people
would just have to pull from there. What a shock, it's easy !
quoted
If it uses git as it's database, which it probably will,
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.
quoted
Yes. But for many people current bug tracking tools do NOT work 99%.
Hmmm. I agree in that "does not work disconnected" is a big issue with
web tools, but debbugs works disconnected, and is good. Git's
bugtracker (git@vger) works disconnected too ;-) And googlegears might
help the rest of us. Is there any other problem with current BTs?
It's not integrated with the workflow. And sorry, but git@vger (or
workse lkml@vger).. it does not work. Maybe for git it does because the
flow is still human manageable, and that it seems junio has enough time
for it. But for the kernel ? please. You should read Bastian Blank
frustration about regressions and nobody tracking them. Know why ?
because there is no tool that is well known and well integrated in the
workflow. There is a long rant against kernel.org's bugzilla, you should
read it as well. It's not really instructive (at least there wasn't
anything new for me in it, I was already bought to many arguments in
there). But you'll see the world isn't as rosa-lila you think it is.
On Sun, Jun 10, 2007 at 08:38:03PM +1200, Martin Langhoff wrote:
On 6/10/07, Junio C Hamano [off-list ref] wrote:
quoted
After looking at the above existing alternatives, some brave soul
might decide and say, "Hey, I can write something better in 2 weeks"
;-).
I'm sure I could come up with something really better in say a
month... If I hadn't paid work to do too :)
And "it's closely integrated with git" can actually be a misfeature.
Cool if it's what gets you going, but not enough for world domination
;-)
It's a misfeature for you because you read it as "non portable".
That's a fair point. And like said, it may be extended to SCM's with the
same set of features I need to build it. But let's be honnest, I don't
care about a BTS that uses the smallest common set of features of SCM's.
Reading this list, you should know it's almost a void set. No, I think a
good BTS should make an excellent use of high level features of the SCM.
The real problem is, there is maybe 2 or 3 SCMs that have this set of
strong and good features. Too bad for the other, I can't work with them,
they suck hard, and I don't see why I should support bad practices
anyways.
(Yes I'm also a guy with strong opinions too, it's not really
restricted to Linus ;p)
I agree it's useful, but I don't think it has any benefit having it in
the SCM _at all_. Having them in the BT is a lot more flexible -- and
the fact that git has stable commit IDs makes it easier to integrate
in a BT; as the BT can spot that the commit fixing bug 123 is now
merged into head ZZ as well as head YYY.
If you do that you loose:
* fastness, and I don't want to work with debbugs anymore.
* distribution: Meaning that for _one_ project everybody needs to use
this central bugtracker. Whereas .oO(kernel) there is some projects
where the subcomponents are dealt with from very different teams,
very different way to release things, and they are interested with
their bugs, and their bugs only. They would prefer a very fast
interface to deal with their 1k bugs, and not worry about the 100k
the rest of the project has.
Branching bugs also makes sense you know ?
Now, to rule the world, BTs gain a lot more from being able to
integrate with different SCMs,
You are the one saying it. I beg to differ.
automated test systems (like tinderbox), MTAs (debbugs), wikis (traq),
stats tracking for PHBs (bugzilla), etc. So loose coupling wins here,
and git's SHA1s are great for that.
IMHO a BTS is a _low_ level tool. that's the road git took, I
sometimes describe the plumbing git commands as the "Assembler" of the
SCM world to friends when I talk to them about git. That's really the
best way to implement a thing: have a small small set of rock solid,
well designed tools, and build the others as porcelains with them.
Testing is a high level tool. I don't need to support them, I need to
have exactly the low level querying rocket-fast query interfaces so that
integration scripts are at most 100 lines long.
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).
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
On 6/10/07, Pierre Habouzit [off-list ref] wrote:
On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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?
quoted
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.
quoted
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
On Mon, Jun 11, 2007 at 11:14:03AM +1200, Martin Langhoff wrote:
On 6/10/07, Pierre Habouzit [off-list ref] wrote:
quoted
On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
quoted
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.
okay, my point is also that using yet another tool that is neither
integrated in my shell nor in my editor sucks. I use the shell to use
$SCM, and to perform tests of my work, so it's in my workflow. I use the
editor (well do I need to tell why ? :P), I just don't want to use a
browser where the two previous should be enough.
quoted
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.
Because it's git-based does not implies there won't be a web UI. And
it's not because there is a lot of options to the underlying process
that you need to show them all to the user.
My experience is also that people never fill informations about OS,
Arch, version properly, because it's tiredsome. debbugs (through
reportbug) approach is excellent: assuming that the user reports the
error from the machine where he experienced it and taking all the
information automatically. _here_ is how it should work for the user,
e.g.: “please download and run that script, and paste the results in your
bug report pretty please ?”
quoted
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 many of those bts'es help the RMs to know if their
soon-to-be-stable branch fits the milestone ? milestones in any BTS I
know are global "yes the fix exists, in this revision (and this
information is not always here)". Sorry but it's worthless.
How about the _rest_ of the BTS-using populace?
Okay, who else uses a BTS ? developpers, as I'm a developper, I'll
write a tool that pleases me. Let's say developpers are taken care of.
Users ? For a user, what should be made easy is reporting, and
interacting with whoever is dealing with the bug on the other end.
Advanced users will want to be able to track discussion about some bugs
they are interested into (meaning that it must be a way to crawl the
bugs database).
So let's take the three points:
* reporting: the tools to make reporting fast, efficient, _and_
useful to the developpers - many many many bug reports suck, hard -
are very often project dependant: a project in python e.g. won't
care about the architecture usually (hence forcing it is stupid) but
will probably mind the OS, python version, distribution, ... Another
project in C will mind the architecture, but is knowingly working
only on Linux so won't mind the OS, but would maybe mind the kernel
version. etc...
=> What can I do ? provide a way to deal with some kind of
property/values that can be customizeable at the BTS side and
show some examples of reporting scripts. ttbomk only debbugs and
reportbug knows how to do that. It does not prevents bad bug
reports at all, but it makes many that would have been bad almost
good, at least usable.
* simplicity to follow up: there isn't 12987123 solutions here. mail,
mail, mail, mail. A BTS should be able to track mail discussions one
way or another. For pure-web BTS, there is still mail alerts to say
"hey $someone has said $sth on your bug $bug". So the user already
is in his MUA when he receives that, well, "reply"-button is the
shortest way to answer, make it possible.
* crawling the database: that one should not be done by the BTS. Every
BTS on the planet doing that is wrong. There is plenty of good
search engines (xapian, clucene, ...) just adapt one. And the most
simple your storage backend is, the simplest it will be.
What I'm saying is that maybe we don't call BTS the same object. To me
a BTS is a "thing" able to deal with large amounts of bugs in an
efficient way, and is able to deal with some basic things like bug
statuses, and some kind of queries to the database (not the full text
search ones). Then you have the Upper Layer Tools: guis, tracking
scripts, every bling you need. Note that Git is exactly designed this
way: low level tools, and then tools like git-mergetool, gitk, ... that
don't use _any_ git internal, but rather only use the underlying
commands. I want to build the core functions to deal with a BTS, so that
everybody is able to turn this into the BTS workflow he needs.
quoted
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.
Why ?
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.
or the BTS can do it for you and you would not need to feed him with
the sha directly.
And all of that can be done SCM-agnostic - except for the regex to
spot a commitid.
Sure, there is projects doing that out there, I believe they are
wrong. Portability is important. I mean, when you write a tool, that has
a purpose, yes you must try to make it available everywhere. That's why
there are people trying hard to make git build and work on windows.
But when you write a tool to help _you_ work, there is now need to
make it work for every workflow in the planet, because that would mean
align yourself to the lowest common denominator of the workflows you can
work with. That's not an acceptable trade-off. Why would I have to
support cvs or svn ? I don't use them. I just don't care about them.
Wherever place I'll work in, I'll use git. Sorry but full genericity
(because it's what we are talking about, not portability) is an
impediment, not an enabler.
quoted
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.
I don't think it needs to be a compromise.
quoted
quoted
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?
That one is easy. Indeed, the big politics in bugtrackers are ...
severity-ping-pong, or close-wars. Good example of that is btw:
http://sourceware.org/bugzilla/show_bug.cgi?id=4509.
Okay, what would we gain in a DBTS: developer would still be (sorry)
a perfect asshole with the user. That is a thing we cannot fix. Though,
the release manager will probably disagree with him. So this bug that
_he_ considers non existant will be closed in his repository, but still
remain open in the main one. Meaning that if another developer steps up,
he'll see this issue is not fixed. Else nobody will have any chance to
step up, ever.
The reverse works equally well: if RM decides bugs have to be closed,
developer is able to reopen the bugs (or not merge) in his repository,
so that he can have a chance to fix them.
Yes there is politics in BTSes, and yes it can help.
quoted
quoted
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?
The perl scripts. It would perceptibly slow down commits. And I don't
want that now that I finally have a fast SCM. I just don't want to turn
git into bzr.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org