TC Bugtracker needed or not?

I would like to ask, maybe it’s worth close the bug tracker? TC is free software, and no one no one should, why should give hope to the rescue?

For example, this ticket hanging 2 months, the crash occurs in many people every day and there was no response. Dear developers, at least be honest, if you do it will not be fixed close the ticket.

And do not be offended at me, you a huge thank you from all your users.

agree with Alexey

I am just wondering why crash reports with BT full have low priority for TC, I think every crash should have high priority, one man make accidentally crash in source code and noone solve it for months

Basically, we’re doing this on our spare time - and to put it this way : try updating to the last core-revisions and see if this occurs again.

And yes, the tracker is needed (and used)…

If you actually look at the reports on that issue, it holds NONE of the required informational fields that we need - here’s a direct copy of the info on the tracker :

Before you file an issue

  • Search through the existing issues to avoid duplicate reports (duplicate reports are bad).[/li][li]If an already existing issue on the subject exists, append information to it (as described in the next section).

When you file an issue

[ul][li]Add which revision of Trinitycore you’re running on (CORE revision, not client version)[/li][li]Add which database, and what revision, you run on[/li][li]Add a list of which modifications that has been done to the core (if any)[/li][li]Supplement your crashreports with backtraces[/li](issues reported as a crashreport and not having a backtrace attached will be deleted on sight)
[/ul]

DO NOT DIRECT-PASTE CRASHDUMPS INTO THE COMMENTARY FIELD - USE ATTACHMENTS

Example:

CORE revision number : 45459bed23b7
Database: TDB 335.11.36
Patches: None

The above is VERY important, so add this when reporting.

Attachment requirements

  • Patches : MUST be attached as a file in diff/patch format[/li][li]SQL-files : MUST be attached as a file[/li][li]Do NOT paste patches/SQL-files into the tracker as regular text in the commentary field[/li][li]Make sure the diff/patch uses CORRECT PATHS (no subdir diff of a random directory on your machine)[/li][li]When multiple diff/patch/sql-files are involved, or require more than 4-5 files to be uploaded, consider attaching it as an archive ( .zip file )

Important:
The tracker issues can not be “bumped” - the only thing you do is add noise to the issues you attempt to bump.

Some additional information

  • Make sure you are running on the latest revision of the source (we are constantly pushing changes, so your issue might have been resolved already)[/li][li]When testing for bugs, make sure you are NOT running a modified core (test without ANY custom patches at all, even if it’s just a tiny textchange)[/li][li]Don’t ask when something will be fixed (it will be sorted as fast as we can, or when someone has the time to look at it)[/li][li]Don’t claim that your issue is “very important” (every issue is equally important to us - the only exception is when it crashes the core AND have a proper crashdump attached)[/li][li]Don’t claim that a change “makes function XXX unusable/unplayable” (give a FULL and DETAILED report)

I don’t every play private servers myself so it’s sometimes hard too keep up with whats bugged or not if people doesn’t report the problems.

BOLD is MISSING

* Add which revision of Trinitycore you’re running on (CORE revision, not client version)

[B]

  • Add which database, and what revision, you run on[/B]


*Add a list of which modifications that has been done to the core (if any)


*Supplement your crashreports with backtraces

(issues reported as a crashreport and not having a backtrace attached will be deleted on sight)

Some additional information

  • Make sure you are running on the latest revision of the source (we are constantly pushing changes, so your issue might have been resolved already)

  • When testing for bugs, make sure you are NOT running a modified core (test without ANY custom patches at all, even if it’s just a tiny textchange)

  • Don’t ask when something will be fixed (it will be sorted as fast as we can, or when someone has the time to look at it)

  • Don’t claim that your issue is “very important” (every issue is equally important to us - the only exception is when it crashes the core AND have a proper crashdump attached)

  • Don’t claim that a change “makes function XXX unusable/unplayable” (give a FULL and DETAILED report)

agree! =)

you know what would be great. To have many users verify the many bugs in the tracker and see if they still happen. This will help a lot.

ZxBiohazardZx

I added the necessary information in the ticket. But I wanted to draw attention not to a particular ticket and the ineffectiveness of the tracker. I’m not a programmer, but really want to help in the development of the TC. Maybe we should really ask such a proposal to the community? http://www.trinitycore.org/f/index.php?/topic/2151-tc-bugtracker-cleaners/

You just tell me and there will be people who will assist in the best of my ability.

Please click this link if you believe the tracker’s presence is in vain.

If you’re not content with the time in which an issue is resolved, roll up your sleeves and do the dirty work yourself. Or, as others posted before me, at least try to follow the tracker guidelines before posting in it.

Wouldn’t you like that, having the TC dev team at your service