Tag DataValues.jl v0.0.2

[attobot]

Repository: davidanthoff/DataValues.jl
Release: v0.0.2
Travis:
Diff: vs v0.0.1
requires vs v0.0.1: no changes
cc: @davidanthoff

Please make sure that:

• CI passes for supported Julia versions (if applicable).
• Version bounds are up to date.

[MikeInnes]

Thanks for the tag! A maintainer will check for issues and then merge the PR. Alternatively you can reply with +ready to do so yourself.

[davidanthoff]

+ready

[tkelman]

Mike, what happened to #9256 (comment)

I'll wait for package CI to go through.

[MikeInnes]

That was for insta-merging – if package maintainers are choosing to ignore CI that's another issue.

Looks like this package is in an early state; if a maintainer wants to choose flexibility over absolute robustness for users at that stage, why should we have a right to overrule that?

[davidanthoff]

I tried this because I saw the option and was curios (and also pretty sure I'm the only user of this package).

But I'm not a fan. I think there should be no option to merge something without a successful CI run. I would even prefer an automated system that doesn't allow registration and merging of tags if there isn't at least travis and appveyor configured, and say a minimal code coverage or something like that.

If folks have package that don't have these minimal quality standards, they don't have to register them, that is what we have cloning for.

I always felt @tkelman's reviews were a lot of work, but also quite key until we have more of this automated. Yes, sometimes the reviews were annoying, but in the end I felt it was for the better of the ecosystem, so I'm for one quite thankful for those.

[MikeInnes]

When JuliaRun CI is up and running I will certainly require that, so I think that addresses the issue.

[tkelman]

It was running earlier today.

For context, xref #9256 #9261 #9270 #9301 attobot/attobot#31
we're arguing a lot, but we're not compromising at all.

[tkelman]

I want to automate all the optional quality linting and test checking, and we have some new tools and systems that are starting to make that feasible. The part that can't entirely be automated is "will this break metadata or do something obviously harmful" due to strange requirements and bounds or a risky build script. That has mostly been a judgement call from doing this for a few years and keeping a close eye on how bounds work and how packages influence each other on pkgeval, ci, etc. If we can automate everything else, I can summarize the risks and consequences and ways in which requirements can do counterintuitive things with version resolution so the last manual bit has a higher bus factor.