"Martin Langhoff" [off-list ref] writes:
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.
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.
You are a brave person to say this (no sarcasm --- I wish I
were, too).
On one hand, I very much applaud and appreciate your comment for
injecting sanity to the discussion. On the other hand, if Linus
had such an attitude, we might not be hacking on git right now.
After looking at the above existing alternatives, some brave
soul might decide and say, "Hey, I can write something better in
2 weeks" ;-).
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
All of your examples are going from a single bug to commits, but
from a release person's point of view, you are never interested
in a single bug, just like a top-level maintainer is never
interested in a single file. A release person would want to go
in the reverse direction: from a commit range to a set of bugs.
What bugs were fixed and what regressions were introduced during
this release cycle. While embedded ticket numbers in commit log
messages would certainly help, a change made to fix a particular
bug may fix another as its side effect, and the develeoper who
did the change may not know about the latter when the commit log
message is written.
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.
But I would _never_ try to describe all the possible relations in the
schema -- existing trackers use a liberal mix of regexes and cache
tables with some free form text fields for this kind of stuff.
These are indeed very good points.
On 6/10/07, Junio C Hamano [off-list ref] 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.
You are a brave person to say this (no sarcasm --- I wish I
were, too).
On one hand, I very much applaud and appreciate your comment for
injecting sanity to the discussion. On the other hand, if Linus
had such an attitude, we might not be hacking on git right now.
Thanks for the reply - sorry for being a bit of a stirrer ;-) Yes, I
do appreciate the irony and I'd have never started git. If anyone
really wants to do their own bugtracker... be like Linus not like me
(a mere follower) ;-)
After looking at the above existing alternatives, some brave
soul might decide and say, "Hey, I can write something better in
2 weeks" ;-).
Definitely. But that takes a deeper look into the above alternatives,
and probably a good perspective. I hope noone takes offence if I say
that -- as a user of several bugtrackers over ~10 years -- I haven't
yet read anything in this thread that is exciting.
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
;-)
All of your examples are going from a single bug to commits, but
from a release person's point of view, you are never interested
in a single bug, just like a top-level maintainer is never
interested in a single file. A release person would want to go
in the reverse direction: from a commit range to a set of bugs.
That's right. It's not that hard to correlate commits-in-the-changelog
and ask the bugtracker to produce a "tracker changelog" showing all
the bugs/tasks that link to the commits (with that liberal view of
"links to" discussed before). Formatting of the tracker changelog _is_
tricky but that's due to the ambiguities in those relationships.
(In Moodle I use JIRA, a non-FOSS tracker, and it does exactly that. I
think it has some notion of CVS branches, and where tags sit, so you
can ask for a report of which bugs are fixed in the release you are
preparing on branch X).
What bugs were fixed and what regressions were introduced during
this release cycle. While embedded ticket numbers in commit log
messages would certainly help, a change made to fix a particular
bug may fix another as its side effect, and the develeoper who
did the change may not know about the latter when the commit log
message is written.
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.
So the BT holds "external tags" to your commits. Lots of them. With a
ton of data. And that's great -- in fact there's no stopping it -- the
stability of SHA1s means that the whole internet holds tags to your
repo. Every time a SHA1 (or output of git-describe) is mentioned in a
mailing list, wiki or forum, there's a tag.
Now, to rule the world, BTs gain a lot more from being able to
integrate with different SCMs, 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.
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?
martin (who's now thinking how to craft a proof of concept)
On Sun, Jun 10, 2007 at 00:35:33 -0700, Junio C Hamano wrote:
"Martin Langhoff" [off-list ref] writes:
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
All of your examples are going from a single bug to commits, but
from a release person's point of view, you are never interested
in a single bug, just like a top-level maintainer is never
interested in a single file. A release person would want to go
in the reverse direction: from a commit range to a set of bugs.
What bugs were fixed and what regressions were introduced during
this release cycle. While embedded ticket numbers in commit log
messages would certainly help, a change made to fix a particular
bug may fix another as its side effect, and the develeoper who
did the change may not know about the latter when the commit log
message is written.
It would be really useful to have a tool, that could link a bug report to
a test case demonstrating it and reporting whenever output of that test case
changes. This would make it much easier for developer to see which bugs he
might have fixed when doing a refactoring.
It should probably report not just unexpected success, but also change to the
error output, because the test case does not have to be 100% correct. That is
if you have a test case that prints:
testFoobar FAIL "foo" != "Bar"
and than starts to say:
testFoobar FAIL "foo" != "Foo"
the problem is probably fixed, but the test still fails because of minor
error in the expected output string.
--
Jan 'Bulb' Hudec [off-list ref]
On Sun, 2007-06-10 at 03:50, Jan Hudec wrote:
It would be really useful to have a tool, that could link a bug report to
a test case demonstrating it and reporting whenever output of that test case
changes. This would make it much easier for developer to see which bugs he
might have fixed when doing a refactoring.
I think the inverse is interesting too. That is, applying
keywords to tests and then making the test database
keywords searchable.
I used to work for a company that had a huge collection
of test cases for its product. It would take days to run
a validation run for some of the simplest of changes that
were introduced during development.
Often what I wanted, and what was needed, was a simple
sanity check that verified that the proposed change was
not brain-dead from the start.
Over time, I found that certain tests proved to be good
at detecting failures in particular portions of the code.
Often, that test was not necessarily directly related to
the concept it was _supposed_ to be designed to test, but
incidentally was good at some _other_ concept too.
The developer who made the change, and ran the tests,
then was able to state "Test t42 from suite Frotz is good
at detecting changes to the <SomeModule>."
The trick is to now associate with that test the keyword
"SomeModule" so that in the future, another developer
could ask: "Say, I just modified <SomeModule>, are there
any tests that are good at proving my changes sound?"
A test driver could then focus some test cycles quickly.
Now, for git, it's not likely a problem to just run
through all of its tests. At ${PriorCompany} it was
essential to pare down the test suites to a manageable
size, yet still have assurance that your coverage was
reasonably good.
jdl
Hi,
This subject is quite interesting. I read that one of the main
expected goal of integrating SCM and BT is to help release manager in
its task.
In my point of view, we have to keep in mind that it's not because a
commit solved a problem, that all the following commits will always
solve the problem. Development ALWAYS suffers regression. The really
way to avoid this is to have an organisation of code that allows
automatic tests. So it needs something greater than the SCM: you have
to be organized for this.
One interesting project to have a look for is aegis (
http://aegis.sourceforge.net/ ).
It proposes a sort of SCM, that integrates process to ensure quality
of code. One of them is that the /SCM/ will control the non regression
before commiting.
I hope these informations will help defining how we can design a
system that integrates SCM and BT in a distributed manner.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/