Please create kubernetes/klog (for forking glog)
dims opened this issue · 25 comments
New Repo, Staging Repo, or migrate existing
Import https://github.com/dims/klog into kubernetes org
Requested name for new repository
klog
Which Organization should it reside
kubernetes
If not a staging repo, who should have admin access
If not a staging repo, who should have write access
@tallclair @justinsb, @erictune @lavalamp
If a new repo, who should be listed as approvers in OWNERS
@tallclair @justinsb, @erictune @lavalamp @dims @thockin
If a new repo, who should be listed in SECURITY_CONTACTS
What should the repo description be
Leveled execution logs for Go (fork of https://github.com/golang/glog)
What SIG and subproject does this fall under in sigs.yaml
sig-architecture
Approvals
Please prove you have followed the appropriate approval process for this new
repo by including links to the relevant approvals (meeting minutes, e-mail
thread, etc.)
Discussion in sig-arch on Oct 25, 2018 ( http://bit.ly/sig-architecture )
Authoritative requirements are here: https://git.k8s.io/community/github-management/kubernetes-repositories.md
tl;dr (but really you should read the linked doc, this may be stale)
- If this is a core repository, then sig-architecture must approve
- If this is a SIG repository, then this must follow the procedure spelled out
in that SIG's charter
Additional context for request
Any additional information or context to describe the request.
/area github-repo
Also started an email thread in sig-arch:
https://groups.google.com/d/msg/kubernetes-sig-architecture/wCWiWf3Juzs/hXRVBH90CgAJ
/lgtm
Are we still intending for this to be a transitional step towards our logging end goal? If so, can we call that out in the description & readme, and discourage others from using this? My concern is that as soon as we put out a "kubernetes-log" repo, other projects will start cargo-culting it...
Along similar lines, I wonder if we should stick with "glog" for the name? It further emphasizes that this is a fork of glog, and not a new kubernetes-endorced log library. It also means fewer lines need to be touched in the migration.
hey @dims, can you ping me back on this when consensus at sig-arch has been achieved? Then I can coordinate with you on a repo transfer.
Will do. thanks @cblecker.
I am going to assume @thockin and @tallclair are approvers on the plan from @kubernetes/sig-architecture-feature-requests
/sig instrumentation
@kubernetes/sig-architecture-feature-requests @thockin @bgrant0607 @tallclair @justinsb sig-arch folks, please +1 this request
/lgtm
/lgtm
/lgtm
Very interested in seeing this happen -- Minor note about glog vs klog, klog sounds a lot like clog which is perhaps not the greatest association for logging? :^)
If we are just doing a glog fork, k8s.io/glog might be good enough and easier to swap with dep etc.
@dims thoughts on @BenTheElder's comment?
/lgtm
/approve
@BenTheElder @thockin klog gives us some wiggle room which can be valuable. we can still use dep + wrapper over klog ( like https://github.com/dims/glog-minimal ) when needed. So let's go with klog for now please.
@dims So this isn't going to be a staging repo, right? Just moving over your existing fork? If so, can you please add me as an admin of the existing repo.
/lgtm
/lgtm
/lgtm
I like the idea of putting the glog-compatible interface under k8s.io/klog/glog, so that 1) only the import lines need to touched, and 2) it is easy to tell which files have been migrated to the new logging interface (once we get to that).
@tallclair affirmative! will do
This is moved into https://github.com/kubernetes/klog . Haven't fully finished all the automation pieces, but it's in progress :)
hm, so we forked glog in https://github.com/kubernetes/klog, but forked yaml in https://github.com/kubernetes-sigs/yaml. 🤔
@dims @cblecker what was the reason for the separate orgs for these brand new forks?
@neolit123 that was my call. klog's initial sponsor was sig-arch and the code was coming from a trusted org so i felt it was ok to bring it directly into the main kubernetes org. the yaml one was coming from a personal github repo (ghodss) and it was coming in under sig-api-machinery, so it seemed better to leave it under kubernetes-sigs.