Triage of Bug Tracker
Yuv
Third rainy day in a row here :-( so I have been spending some time on
things I've neglected for a while. One of them is <http://
wiki.panotools.org/Development_of_Open_Source_tools>
and specifically the mention of the bug tracker <https://
sourceforge.net/tracker/?group_id=77506&atid=550441>
On the wiki the release process described is still very much 0.7.0
related. I'd like to generalize it. And I'd like to remove the
specific (and very quickly obsolete) links to specific bugs and
feature requests to be looked at. I'd like to replace them with a link
into the bug tracker, assuming it will be more dynamic and up to date.
I recall a discussion about dividing tracker tickets into two groups:
"release" and "later". Self-explaining.
I see there are two grouping facilities on the (new?) SF bugtracker:
Category and Group. I am a bit confused about the criteria. Maybe we
need a clean up there? But first the most pressing question: am I
right to assume that the group "hugin-critical" is what needs to be
solved before we can release 0.8.0?
https://sourceforge.net/tracker/?limit=100&group_id=77506&atid=550441&status=1&artgroup=801640
there are 25 tickets open there. Let's work them down!
Yuv
Bruno Postle
>
>I see there are two grouping facilities on the (new?) SF bugtracker:
>Category and Group. I am a bit confused about the criteria. Maybe we
>need a clean up there? But first the most pressing question: am I
>right to assume that the group "hugin-critical" is what needs to be
>solved before we can release 0.8.0?
The categories and groups just narrow things down.
I use categories are to indicate if the bug is platform specific
(Linux, OS X, Windows), and groups for the various tools, i.e. a
large number of entries in the hugin tracker are actually enblend or
autopano-sift-c bugs.
>https://sourceforge.net/tracker/?limit=100&group_id=77506&atid=550441&status=1&artgroup=801640
>
>there are 25 tickets open there. Let's work them down!
I don't think any of these are actually release blockers or are not
going to be fixed anytime soon.
..however there are a couple of uncategorised recent items that
should be in this 'critical' group.
--
Bruno
Yuval Levy
> I use categories are to indicate if the bug is platform specific
> (Linux, OS X, Windows), and groups for the various tools, i.e. a
> large number of entries in the hugin tracker are actually enblend or
> autopano-sift-c bugs.
thanks for clearing up my confusion.
>> https://sourceforge.net/tracker/?limit=100&group_id=77506&atid=550441&status=1&artgroup=801640
>>
>> there are 25 tickets open there. Let's work them down!
>
> I don't think any of these are actually release blockers or are not
> going to be fixed anytime soon.
>
> ..however there are a couple of uncategorised recent items that
> should be in this 'critical' group.
so how is a 'critical' bug different from a 'release blocker' bug?
can we make a list of what are 'release blockers' and focus on them?
for future releases I would like to have a category of bugs that are
singled out for fix in the upcoming release. Those would obviously all
be 'release blockers'.
Yuv
Bruno Postle
>
>so how is a 'critical' bug different from a 'release blocker' bug?
It's the result of not maintaining the tracker very well.
>can we make a list of what are 'release blockers' and focus on them?
>for future releases I would like to have a category of bugs that are
>singled out for fix in the upcoming release. Those would obviously all
>be 'release blockers'.
Maybe we should just use the numeric scoring and remove the 'hugin
critical' group (we don't have a 'batch processor critical' group).
i.e. '9' is a blocker.
--
Bruno
Harry van der Wolf
To give my (personal) viewpoint on these critical bugs on the OSX "side":
2297456 Hugin crashes on exit after use OpenGL fast preview window: Still happens all the time after it has been used.
2189798 syslogd on OS X gets crazy: Can be closed. Ippei built in some extensive (debug) logging (and so did some other programmers). I "out commented" most of it (svn 3593) and the syslog is no longer flooded.
2152269 Crash on MacOS when deleting control points. Can be closed? I can't reproduce this one, not even with a couple of very big projects, trying a couple of builds.
1969739 [OSX] jpeg quality setting by user is not read correctly. Still not solved. It's mentioned as a duplicate but I can't find the other. The work-around is to set the jpeg-quality. Click another text-field, click the jpeg-quality textfield again and then it's used.
1898264 autopano-sift-c failure with Hugin.app (OS X). Should be closed. This must be a configuration "error". Stupid OSX holds a special path in a special file for external binaries called from a bundle application. A "quality passed" OSX bundle should only use OSX standard libraries and binaries outside the bundle. However, when a binary inside a bundle is started from the command line using the full path to it (as specified in the ticket), the normal PATH is used (Who at Apple was so stupid to design it like that). It works fine in all combinations I tried (using that "special" bundle path that's not in the normal environment).
Harry
Lukáš Jirkovský
> Hi all,
>
> To give my (personal) viewpoint on these critical bugs on the OSX "side":
>
> 2297456 Hugin crashes on exit after use OpenGL fast preview window: Still
> happens all the time after it has been used.
>
> 2189798 syslogd on OS X gets crazy: Can be closed. Ippei built in some
> extensive (debug) logging (and so did some other programmers). I "out
> commented" most of it (svn 3593) and the syslog is no longer flooded.
>
> 2152269 Crash on MacOS when deleting control points. Can be closed? I can't
> reproduce this one, not even with a couple of very big projects, trying a
> couple of builds.
>
> 1969739 [OSX] jpeg quality setting by user is not read correctly. Still not
> solved. It's mentioned as a duplicate but I can't find the other. The
> work-around is to set the jpeg-quality. Click another text-field, click the
> jpeg-quality textfield again and then it's used.
>
> 1898264 autopano-sift-c failure with Hugin.app (OS X). Should be closed.
> This must be a configuration "error". Stupid OSX holds a special path in a
> special file for external binaries called from a bundle application. A
> "quality passed" OSX bundle should only use OSX standard libraries and
> binaries outside the bundle. However, when a binary inside a bundle is
> started from the command line using the full path to it (as specified in the
> ticket), the normal PATH is used (Who at Apple was so stupid to design it
> like that). It works fine in all combinations I tried (using that "special"
> bundle path that's not in the normal environment).
>
> Harry
>
>
Thanks, I've closed 2189798. I'm not sure about the 1898264. IMO it's
the 172+ bug.
Lukáš Jirkovský
bug as the bug discussed in this [1] thread which Bruno already fixed.
[1] http://groups.google.com/group/hugin-ptx/browse_thread/thread/f9062c8a15bc43c6/20f36dde2354e816
Harry van der Wolf
2009/6/10 Harry van der Wolf <hvd...@gmail.com>:
>
> 1898264 autopano-sift-c failure with Hugin.app (OS X). Should be closed.
> This must be a configuration "error". Stupid OSX holds a special path in a
> special file for external binaries called from a bundle application. A
> "quality passed" OSX bundle should only use OSX standard libraries and
> binaries outside the bundle. However, when a binary inside a bundle is
> started from the command line using the full path to it (as specified in the
> ticket), the normal PATH is used (Who at Apple was so stupid to design it
> like that). It works fine in all combinations I tried (using that "special"
> bundle path that's not in the normal environment).
>
> Harry
>
>
Thanks, I've closed 2189798. I'm not sure about the 1898264. IMO it's
the 172+ bug.
No. it's not. The 1898264 is not related to the 172+ bug.
However you made me doubt. I did some thorough testing but I used the "real" 2.5 from July 2008.
So to be sure I just rebuilt the latest version from svn with the lately added patches.
Fortunately, that one works fine too! It's even about 10% faster on small sets and 15-20% on big sets.
Harry
Yuval Levy
> It's the result of not maintaining the tracker very well.
AFAIK you're the only person who works consistently through the
trackers. Others, including me, look occasionally at it. Do you see ways
how we can help you maintain the tracker better? should we codify the
process of tracker maintenance?
As a minimum I would suggest keeping track of new vs. existing bugs; a
set of rules on how to triage new bugs; and a way to tell other
volunteers what dateline divides the existing vs. new bugs (i.e. when
were the bugs triaged last).
Things would work this way:
1. when a volunteer has time to go over the new bugs, he/she goes to the
bugtracker, filters for "Open" status and sort by "Opened":
<http://sourceforge.net/tracker/?words=tracker_browse&sort=open_date&sortdir=asc&group_id=77506&atid=550441&status=1>
2. the volunteer scrolls down to the last "cutoff date" and looks at
each new bug report added after the cutoff date.
3. For each bug report:
- determine if it is a duplicate or can otherwise be closed
- if it is anonymous, determine the likelyhood that we may need
additional feedback and eventually set it to pending status (we may want
to word out a policy about anonymous bug reports)
- assign Category, Group, Priority - when in doubt, ask on the mailing list
- add clarifying questions to the bug ticket if applicable
- if necessary, post a message to the mailing list about the new bug.
e.g. if the bug report is anonymous and we need more information, post
to the mailing list, chances are the reporter is here and just did not
log on to SF
4. at the end of the day, post a message to the mailing list saying that
bugs from old cutoff date to new cutoff date have been triaged. Ideally
the new cutoff date is today, but sometimes people don't have the time
to process all the new bugs that are in the tracker, and we need a way
to enable team work on this. So the new cutoff date is the pointer for
the next bug triage volunteer.
> Maybe we should just use the numeric scoring and remove the 'hugin
> critical' group (we don't have a 'batch processor critical' group).
>
> i.e. '9' is a blocker.
I second that. I started updating
<http://wiki.panotools.org/Development_of_Open_Source_tools> and
specific to this subject I edited under
<http://wiki.panotools.org/Development_of_Open_Source_tools#Release_Cycle>
the link to the bugs that will have been fixed before the next Hugin
will be released.
Feel free to add/edit/change/improve. I'm just me, pushing for the
systematic approach :)
Yuv
Yuval Levy
Harry van der Wolf wrote:
> To give my (personal) viewpoint on these critical bugs on the OSX "side":
my (personal) viewpoint is: update the bug tracker. Even if others may
not agree with your viewpoint, it is by doing things and discussing them
later that we move forward together.
EDIT: when I was at bug 2152269 I realized I had no longer permission to
change status in the (new) SF bugtracker. As admin I corrected my
permissions and at the same time I gave you permissions. If somebody
else find that they can't contribute due to lack of permission, let us
know *here*.
> 2297456 Hugin crashes on exit after use OpenGL fast preview
> window<http://sourceforge.net/tracker/?func=detail&aid=2297456&group_id=77506&atid=550441>:
> Still happens all the time after it has been used.
to me this is cosmetics. as long as it does not corrupt the project
files, if it crashes on exit, it was exiting anyway so it exits with a
crash. nice to fix but not a show stopper.
> 2152269 Crash on MacOS when deleting control
> points<http://sourceforge.net/tracker/?func=detail&aid=2152269&group_id=77506&atid=550441>.
> Can be closed? I can't reproduce this one, not even with a couple of very
> big projects, trying a couple of builds.
I can't really make a call on this one. Brent is one of the most
thorough testers and he's "tracked down the problem. It is due to having
control points in the PTO that are outside the limits of one of the
images. Although PTO files really shouldn't have them, I think Hugin
should respond somewhat more gracefully to this situation."
as such it should actually affect also other platforms.
I am on Ubuntu, SVN 3926. I artificially edited a PTO file to have
points outside the limits of the images. Deleting, adding, editing, no
crash. The point is still in the project and influences it (it would be
more graceful to weed out this kind of obviously wrong points) but no
crash, and we can't prevent users from fooling around their PTO. I'm
setting this bug report to pending.
actually setting it to pending was more difficult than I thought :)
>
> 1969739 [OSX] jpeg quality setting by user is not read
> correctly<http://sourceforge.net/tracker/?func=detail&aid=1969739&group_id=77506&atid=550441>.
> Still not solved. It's mentioned as a duplicate but I can't find the other.
> The work-around is to set the jpeg-quality. Click another text-field, click
> the jpeg-quality textfield again and then it's used.
in the thread to the bug you mention the other: "This is indeed the same
as bug 1905674"
<https://sourceforge.net/tracker/?func=detail&aid=1905674&group_id=77506&atid=550441>
Pablo said to it: "fixed in SVN 2959"
is this still an issue? if yes, you can edit its priority.
> 1898264 autopano-sift-c failure with Hugin.app (OS
> X)<http://sourceforge.net/tracker/?func=detail&aid=1898264&group_id=77506&atid=550441>.
> Should be closed.
done.
Yuv (who has to go now, my son woke up 15 minutes ago and we're ready
"for the day")
Gerry Patterson
Just so I understand, any bugs that are marked '9' prioity and are 'open', need to be fixed before the 0.8.0 release?
If that is the case, I see three.
I am next to useless on OSX only bugs as I don't have that platform. But I can take a look at the rest.
Best Regards,
- Gerry
Harry van der Wolf
EDIT: when I was at bug 2152269 I realized I had no longer permission to
change status in the (new) SF bugtracker. As admin I corrected my
permissions and at the same time I gave you permissions.
Thanks. I will take a more pro-active approach in the future now I'm able to change statuses myself.
> 2297456 Hugin crashes on exit after use OpenGL fast preview> window<http://sourceforge.net/tracker/?func=detail&aid=2297456&group_id=77506&atid=550441>:
> Still happens all the time after it has been used.to me this is cosmetics. as long as it does not corrupt the project
files, if it crashes on exit, it was exiting anyway so it exits with a
crash. nice to fix but not a show stopper.
> points<http://sourceforge.net/tracker/?func=detail&aid=2152269&group_id=77506&atid=550441>.
> 2152269 Crash on MacOS when deleting control
> Can be closed? I can't reproduce this one, not even with a couple of veryI can't really make a call on this one. Brent is one of the most
> big projects, trying a couple of builds.
thorough testers and he's "tracked down the problem. It is due to having
control points in the PTO that are outside the limits of one of the
images. Although PTO files really shouldn't have them, I think Hugin
should respond somewhat more gracefully to this situation."
as such it should actually affect also other platforms.
I am on Ubuntu, SVN 3926. I artificially edited a PTO file to have
points outside the limits of the images. Deleting, adding, editing, no
crash. The point is still in the project and influences it (it would be
more graceful to weed out this kind of obviously wrong points) but no
crash, and we can't prevent users from fooling around their PTO. I'm
setting this bug report to pending.
actually setting it to pending was more difficult than I thought :)
Where does the ticket mentions that the control points are outside of one of the images? Did I overlook that?
I didn't test that but I will asap.
> correctly<http://sourceforge.net/tracker/?func=detail&aid=1969739&group_id=77506&atid=550441>.
>
> 1969739 [OSX] jpeg quality setting by user is not read
> Still not solved. It's mentioned as a duplicate but I can't find the other.in the thread to the bug you mention the other: "This is indeed the same
> The work-around is to set the jpeg-quality. Click another text-field, click
> the jpeg-quality textfield again and then it's used.
as bug 1905674"
<https://sourceforge.net/tracker/?func=detail&aid=1905674&group_id=77506&atid=550441>
Pablo said to it: "fixed in SVN 2959"
is this still an issue? if yes, you can edit its priority.
I assume it has something to do with wxwindows behavinf differently on OSX.
Harry
Bruno Postle
>
>AFAIK you're the only person who works consistently through the
>trackers. Others, including me, look occasionally at it. Do you see ways
>how we can help you maintain the tracker better? should we codify the
>process of tracker maintenance?
Yes that would be good, especially because I'm finding that I don't
have time to cope with it.
Your description is more-or-less what I already do, reports are
generally:
- duplicates of known bugs
- don't have enough information, usually anonymous
- something new
I usually try and close/score or set to pending, assign the
component (enblend/hugin/etc...) and the OS (but only if relevant, a
generic bug will get lost if mis-assigned to an OS).
Anonymous bugs with not enough information should always be set to
pending so the tracker can automatically close them after a few days
if there is no more info forthcoming.
Also rename the bug, especially if there is a distinctive error
message, "stitching fails" almost guarantees that nobody will look
at the report.
Dealing with duplicates is difficult since searching the tracker is
painfully slow. So there are large numbers of duplicates in the
tracker, and there are a lot of unclosed reports for things that have
since been fixed.
So the tracker needs three kinds of maintenance:
1. Triage, described above. We don't really need to log this, just
open all the most recent reports and it is fairly obvious when you
get to stuff that has aready been dealt with.
2. Cleaning up old stuff, the tracker is a bit of a mess.
3. Actual bug fixing.
--
Bruno
Bruno Postle
>
>Just so I understand, any bugs that are marked '9' prioity and are 'open',
>need to be fixed before the 0.8.0 release?
In principle yes, in practice they are not so consistent.
At the moment I can only recommend: 'advanced' search all the open bugs
for hugin, batch-processor and hugin-critical, excluding the ones
that are OS specific, this should return about 80 reports.
You then need to make a judgement as to what is important.
--
Bruno
Yuval Levy
I've attached a patch to one of the three bugs.
<https://sourceforge.net/support/tracker.php?aid=2803939>
I don't have write access to libpano's SVN.
A 0.8.0 release is overdue. The sooner the better. I suggest being very
strict about what bugs or application behaviors to consider show stoppers.
If it affects negatively functionality that was working in 0.7.0 it is
definitely a show stopper.
Most of them can be left for subsequent releases. We "just" have to be
consequent and keep fixing them at current speed and release more often.
Yuv
Yuval Levy
> Yes that would be good, especially because I'm finding that I don't
> have time to cope with it.
ok, I'll draft a process document with the objective to give community
volunteers with a few free cycle the information they need to contribute
to the bug's triage and I'll put it up on the wiki for
comments/corrections. Won't be in the coming days - we finally have some
good weather and it's here to stay for the weekend at least :)
Yuv
Yuval Levy
Harry van der Wolf wrote:
> Where does the ticket mentions that the control points are outside of one of
> the images? Did I overlook that?
in the new SourceForge bug tracker you have to scroll down beyond the
form where you can add your comments. There is a header "Comments" with
in parenthesis the number of comments and on the right side of the
window a + or a - sign in a black circle. If you see a +, hit it and it
will list all the comments underneath, before the files and other things.
not exactly the most obvious design, so it is very easy to overlook
parts of the bug report.
Yuv
Bruno Postle
>
>A 0.8.0 release is overdue. The sooner the better. I suggest being very
>strict about what bugs or application behaviors to consider show stoppers.
As far as I'm concerned the Fast Preview Crop button crash is a
blocker, I'm not sure about anything else:
https://sourceforge.net/tracker/?func=detail&aid=2801663&group_id=77506&atid=550441
--
Bruno
Doug
compiling hugin-0.8.0.rc2/3) related to this?
Doug
Gerry Patterson
I have checked a fix into SVN for this problem.
- Gerry
Seb Perez-D
> On Thu, Jun 11, 2009 at 5:37 PM, Bruno Postle <br...@postle.net> wrote:
>> As far as I'm concerned the Fast Preview Crop button crash is a
>> blocker, I'm not sure about anything else:
> I have checked a fix into SVN for this problem.
It's fixed for me.
Thanks !
Seb