Yeah, now that I read that thread, well yeah, I think notes are a hell
of a good concept for my ideas. I mean, a bug report would be basically
a collection of notes:
* the bug has been found at this commit ;
* the bug has been not-found at this commit ;
* this commit is a fix for that bug ;
That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.
The kind of information you're mentionning above can be a great
starting point for "bisect". I can even imagine a kind of distributed
bisect, where several users could give their "bad commits" for the
same bug.
--
Matthieu
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:13
On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
Pierre Habouzit [off-list ref] writes:
quoted
Yeah, now that I read that thread, well yeah, I think notes are a hell
of a good concept for my ideas. I mean, a bug report would be basically
a collection of notes:
* the bug has been found at this commit ;
* the bug has been not-found at this commit ;
* this commit is a fix for that bug ;
That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.
That would work with notes, as while merging you'll get the notes of
the commit in your branch, *and* the note about the fixing patch. So
there is no loss of "concept" here. In fact that was the thing that I
looked for. Notes are good. They just may not be enough to write an
in-git bugtracking tool, as a bug needs the "notes collection" concepts,
and maybe a few other.
The kind of information you're mentionning above can be a great
starting point for "bisect". I can even imagine a kind of distributed
bisect, where several users could give their "bad commits" for the
same bug.
Heh yes. Sometimes it's more complex than that as bugs can come back
(regressions) or be the result of many commits (like the cases that suck
with bisect). For a complex bug it's more a set of [found..notfound[
intervals. Though this indeed is very valuable information, and the
distributed component thing *is* great.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
quoted
Pierre Habouzit [off-list ref] writes:
quoted
Yeah, now that I read that thread, well yeah, I think notes are a hell
of a good concept for my ideas. I mean, a bug report would be basically
a collection of notes:
* the bug has been found at this commit ;
* the bug has been not-found at this commit ;
* this commit is a fix for that bug ;
That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.
That would work with notes, as while merging you'll get the notes of
the commit in your branch, *and* the note about the fixing patch. So
there is no loss of "concept" here. In fact that was the thing that I
looked for. Notes are good. They just may not be enough to write an
in-git bugtracking tool, as a bug needs the "notes collection" concepts,
and maybe a few other.
how would you identify bugs in such a way that they will match up when you
merge different trees?
if you can manage to do this it sounds like a great idea. but I'm not
seeing a good way to do it at the moment. the answer may be a combination
of a number of factors.
1. bug number doesn't work well in a distributed environment
2. something based on indentifying the cause of the bug (commit id + file
+ line????) will only work after you know the real cause of the bug
3. description is worthless, too many ways to describe things that have
the same underlying cause
David Lang
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:14
On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
On Sun, 3 Jun 2007, Pierre Habouzit wrote:
quoted
On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
quoted
Pierre Habouzit [off-list ref] writes:
quoted
Yeah, now that I read that thread, well yeah, I think notes are a
hell
of a good concept for my ideas. I mean, a bug report would be
basically
a collection of notes:
* the bug has been found at this commit ;
* the bug has been not-found at this commit ;
* this commit is a fix for that bug ;
That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.
That would work with notes, as while merging you'll get the notes of
the commit in your branch, *and* the note about the fixing patch. So
there is no loss of "concept" here. In fact that was the thing that I
looked for. Notes are good. They just may not be enough to write an
in-git bugtracking tool, as a bug needs the "notes collection" concepts,
and maybe a few other.
how would you identify bugs in such a way that they will match up when
you merge different trees?
well, because they will be sha1's, a git object. And when it's a
duplicate, well, let's face it, not bugtracker helps *automatically*
tracking duplicates. The merge work is up to the QA people. Yeah,
bugtracker won't do all the tracking. In a way, that's good, that means
there is still place for humans in that world :)
if you can manage to do this it sounds like a great idea. but I'm not
seeing a good way to do it at the moment. the answer may be a combination
of a number of factors.
1. bug number doesn't work well in a distributed environment
Sure, SCM revisions either. But git solved that once, I don't see why
the solution found at that time would be less of a solution now :)
2. something based on indentifying the cause of the bug (commit id + file
+ line????) will only work after you know the real cause of the bug
It does not work in a real world, where real user don't grok code.
3. description is worthless, too many ways to describe things that have
the same underlying cause
Sure, though it could help finding dupes. BUt in my experience what
helps most, is fine grained categorizing, because you end up with few
bugs for a given component, and "same" bugs end up actually being near
in the UI or query tool. Of course it let space for bugs that get
actually miscategorized. But hell, my experience is also that many bugs
are discovered as beeing fixed years after the fix anyway.
I don't plan fixing all that stuff, it can't really be. I just would
like to create a tool that isn't as painful for the programmer as
bugzilla (or rt or ...) is, while it would still be as pleasant and easy
to stick a web UI for the users over it, hence not making the user
experience less pleasant.
My experience with bugtracking is that the most efficient way to deal
it is to let the programmer in charge of the responsible module deal
with those bugs. What programmer aren't willing to do is the triaging,
and pulling the bugs off a distant database/UI/.. off something that
isn't in their usual workflow.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
quoted
On Sun, 3 Jun 2007, Pierre Habouzit wrote:
quoted
On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
quoted
Pierre Habouzit [off-list ref] writes:
quoted
Yeah, now that I read that thread, well yeah, I think notes are a
hell
of a good concept for my ideas. I mean, a bug report would be
basically
a collection of notes:
* the bug has been found at this commit ;
* the bug has been not-found at this commit ;
* this commit is a fix for that bug ;
That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.
That would work with notes, as while merging you'll get the notes of
the commit in your branch, *and* the note about the fixing patch. So
there is no loss of "concept" here. In fact that was the thing that I
looked for. Notes are good. They just may not be enough to write an
in-git bugtracking tool, as a bug needs the "notes collection" concepts,
and maybe a few other.
how would you identify bugs in such a way that they will match up when
you merge different trees?
well, because they will be sha1's, a git object. And when it's a
duplicate, well, let's face it, not bugtracker helps *automatically*
tracking duplicates. The merge work is up to the QA people. Yeah,
bugtracker won't do all the tracking. In a way, that's good, that means
there is still place for humans in that world :)
quoted
if you can manage to do this it sounds like a great idea. but I'm not
seeing a good way to do it at the moment. the answer may be a combination
of a number of factors.
1. bug number doesn't work well in a distributed environment
Sure, SCM revisions either. But git solved that once, I don't see why
the solution found at that time would be less of a solution now :)
git's tracking of revisions works becouse it's tracking the content, it
doesn't care _how_ the content got that way, if it's the same it's the
same and will have the same hash.
with bugs the reports aren't the same so you can use the sha1 to track a
particular entry/tag/comment but not to identify the bug itself
quoted
2. something based on indentifying the cause of the bug (commit id + file
+ line????) will only work after you know the real cause of the bug
It does not work in a real world, where real user don't grok code.
quoted
3. description is worthless, too many ways to describe things that have
the same underlying cause
Sure, though it could help finding dupes. BUt in my experience what
helps most, is fine grained categorizing, because you end up with few
bugs for a given component, and "same" bugs end up actually being near
in the UI or query tool. Of course it let space for bugs that get
actually miscategorized. But hell, my experience is also that many bugs
are discovered as beeing fixed years after the fix anyway.
fine grained categorization is something that takes place long after the
bug is reported, users don't know how to correctly categorize bugs any
more then they know what code caused the bug.
I don't plan fixing all that stuff, it can't really be. I just would
like to create a tool that isn't as painful for the programmer as
bugzilla (or rt or ...) is, while it would still be as pleasant and easy
to stick a web UI for the users over it, hence not making the user
experience less pleasant.
My experience with bugtracking is that the most efficient way to deal
it is to let the programmer in charge of the responsible module deal
with those bugs. What programmer aren't willing to do is the triaging,
and pulling the bugs off a distant database/UI/.. off something that
isn't in their usual workflow.
this only works if someone goes to the work to send the bugs to the right
programmer. in many cases this is non-trivial.
David Lang
On Sun, Jun 03, 2007 at 12:07:44PM -0700, david@lang.hm wrote:
quoted
quoted
1. bug number doesn't work well in a distributed environment
Sure, SCM revisions either. But git solved that once, I don't see why
the solution found at that time would be less of a solution now :)
git's tracking of revisions works becouse it's tracking the content, it
doesn't care _how_ the content got that way, if it's the same it's the
same and will have the same hash.
with bugs the reports aren't the same so you can use the sha1 to track a
particular entry/tag/comment but not to identify the bug itself
Do you see any problem with taking as bug id the hash of the first
entry submitted ? Just like in a classical BTS, the bug id gets
allocated at submussion time. Further informations then get
associated with the initial report - here that would problably
translate into the initial report being an annotation to a source
commit, and further information being annotations to the initial
annotation.
fine grained categorization is something that takes place long after the
bug is reported, users don't know how to correctly categorize bugs any
more then they know what code caused the bug.
Is that a problem ?
quoted
My experience with bugtracking is that the most efficient way to deal
it is to let the programmer in charge of the responsible module deal
with those bugs. What programmer aren't willing to do is the triaging,
and pulling the bugs off a distant database/UI/.. off something that
isn't in their usual workflow.
this only works if someone goes to the work to send the bugs to the right
programmer. in many cases this is non-trivial.
This is he work of a QA team, and although it is not as common in the
Free Software world as it should be, there are people willing to do
the job. This discussion is about giving these people a better tool
to help them focus on the tasks where a human being is really needed.
Best regards,
--
Yann.