1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Bug tracker details

From jedit

Jump to: navigation, search

Main purpose of a bug tracker is to describe software errors, so that developers could fix them. In a perfect scenario we have only 2 phases of work: a bug open and a bug fixed and closed. Many times things get complicated and that's why we need all those statuses and resolutions.

Our issues database is quite big, so we need good facilities for sorting and qualifying them. Categories, groups and priorities are used for this purpose.

Bug reports should be shortest possible, but at the same time should make sure that a developer is able to reproduce a bug. Therefore we put here #Bug report requirements, to make it easier for you to submit sufficient bug reports. Please also have a look at the #Rules.


Bug report requirements

Mandatory things

Think of a few words that will describe the issue, make it different from others and recognizable. When referring to a plugin, give its name and a colon at the beginning of the summary.
Say what you do and what goes wrong. Sometimes it's obvious how the software should work, but it's preferrable to describe also the desired behaviour, that is what you expect from it.
Operating system, Java version, jEdit version
Type it manually or copy first lines from the #Activity log. jEdit versions older than the current stable are usually not supported.

Optional information

Sometimes it is desired to provide also:

Plugins used
With their version numbers. This is mandatory for bugs regarding plugins. Plugin versions may be read from: Plugins / Plugin Manager / Manage (tab).
Java Look and Feel
Detailed step by step instructions to reproduce the bug
Here is an example:
  1. Download jedit daily 2012-01-16 and install it into a new directory
  2. Run it with new settings dir (see #Isolating the issue)
  3. Download plugins ProjectViewer 3.2.0 and TaskList
  4. Replace TaskList with svn version
  5. Have PV docked at the left, and TaskList at the bottom. Both should be active.
  6. Create 2 projects: A and B. A contains 1 file test.txt, B contains 1 file test2.txt. Fill both files with 2 lines of text.
  7. Choose project A
  8. Choose project B - notice files closing and opening with project change
  9. Choose project A again

Diagnostic tips

Activity log

Utilities / Troubleshooting / Activity log.

Log starts with lines like:

19:22:46 [main] [message] Log: When reporting bugs, please include the following information:
19:22:46 [main] [message] Log: java.version=1.6.0_22
19:22:46 [main] [message] Log: java.vm.version=17.1-b03
19:22:46 [main] [message] Log: java.runtime.version=1.6.0_22-b04
19:22:46 [main] [message] Log: java.vendor=Sun Microsystems Inc.
19:22:46 [main] [message] Log: java.compiler=null
19:22:46 [main] [message] Log: os.name=Windows XP
19:22:46 [main] [message] Log: os.version=5.1
19:22:46 [main] [message] Log: os.arch=x86

From the rest of the log paste to the description only the relevant lines. The full log is sometimes very helpful, but then it should be submitted as an attachement instead.

Freezes - thread dump generation

For freezes, run jEdit from the command line (with java command), reproduce the freeze, and press CTRL+Break on Windows or CTRL+\ on Unix. Include the information given in the bug report.

Isolating the issue

To isolate the issue it is recommended to:

  1. Install jedit to a new directory. Tests on latest version are most welcome, for example from daily builds.
  2. Run it specifying new settings dir:
    java -jar jedit.jar -settings=a_new_dir
  3. Install minimum number of plugins required to reproduce the bug


It seems that one must manually grant each developer admin/tech rights (the ability to assign/be assigned tickets) for each tracker. If you are a developer and find yourself lacking in tracker permissions you might want, just ask one of the admins to give you permissions on that tracker(s). It's nothing personal if you were not added yet.


If a developer is assigned to an issue, it means he will try to find the time to work on it. We can expect him to fix the issue in a given time. If the time is not specified, we may assume it depends on the priority in a following way:

Priority 1 2 3 4 5 6 7 8 9
Time 12 months 6 months 4 months 3 months  ? 2 months 1 month 2 weeks 3 days

After this estimated time has passed and there's no new comment, it means that the developer rather ditched this entry and he should be unassigned.

Developers: Assign yourself something you are working on, and un-assign yourself if you are not. Assignee acquires a lock on the bug. No one should work on the bug without discussing it first, to avoid duplication of work which is resource wasting.

Users: Don't assign a developer manually.


Bug submitter should usually not change the default priority value, 5. He may lower it if that's his impression, but leaving default value of 5 will draw developers' attention, which they will have to change to some other value.

A harmless bug, hardly noticeable. This priority is suitable for bugs that were discovered through thorough examination. Such bugs will be fixed only by the way, during work on the given area.
An inconvenience or an easy workaroundable bug.
A bug that is not very important. It may regard only to part of users or have a workaround. This is a priority below the default, so if the resources are low, developers will not try to fix it.
Default value. Unknown priority. After developer's consideration it must be changed to some other number. It will mean that the bug was categorized and will wait in the queue for solution.
A bug that may have negative influence on the jEdit reputation to majority of users. If the resources are sufficient, it should be fixed in current repository before branching a new release.
A serious bug that must be fixed before the next release.
Must be fixed immedietaly. If possible call the maintainer!

Other priority values are possible, by subjective judgement.

Developers will take responsibility to fix bugs of priority above 5. Other bugs will be usually fixed by submitters or volunteers. Anyone is always welcome to fix a bug regardless of its priority and may expect help from the developers. But the patches must meet our standards. For sending patches see our Creating and submitting Patches section of the Development page.

Although the above mentioned values refer to bugs, similar criteria should be applied to the priority of patches and feature requests.



The issue needs work from the developers. It is either new or the information given is complete and limited time of the developers is the only obstacle to fix the issue. New issues have the default #priority, 5. A different priority value means that the issue is already confirmed and analyzed.


The ball is in the submitters court. Developers set this status, because they need some additional info. Without this info the work on the bug cannot proceed. It may happen for example if the bug report was incomplete (see #Bug report requirements) or developers are not able to reproduce the bug for some reason. Pending status means that the issue will be closed if the requested info is not provided. Resolution is set to such, which would be a reason to close the ticket. Resolutions for this status are the same as for the #Closed status.

There used to be a creature signing itself as sf-robot, which was closing pending tickets automatically, after 14 days (configurable). No one knows where he's gone and currently developers do his job manually.

Users: After supplying the information change the status back to Open. You may also modify the Resolution then.


The bug will not be worked on. Reasons may vary and resolution explains it. In the ideal case the resolution is Fixed. It should never be None for closed entries.

Developers: Don't check the box Close comment posting unless you have serious reasons for that. Let's leave the user an opportunity to comment on the ticket, if he is sure that it needs further work.

Users: Commenting on closed tickets sometimes automatically re-opens them, so please do it with care and check the bug status after posting a comment.


Such a bug report is not actually deleted, but only marked as deleted. When searching for bugs one will not search for bugs with "Deleted" status. This forces the criteria for deleting a report: this report carries no useful information for anyone interested in project bugs or issues. Either it is not at all a bug report (spam, complain, discussion) or is an exact duplicate of some other entry.


The resolution complements bug status information. Resolutions are divided into two parts: for open and for closed (or pending) status. Sometimes closed resolutions may appear in open status as a signal that it looks like a possible option to close the ticket.

Resolutions for open status


The solution for this bug is postponed for undetermined time. The reason is given. It may be for example that the current maintainer is not interested in solving the bug or implementing the feature. Volunteers may step forward for such entries.


The initial phase of working on a bug.


The solution for this bug is postponed until some circumstance is fulfilled. Happens if solving another bug is required to work on this one.


The developer asks for additional info from the submitter, but this time there is no threat of closing the issue, which happens in pending status. The information from the user will be helpful and will shorten the process of fixing the bug.

Resolutions for closed status


Used in the patches tracker, not in the bug tracker.


A comment points to an entry that describes the same issue as the current one.


The bug is fixed in the repository. Currently there is no an easy way to find out, in which earliest version the bug is fixed. All branches made after the date of the fix will have the bug fixed. If there were also merge requests for this bug, then it will also be fixed in earlier versions. Merge requests are posted to a dedicated tracker, but I guess it's rather hard to find a specific bug there. There is a chance that searching for a bug number (with and without a # prefix) will do.

List of branches: www or a command: svn list https://jedit.svn.sourceforge.net/svnroot/jedit/jEdit/branches

Creation date of a branch: svn log --stop-on-copy https://jedit.svn.sourceforge.net/svnroot/jedit/jEdit/branches/4.5.x | tail -2

Latest branches were created: 5.0.x r21781 2012-06-10, 4.5.x r20110 2011-10-18, 4.4.x r18761 2010-10-10, 4.3.x r16589 2009-12-02


Not a bug at all or not a bug in jedit.


The solution for this bug is postponed for an undetermined period time. The reason is given, which usually would be that the component is unmaintained. This resolution may be found both in open and closed entries. If it appears under a closed entry, it is rather unlikely that it will ever be addressed. However it's possible that a volunteer steps up to maintain the abandoned component. Then they would pick up all latered entries.

Out of date

The entry is not applicable to currently supported jedit or plugin versions. Older entries are frequently closed this way, when the developer discovers that the bug was fixed some time ago and the error is no longer reproducible. Another example is a bug or feature regarding a component that is no longer maintained.


Used only in the patches tracker.

Wont fix

For some reason the bug won't be fixed, although is reproducible.

Works for me

Developers' tests show no errors.


Only the user who submitted the tracker ticket and project members with sufficient rights are allowed to attach files to the tracker ticket, as described in sf ticket #13459. So if you are another user you may post a link and tracker admins can add it as a direct ticket attachement.

Alternatively you may use Sourceforge Developer Web. It's an individual web site available to all users*. After ftping a file to this space, the link looks like this: http://jarekczek.users.sourceforge.net/test.txt. By posting such link you may circumvent a limitation for an attachement size. And finally the file resides on the same server, so it's very close to posting as a direct attachement.

  • Maybe not really all users, but all developers, that is members of any project. If you are not a member of any project yet, you may create a new project or ask to become a member of jedit. There's no problem with it.


For submitters

  1. Search before submitting a bug entry. Maybe it is already contained in the database. We know that the sourceforge tracker's searching is not as good as it should be. It's not possible to search on the summary field and whole text is searched instead. We are thinking about improving that. Anyway, give it a try.
  2. Don't create bug tracker entries for things it is not designed for. We will be glad to hear your opinions and constructive complains, but please do it through the jedit-devel mailing list.
  3. Discussion should be limited to technical information strictly regarding the issue. Relaxed posts or subjects that have broader meaning than just the current entry should be sent to the mailing list.
  4. Rather don't say thank you. We are grateful for all the bug reports. If a bug gets fixed, that means we considered it important and we are even more grateful for such bug reports. So instead of thanking each other in every bug entry, let's omit it at all. If you notice an unusual effort on the side of a developer, you can always leave him a message (clicking his nick) or post to the mailing list.
    Sometimes a tracker is configured in such a way, that a comment to a closed issue reopens it. So it must be closed again. And every tracker action is forwarded to the mailing list which may produce unnecessary traffic.
  5. Don't join different issues in one report. It's better to diagnose and fix one bug at a time and close it then. Joining is possible if issues are so closely related, that they should be fixed at the same time.
  6. Problems with openId accounts. Actually this is not a rule but a hint. OpenID-only accounts are handled somewhat strange by sf and it looks best to integrate them with a plain sourceforge user account, as described in sourceforge ticket 21829. If you don't integrate, we are unable to get your username or real name (sf ticket 23990). We use it to credit the people who help the project.

For developers

  1. When you are not able to reproduce a bug, supply all the environment details that are usually requested from the submitter. Even if the submitter didn't provide them.


Currently, our tracker does not support voting. We need a new tracker. It should support votes. Registered SF.net users get 5 votes, Members of jEdit developer project get 20 votes, and admins get 50. If a ticket is closed with X votes, those X votes then go to the assignee of the ticket for voting on other tickets.

Until then, you can add comments to the tracker with more useful information, as a substitute for voting.

For feature requests, find or create and vote on the corresponding issue in http://jedit.uservoice.com. Add a link to it from the sf.net tracker so others can find it too.
For bugs, "I can reproduce too, using jEdit XXX and plugin YY and ZZ. but I need setting DDD checked."
For patches, you can test it yourself and then post a comment (if you are not a committer): "I tested this patch and it works!" or if it didn't apply/work, mention that and how/why it doesn't.

Other info

  • This is the universal tracker entry link: http://sourceforge.net/support/tracker.php?aid=XXXXXXX. To make it even shorter use sf.net server address.
Personal tools