Canonical repo address is inconsistent with go import path

[KateGo520]

The github.com/directxman12/k8s-prometheus-adapter repo was just renamed to github.com/DirectXMan12/k8s-prometheus-adapter
This means that the canonical github repo address now conflicts with canonical go import packages (for example, "github.com/directxman12/k8s-prometheus-adapter/pkg/client", as referenced from https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/v0.7.0/pkg/client/fake/client.go#L23)

It is now very easy for downstream consumers (which don't import "github.com/directxman12/k8s-prometheus-adapter/..." packages) to accidentally clone and add imports to upper-case "github.com/DirectXMan12/k8s-prometheus-adapter/..." packages. This will create many pitfalls and break the module users. They may encounter errors:

go get: github.com/DirectXMan12/[email protected]: parsing go.mod:
        module declares its path as: github.com/directxman12/k8s-prometheus-adapter
                but was required as: github.com/DirectXMan12/k8s-prometheus-adapter

(This was possible before, but way harder to do accidentally, since all the links and clone commands from github agreed with the canonical go import packages)

Cautionary tale:

• sirupsen/logrus#570 (comment)

Please consider reverting the directxman12 -> DirectXMan12 rename.

If the case change is here to stay, some things that would help a lot:

1. Example go get github.com/directxman12/k8s-prometheus-adapter commands or others in the READMEs of all the go repos to guide consumers.
2. Add canonical import paths with the correct case (https://golang.org/doc/go1.4#canonicalimports) to prevent accidental use of the wrong case downstream.

[KateGo520]

@smarterclayton @sergii-koshel-exa Could you help me review this issue? Thx :p

[s-urbaniak]

We are planning to move this repository into a more kubernetes canonical organization. Once this happens the issue should resolve itself.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.