> Because we manage such a vast quantity of open tickets
> It is not reasonable to test all 4,000 tickets

That should alert the people at Mojang as it shows they are incapable of good bug management. Developers should fix known bugs BEVORE doing new releases. If every bug would be fixed the time it is reported, there weren't so much tickets and there would be nothing old to test after releasing new versions.

When bugs are handled the way they are currently handled, they will almost never be fixed and this tracker is just useless.

There are always better ways to manage a system, however the fact remains true that this system is light years better than it was prior (using a Wiki to manage bugs...) to this being set up.

> You're suggesting fixing 4000 bugs before next Wednesday.

I suggest releasing things when they're done. Which not means next Wednesday. Stable versions should be, well... – stable. That means not contain any known bugs.

Ok

I suggest releasing things when they're done. Which not means next Wednesday. Stable versions should be, well... – stable. That means not contain any known bugs.

Then there'd probably never be another release. Most people would rather have some bugs fixes as soon as possible, rather than waiting for them all to be fixed. And lots of people would rather have new features than fixes for bugs they've never personally encountered. That's why almost any major software project will release with hundreds of known bugs. Unless it's a mission-critical, lives-are-on-the-line piece of software, the cost of that kind of rigor isn't feasible. Most companies just don't have public bug trackers, so it's harder to see how many bugs they are aware of.

Many of the bugs in Minecraft are the result of short-sighted implementation decisions early in its development. Minecraft was something the original developer hacked together in his spare time. He never expected it to become so successful, and didn't approach it with the kind of care necessary to ensure maintainability in the future. The current development team has thus had to spend a significant proportion of their efforts on restructuring the code and replacing large chunks of it, sometimes from the ground up. Many bugs are fixed simply as a result of this process, without the development team even being aware of the bug in the first place. This bug tracker is not the primary driver for most changes in the codebase.

Had Minecraft been developed responsibly from the start, things might be different. As it is, I don't think it's fair to blame the current development team for the situation they inherited. They're not working from a clean, well-structured codebase, in which it might be reasonable to address bugs as they come up. Instead, they're tasked with overhauling a fundamentally broken, buggy, fragile codebase, trying to replace one bit at a time without breaking the whole thing, while also adding the occasional new feature to keep people interested in new releases.

Regardless, it's Mojang's choice how to manage bugs and run this tracker. They have no obligation to be thankful for bug reports, or even to test, find, and fix bugs. And yet they are thankful all the same, and do spent a lot of time and effort hunting down and fixing bugs. They care a great deal about Minecraft. It's not just a job to pay the bills, it's something they're passionate about. They interact very differently with their community than most companies do, and much more directly. They chose to have a public bug tracker, and to involve the community in maintaining it. If that community didn't care, if they had that much of a problem testing bugs and maintaining reports, they wouldn't do it, and this tracker wouldn't see nearly so much activity. It's your own choice whether or not to be involved, but we don't have to put up with you dictating how the tracker should be run.

Has there been some development on this issue yet?
This is really nagging us...

Can someone please at last spend an hour coding a conformant server selection?
It's not like you need to invent wheels, the process is well documented.

Quoting grum from [MC-6941] (emphasis mine):

The SVR lookup was done using sun.* classes and would give huge timeouts for people who didn't use the Sun JRE. Now we check for the existance of the class used before we do the SVR lookup to prevent that. From this I can only assume you do not have that class and thus are not using Sun's JRE.

If you stumble upon a better way to do the SVR lookups feel free to let us know.

Here's the way that Minecraft is currently doing it (from net.minecraft.client.multiplayer.ServerAddress in MCP):

/**
 * Returns a server's address and port for the specified hostname, looking up the SRV record if possible
 */
private static String[] getServerAddress(String userAddress) {
    try {
        String s = "com.sun.jndi.dns.DnsContextFactory";
        Class.forName("com.sun.jndi.dns.DnsContextFactory");
        Hashtable<String, String> hashtable = new Hashtable();
        hashtable.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
        hashtable.put("java.naming.provider.url", "dns:");
        hashtable.put("com.sun.jndi.dns.timeout.retries", "1");
        DirContext dircontext = new InitialDirContext(hashtable);
        Attributes attributes = dircontext.getAttributes("_minecraft._tcp." + userAddress, new String[] {"SRV"});
        String[] astring = attributes.get("srv").get().toString().split(" ", 4);
        return new String[] {astring[3], astring[2]};
    } catch (Throwable var6) {
        return new String[] {userAddress, Integer.toString(25565)};
    }
}

I personally am not familiar with any part of JDNI or that related code, but maybe someone who does know it could explain what's wrong with the approach minecraft is using.

The apparent problem is that it missing a lot of code.
See https://tools.ietf.org/html/rfc2782 section "Usage rules".

This is annoying as I can't have failover servers that are only for failover.

Is this still a issue in the latest version of the game(currently 1.13.1)?

If so, please add it to the affected versions, thanks!

Were anything changed in the relevant code? No? Then of course this is still an issue.

Please reopen this as it is still an issue in the latest version of the game 1.14.1