Hugin Trackers

From PanoTools.org Wiki
(Difference between revisions)
Jump to: navigation, search
(Bug Triage)
(Sign the Ubuntu Code of Conduct)
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== General ==
+
= General =
  
The [http://sourceforge.net/tracker/?group_id=77506&atid=550441 Bug Tracker] (BT), the [http://sourceforge.net/tracker/?group_id=77506&atid=550444 Features Request Tracker] (FT), and the [http://sourceforge.net/tracker/?group_id=77506&atid=550443 Patch Tracker] (PT) are the official tools to communicate bugs, feature requests, and proposed changes to the developers. While bug reports, feature requests, and patches are always welcome over any channel, these are the only tools that make sure they will not be forgotten / hidden in the past archives. All users are encourage to make use of these tools. In the following text I explain the basic usage and set some policies with regard to Hugin.
+
Since November 22, 2010 bugs, feature requests and patches for Hugin are [https://bugs.launchpad.net/hugin tracked] in Launchpad, the official tools to communicate bugs, feature requests, and proposed changes to the developers. While bug reports, feature requests, and patches are always welcome over any channel, the Launchpad tracker is the only tools that make sure they will not be forgotten / hidden in the past archives. All users are encouraged to make use of Launchpad. In the following text I explain the basic usage and set some policies with regard to Hugin.
  
 
Moreover, discussion of tracker tickets is welcome on the [http://groups.google.com/group/hugin-ptx/ Mailing List] (ML). This includes (non-exhaustive list):
 
Moreover, discussion of tracker tickets is welcome on the [http://groups.google.com/group/hugin-ptx/ Mailing List] (ML). This includes (non-exhaustive list):
Line 9: Line 9:
 
* insuring follow up on anonymous tickets  
 
* insuring follow up on anonymous tickets  
  
 +
= Launchpad Account =
  
== Structure of a Ticket ==
+
Launchpad tickets can be viewed anonymously but to interact with the tracker you will need to register an account.  It is a straight forward process.  Once registered you can:
 +
* submit a new ticket
 +
* comment on existing tickets
 +
* vote on tickets
  
Whether it is to report a bug or to work on it, familiarizing with the structure of a ticket in the tracker is the first step. Look at existing tickets for examples.  
+
Moreover, if you are a power user and want to help triage and prioritize tickets; help users solve their problems; help developers with testing and observations; join the [https://launchpad.net/~hugin-bug-hunters Hugin Bug Hunters] team.
  
* On top is the summary, the ID, and the last update information. With "Tech & Admin" permission the summary is editable.
+
== OpenPGP key ==
* Under the details header is the initial comment, followed by some information about the status of the ticket. The status information is editable with "Tech & Admin" permission.
+
* Most important, at least initially, is who submitted the ticket. A ticket can be submitted anonymously but it is strongly recommended that users [http://sourceforge.net/account/registration/ register] with SourceForge (it's free and SF has a consistent track record of respectful committment to user's privacy) and [https://sourceforge.net/account/login.php log in] before creating a ticket or commenting on one. If you have [http://openid.net/ OpenID] there is no need to remember another password.
+
* Next is the comments thread. It may be condensed - click on the + icon on the right to expand it. When working on a ticket it is important to be aware that the "Details" section may not be everything there is to read. The follow ups often contain relevant / critical information. All users can add to the discussion.
+
* The attached files section lists all files that have been uploaded. This is usually meant for logs and patches. Project files (.pto) and screenshots still fit the weight limits. For full test cases with images this is not practicable - better store them somewhere on the web and publish a link in a comment. If you need such web space, ask on the ML.
+
* Users with "Tech & Admin" permission can associate a ticket to another one, marking it as a duplicate.
+
* Last but not least, all changes are listed.
+
  
 +
An OpenPGP key is not mandatory for general use, but it makes life easy.
  
== Initial Bug Report ==
+
You will need an OpenPGP key to
 +
* use the (faster and more comfortable) email interface to the tracker
 +
* sign the Code of Conduct and get access to advanced Launchpad features such as a personal PPA.
 +
* sign software uploaded to the repository.
 +
 
 +
== Generate Your Key (Linux/BSD/Mac) ==
 +
 
 +
Start a command line and type:
 +
 
 +
<pre>
 +
gpg --cert-digest-algo=SHA256 --default-preference-list="h10 h8 h9 h11 s9 s8 s7 s3 z2 z3 z1 z0" --gen-key
 +
</pre>
 +
 
 +
At the prompt
 +
* Confirm the type of key you want to create (RSA)
 +
* Give the key a validity.  Recommended setting two years so that if you loose your key or password it will be purged from the system
 +
* Real Name: enter your real name
 +
* Email: enter your email address
 +
 
 +
Read/copy the last 8 digits (e.g. 637572E4) from the key fingerprint and add them to ~/.bashrc
 +
 
 +
<pre>
 +
echo "export GPGKEY=637572E4" >> ~/.bashrc
 +
</pre>
 +
 
 +
Then restart the terminal session.
 +
 
 +
Upload the key to the Ubuntu key server and output the key's fingerprint
 +
 
 +
<pre>
 +
gpg --send-keys --keyserver keyserver.ubuntu.com $GPGKEY
 +
gpg --fingerprint $GPGKEY
 +
</pre>
 +
 
 +
Log on to your launchpad page https://launchpad.net/~<USER>/+editpgpkeys and paste the fingerprint.  Hit import key.  A message encrypted with your key ('''637572E4''') will be sent to you. Read your email.
 +
 
 +
== Generate Your Key (Windows) ==
 +
 
 +
Can somebody with a Windows box document the equivalent PuTTY commands?
 +
 
 +
== Sign the Ubuntu Code of Conduct ==
 +
 
 +
Read and sign the [https://launchpad.net/codeofconduct/1.1/+download Ubuntu Code of Conduct].  This will grant you privileges such as creating your own PPA and uploading source packages for build and distribution.
 +
 
 +
<pre>
 +
wget -O code.txt https://launchpad.net/codeofconduct/1.1/+download
 +
gpg -u $GPGKEY --clearsign code.txt
 +
cat code.txt.asc
 +
</pre>
 +
 
 +
Copy the resulting text and paste it into https://launchpad.net/codeofconduct/1.1/+sign
 +
 
 +
== Configure eMail Client ==
 +
 
 +
Last but not least, to use the email interface you need to configure your email client.
 +
 
 +
=== Kmail ===
 +
 
 +
* Settings -> Configure Kmail
 +
* In the Manage Identities tab, select the Email Address associated with your Launchpad account and hit the Modify... button (or hit Add... to create a new identity for it)
 +
* In the Cryptography tab, hit the Change... button next to the OpenPGP signing key.  Select the key and hit OK.  Repeat for the OpenPGP encryption key.
 +
 
 +
= Claim an Imported SourceForge Account =
 +
 
 +
If you used the older trackers on SourceForge, chances are there is already something from you in Launchpad.  Use the following procedure to claim it as being yours:
 +
 
 +
* Make sure your SF account is in good standing and that you are receiving emails at it.
 +
* Log on to the [https://bugs.launchpad.net/hugin Hugin bug tracker].
 +
* Find a ticket or comment that you filed in the old tracker.  Unfortunately entering your old user handle in the simple search field form does not work.  Maybe using the advanced search reporter field, however note that SF users are not LP users, so don't count on it to work.
 +
* On the ticket page you should see your SF user name, clickable. Click on it.
 +
* A standard page will display, saying that the user does not use LP and that the page was created when importing bugs for Hugin.  There is a link on the page asking if you are the user.  Hit the link.
 +
* You will land on a pre-filled Merge LP accounts form. Hit the Continue button.
 +
* An email message will be sent to the email address associated with the old account.  Open that email and click on the link.
 +
* You will land on a confirmation form.  click Confirm.
 +
* If everything completed successfully you will land on your LP account page with a confirmation of the successful merge.
 +
 
 +
= Email Notifications =
 +
 
 +
Launchpad uses a sophisticated [https://help.launchpad.net/Bugs/EmailInterface email interface].  It is possible to do almost anything via email without having to log into the web app.
 +
 
 +
Activity on the tracker is notified by email to:
 +
* everybody who subscribe to the individual ticket by hitting the subscribe link on the right of the tracker.  If you file a ticket, you are automatically subscribed to it.
 +
* everybody who subscribes to the tracker https://bugs.launchpad.net/hugin/+subscribe
 +
* the [https://launchpad.net/~hugin-bug-hunters Hugin Bug Hunters] team and the [https://launchpad.net/~hugin-devs Hugin Developers] team
 +
 
 +
To manage your notification settings you can (replace $USER with your Launchpad name):
 +
* change your email settings (short-term/holiday) for team mailing lists at <code>https://launchpad.net/~$USER/+editemails</code> and a general subscription policy to new mailing lists.
 +
* change your team participation (long-term) at <code>https://launchpad.net/~$USER/+participation</code>
 +
* list the bugs you're subscribed to and change the individual subscription to each bug (fine tuning) at <code>https://bugs.launchpad.net/~$USER</code>
 +
 
 +
= Placing a Ticket =
 +
 
 +
To use the tracker, you need a [http://wiki.panotools.org/Hugin_Trackers#Launchpad_Account Launchpad Account].  You can submit our translation via the web or via email.
 +
 
 +
== Web ==
 +
 
 +
* Log on with your Launchpad account.
 +
* Start reporting a [https://bugs.launchpad.net/hugin/+filebug new ticket].
 +
* Enter a title/summary (e.g. German Translation).
 +
* Launchpad will look for duplicates.  Look in the list of reports found if your issue has already been reported.  It is preferable to add to an old report (and even re-open a closed or expired report)  than to start a new one.  In most cases the previous history will give more weight to your report.
 +
* On the reporting form, enter a description.
 +
* If you need to attach a .pto file, a stitch log, a screenshot, or anything else that may be useful, scroll to the bottom and hit the link "Extra options".
 +
* There you will find an Attachment field.  Hit it and browse to the file you want to attach.
 +
* Click the "Submit Bug Report" button.
 +
 
 +
To add an attachment to an already existing ticket:
 +
* Log on to your Launchpad account.
 +
* Get on the report's page.
 +
* Scroll to the bottom.
 +
* Hit the "Add attachment or patch" link.
 +
* Enter a comment.
 +
* Hit the attachment field and browse to the file you want to attach.
 +
* Enter a description (optional).
 +
* Hit the "Post Comment" button.
 +
 
 +
 
 +
== eMail ==
 +
 
 +
Reporting a new ticket by email works too, but there are some critical conditions:
 +
* Your email account must be registered with Launchpad.
 +
* You must have an OpenPGP key associated with it and known to Launchpad.
 +
* You must craft your email carefully.  A misplaced space or a typo can doom your report.
 +
* To be safe, use TEXT email, not HTML -- a good habit anyway.  In most email client you recognize the TEXT mode by the lack of a formatting toolbar).
 +
 
 +
The message:
 +
* From: your Launchpad-registered email address
 +
* To: new@bugs.launchpad.net
 +
* Subject: title of the bug
 +
* Body:  description + carefully crafted commands.  Commands are usually at the end of the body.  One per line.  Each command line starts with a single space.
 +
* Enter the command " affects hugin" to assign the report to Hugin.
 +
* Enter the command " tag translation" to tag the report as being a translation.
 +
* Attach the file(s) to the email.
 +
* Send.  It takes about five minutes to process and you get an email back with the result.
 +
 
 +
Replying to a bug report by email is easier.  You don't need to issue the " affects hugin" command since the reply is referenced by the ticket number.
 +
 
 +
 
 +
= Types of Tickets =
 +
 
 +
== Feature Request ==
 +
 
 +
Do you have an idea for a feature that Hugin does not have yet? You don't have the time/skill for coding? You can at least contribute the idea and some analysis. Discussions on the mailing list are OK but tend to get lost in time. If you want to make sure that your idea is remembered, enter it into the tracker.  The more analysis and description of the feature, the better.  Make a case for it, show why it would be an advantage. The feature may be picked up by a skilled developer, or it could also become a Google Summer of Code or otherwise sponsored project.
 +
 
 +
== Bug Report ==
  
 
All users are encouraged to report bugs. Please help us improve the quality of the bug reports and the information available to the developers by following these guidelines:
 
All users are encouraged to report bugs. Please help us improve the quality of the bug reports and the information available to the developers by following these guidelines:
Line 33: Line 175:
 
If you have access to a second system, please validate the bug before reporting it.
 
If you have access to a second system, please validate the bug before reporting it.
  
 +
Recent version of Hugin have system information in the About menu.  Copy and paste it.
  
=== The Sofware ===
+
 
 +
=== The Software ===
  
 
We also need to know as much as possible about the software used. Which version of Hugin? Where did you install it from? Did you compile Hugin yourself? An easy way to identify your version of Hugin is to look up the About Hugin dialog (Menu Help -> About Hugin) and report the whole version string.
 
We also need to know as much as possible about the software used. Which version of Hugin? Where did you install it from? Did you compile Hugin yourself? An easy way to identify your version of Hugin is to look up the About Hugin dialog (Menu Help -> About Hugin) and report the whole version string.
  
 
Hugin depends on third party libraries and tools such as libpano and enblend/enfuse. Unless you have downloaded a Windows installer or a Mac bundle (that are self-contained), we'd need to know the same information for the dependencies. Where and when did you install them from?
 
Hugin depends on third party libraries and tools such as libpano and enblend/enfuse. Unless you have downloaded a Windows installer or a Mac bundle (that are self-contained), we'd need to know the same information for the dependencies. Where and when did you install them from?
 
  
 
=== The Application ===
 
=== The Application ===
  
Often times the nature of your project, particularly the images, will help understand the bug. How many images? What format? Do they have EXIF data? What camera make/model? Is it HDR? Often time, providing the .pto file (can be attached in the BT) is a valuable input to the analysis process. If you have access to web-space, providing the full test case including images (in JPG format and/or resized to reduce storage/bandwidth need) can also help.
+
Often times the nature of your project, particularly the images, will help understand the bug. How many images? What format? Do they have EXIF data? What camera make/model? Is it HDR? Providing the .pto file (can be attached) is a valuable input to the analysis process. If you have access to web-space, providing the full test case including images (in JPG format and/or resized to reduce storage/bandwidth need) can also help.
  
  
Line 53: Line 196:
 
== Bug Triage ==
 
== Bug Triage ==
  
To triage bugs a user need a SourceForge login and "Tech & Admin" permission to the BT. Permission will be liberally given to users who have shown continued, relevant contributions to the debugging process.
+
Power users can triage tickets by reading them, understanding, validating and editing their settings such as priority and status.
  
* Log on to the [https://sourceforge.net/tracker/?limit=20&sort=open_date&sortdir=desc&offset=0&group_id=77506&atid=550441&status=1
+
* Log on to the tracker
BT] (the link is already filtered for opened ticket sorted from the most recent one on top).
+
* Start with the oldest bug that has not been triaged yet (status is New and it is not the result of a status reset).
* Start with the oldest bug that has not been triaged yet. Ideally the new reports are identified by Priority 5, although at the time of writing many old reports still have Priority 5. It is also possible to be alerted to new reports by [https://lists.sourceforge.net/lists/listinfo/hugin-tracker subscribing] the tracker mailing list.
+
 
* Read the ticket and make sure you fully understand it. When in doubt, leave it for more experienced users to triage or ask on the ML.
 
* Read the ticket and make sure you fully understand it. When in doubt, leave it for more experienced users to triage or ask on the ML.
* If you determine that the ticket is a duplicate, mark it as such and close it.
+
* If you determine that the ticket is a duplicate, mark it as such and close it.  You will need to enter the ticket number of the other ticket.
* There are frequently appearing error messages such as "precondition violation", "false --compression", "Mask is entirely black but white image was not identified as redundant", etc... that need entries in the [[hugin FAQ]] - Duplicates should be closed with a link to the FAQ.
+
* There are frequently appearing error messages such as "precondition violation", "false --compression", "Mask is entirely black but white image was not identified as redundant", etc... that need entries in the [[hugin FAQ]] - Duplicates should be closed with a link to the FAQ.  If applicable, update the FAQ.
* Assign Category, Group, Priority according to the policies in the next sections.
+
* Tag the bug liberally and assign status and importance-
 
* Add clarifying questions to the bug ticket if applicable. In doing so, compare the currently available information against the requested information listed above in "Reporting a Bug" and the specifics of the report.
 
* Add clarifying questions to the bug ticket if applicable. In doing so, compare the currently available information against the requested information listed above in "Reporting a Bug" and the specifics of the report.
* If the ticket was entered anonymously, determine the likelyhood that the developers may need additional feedback. Ask for that feedback on the ML. Eventually set the report to pending status so that if nobody acts on the request it will be closed in two weeks for lack of information.
 
 
* When in doubt, ask on the ML.
 
* When in doubt, ask on the ML.
 +
 +
=== Understanding Ticket Status ===
 +
 +
As the ticket evolves throughout its life cycle, it can have the following stati:
 +
 +
* '''New''':  All tickets are born with the New status.  Moreover, if a user has made a change to a ticket and want to draw triager attention, he will reset the status to '''New'''.  This is particularly important for tickets with status '''Incomplete''' that risk to expire if not reset to '''New'''.  Try not to leave a '''New''' status after looking at a ticket, unless you are completely clueless about it.  Set it to '''Triaged''' if you tagged it, verified that it is not '''Incomplete''' or '''Invalid'''.
 +
 +
* '''Incomplete''':  Triagers will set the status to incomplete if information is missing / expected from the reporter, or if the contributed patch requires some extra work.  Usually they will post a note detailing what information is required.  If there is no further activity within 60 days, the ticket will expire.  It is important that whoever completes / adds to the ticket set the status again to '''New''', to draw attention to the extra information.  An email warning is sent a few days before expiry.
 +
 +
* '''Opinion''':  Before setting the status to '''Opinion''' a triager will check if it is possible to accomodate the wish, e.g. with a preference.  But sometimes things are just too far fetched and Hugin is not an [http://en.wiktionary.org/wiki/eierlegende_Wollmilchsau].  Please respect it if one of your ticket has been marked as an '''Opinion''' and don't start a flame.  If you mark a ticket as an '''Opinion''' make sure to provide alternatives / justification (e.g. list alternative tools that are better suited to solve the problem described).  Use sparingly.
 +
 +
* '''Invalid''':  A bug is set to '''Invalid''' if it was filed against an older version and is no longer applicable; or if the problem is not in the code; or if the contributed patch will never be accepted.
 +
 +
* '''Won't fix''':  The behavior is known, but for some reason it won't be fixed, e.g. the code causing it has become or will become obsolete in a subsequent release, or the bug is just an annoyance that would take too much effort to fix. Or the behavior is "odd" to some people, but useful for others.
 +
 +
* '''Confirmed''':  It's on our radar screen.  we know what needs to be done in the code, but there are no resources to tackle it yet.  This is also the status to give to ticket with contributed patches.
 +
 +
* '''Triaged''':  Somebody has been looking at the report but it is still work in progress and we don't know yet what the next step will be other than looking at it again.  At least it has not been declared '''Invalid''' yet.
 +
 +
* '''In Progress''': A developer has started to tackle the issue.
 +
 +
* '''Fix Committed''': A fix has been committed to the repository.  users with access to bleeding edge builds can test it and confirm if the fix worked or not.  If the fix did not work, report it and set the status to new again.
 +
 +
* '''Fix Released''':  The fix is part of a release.  If users using stable versions after that release find the error again, they can change the status to New and report that the fix did not work.
  
 
== Bug Validation ==
 
== Bug Validation ==
Line 78: Line 243:
 
== Bug Fixing and Testing ==
 
== Bug Fixing and Testing ==
  
Everybody is encouraged to provide fixes and patches to correct bugs. Only developers can add them to the repository. Write access to the repository will be liverally given to users who need it.
+
Everybody is encouraged to provide fixes and patches to correct bugs. Only developers can add them to the repository. Write access to the repository will be liberally given to users who need it.
 
* when a developer fixed a bug, he can ask the ML for testing.
 
* when a developer fixed a bug, he can ask the ML for testing.
 
* a fix tested on the developers system only can be set to Pending status.
 
* a fix tested on the developers system only can be set to Pending status.
Line 87: Line 252:
  
 
* The more complete a bug report, the more attention it is likely to get.
 
* The more complete a bug report, the more attention it is likely to get.
* Anonymous bug reports are set on Pending status by default, unless the report is complete enough not to need further feedback and/or there is interest from contributors to work on the report.
 
* When triaging a bug, set it's priority to something different than 5 so that priority 5 reports are known to be untriaged.
 
 
 
=== Categories ===
 
 
We use categories to indicate if the bug is platform specific, although some tickets still carry "legacy categories" that are unrelated to the platforms.
 
 
 
=== Groups ===
 
  
We use groups to indicate which tool is affected by the bug.
+
=== Importance ===
  
 +
* Members of the Hugin Bug Hunter team can set the importance of a bug.
 +
* You can indicate that a bug is important to you by hitting the "affect me too" button.
  
=== Priorities ===
+
=== Ticket Assignement ===
  
We use priorities to sort out the the tickets.
+
* The tracker enables the assignment of a ticket to a person. It is considered rude to assign a ticket to somebody else without their prior consent. Developers sometimes assign a ticket to themselves to signal they are working on it, but we do not use this feature too often.
 +
* The tracker allows the subscription of somebody else to a ticket.  You can do so once if you think a person should be aware of a ticket.  Then add a note to that ticket and the person concerned will receive it in her mail.  But if the person decides otherwise and unsubscribes from the ticket, please respect it.
  
* 9: show stopper for the current release
+
== Tips & Tricks ==
* more than 5: bug affects a large number of use cases.
+
* 5: new bug that needs to be triaged
+
* less than 5: bug affects a small number of use cases - rare / specific situation
+
  
 +
If you know the old SourceForge bug number (e.g. form a comment on a migrated ticket), you can find it at the URL
 +
  https://bugs.launchpad.net/bugs/${name}
 +
So, for example https://bugs.launchpad.net/bugs/sf-2789151 (referenced at https://bugs.launchpad.net/hugin/+bug/679170/comments/5)
 +
will redirect you to https://bugs.launchpad.net/hugin/+bug/679179
  
=== Bug Assignement ===
 
  
The tracker enables the assignement of a bug to a person. It is considered rude to assign a bug to somebody else without their prior consent. Developers sometimes assign a bug to themselves to signal they are working on it, but we do not use this feature too often.
+
[[Category:Software:Hugin]]

Latest revision as of 14:39, 6 August 2011

Contents

[edit] General

Since November 22, 2010 bugs, feature requests and patches for Hugin are tracked in Launchpad, the official tools to communicate bugs, feature requests, and proposed changes to the developers. While bug reports, feature requests, and patches are always welcome over any channel, the Launchpad tracker is the only tools that make sure they will not be forgotten / hidden in the past archives. All users are encouraged to make use of Launchpad. In the following text I explain the basic usage and set some policies with regard to Hugin.

Moreover, discussion of tracker tickets is welcome on the Mailing List (ML). This includes (non-exhaustive list):

  • requests to test bugs and patches
  • requests for opinions on ways to fix bugs and implement new features
  • enlarging the base of interested user / tester to encompass a variety of platforms
  • insuring follow up on anonymous tickets

[edit] Launchpad Account

Launchpad tickets can be viewed anonymously but to interact with the tracker you will need to register an account. It is a straight forward process. Once registered you can:

  • submit a new ticket
  • comment on existing tickets
  • vote on tickets

Moreover, if you are a power user and want to help triage and prioritize tickets; help users solve their problems; help developers with testing and observations; join the Hugin Bug Hunters team.

[edit] OpenPGP key

An OpenPGP key is not mandatory for general use, but it makes life easy.

You will need an OpenPGP key to

  • use the (faster and more comfortable) email interface to the tracker
  • sign the Code of Conduct and get access to advanced Launchpad features such as a personal PPA.
  • sign software uploaded to the repository.

[edit] Generate Your Key (Linux/BSD/Mac)

Start a command line and type:

gpg --cert-digest-algo=SHA256 --default-preference-list="h10 h8 h9 h11 s9 s8 s7 s3 z2 z3 z1 z0" --gen-key

At the prompt

  • Confirm the type of key you want to create (RSA)
  • Give the key a validity. Recommended setting two years so that if you loose your key or password it will be purged from the system
  • Real Name: enter your real name
  • Email: enter your email address

Read/copy the last 8 digits (e.g. 637572E4) from the key fingerprint and add them to ~/.bashrc

echo "export GPGKEY=637572E4" >> ~/.bashrc

Then restart the terminal session.

Upload the key to the Ubuntu key server and output the key's fingerprint

gpg --send-keys --keyserver keyserver.ubuntu.com $GPGKEY
gpg --fingerprint $GPGKEY

Log on to your launchpad page https://launchpad.net/~<USER>/+editpgpkeys and paste the fingerprint. Hit import key. A message encrypted with your key (637572E4) will be sent to you. Read your email.

[edit] Generate Your Key (Windows)

Can somebody with a Windows box document the equivalent PuTTY commands?

[edit] Sign the Ubuntu Code of Conduct

Read and sign the Ubuntu Code of Conduct. This will grant you privileges such as creating your own PPA and uploading source packages for build and distribution.

wget -O code.txt https://launchpad.net/codeofconduct/1.1/+download
gpg -u $GPGKEY --clearsign code.txt
cat code.txt.asc

Copy the resulting text and paste it into https://launchpad.net/codeofconduct/1.1/+sign

[edit] Configure eMail Client

Last but not least, to use the email interface you need to configure your email client.

[edit] Kmail

  • Settings -> Configure Kmail
  • In the Manage Identities tab, select the Email Address associated with your Launchpad account and hit the Modify... button (or hit Add... to create a new identity for it)
  • In the Cryptography tab, hit the Change... button next to the OpenPGP signing key. Select the key and hit OK. Repeat for the OpenPGP encryption key.

[edit] Claim an Imported SourceForge Account

If you used the older trackers on SourceForge, chances are there is already something from you in Launchpad. Use the following procedure to claim it as being yours:

  • Make sure your SF account is in good standing and that you are receiving emails at it.
  • Log on to the Hugin bug tracker.
  • Find a ticket or comment that you filed in the old tracker. Unfortunately entering your old user handle in the simple search field form does not work. Maybe using the advanced search reporter field, however note that SF users are not LP users, so don't count on it to work.
  • On the ticket page you should see your SF user name, clickable. Click on it.
  • A standard page will display, saying that the user does not use LP and that the page was created when importing bugs for Hugin. There is a link on the page asking if you are the user. Hit the link.
  • You will land on a pre-filled Merge LP accounts form. Hit the Continue button.
  • An email message will be sent to the email address associated with the old account. Open that email and click on the link.
  • You will land on a confirmation form. click Confirm.
  • If everything completed successfully you will land on your LP account page with a confirmation of the successful merge.

[edit] Email Notifications

Launchpad uses a sophisticated email interface. It is possible to do almost anything via email without having to log into the web app.

Activity on the tracker is notified by email to:

To manage your notification settings you can (replace $USER with your Launchpad name):

[edit] Placing a Ticket

To use the tracker, you need a Launchpad Account. You can submit our translation via the web or via email.

[edit] Web

  • Log on with your Launchpad account.
  • Start reporting a new ticket.
  • Enter a title/summary (e.g. German Translation).
  • Launchpad will look for duplicates. Look in the list of reports found if your issue has already been reported. It is preferable to add to an old report (and even re-open a closed or expired report) than to start a new one. In most cases the previous history will give more weight to your report.
  • On the reporting form, enter a description.
  • If you need to attach a .pto file, a stitch log, a screenshot, or anything else that may be useful, scroll to the bottom and hit the link "Extra options".
  • There you will find an Attachment field. Hit it and browse to the file you want to attach.
  • Click the "Submit Bug Report" button.

To add an attachment to an already existing ticket:

  • Log on to your Launchpad account.
  • Get on the report's page.
  • Scroll to the bottom.
  • Hit the "Add attachment or patch" link.
  • Enter a comment.
  • Hit the attachment field and browse to the file you want to attach.
  • Enter a description (optional).
  • Hit the "Post Comment" button.


[edit] eMail

Reporting a new ticket by email works too, but there are some critical conditions:

  • Your email account must be registered with Launchpad.
  • You must have an OpenPGP key associated with it and known to Launchpad.
  • You must craft your email carefully. A misplaced space or a typo can doom your report.
  • To be safe, use TEXT email, not HTML -- a good habit anyway. In most email client you recognize the TEXT mode by the lack of a formatting toolbar).

The message:

  • From: your Launchpad-registered email address
  • To: new@bugs.launchpad.net
  • Subject: title of the bug
  • Body: description + carefully crafted commands. Commands are usually at the end of the body. One per line. Each command line starts with a single space.
  • Enter the command " affects hugin" to assign the report to Hugin.
  • Enter the command " tag translation" to tag the report as being a translation.
  • Attach the file(s) to the email.
  • Send. It takes about five minutes to process and you get an email back with the result.

Replying to a bug report by email is easier. You don't need to issue the " affects hugin" command since the reply is referenced by the ticket number.


[edit] Types of Tickets

[edit] Feature Request

Do you have an idea for a feature that Hugin does not have yet? You don't have the time/skill for coding? You can at least contribute the idea and some analysis. Discussions on the mailing list are OK but tend to get lost in time. If you want to make sure that your idea is remembered, enter it into the tracker. The more analysis and description of the feature, the better. Make a case for it, show why it would be an advantage. The feature may be picked up by a skilled developer, or it could also become a Google Summer of Code or otherwise sponsored project.

[edit] Bug Report

All users are encouraged to report bugs. Please help us improve the quality of the bug reports and the information available to the developers by following these guidelines:

[edit] Your System

We need to know as much as possible about your system. Which version? What processor? How much memory? How much disk space is available, particularly temporary space? Are all updates recommended by the system's distributor applied? Have you customized the system? added/replaced libraries?

If you have access to a second system, please validate the bug before reporting it.

Recent version of Hugin have system information in the About menu. Copy and paste it.


[edit] The Software

We also need to know as much as possible about the software used. Which version of Hugin? Where did you install it from? Did you compile Hugin yourself? An easy way to identify your version of Hugin is to look up the About Hugin dialog (Menu Help -> About Hugin) and report the whole version string.

Hugin depends on third party libraries and tools such as libpano and enblend/enfuse. Unless you have downloaded a Windows installer or a Mac bundle (that are self-contained), we'd need to know the same information for the dependencies. Where and when did you install them from?

[edit] The Application

Often times the nature of your project, particularly the images, will help understand the bug. How many images? What format? Do they have EXIF data? What camera make/model? Is it HDR? Providing the .pto file (can be attached) is a valuable input to the analysis process. If you have access to web-space, providing the full test case including images (in JPG format and/or resized to reduce storage/bandwidth need) can also help.


[edit] The Bug

What are the steps that need to be undertaken to reproduce the bug? Does it happen consistently all the times, or only sporadically? what is the expected application behavior and how does it differ from the observed application behavior?


[edit] Bug Triage

Power users can triage tickets by reading them, understanding, validating and editing their settings such as priority and status.

  • Log on to the tracker
  • Start with the oldest bug that has not been triaged yet (status is New and it is not the result of a status reset).
  • Read the ticket and make sure you fully understand it. When in doubt, leave it for more experienced users to triage or ask on the ML.
  • If you determine that the ticket is a duplicate, mark it as such and close it. You will need to enter the ticket number of the other ticket.
  • There are frequently appearing error messages such as "precondition violation", "false --compression", "Mask is entirely black but white image was not identified as redundant", etc... that need entries in the hugin FAQ - Duplicates should be closed with a link to the FAQ. If applicable, update the FAQ.
  • Tag the bug liberally and assign status and importance-
  • Add clarifying questions to the bug ticket if applicable. In doing so, compare the currently available information against the requested information listed above in "Reporting a Bug" and the specifics of the report.
  • When in doubt, ask on the ML.

[edit] Understanding Ticket Status

As the ticket evolves throughout its life cycle, it can have the following stati:

  • New: All tickets are born with the New status. Moreover, if a user has made a change to a ticket and want to draw triager attention, he will reset the status to New. This is particularly important for tickets with status Incomplete that risk to expire if not reset to New. Try not to leave a New status after looking at a ticket, unless you are completely clueless about it. Set it to Triaged if you tagged it, verified that it is not Incomplete or Invalid.
  • Incomplete: Triagers will set the status to incomplete if information is missing / expected from the reporter, or if the contributed patch requires some extra work. Usually they will post a note detailing what information is required. If there is no further activity within 60 days, the ticket will expire. It is important that whoever completes / adds to the ticket set the status again to New, to draw attention to the extra information. An email warning is sent a few days before expiry.
  • Opinion: Before setting the status to Opinion a triager will check if it is possible to accomodate the wish, e.g. with a preference. But sometimes things are just too far fetched and Hugin is not an [1]. Please respect it if one of your ticket has been marked as an Opinion and don't start a flame. If you mark a ticket as an Opinion make sure to provide alternatives / justification (e.g. list alternative tools that are better suited to solve the problem described). Use sparingly.
  • Invalid: A bug is set to Invalid if it was filed against an older version and is no longer applicable; or if the problem is not in the code; or if the contributed patch will never be accepted.
  • Won't fix: The behavior is known, but for some reason it won't be fixed, e.g. the code causing it has become or will become obsolete in a subsequent release, or the bug is just an annoyance that would take too much effort to fix. Or the behavior is "odd" to some people, but useful for others.
  • Confirmed: It's on our radar screen. we know what needs to be done in the code, but there are no resources to tackle it yet. This is also the status to give to ticket with contributed patches.
  • Triaged: Somebody has been looking at the report but it is still work in progress and we don't know yet what the next step will be other than looking at it again. At least it has not been declared Invalid yet.
  • In Progress: A developer has started to tackle the issue.
  • Fix Committed: A fix has been committed to the repository. users with access to bleeding edge builds can test it and confirm if the fix worked or not. If the fix did not work, report it and set the status to new again.
  • Fix Released: The fix is part of a release. If users using stable versions after that release find the error again, they can change the status to New and report that the fix did not work.

[edit] Bug Validation

Every user can validate a bug against their system / software and add a comment to validate the bug. We encourage all users to do so. The more validation information we have, the better. We need to narrow down whether a bug applies to a specific operating system or across the board. And it is also very useful to know if a bug applies to a specific context or if it applies also in different contexts.

  • To validate a specific bug, simply try to reproduce it by following the instructions described in the ticket.
  • Add a comment to the ticket reporting your observation.
  • Were you able to reproduce the bug?
  • It is important to add context to your validation: what operating system? what version of Hugin?


[edit] Bug Fixing and Testing

Everybody is encouraged to provide fixes and patches to correct bugs. Only developers can add them to the repository. Write access to the repository will be liberally given to users who need it.

  • when a developer fixed a bug, he can ask the ML for testing.
  • a fix tested on the developers system only can be set to Pending status.
  • when at least one user validates a fix on a different system and there are no reports that the fix does not work, the bug report can be closed.


[edit] Triaging Policy

  • The more complete a bug report, the more attention it is likely to get.

[edit] Importance

  • Members of the Hugin Bug Hunter team can set the importance of a bug.
  • You can indicate that a bug is important to you by hitting the "affect me too" button.

[edit] Ticket Assignement

  • The tracker enables the assignment of a ticket to a person. It is considered rude to assign a ticket to somebody else without their prior consent. Developers sometimes assign a ticket to themselves to signal they are working on it, but we do not use this feature too often.
  • The tracker allows the subscription of somebody else to a ticket. You can do so once if you think a person should be aware of a ticket. Then add a note to that ticket and the person concerned will receive it in her mail. But if the person decides otherwise and unsubscribes from the ticket, please respect it.

[edit] Tips & Tricks

If you know the old SourceForge bug number (e.g. form a comment on a migrated ticket), you can find it at the URL

 https://bugs.launchpad.net/bugs/${name}

So, for example https://bugs.launchpad.net/bugs/sf-2789151 (referenced at https://bugs.launchpad.net/hugin/+bug/679170/comments/5) will redirect you to https://bugs.launchpad.net/hugin/+bug/679179

Personal tools
Namespaces

Variants
Actions
Navigation
tools
Tools