a) A package doesn't need to be in the stdlib to have more than one
maintainer. If you believe go-yaml needs more maintenance, you can either
ask Gustavo to give more people push-access, or create a better-maintained
fork. There are tons of go projects out there that are well-maintained by a
vibran
Anybody can write a spec and deem it a standard.
YAML is certainly not a common data serialization format. Adding a YAML
parser is in my opinion the least of of Go's priorities when one can see
all the packages pilling up @ /x/ namespace that should have been in the
stdlib already. More tools s
On Fri, Sep 23, 2016 at 5:02 PM, Zachary Gershman
wrote:
> Gustavo - it is not jus that YAML is well known, it is also widely used
> (as I even mentioned). It is a *standard *even though some may not want
> to consider it as such. If I can read xml in the stdlib why not yaml? And
> it is widely s
Gustavo - it is not jus that YAML is well known, it is also widely used (as
I even mentioned). It is a *standard *even though some may not want to
consider it as such. If I can read xml in the stdlib why not yaml? And it
is widely supported now but are you committed to supporting it for as long
Hi Zachary,
You have already seen the thread, but for the benefit of others, Zach's
email comes from a thread raised and replied to yesterday on Twitter:
https://twitter.com/jvehent/status/778687333956587522
As I said there, the yaml spec is big, messy, and I wouldn't encourage
having the packag